In our previous blog on requirements, we explored the benefits of implementation-free requirements. Requirements that are implementation-free help maintain a more efficient hierarchical process and avoid duplication of redundant information. In this blog, we will look more closely at the requirements hierarchy itself: how many levels of requirements are reasonable? What are the relationships between the levels? What is this bidirectional traceability thing, and why is it useful? How can the hierarchy be used to help with distributed development and communicating requirements to suppliers or sub-teams?
Figure 1
ISO 26262-8:2018 Clause 6 regarding management of safety requirements gives a typical overview of the requirements hierarchy for safety-related product requirements. This hierarchy (in Figure 1) shows a flow of general requirements starting at the safety goals and becoming more specific, culminating in the hardware and software safety requirements. This hierarchy has four explicit levels of requirements, plus one level of safety goals which ISO 26262 designates as the top level safety requirement. This model suggests that it is reasonable to have only a few levels of requirements in the hierarchy. This model, however, omits a few levels and important details. Specifically, it does not show the highest level of requirements for the product – what some organizations call stakeholder requirements, user requirements, or product requirements – which are developed outside the scope of ISO 26262. This model as presented by 26262 also does not show the relationship between those “implementation specific” architectural or design specifications and the requirements.
Figure 2
Before tackling the entire hierarchy, it is useful to consider just a single level of the hierarchy. We think about what we want to accomplish, then develop a mechanism to realize our goals. The process flow of a single phase (see Figure 2) is conceptually straightforward: write down ideas on how to meet the requirements and evaluate the idea against the requirements (using analysis, simulation, expert knowledge, etc.).
The exercise of generating a concept often finds the requirements are lacking (ambiguous, incomplete, etc.) and drives iteration of the requirements. An important observation is that even though the requirements are refined based on an attempt to generate a concept, the requirements should not be specific to that concept.
The astute reader will note an ambiguity in the above paragraph: the phraseology “the requirements…” fails to respect the fact that there isn’t really “the requirements” – there are “requirements at this level.” It’s easy to take for granted that any phase of development has two “levels” of requirements associated with it: the requirements that phase is attempting to satisfy, and the requirements that arise because of the concept itself. So, an “incoming” requirement at the immediately higher level of abstraction does not dictate what a concept must be to satisfy those requirements, but the “outgoing” or “current level” requirements do embody a specific concept. This is an important distinction: a set of requirements defines implementation at one level of abstraction but does not define the details of the implementation at the next more detailed level of abstraction. This is best illustrated with a contrived example.
Product Purpose & Definition:
[PPD-01] 4 people and their luggage (up to 100kg total luggage, 2 square meters cargo area footprint, 1.5 cubic meters total cargo volume) travel from one location to another.
[PPD-02] Travel along paved roadways with a grade no more than 5%.
[PPD-03] At least one of the traveling people shall control travel speed and direction.
Design Concept A:
[DesA-01] A four-wheeled cart with four handles. Up to four people can hold the handles while walking and manually pull the cart and luggage to the destination.
Design Concept B:
[DesB-01] The product is a four-wheeled vehicle with an electric motor; wheels arranged in a rectangular pattern with two front wheels and two rear wheels.
[DesB-02] One person, designated the “Driver” of the vehicle, controls the vehicle speed and direction of travel, from within the vehicle.
[DesB-03] The two “front” wheels are used for steering.
Et cetera.
Both proposed design concepts allow four people with 100kg cargo to travel on paved roads and satisfy the Product Purpose and Definition. This property – the fact that multiple concepts can satisfy the Product Purpose and Definition – is evidence that, as stated, the purpose and definition statements are indeed implementation free requirements.
It’s worth emphasizing here that the Design Concepts are not phrased with requirements language. These are not “shall” statements. They are simply descriptions of a particular product that will satisfy the higher-level requirement, purpose, or goal! The design concept is characterized by statements of fact rather than criteria. “The vehicle is…” and “The driver controls…” Note that the design concept can – and should! – be traced back to the higher-level requirements.
Once the design concept has been chosen, requirements for that design are necessary and expected.
[DAReq-01] The cart weight shall be 200kg or less.
Due to [DesA-01] and [PPD-01] and [PPD-02]. For 5% grade, 200kg cart plus 100kg luggage needs a pulling force of ~150N (33lbf), which can be managed by a single person.
[DAReq-02] The cart handles shall withstand a force of 300N in the pulling direction without deformation.
Due to [DesA-01] and [PPD-01] and [PPD-02]. If only a single handle is used, all the force is in one handle. Uses a safety factor of 2.
[DAReq-03] The cart handles shall be located such that the moment arm from the handle to the center of the cart is no less than <Foo> meters.
Due to [DesA-01] and [PPD-03]; for a single person to control direction, the moment arm should be large enough to turn the vehicle with a force less than <TBD from human factors studies>.
The design requirement examples above illustrate a possible traceability scheme relating the requirements to the design. The design statements trace back to (fulfill) the higher-level requirements. The design-level requirements trace to both the design (because they only make sense in the context of that design) and the higher-level requirements. Figure 3 depicts the graphically, showing how the design which satisfies requirements at one level becomes the requirements for the next level. Note that the traceability shows that a lower level of detail “traces up” to its parents. In this nomenclature, a child is any design or requirement statement that intends to satisfy one or more requirements; a parent is a statement which is satisfied by one or more children.
Figure 3
When a requirement is drafted, the requirement authors do not know the content or number of design and requirement statements that will be used in its fulfillment. This means that traceability can only be established when a child is created. Establishing a parent-child relationship is a claim that the child satisfies a parent requirement or, if the parent is a design statement, if the requirement formally defines the design characteristics. This is “backward” traceability – the more specific element refers to its more general parent. Any requirements tool worthy of such a name, however, will be able to run “forward” traceability: it will be able to list any requirement that has no children. Such a traceability report can then easily be used to help manage the program, identifying requirements which do not have documented solutions. That is, if a requirement has no children, there is no evidence that a design has fulfilled it. Similarly, any low-level design statement that has no parent is evidence that either a parent is missing (driving an update to the parent requirements) or the design statement is not actually needed. One caution here is that the forward links – that is, the information about which children satisfy a parent – should not be considered normative aspects of the requirement. A practical reason for this distinction is that if a parent requirement document is released and version controlled, specifying the children of that requirement should not “change” the parent requirement document. In other words, changing the design should not change the requirements document the design is intended to fulfill.
The hierarchy and traceability example in Figure 3 also facilitates demonstrating the design fulfills [PPD-01], [PPD-02], and [PPD-03]. Note that these requirements can ideally be verified without knowledge of the requirements at the next level below. For example, regardless of selection of the cart or vehicle solution, [PPD-01] can be verified by having four people and 100kg of luggage use the product to move. [PPD-02] can be verified by moving along a 5% paved grade. At that level of verification, a tester would not need to be concerned with measuring the moment arm; they would just try to manipulate the cart with a single person and give it a pass-fail evaluation.
This highlights the benefit of true hierarchical abstraction: it frees teams up to focus on the information relevant for their activity. It also aids in troubleshooting: if a cart manufacturer finds their handle breaks at 200N force (for example), there is no benefit in sending the cart for final verification. Establishing correct hierarchical level helps move problem discovery as early as possible in the development timeline. An appropriate hierarchical structure also facilitates supplier management, since a supplier can be freed to be responsible only for delivering an implementation at their designated level in the hierarchy.
Finally, we encourage organizations to plan their requirements hierarchy structure early in a project, perhaps even formalizing it as part of the product development process. This formalization helps all participants in the process understand the development stages and highlights natural gateway milestones; if level B requirements haven’t been satisfied, there may be no benefit in starting level A verification, for example. A practical “design map” might look something like Figure 4, where there is a clear delineation of the requirements and design documents associated with each development phase.
Figure 4 – Requirement and Design document map
Requirements hierarchy and structure of documents can indeed seem like a daunting topic, but much like the hierarchy itself, the complexity is only due to scale, not in the steps themselves. We hope that this discussion has shown that requirements management is a conceptually straightforward and, ultimately, natural approach to development. This takes practice, learning from mistakes, and encouraging an environment of continuous learning. The key is to be diligent in developing the hierarchy during the process of drafting the design, rather than merely documenting it after the fact; the benefits of an alternating requirement-design cadence are realized only if done while designs are being drafted.
At SRES, we offer consulting and training to support the safe and secure development of products. Learn more about our functional safety trainings and workshops.
