In this blog, I conclude my discussion on requirement attributes that can be associated with each requirement statement by addressing attributes that help to identify the applicability of the requirement and allow reuse. I also provide some guidance on the use of attributes.

In Part 1, I covered attributes to help define the requirement and its intent and attributes associated with the system of interest and system verification. In Part 2, I addressed the attributes that help you as you maintain your requirements.

Attributes to show applicability and allow reuse

These attributes may be used by an organization that has a family of similar product lines to identify the applicability of the requirement (to product line, region, country, etc.) and reuse of requirements that may apply to a new product being developed or upgrade of an existing product.

Applicability: Can be used to indicate which increment, build, release, or model a requirement applies to.

Region: Region where the product will be marketed, sold, and used.

Country: Country(ies) where the product will be marketed, sold, and used.

State/Province: State(s) or province(s) within a country or region where the product will be marketed, sold, and used.

Application: The applicability to a specific product within a product line.

Market Segment: Segment of the market who will be using the product.

Business Unit: A specific business unit within the enterprise that produces the product.

Business (Product) Line: A specific brand or product line within a given business unit.

Guidance in using requirement attributes

The reason for using requirement attributes is to better manage your project. Given that requirements are the common threads that tie all systems engineering product development life-cycle processes together, having insight into these processes is necessary to manage the project effectively.

One of the main features I listed for a requirement management tool (RMT) was that the RMT needs to have the ability to manage both the requirement and its associated attributes. With this ability, you can use the tool to filter, sort, and query the database to view and create reports of selected subsets of requirements based on their attribute values. Managers can define specific reports that target various aspects of their project based on the attributes. Some RMTs allow you to define a dashboard display that includes graphics based on the selected attributes.

Knowing the priority of a requirement helps to better plan your project activities, knowing the risk allows mitigation of that risk. Combining risk and priority or criticality can provide management with valuable information they can use to manage the project’s requirements and associated risks. Identifying that requirements are both high priority (or criticality) and high risk allows management to focus on the most important issues. Again, you can create a 3×3 matrix but this time one axis is risk and the other priority or criticality. If these attributes are not documented for each requirement, how will management know which ones are high priority or criticality AND high risk?

Knowing the criticality of a requirement or the fact a requirement is a Key Driving Requirement (KDR} allows systems engineers to plan accordingly. When under schedule or budget pressure, a KDR that is low priority or low criticality, but high risk, may be a candidate for deletion.

Activities like system verification and system validation are key cost and schedule drivers on any project. Knowing the proposed method and approach of system verification or system validation facilitates the development of a more realistic budget and schedule. Knowing the status of the requirement and status of the system verification and system validation activities allows management of the budget and schedule so actions can be taken when there are indications of problems that could lead to budget overruns and schedule slips before they become a real problem.

A major source of budget and schedule issues is change. Attributes such as rationale, version, change status, control board, priority, criticality, parent, traceability, stability, and KDR allow managers to access the need for a change and the potential impacts of that change.

A word of caution. As with the use of all information, a “lean” approach should be taken to defining which attributes will be used – don’t include a specific attribute unless you, your team, or your management has asked for that attribute and will use that attribute in some manner to manage the project and set of requirements. While attributes discussed in this blog are all potentially useful, it does take resources to create and maintain the attributes. Each attribute that you do choose to include should “add value”. If the information is not going to be used, why spend the resources on that attribute? On the other hand, for the attributes to be useful to manage projects more effectively, you must be diligent about storing the information for each attribute and keeping that information up-to-date.   As the old saying goes –“garbage in; garbage out”. Another applicable saying is: “A time saving tool should not take more time to maintain than the time it saves.”

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.