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.
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:
Ground Station Network specification
Landing site specification
& many more
Maintenance Staff Training specification
& many more
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:
A breakdown of the product functions into its subsystems
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).
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).
Organised hardware requirements engineering in Valispace using folders
Visualise requirements breakdown of complex hardware using the connections graph in Valispace
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
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.
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.
Collaborating easily on requirements inside Valispace for reviews
Viewing full history of changes per requirement: who, what, why & when something changed
Resolving discussions in Valispace
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:
Standards that apply to the entire product (e.g. FAA or EASA standards for flying vehicles)
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.
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.
Adding verification status to components in Valispace
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.
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?
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.
Requirements breakdown is one of the core activities when developing complex hardware. Many pitfalls are often overlooked and there is not a single way that works for all product developments.
If you don’t manage to break down and trace your requirements, performing an impact analysis becomes very difficult and time consuming. Whenever a Customer Requirement or Standard is updated, you need to be able to quickly identify which requirements must be reviewed in order to confirm if any change in any level of the system is required.
So, the core takeaways are:
Traceability is key.
Engineers need digital systems to support them. It is too complex to do it manually and the risks of making a mistake are too high.
Collaboration through review, shared activities and ownership of different specifications prevents costly re-work.
Once you have broken down your requirements the next step is defining how to verify that all requirements are met. Stay tuned for the next part of the series where this will be explained.
If you’d like to get a free 30 minute consultation by our solution managers, to review and help with your requirements management process, reach out to email@example.com.
Efficient Hardware Testing - launching the new Valispace testing module
Are you a student, teacher or academic researcher? Contact-us directly
Manage Cookie Consent
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.