Hierarchical Classification of Requirements

Introduction

Many users face situations, where hierarchical classification of Requirements is required. This means that

• There is a fixed Hierarchical Structure for organizing Requirements.
• Requirements exist at different levels of this hierarchy.
• Different set of users may have different perspectives; say functional or architectural classification.
• Users have need to view a set of requirements by filtering on different perspectives and options; for example a specific user may want to view all Requirements belonging to a specific Component.

 Custom field of type Hierarchical View can provide one possible solution for this problem; as explained in the following sections.

Defining Custom Field of type Hierarchical View

Custom Fields of type Hierarchical View can be created at the

• System Level
• OR Project Level

The Field Options configured for this custom field are essentially labels organized in a hierarchical format as shown below.

Multiple Perspectives

This kind of classification helps in defining multiple perspectives on the same set of Requirements. A user can choose the perspectives relevant to him / her.

In the example below, two perspectives are defined

• System Hierarchy
• Spec Classification

User Views

A user can

• Enable only the perspective relevant to him / her, while there may be many perspectives defined in the system.
• Select the labels (using filter functionality) to narrow down the list of relevant Requirements. For example, a developer may be interested only in the Specifications of a specific Component.

Limitations of Hierarchical View

1. This mechanism may not be suitable, when the hierarchy is very large, say of the order of 1000's
2. Since the options are defined by Administrator and cannot be dynamically created by end user; this solution will work only when the updates to the hierarchy are not very frequent.
3. It may not be possible to restrict the permissions for a subset of requirements.