Requirement management
Responsible and proper development of software developments requires the presence of proprietary control process.
Identification of requirements
Unique requirement ID is used to refer to this requirement when creating dependencies or exporting/printing documents. By default, Devprom ALM independently assigns IDs to requirements in the form o R-NNN where NNN is a number. This identification is pass-through for all documentation registered in the system. This ensures uniqueness of ID and allows to use it to refer to the requirement.
You can use your own identification system based on your project, requirement type, and other requirement attributes. To do this, create a custom attribute for Requirement entity in the project settings. Value of attribute type must be "calculated field".
Specify a reference name UID in the custom attribute parameters. Thus, the application will know that this attribute is a calculated UID.
Enter an expression from the example description as the formula to calculate the requirement ID. Here are some examples of custom identification of requirements:
- {Requirement type.Short name,R}.{ID} - short name of requirement type will be specified in the beginning or requirement ID, e.g., СТ.123
- {Requirement type.Brief name,R}-{ID in project} - allows to make unique ID only within one project. Value of "ID in project" field is filled with the counter of requirement type. Counter of requirement type is increased by system automatically. Thus, you can receive the following IDs: BT-1, CT-1, etc.
If it's required, you can edit UID that was assigned for requirement automatically. To do this, open the requirement for modification and change value in UID field on Advanced tab.
Types of requirements
It's convenient to mark requirements with different purposes by different types. Use filters or groupings in the application to work on different types of requirements.. Each type of requirement can be matched with the corresponding default template. When creating a requirement, it will be used as a sample to be filled.
| Option | Purpose |
|---|---|
| Requirements are being implemented | Used in "Development based on requirements” scheme. Development tasks (enhancements) are not created based on business requirements. Enhancements are created based on functional and system requirements. To not confuse users, it's necessary to set proper value of this option for requirements of different types. |
| Requirements are being tested | Similarly to requirement implementation, not all types of requirements are used in the testing process. Set this option for those requirements for which you need to calculate the rate of test coverage. |
| Can be derived | You can establish causal relationships between requirements. Set this option to distinguish source requirements (e.g., business requirements) from derived requirements (e.g., functional requirements). |
| Identification of requirements is not used | Some document sections are not requirements by nature, however they form important context that is required to understand other requirements. Such sections may be necessary in terms of the requirements to documentation preparation. In built-in processes, use “Common description" type for such requirements. Identification of such requirements is not required. For example, when exporting to external formats, a requirement ID will not be added to the document sections. |
You can define a particular suite of custom attributes for each type of requirements.
Lifecycle
A requirement as the project solution (in business area or technical implementation area) passes through several evolution stages - it is developed (documented), refined (involving designers and testers), reconciled with customer, and then implemented in the source code.
Lifecycle of requirements in different projects or for different types of requirements may differ. Project team sets up lifecycle of requirements for their project independently. In "Development based on requirements" process, we have already set up some useful requirements, e.g.:
- Prohibition of modifying requirement text after its reconciliation. To edit text, return the requirement to stage "In progress" and specify source of modification - source issue, or modified business requirement.
- Mark about obsolescence of derived artifacts. In order to provide that every single change (up to a missed colon) will not lead to the obsolescence of test documentation (or other derived artifacts), we perform this operation only during the transition of requirement to state "Ready". Thus, restoring integrity of project documentation, we work directly with portions of changes.
You can use synchronous (cascade) modification of states of parent or child requirements to accelerate status control. For example, it's enough to reconciliate the root section (document header) during the document reconciliation, and all its subsections will also be marked as reconciled. Such synchronous operations are set up in requirement lifecycle by means of the corresponding system actions. Since it's a bulk operation, user can receive an unexpected result. To warn the user about execution of such operation, set the following flag when adding a system action:
Before performing transition or status modification, system will warn the user about the execution of system action.
Traces
Traces between requirements are formed by causal relationships and coverages. Traces are formed while working on project artifacts. You can create and edit traces manually on Traces tab.
Traces are used for the following purposes:
Completeness control
Tabular representation of dependencies between requirements of different types, e.g., between business requirements and system requirements, is called a traceability matrix. This tool allows you to:
- Control the integrity of product being developed, and identify differences between the required items and the items being implemented.
- Significantly reduce time spent for analysis of changes that will follow the appearance of new query from users.
- Maintain the derived requirements in an actual state.
Traceability matrix allows to answer the questions immediately:
- how exactly the source issues were taken into account, and when they will be implemented;
- whether all important issues were taken into account in the next version of business requirements or product version;
- where a business requirement came from, and what importance it has;
- how the business requirements will be implemented based on studying the system requirements;
- whether all the required business requirements are reflected in system requirements, etc.
To set up filtering in "Source requirements" or "Derived requirements" columns, use the button with dots.
Budget management
"Workloads by requirements" report shows planned and actual workloads providing the capability to estimate the budget overruns, or, vice versa, the free resources. Planned workloads (Estimate) are specified for each atomic requirement to be implemented. Actual workloads are calculated by the application based on development tasks, test tasks, etc.
Values on red background mean the budget overruns, values on green background - the presence of free resources. Use the report to determine a possibility to change requirements without the budget reconciliation.
You can detail planned expenses by requirements by decomposing requirements to tasks or enhancements. In this case, the report will contain the breakdown of planned workloads by type of work items.
When using "Project finances and budget management" module, you can view value of costs regarding time planned or spent by a project member. To do this, use "Expenses by requirements" module.
When creating a baseline, system stores values of estimation, costs and price. Thus, you can see changes of these parameters (in parentheses) between different document versions in comparison mode.
