Good Practices for Requirements Management
- Sanjay Sahani
Introduction
Today, despite making a significant progress in technology, majority of software projects still fail to meet the user needs, may it be in terms of cost, quality, timeliness or functionality. While the development tools and processes have significantly improved, we @ Optimizory believe that Requirements Management still remains a key bottleneck in the successful execution of projects. RMsis fills this gap with a user friendly interface and by focusing on a large set of small requirements, which can be iteratively analyzed and which closely map to the delivered product.
However, it is also true that in order to achieve results, the tool has to be complemented by organizational intent and the right set of processes.
In this article, we shall detail out our views about effectively managing Requirements, addressing many dimensions of Requirement Management, not necessarily the areas directly addressed by RMsis.
Key Assumptions
Requirements Management is based on accepting several key assumptions as reality as stated below:
- Software Projects are increasing in size and complexity and require effective mechanisms to manage this complexity.
- An iterative or evolutionary development approach is preferred today. Even in a waterfall model, requirements will evolve.
- Requirements will, emerge / change over the life of the project.
- Requirement attributes (criticality, priority, effort) will constantly change.
- Requirements drive the rest of the project lifecycle.
Characteristics of Good Requirements and their implementation
While writing a perfect set of requirements is very difficult, following a good set of thumb rules can greatly improve the quality of requirements. Moreover, the definition of "Good Requirements" greatly varies from author to author, but the following characteristics are generally acknowledged :
| Characteristic | Description | How it is addressed in RMsis ? | User's Responsibility |
|---|---|---|---|
| Unitary (Cohesive) | The requirement addresses one and only one thing. | Requirements are managed in Database; each one of them is identified by a unique Id. | Â |
| Complete | The requirement is fully stated in one place with no missing information. | - | Specification |
| Consistent | The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. | - | Verification |
| Atomic | The requirement is atomic, i.e., it does not contain conjunctions. | - | Specification |
| Traceable 1 | The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented. | Provides mechanism to reference the source of a requirement (link to the source document). | Â |
| Traceable 2 | The requirement should have forward traceability to and reverse traceability from other artifacts in the project. | Extensive forward and reverse traceability support. | Create the desired links. |
| Current | The requirement has not been made obsolete by the passage of time. | - | On receipt of additional information, verify for change in existing requirements. |
| Feasible | The requirement can be implemented within the constraints of the project. | Defines an attribute. | Determines the business / technical feasibility. |
| Unambiguous | The requirement is concisely stated without recourse to technical jargon and acronyms. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. | - | Specification |
| Mandatory | The requirement represents a stakeholder-defined characteristic, the absence of which will result in an unacceptable deficiency. | - | Specification |
| Verifiable | The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis. | Provides for Test Case mapping. | Need to specify the validation criteria in terms of test cases. |
Good Practices for Requirements ManagementÂ
| Practice | Description | How it is addressed in RMsis ? | User's Responsibility |
|---|---|---|---|
| Requirements Organization | Decompose the system to build a "Hierarchy of Requirements", clearly identifying the dependencies / relationships between requirements. A typical hierarchy looks something like the following :
| Provides mechanism to build a hierarchy and define interdependencies between requirements. | Organize as per this intent. |
| Architecture Design | Since functionality will change continuously, keep the architecture independent of functionality. It will really help in the long term. | Provision for clubbing of similar requirements under one head in the Requirements Hierarchy. |
|
| Requirements sharing with the team | Sharing of Planned Requirements across the team and ensuring their participation through reviews. | Built in collaboration mechanism. | Encourage building of common understanding and share intent across the team. |
| Requirements Baselines | Achieve universal consensus on the Requirements, including all stakeholders. Subsequently, create a Baseline for a set of agreed upon requirements. | Provides functionality to
| Include Baselining as an essential step in the project execution process. |
| Version Control of requirements | Provide for management of change control using versions of requirements. | Provides mechanism to commit versions (of requirements) and create new ones. | Use committed versions as a basis for next steps in the lifecycle. |
| Acceptance Criteria | Define acceptance criteria for each requirement. | Acceptance criteria can be implemented as a set of test cases mapped to a specific requirement. | Define the use the acceptance criteria as an essential step in validation. |
| Release Composition. | Map all Artifacts to Requirements and Releases. | Provides mechanism to map Requirements and indirectly map Artifacts and Test Cases to Releases. Maintaining this association is critical because this information will be used in futuristic releases to ascertain the progress and readiness of a release. | Ensure that the mapping to release is complete. |
| Test coverage of requirements. | Map Requirements to the Test Cases and ensure complete coverage. | Provides mechanism to map Test Cases to Requirements. | Ensure that the mapping of Test Cases to Requirements is complete. |
Good ! Why not best ?
Â
Because there is always a scope for improvement !!!