Leveling Requirements

I was recently asked the question. “Suboptimal leveling of requirements seems to be a recurring issue for the projects in my business group (we’ve even seen low-level mechanical dimensions specified in the system requirements). We’ve been reading through the INCOSE Guide for Writing Requirements characteristic “C2 – appropriate” and it briefly mentions “leveling exercises.” Could you provide more detail on what is meant requirements leveling?  I’m looking for help on how to do good requirements leveling; acceptance criteria for assessing the leveling of requirements; and how to conduct leveling exercises. I appreciate any information you can provide in these areas.”

Read my blog on how to get the latest copy of the INCOSE Guide for Writing Requirements.

“Leveling” of requirements is a common issue many organizations have.  A key tenet of Systems Engineering is the top-down development of requirements from system, to subsystem, to assembly, to sub-assembly, and component levels of the architecture.   Alternatively, rather than architectural levels, the organization may use organizational levels: mechanical, hardware, software to specify and organize their requirements.

The use of the word level can be, and is, confusing.  Levels of organization? Levels of architecture? Levels of abstraction?  Levels of detail? High-level requirements? Low-level requirements? Design-to requirements? Build/code-to requirements? etc.

For more details on levels, see my blogs: “Levels of abstraction when writing requirements” and “Requirements Decomposition”.

Fundamental to levels of requirements are the concepts of allocation and traceability.  In Systems Engineering, we start at the system level and transform system stakeholder needs into requirements.  We then define an architecture (or organization), and allocate the system level requirements to the next level of the architecture (or organization) for implementation. Then those responsible for the next level, write children requirements through either decomposition or derivation.  These children requirements are traced back to the parent or source.  This process continues until a buy, build, code, or reuse decision is made.

Requirement best practices tell us to avoid implementation in the design-to requirements – design-to requirements should state the “what” vs the “how”.  “How” should only be communicated in the build/code-to requirements that result from the design decisions made by the developers.

The what/how debate is often confused by the fact that when it comes to parent/children requirements, the children look like “how” in respect to the parent.  But each child can, in turn, be a parent for the level below it!  In reality, the “what” vs “how” alternates from level to level.

For more information on implementation in requirements, see my blog: “Avoiding Implementation”, “How to Handle Implementation in Customer Requirements”, and Implementation in Requirements – Internal Directive (i.e., Constraint) to use a Legacy Component.

It is because of this confusion that we in the INCOSE RWG decided on the characteristic “appropriate to level”.  At the business management level, there may be requirement that all medical devices are “safe”.  At the system level, this would be ambiguous, but at the business management level, this is appropriate.  At the business operations level, all the standards, design guidelines, and regulations that define “safe” would be identified and represent requirements for all devices manufactured by the enterprise.  These types of requirements are appropriate for the business operations level.

For more information, see my blog: “Layers of Requirements above the System Layer.”

At the system level, requirements applicable to a specific device would be defined to meet the intent of the standards, design guidelines, and regulations allocated to it.  These requirements then would flow down (be allocated) throughout the various levels of the architecture, adding more detail the lower in the architecture you go. These requirements would also be traced back to their parent or source as a way to show both the need for the requirement and to document compliance.

Why does “suboptimal leveling of requirements seem to be a recurring issue” for many organizations? There are several reasons:

1. People don’t understand the basics of levels, allocation, and traceability concepts.
2. Design people often have a problem thinking at higher levels of abstraction.  They tend to focus on the “how”, rather than the “why” or “what”.  This can result in “build/code-to” requirements being documented in the “design-to” levels of requirements.
3. Customers often include build-to “how” requirements in their requirement set.
4. Regulations and standards can include build-to “how” requirements.

A prime example I have seen is that there may be a medical device being developed.  The organization is organized into “mechanical, hardware, and software”.  There are no system level requirements, just a mechanical requirement document, a hardware requirement document, and a software requirement document.  In the software requirement document, there is a system level requirement to display information.  There are no requirements in the other requirement documents concerning the display of information.  The problem is that to display information there needs to be a display. The display is supplied by the hardware group, and mounted in the device by the mechanical group.  There needed to be a system level requirement concerning displays that would then be allocated to mechanical, hardware, and software.  Each of these would write requirements applicable to their level and trace those requirements back to the system level requirement on the display of information.  There would be internal interfaces defined for the interactions.  Mechanical would have to know the dimensions of the display and mounting information, hardware would supply the display that has the characteristics required of the display (fonts, resolution, brightness, readability, etc..  Software would have requirements on information to display, when, what languages, etc.

So how do we do a “leveling exercise” to get all of the requirements to the appropriate level?  Here are some general guidelines:

1. A key rule is that a requirement should only be documented at the level of the entity (part) to which it applies and will be implemented.  A system level requirement that applies to more than one part at the next level for implementation, needs to be documented at the system level and then allocated to the parts to which will play a role in its implementation.
2. Another key rule is that a requirement should only be documented at the level of the entity to which the requirement will be verified.  If a “lower” level requirement is documented at too high a level, the test team may not have access to specific performance measurements once the entity to which the requirement applies is integrated into a higher-level assembly.
3. A requirement could be specified at too high a level.  In theory, we develop requirements for a given level of the architecture, baseline that set of requirements, and allocate those requirements to the next level of the architecture.  Then we develop children requirements for the parts at that level the parent requirement was allocated to.Often, during allocation, if a requirement at one level is only allocated to a single part at the next level, it could mean that requirement is documented at too high a level and, via the leveling exercise, needs to be moved down to the lower level set of requirement for the single part to which it applies.  In doing so, it is important that there still needs to be a parent requirement it can be traced/linked to.  In these cases, the parent may not exist (was never developed). This means the what or why parent requirement was not defined at the previous level.  If it was not defined, then it could not be allocated properly to the parts at the next level that are involved in its implementation – the result being there could be missing children requirements at the next level, which in turn would not be able to be allocated the next level below that level, meaning there could be even more missing requirements! Too fix this issue, you need to develop and add the missing parent requirement to the requirement set.
4. A requirement could be specified at too low a level.  If this happens, it would not be able to be allocated properly to all the parts that play a role in its implementation – resulting in missing requirements.  In this case the leveling exercise would result in the requirement being moved up to the appropriate level and then allocated to the parts at the next level of architecture that play are role in implementing that requirement.  Those at the next level would then develop children requirements and trace them back to the parent.
5. To make it easier to flowdown “how” requirements specified in standards, regulations, or customer requirement sets, you can use an applicability matrix.  For an applicability matrix, you list the requirements you need to flowdown to the applicable levels and parts at those levels as rows.  The columns are the parts at the next level of the architecture.   Put an “x” in the column of the part a requirement applies to.  Then, write a requirement for that part that says the part will meet all requirements allocated to it via the matrix documented in the parent set of requirements.  That part can sub-allocate to its next level of architecture using a similar matrix. This can continue until the “how” requirement is allocated to the appropriate level for implementation and verification.

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.

ArgonDigital specializes in helping clients improve their requirement development and management processes.  Let us know if there is anything we can do to help you and your team.