Requirements Management

December 4, 2015 - Rebecca Haag, Systems Engineer II; and Gary Seim, Principal Systems Engineer, Retired

The white paper titled, “Characteristics of Good Requirements,” discussed the positive impact good requirements can have on a project’s schedule, budget and quality output. However, the impact of requirements extends beyond the initial agreement and continues throughout the project to ensure requirements are appropriately documented, traced and changes are controlled.


The total number of requirements for a project is generally correlated with the complexity of the system under development (i.e. how many functions and qualities it needs to have). For even moderately complex projects, this can become overwhelming. It can be difficult to keep track of where specific requirements came from and why they are necessary. These types of questions can be avoided by the appropriate use of a requirements management system.

A management system can help organize the different levels of requirements and show how each one ‘cascades’ down from those at higher levels:

  • There may be business requirements which identify strategic goals for the organization – owned by Minnetronix’ customers. These may not be product or system specific, but can help to drive investment in appropriate projects and programs.
  • Stakeholder requirements identify the needs of interested parties for a specific system and are also typically owned by Minnetronix’ customers. These may include the end-user needs, but should also capture the needs of other people who interact with the system lifecycle (regulatory bodies, marketing, installers, maintainers, etc.).
  • Systems requirements flow from the stakeholder requirements. Rather than being expressed as desired implementations, the system requirements should be stated in terms of system characteristics, qualities and functionalities that will meet the stakeholder requirements; that is what the system needs to do, not how it does it.
  • Depending on the complexity and scope of the system under development, the system requirements may flow down into subsystem requirements (for instance software requirements associated with a system element) based on their allocation (i.e. which element of the system needs to implement the functionality described at the system level).

At each level of the cascade, the requirement statements should contain the appropriate level of specificity. Those at high levels, such as the stakeholder needs, should not be overly prescriptive in the means by which the system is to meet the intended requirement. If too much detail is included at the higher level, the system may be made more costly, complex and take longer to develop than it needs to. At each subsequently lower level, additional detail can be added.

Maintaining Traceability:

Maintaining traceability between different levels of the cascade is a key component of requirements management. It is necessary to be able to show that all of the higher level requirements will be implemented by satisfying the lower level requirements.

Project change is highly likely to occur at some point in the design process. By creating and maintaining the traceability between requirements, the effects of change can be dealt with effectively and efficiently. It can be easier to evaluate the impact of changes throughout the cascade and on the project scope, schedule, and cost.

For instance, if a stakeholder requirement is found to need updating, by utilizing the traceability within the cascade the impacts to the system and subsystem levels can be quickly and efficiently assessed. It is also useful to understand where the requirements came from (bottom-up traceability) for cases in which it is found that the lower level requirement cannot be implemented as described. In these cases, the evaluation can proceed back up the cascade to identify the higher level functionality being described to determine whether an alternate implementation method or alternate requirement wording can be chosen to address the concern.

In addition to maintaining traceability within the different levels, it can also be useful to create an organizational structure within each level. Grouping related or mutually dependent requirements together within the documentation structure helps designers understand the scope of a function at a quick glance rather than forcing them to hunt through the documentation for anything that may be related. In this way, a good organization structure for the requirements documents can improve efficiency for the engineers tasked with system implementation.

Controlling Changes:

Overall management of requirements extends beyond maintaining traceability within the cascade and creating an organization structure. Requirements must be formally captured, documented, reviewed with stakeholders and design functions, baselined and configuration managed. It is important to ensure that the requirements identified are agreed to by the appropriate stakeholders, including design engineers. After an initial set of requirements has been agreed to, they are considered baselined.

Any changes made after the baselining of the requirements need to be tracked to understand what is driving the changes, why the change can be made and what impact it has on the design and throughout the rest of the requirements. It is important to be able to understand when each version of the requirement was introduced throughout the development and prototyping process as this helps ensure efficient integration as the design proceeds forward.

Minnetronix Philosophy on Managing Requirements:

At Minnetronix, managing requirements is an essential and fundamental component of our engineering effort. Our systems and quality engineers help ensure requirements are appropriately documented, traced and changes are controlled by:

  1. Using requirements management software to help capture, trace, organize, baseline and control changes to requirements.
  2. Maintaining the various levels of the requirements cascade throughout the project and, as needed, employing specific engineering disciplines to help define subsystem level requirements.
  3. Engaging team members and customer representatives during requirements elicitation and reviews throughout the project.

By utilizing requirements management software, experienced engineers, and customer representatives throughout the project, Minnetronix’ process for managing requirements helps provide a positive impact on schedule, budget and quality outcomes for a project.


While the process of initially documenting the requirements is critical to starting the development effort off on the right foot, it is also important to maintain appropriate requirements management as changes occur to the design. Project change cannot be eliminated and so it is necessary to keep everyone on the same page throughout the effort. Effective requirements management will keep the work proceeding efficiently with everyone driving towards the same set of evolving blueprints. This in turn helps projects be delivered on schedule, on budget and with a quality output.