In this blog, I continue my discussion on requirement attributes to focus on those attributes that help you to maintain your requirements.

In Part 1, I covered attributes to help define the requirement and its intent and attributes associated with the system of interest and requirement verification. In Part 3, I  address the attributes that can be used to show applicability and allow reuse. I will also provide some guidance on the use of attributes.

Note, while we do not expect everyone to use all the attributes listed, the attributes that we feel should always be included in your set of attributes are annotated with an asterisk “*”.

Attributes to help maintain your requirements

This set of attributes is used to manage your individual requirements and your requirements as a complete set. Areas of prime importance to management, in addition to the attributes discussed in Part 1, include attributes dealing with managing risk, managing change, ensuring consistency and completeness, and having insight into the status of requirement implementation by the design team. Managing risk is a key role of management as well as making sure the high priority and requirements critical to project success are tracked. Including attributes dealing with these topics helps management keep the project on track to success and manage change not only as it relates to individual requirements but change to the project like budget cuts and problems resulting in cost overruns and schedule slips.

Unique Identifier*: This is a unique identifier, which can be either a number or mixture of characters and numbers used to refer to the specific requirement. The unique identifier is not a paragraph number. It can be a separate identifier or automatically assigned by whatever requirement management tool (RMT) your organization is using. This identifier is used once and never reused. A unique identifier is also needed to link requirements in support the flow down of requirements (allocation), traceability, and establish peer-to-peer relationships. Some organizations include in the unique identifier codes that relate to SOI to which the requirement applies: e.g. [SOI]1234.

Unique Name: This is a unique name or title for the requirement that reflects the main thought the requirement is addressing.

Originator/Author*: Person responsible for entering the requirement into the RMT. (Note: when entering a requirement into an RMT, the RMT may automatically log the name of the person entering the requirement).

Date Requirement Entered: This is the date the author entered the requirement into the RMT. This date may be automatically generated by the RMT.

Owner*: The person or element of the organization that maintains the requirement, who has the right to say something about this requirement, approve changes to the requirement, and report the status of the requirement. The Owner could be the Source but they are two different attributes. The Owner maintains the attributes Requirement Verification Status, Requirement Validation Status, and Status (of requirement) – see below.

Stakeholders: List of key stakeholders that have a stake in the implementation of the requirement and who will be involved in the review and approval of the requirement as well as any changes to the requirement.

Change Board: The organizational entity that has configuration management authority to approve changes to the requirement and set of requirements it is a part.

Change Status: An indication that the requirement has a proposed change to it or the status of a proposed change.

Version Number: An indication of the version of the requirement. This is to make sure that the correct version of the requirement is being implemented as well as provide an indication of the volatility of the requirement. A requirement that has a lot of change, could indicate a problem or risk to the project. This could be automatically assigned by the RMT.

Approval Date: Date the current version of the requirement was approved. This could be automatically assigned by the RMT.

Date of Last Change: Date the requirement was last changed. This could be automatically assigned by the RMT.

Stability: An indication of the chances that the requirement will change. Some requirements when first proposed will have numbers that are best guesses at the time or the actual value is not readily available when the requirement has been entered into the RMT. The number may not be agreed to by all stakeholders or there may be an issue on the achievability of the requirement. Some requirements will have a to-be-determined (TBD) or to-be-resolved (TBR) in the requirement text. Stability is directly related to a high or medium risk requirement (see the risk attribute below for more information.) [Possible values could include: stable, likely to change].

Responsible Person: Person responsible for ensuring that the requirement is satisfied. The Responsible Person maintains the attribute Status (of implementation) – see below.

Requirement Verification Status*: An indication that the requirement has been verified. Requirement verification is the process of ensuring the requirement meets the rules and characteristics for a well-formed requirement (necessary, singular, conforming, appropriate to level, correct, unambiguous, complete, feasible, and verifiable) . Possible values could include: true/false, yes/no, or not started, in work, complete).

Requirement Validation Status*: An indication that the requirement has been validated. Requirement validation is the confirmation the requirement is an agreed-to transformation that clearly communicates the needs of the stakeholder expectations in a language understood by the developers. Requirement validation activities need to involve the customers and users of the system being developed. (Possible values could include: true/false, yes/no, or not started, in work, complete) For a more detailed discussion on requirement validation, read my paper: Getting Started on the Right Foot: Developing Requirements for Constellation’s Next Generation Space Suit

Status (of requirement): Maturity of the requirement (draft, in development, ready for review, in review, approved). A status of ‘approved’ should only be allowed if the above requirement verification and requirement validation status are both ‘True’; the requirement expression is stable (possible values could include: unlikely to change), and has all the organization’s mandatory attributes defined.

Status (of implementation): Indicator of the status of the implementation or realization of the requirement. (Possible values could include: Not meeting requirement and no plan to do so, not meeting requirement but have plan to do so, design addresses the requirement, SOI verification complete.)

Trace to Interface Definition: The interactions between two systems are described in interface definitions, which are often contained in a document which has a title such as an Interface Control Document (ICD), an Interface Agreement Document (IAD), an Internal Interface Definition Document (IIDD), an Interface Definition Document (IDD), or an Interface Requirements Document (IRD). The interface requirements contained in each of the interacting systems’ requirement set will include a reference to where the interaction is defined. This attribute provides a link trace between any of the interface requirements to where the interaction is defined. This facilitates reports out of the RMT so that, for any definition, it is obvious which interface requirements invoke that definition. This aids in change control. If any interface requirement changes, the definition may need to be changed. If the definition changes, all interface requirements that point to that definition could need to be changed as well (or at least the owners of the interface requirement need to be made aware that the definition changed.) For more information on interface requirements and interface definitions, read my paper: Everything you wanted to know about interfaces, but were afraid to ask.

Trace to Peer Requirements: This attribute links requirements that are related to each other (other than parent-child) at the same layer.  Peer requirements may be related for a number of reasons, such as: they may be co-dependent (a change to one could require a change to the other), or bundled (you can only have this requirement if you also have the one it is linked to), or a complimentary interface requirement of another system to which your system has an interface with.

Priority*: This is how important the requirement is to the stakeholders. It may not be a critical requirement (that is, one the system must possess or it won’t work at all), but simply something that the stakeholder(s) hold very dear. Priority may be characterized in terms of a value (1,2,3 or high, medium, low). Priority may be inherited from a parent requirement. High priority requirements must always be met for the project to be successful, lower priority requirements may be traded off when conflicts occur or when there are budget or schedule issues. For a more detailed discussion on priorities read my blogs Why You Should Prioritize Requirements and How to Prioritize Requirements.

Criticality: A critical requirement is one that the system must achieve or the system cannot function at all—can be viewed as one of the set of minimum essential requirements or key performance requirements. Criticality may be characterized in terms of a a value (1,2,3 or major, medium, minor or critical, major, minor, ). Criticality may be inherited from a parent requirement. While highly critical requirements will also have a high priority, it is possible to have a non-critical yet high priority requirement.

Risk*: A risk value assigned to each requirement based on risk factors. Requirements that are at risk include requirements that fail to have the set of characteristics that all well-formed requirements must have: necessary, singular, conforming, appropriate, correct, unambiguous, complete, feasible, and verifiable. Risk can also address feasibility/attainability in terms of technology, schedule, and cost. If the technology needed to meet the requirement is new with a low maturity, the risk is higher than if using a mature technology you have used is other similar projects. The requirement can be high risk if the cost and time to develop a technology is outside what has been planned for the project. For more information on risk associated with developing technology driven projects, read my paper: Developing Requirements for Technology-Driven Products

Risk may be inherited from a parent requirement. Failing to have these characteristics can result in the requirement not being implemented (will fail system verification) and entity needs not being realized (will fail system validation). Risk may be characterized in terms of a value (high, medium, low or 1, 2, 3 with 1 highest risk).   Some communicate Risk as a cross product likelihood and impact (a high likelihood and a high impact would be represented in a risk matrix as 1×1 while a low likelihood and high impact would be 3×1). An unstable requirement may also be high risk. (See stability as an attribute for more information.) For more information on risk and requirements, read my paper: Triple Your Chances of Project Success Risk and Requirements.

Key Driving Requirement (KDR): A KDR is a requirement that, to implement, can have a large impact on cost or schedule. A KDR can be of any priority or criticality—knowing the impact a KDR has on the design allows better management of requirements. If your project is in trouble you may want to consider deleting a low-priority, low criticality, high-risk, KDR.

Additional Comments: Generic comment field that can be used to document possible issues with the requirement, any conflicts, status of negotiations, actions, etc.   This information may be useful as the requirement is being reviewed and serves as a place to document information not addressed by other attributes.

Type/Category: Each organization will define types or categories to which a requirement fits based on how they may wish to organize their requirements. The Type/Category field is most useful because it allows the requirements database to be viewed by a large number of designers and stakeholders for a wide range of uses. For example, maintainers could review the database by asking to be shown all the maintenance requirements, engineers developing test plans could extract all corrosion-control requirements, and so on. For a more detailed discussion on requirement categories, read my three part blog: Requirement Categories – Part 1: General Discussion and Functional and Performance Requirements.

In Part 3, I address the attributes that can be used to show applicability and allow reuse. I will also provide some guidance on the use of attributes.

As always, comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.