In this blog I discuss attributes that can be associated with each requirement statement. A requirement expression consists of both the requirement statement plus its attributes.
I have organized requirement attributes within the four broad categories:
Attributes to help define the requirement and its intent
Attributes associated with the system of interest and requirement verification
Attributes to help maintain the requirements
Attributes to show applicability and allow reuse
I will cover the first two categories in Part 1 of this blog. In Part 2, I will address the attributes to help maintain your requirements, and in Part 3, I will address the attributes that can be used to show applicability and allow reuse and I will also provide some guidance on the use of attributes.
The list of attributes discussed herein is not exhaustive and is not meant to be prescriptive or proscriptive in any way. Moreover, it is not my intention to imply that an organization include all these attributes when defining their requirements. However, there is a subset of these attributes that I propose be captured for each requirement. These proposed attributes represent what I consider to be a minimum set of attributes that should be defined for each requirement. This minimum set supports the mandatory characteristics of all well-formed requirements, and also supports the maintenance of the requirements. The attributes in the minimum set are annotated with an asterisk “*”.
Note: In the following discussion, the phrase ‘System of Interest” (SOI) is used. The SOI is the entity, system or system element to which the requirement applies. SOI is closely associated with the characteristic of a well-formed requirement – appropriate to level.
Attributes to Help Define the Requirement and its Intent
The attributes that help define the requirement and its intent are used by both the author of the requirement and anyone that will be reviewing the requirement, implementing the requirement, or involved in the various verification and validation activities throughout the system development lifecycle. These attributes help ensure the requirements have the characteristics of well-formed requirements (necessary, singular, conforming, appropriate to level, correct, unambiguous, complete, feasible, and verifiable) as well as help all to understand the intent and need for the requirement.
Rationale* : Rationale states the reason for the requirement’s existence. Rationale defines why the requirement is needed and other information relevant to better understand the reason for and intent of the requirement. Rationale can also record any assumptions that were made when writing the requirement, what design effort drove the requirement, and the source of any numbers in the requirement. Rationale, along with the attributes of Trace to Parent Requirement and Trace to Source, help to support the claim that the requirement characteristic ‘necessary’ is true.
System of Interest (SOI) Primary Verification Method*: The primary verification method (VM) for each requirement states the planned primary method of verification (test, demonstration, inspection, analysis) that is being proposed to provide proof the designed and built system meets the requirement. Identifying the SOI primary verification method helps to ensure the requirement characteristics ‘unambiguous’, ‘verifiable’, and ‘correct’ are true. This attribute can be used to build an SOI verification matrix. This attribute may also be classified under attributes associated with verification and system validation. For more information on the importance of planning ahead for system verification and system validation read my paper: Thinking Ahead to Verification and Validation.
SOI Verification Approach*: Approach or strategy suggested to verify a requirement per the primary verification method. For example, for a requirement “The system shall do X.”, the primary method may be Test. Then the verification approach may be “The Test will consist of …………..” with a definition of what the test comprises. Other information may also be included: “The ability of the system to do X will be proven when the [VM] shows …………” or “Verification will be considered successful when the [VM] shows …”. This is a definition of the success criteria for verifying the system does meet the SOI requirement. Identifying the SOI verification methods helps to ensure the requirement characteristics ‘unambiguous’, ‘verifiable’, and ‘correct’ are true. This attribute can be used to build an SOI verification matrix. This attribute may also be classified under attributes associated with verification and system validation.
Trace to Parent Requirements* : Parent requirements at one layer are implemented at the next layer of the system architecture via allocation. A child requirement is one that has been derived or decomposed from the allocated parent—the achievement of all the children requirements will lead to the achievement of the parent requirement. Each of the children requirements must be able to be traced to its parent requirement (and thence to any antecedent requirement, and ultimately to the system need/mission). When managing requirements in a requirement management tool (RMT), when a trace is established from the child to the parent, a reverse trace is also established between the parent and that child requirement. This is commonly referred to as ‘bi-directional’ traceability. Having this knowledge allows you to make sure: all parents have children, all the children are necessary and sufficient to meet the intent of the parent, all parents have the correct children, all children requirements have one parent, and all children requirements have the correct parents. These traces also help to identify internal interface requirements. The attribute Trace to Parent Requirement, along with Rationale and Trace to Source, help to ensure the requirement characteristic of ‘necessary’ is met. This attribute may also be classified under attributes used to manage the requirement. If you want more details on traceability, read my blog: Allocation and Traceability.
Trace to Source*: Each requirement must be able to be traced to its source—this is different from tracing to a parent requirement because it identifies where the requirement came from and/or how it was arrived at (rather which other requirement is its parent). The source could be a stakeholder need. Examples of sources include system concepts, user stories, use cases, regulations, standards, derived during Trade Study 6.3, interview with stakeholder, minutes of stakeholder workshop 4, or Engineering Change Proposal 7. Sources could also be a functional area within an enterprise or business unit (marketing, safety, compliance, etc.) Trace to Source, along with Rationale and Trace to Parent Requirement, help to ensure the requirement characteristic of ‘necessary’ is met.
Condition of Use: Description of the operational conditions of use expected in which the requirement applies. Some organizations prefer to include the Condition of Use as part of the requirement statement. This attribute may also be classified under attributes associated with verification and system validation.
States and Modes: The state or mode of the system to which the requirement applies. Some systems have various states and modes, each having a different set of requirements that apply to the specific state or mode. If the system is structured in this way, this attribute allows requirements to be assigned to the applicable states and modes.
Attributes Associated with the System of Interest (SOI) Verification
This set of attributes along with SOI Primary Verification Method, SOI Verification Approach, and Condition of Use described above, are used to help track and manage the SOI verification activities and status to make sure the designed and built SOI meets the requirement. This set of attributes can be used for developing a SOI verification matrix as well as provide metrics that management can use to track the status of the project’s SOI verification activities.
SOI Verification Level: Architecture layer at which it will be proven that the SOI meets the requirement.
SOI Verification Phase: Life-cycle phase in which the SOI will be proven to meet the requirement.
SOI Verification Results: The results of each SOI verification activity will most often be contained in a separate document. This attribute traces each requirement to the associated SOI verification results document. (Possible values could include: successful, partially successful, and unsuccessful.
SOI Verification Status: Indicates the status of the SOI verification activities including sign-off/approval of the SOI verification stating whether the system has verified that it meets the requirement. (Possible values could include: true/false, not-complete/complete, percent complete).
In Part 2, I will continue this discussion by addressing those attributes that can be use to help manage your requirement set.
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.
