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
- This mechanism may not be suitable, when the hierarchy is very large, say of the order of 1000's
- 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.
- It may not be possible to restrict the permissions for a subset of requirements.