What is Requirements Management
According to INCOSE (the International Council on Systems Engineering), "Requirements management is the collection, analysis, and validation of requirements", but other organisations have slightly different definitions.
A requirement is a capability to which a project outcome (product or service) should conform. - Wikipedia
There is usually a hierarchy to requirements from Stakeholder Requirements (often called User Requirements in the defence industry), down to System Requirements and then once the system architecture has been decided, down to the sub-system and component level. Note - A Concept of Operations, or Use Cases / User Stories or a Product Idea should be in place first.
Requirements Management comprises seven major elements and how these are to be handled can be outlined in a Requirements and Acceptance Management Plan (RAMP) :
Note - The biggest challenge is often the identification of the set of stakeholders and then negotiating a set of requirements that all the stakeholders will agree to.
Some people use the term Requirements Engineering instead of Requirements Management, meaning the same thing as described above, or in some cases, meaning the development of requirements and the flow-down, but not the management of changes and negotiation with the customers. For this aspect they use the term Requirements Management.
Prioritisation of Requirements
Not all requirements are as important as each other, so it is useful to have a system of prioritisation. Several systems are in use, the 2 most popular are MoSCoW, used generally, and MK123, used in the defence industry
MK123 (as per MODAF*)
* MODAF = MoD Acquisition Framework
–An Effectiveness Envelope defines ‘trade-space’ within each requirement. The span of levels of functionality for each requirement are expressed as Threshold and Objective. Where there is no scope for trading, a single point value is used (i.e. no ‘envelope’ or ‘must comply’).
–The worst case value, beyond which there will be insufficient operational benefit to justify the requirement.
–Once set, the requirement or constraint may be traded down to their Threshold values but their satisfaction will be judged collectively.
•Objective, sometimes called the Target
–The best case value, beyond which there will be insufficient additional operational benefit achieved.
–Objective values should be determined and traceable to the Operational Analysis. They reflect, for individual requirements, the initial operational boundary beyond which a capability surplus would arise.
–As optimisation, trade-off and risk management progresses, an objective value could become unachievable, unaffordable or the cost of achieving it may not deliver Value for Money. As a result, it would be necessary to reduce the objective value.
For more information see the following web sites
and the following books
Questions or comments about this web site should be addressed to