Requirements Management

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

 

Requirements Management comprises seven major elements and how these are to be handled can be outlined in a Requirements and Acceptance Management Plan (RAMP) :

  • Elicit and capture stakeholder/user requirements, both functional and non-functional,
  • Flow down the stakeholder requirements into system requirements, translating them from qualitative everyday language into quantitative technical terms, and then down to the sub-system and component level. Note one way of doing this is to use QFD (Quality Function Deployment)
  • Document the requirements, often as a User Requirements Document (URD) and a System Requirements Document (SRD),
  • Cross-check and agree the requirements with the stakeholders
  • Develop a traceability matrix showing the flow of the requirements so that low-level requirements can be related back to user requirements.
  • Develop a Verification and Validation Plan to show how the various requirements will be verified and validated (sometimes called an Integrated Test, Evaluation and Acceptance Plan (ITEAP))
  • Manage changes to to the requirements and negotiate with the stakeholders / users as required.

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.

Requirements Engineering

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

MoSCoW

  • Must. Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. If even one MUST requirement is not included, the project delivery should be considered a failure MUST can also stand for for the Minimum Usable SubseT.
  • Could. Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. SHOULD requirements are as important as MUST, but are not necessary for delivery in the current delivery time-box, as long as they come along later.
  • Should. Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. Often seen as nice to have. A few easily satisfied COULD requirements in a delivery can increase customer satisfaction for little development cost.
  • Won’t (or Would, only if paid more or had more time). Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (Note: occasionally the word “Would” is substituted for “Won’t” to give a clearer understanding of this choice).

MK123 (as per MODAF*)

  • M = Mandatory (for example, legislative)
  • K = Key Requirement. Assume un-tradable without formal agreement of the URD owner. Trading will require re-submission to the IAC
  • 1 = A high priority requirement. Trading will require reference back to the Head of Capability (HoC) / Capability Working Group (CWG)
  • 2 = A medium priority requirement. Trading will require reference back to the sponsor
  • 3 = A low priority requirement. Trading can be decided by the Equipment Capability Desk officer

* MODAF = MoD Acquisition Framework

Trade-Offs

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’).

  • Threshold (Minimum Acceptable)

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. There is no point trying to be better than this.

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

  • INCOSE
  • MoD Acquisition Framework

and the following books:

  • INCOSE System Engineering Handbook
  • Requirements Management by Hood et al, pub by Springer
  • Requirements Engineering by Hull et al, pub by Springer

If you would like to discuss how to handle Requirements Manageemnt in your product development process, please contact us.