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
- Cost specification
- 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).