Child pages
  • Good Practices for Requirements Management
Skip to end of metadata
Go to start of metadata


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 :

CharacteristicDescriptionHow 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. 
CompleteThe requirement is fully stated in one place with no missing information.-Specification
ConsistentThe requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.-Verification
AtomicThe 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 2The 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.
FeasibleThe requirement can be implemented within the constraints of the project.Defines an attribute.Determines the business / technical feasibility.
UnambiguousThe 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.
MandatoryThe requirement represents a stakeholder-defined characteristic, the absence of which will result in an unacceptable deficiency.-Specification
VerifiableThe 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 

PracticeDescriptionHow 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 :

  • User Intent & Needs
  • Product Requirements
    • Architectural Requirements
    • Functional Requirements
    • Non Functional Requirements
    • ...
  • Process Requirements
  • ...
Provides mechanism to build a hierarchy and define interdependencies between requirements.Organize as per this intent.
Architecture DesignSince 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.
  • Build a separate category of Architectural Requirements.
  • Consider all possibilities of Non Functional requirements and make sure that the architecture can address all of those.
Requirements sharing with the teamSharing 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 BaselinesAchieve universal consensus on the Requirements, including all stakeholders. Subsequently, create a Baseline for a set of agreed upon requirements.

Provides functionality to

  • Mark for Baseline
  • Create Baselines
  • View Baselines
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 CriteriaDefine 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 !!!

  • No labels