How to: Break Down Requirements for Efficient Engineering in Complex Hardware Projects

When building complex products, engineers need to break down high level requirements into smaller chunks in order to: make them more manageable, to be able to design subsystems in parallel and to ensure from the bottom up that the high level requirements are verified.

While most engineers have learned all about the V-Model in their studies, the actual skill of breaking down requirements from higher to lower levels is a craft that needs to be acquired, with quite a few pitfalls to avoid that could create major problems much later into the development process if not managed right from the start.

To avoid that kind of re-work, here are the best-practices that we have gathered from our customers, as well as our own experience. 

As an example, we are looking at the design of an autonomously flying Vertical Takeoff and Landing (VTOL) vehicle: the Valicopter 5000.

Design Study: Vertical Takeoff and Landing (VTOL) vehicle: the Valicopter 5000

1. Start with Customer Requirements

Customer requirements describe on a very high level what the product should do. These requirements can either come from a contract with the customer, as results from a market study, or as a product-vision. 

These requirements are usually not necessarily well formulated or organized but will still in the end determine whether your product development achieved its main goals.

To design an actual product that meets these high level requirements, we will break them down multiple times into lower level requirements. Each breakdown serves the goal of clearly allocating responsibilities between subsystems (e.g. which functionalities need to be solved in hardware and which ones in software), as well as to detail the requirements (e.g. what exactly does “size of a helicopter pad” mean?).

When breaking down requirements, the original requirement is often referred to as “parent” while the derived requirements are its “children”. In general a parent requirement can have multiple child requirements and vice versa.

Try generating requirements with Valispace’s new AI ValiAssistant

2. Break down the requirements into technical and non-technical Requirements

The first distinction to be made is between  requirements that have a direct impact on your product and those that don’t  relate explicitly to the product itself. Non-technical requirements can refer to cost, time, organization, environmental factors, operational requirements etc.

This does not mean that non-technical requirements don’t have an impact on your product. However, the impact is usually less direct and the relationship between them and specific parts of the product often need additional analysis. 

The goals of this breakdown are:

• To clarify the requirements’ meaning 
• To separate physical requirements that can be verified with the product alone from requirements that depend on its usage, its development process etc.

It is important to keep and document the connection to the customer requirement to be able to trace back certain product decisions to the initial specification. An  initial requirement can be broken down into one or more technical or non-technical requirements. 

In the Valicopter case we are going to focus on product requirements (as an example of technical requirements) and operational requirements (as an example of non-technical requirements):

Additional specifications in this example could be:

Technical specifications:

• Ground Station Network specification
• Landing site specification
• & many more

Non-technical specifications:

• Cost specification
• Maintenance Staff Training specification
• & many more 

Pro-Tips:

• Mark the link between the requirements in a way that it is easy to find the related requirements in both directions: all children of one requirement and all parents of a requirement should be easily visualized. This will become very important, once technical changes are introduced in the future.
• Numbers in requirement text should be treated as variables with numbers and physical units. This ensures that an update to a value that is reused in other requirements will automatically change those other requirements in the future. Otherwise, it is very likely that requirements will become inconsistent amongst each other further in the process.

After this breakdown has been performed, a review with the customer / target-group / users should be conducted to ensure that the understanding of the requirements are correct. The agreed broken down requirements should regularly become part of the Statement of Work with the customer, since these are the only ones that are well formulated and fully testable.

3. Break down the product into subsystems

Now it is time to come up with a design that can fulfil the product requirements.

Usually this is the creative step where the engineering magic happens (think whiteboard, discussions, back-of-the-envelope calculations, etc.) Although a dedicated post will dive in detail into how to conduct Design studies and Tradeoffs, the most important outcomes from a requirements perspective are two things:

1. A breakdown of the product functions into its subsystems
2. A clear division of which subsystem is responsible to provide which function

Often this activity is led by one or multiple lead system engineers who have the overview of the entire system and who work in close collaboration with experts/architects for each subsystem. Expect this to be a very iterative process where it is normal to have long discussions, multiple tradeoffs, hundreds of comments, reviews and changes. 

Subsystem requirements should not yet force a certain design solution within their area, but rather provide a functional view. E.g. a good subsystem requirement for the propulsion subsystem does not yet specify the details of the rotor blades, but rather focus on function and performance:

However it is very important to capture the reasoning between those assumptions. Sometimes writing a short justification might be sufficient, but in other cases (like above) the calculation that made you arrive at the values should be attached to the requirement for full traceability too. Experience shows that trying to find out months or years later which assumptions went into numbers is very hard (if not well documented). 

Pro Tips:

• It is normal that inside this design process, requirements are introduced that don’t have a direct parent but come from the implementation choices on this subsystem level. E.g. the fact that the motor needs a cooling system does not come necessarily from top level requirements, but from design implementation choices. Therefore, as long as these requirements are well justified and their justification is documented, it is not a problem that subsystem requirements don’t always have a parent.
• Requirement parent-child relationships do not only exist between the hierarchy of the specifications, e.g. the engine subsystem might have the need for cooling from the thermal subsystem. Allowing requirements to have parents and children “on the same level” (meaning across subsystems) is a best practice.
• The definition of what a subsystem is, is quite fuzzy. A best practice here is to group elements by its core functionality, even if in the physical product they are scattered (e.g. the thermal subsystem might have actuators and sensors all over the place, as long their main purpose is to manage the temperature of the system). 

4. Distribute shared properties across subsystems

To allow multiple teams to work quite independently against a shared design, it is good practice to allocate properties that get divided into engineering budgets.

Concretely this means to distribute mass, power consumption, cost, etc. across subsystems, so that each of them has a required limit to work against. 

This process is not an exact science and we will go more in depth on how to break down a system in a separate post. However good starting points for mass are, for example: 

• making deductions from already existing products (e.g. battery packs on average make up X-Y% of electrically powered flying vehicles)
• make rough bottom up calculations (e.g. each engine weighs around 300kg and some cabling and physical connections are needed on top)
• Allocating the correct materials to the biggest parts in a CAD model to estimate the subsystem mass.

Similar back-of-the-envelope calculations can be done for power, cost and other properties.

The philosophy of where to introduce margins in this breakdown depends on many factors. However, it is very important to decide on a margin philosophy at this point. It can be one of the following or a combination of several:

• Adding a margin on top of requirements: i.e. the requirement of “4t” is not the actual limit, because helipads will allow for 5t.
  • Benefit: all requirements are coherent amongst each other
  • Downside: it might be hard, very costly or even impossible to design against too strict requirements
• Accounting for margins within the requirement breakdown: i.e. not allocating the full 4t to all the subsystems. 
  • Benefit: flexibility between the subsystems can balance out unforeseen needs
  • Downside: hard to keep track of where the margins were taken leading to misunderstandings and conflicting requirements 
• Accounting for margins within the subsystems: i.e. ensuring that the design of each subsystem is targeted  to be, for example, 20% below requirement at a specific milestone of the design phase.
  • Benefit: requirements do represent the truth about absolute limits at all times
  • Downside: a clearly defined margin philosophy needs to be tracked across the project, ensuring that the worst-case values (incl. margin) are compared against the requirements

Pro Tips:

• Ideally the values in the requirements breakdown are actually linked via an automatic  formula (e.g. percentage) to the top value. So in case anything changes (like the total permitted mass is actually 4.2t) then all other values and requirements just follow.

5. Deal well with hardware-software requirement interactions

There is a constant debate of how to best deal with software requirements, since they affect most subsystems. They could either be: a dedicated section in each subsystem or software could be regarded as a dedicated subsystem. Experience shows that treating it as a dedicated subsystem and then cross linking between software and subsystems is normally the better trade-off.

The interactions between hardware and software are key in any complex product. Since the correct understanding and interface definition between hardware and software engineers is crucial to avoid later incompatibilities, it is best to treat the software subsystem similar to the “customer specification”. This way, the system- and hardware-teams can create requirements in the software subsystem that they expect the software to handle without going into architectural details. The software team will then break those needs down into an actual software architecture that they will implement from.

Pro Tips: 

• The Software Needs Specifications will evolve significantly over time, as you develop your product, since you will find more and more things that you want the software to do. Tagging requirements with a specific software version that you expect to see this on will allow your team to develop the software in increments that let you already use it (while the development is still ongoing). At the same time it will set clearer priorities of what each team can expect at which point in time.
• The Software Needs Specification  should be well reviewed by all hardware architects (for every subsystem), as well as by the software team. Early discussions and clarifications will allow your team to identify misunderstandings sooner. 
• Expect that the Software Architecture Specification should be able to be tested entirely on a virtual environment, while the verification of the requirements on the Software Needs Specification will often rely on the interaction between hardware and software; at least on an early prototype model.

6. Trace External Requirement Standards and Regulations

Depending which field you are working in, you will have to deal with requirement standards that are either imposed by a regulatory body and/or by internal standards that your company has decided to obey by. 

When it comes to product development, we can distinguish between 2 kinds of standards:

1. Standards that apply to the entire product (e.g. FAA or EASA standards for flying vehicles)
2. Standards that apply to each element of a product (e.g. quality standards)

For the first case, the requirements are simply treated like another “customer specification”: linked to the product and operations specifications, as in (2). This should be done at the very beginning of the project to make sure that the design complies with all regulatory needs from the start of development.

For the second case it needs to be decided on which level of subsystems or equipment the specification applies, then it needs to be applied to all of them to live next to the design requirements for that same component. These requirements are often complementary to the functional requirements and therefore can be added to the existing breakdown.

Pro Tips: 

• Make sure that the way standards are applied to multiple components allows you to later update the standard and still have full traceability to each component. Copy-paste is usually not enough here, but rather an applicability matrix with dedicated compliance and verification tracking per equipment.

7. Trace failure modes

While the details of how to perform failure analysis with Fault Mode and Effect Analysis (FMEA) and Fault Tree Analysis (FTA) fills entire books, the key connection to requirements management is that all measures that are taken in the design (to prevent failures or to deal with their effects) need to become requirements, so they can be verified along the design process.

A typical flow therefore could look like this:

Risk Register → Identified Failure → Chosen Counter Measure → Design/Operation Requirements

The most important aspect of FMEA/FMECA work is the full traceability. You need to be able to answer at any point in time:

• Which failures are related to critical risks?
• Have all failures with critical risks been addressed?
• Are all counter measures related to acceptable risks?
• Which are all the failure modes that we are tracking for a given component?

Pro Tips: 

• The Risk register is very important to define early on so that it is clear to everyone on the team which ones are acceptable risks and which ones aren’t. Other considerations involve whether single-failure or also multi-failure resistance should be considered. 
• No matter which method you use to derive the failure modes; make sure that you gather them on multiple levels: failures that can occur on equipment, subsystems or the entire system.  Often, failure analysis will come from the supplier of parts, but the ultimate assessment of linking those failures to risks needs to happen on system level (e.g. a supplier of an engine can not know or assess, if an engine failure will lead to loss of your entire vehicle or not).
• Countermeasures can also be linked to new or  already existing design or operational requirements. Preserving these links, however, is highly important in both cases in order to know that these requirements cannot be altered without a re-performed failure mode assessment.