We are still exploring the System Requirements document. In the previous post we covered all the requirement sections that should appear in our System Requirements document. In this post we will explore the requirement hierarchy and the act of requirement derivation.
What is Requirement Hierarchy?
Our story starts with a client need. This client need has to be resolved by our product and hopefully the client will compensate us nicely for our effort. To keep thing tidy, client needs are “translated” to Product or Marketing Requirements.
Requirement Hierarchy refers to a doctrine where there is a connecting thread between the client need to each requirement and specification in our system, no matter how low-level it is, with the following distinction in System Requirements:
- Direct Requirement – when this requirement is met the result is immediately translated to client need met. Very common in SW-only systems.
- Derived Requirement – when this requirement is met an enabler to meet another higher-level requirement materializes. Meeting this kind of requirements does not lead immediately into meeting a client need.
In an ideal world each and every System Requirement must originate from a Product Requirement or a set of requirements (direct requirement) or originate from other System Requirements (derived requirement). This is extremely important in the cases where the development process is long (years) and product requirements may change significantly in different evolution stages of the project. During a requirement compliance review sometime in mid to end of the development process we may encounter a System Requirement and ask ourselves why we needed it in the first place.
Requirement Tracking Table
For the sake of tracking this connecting thread between the origin and the lower-level requirements, the concept of Requirement Tracking Table was invented.
Our tracking table is simply a big and long table that shows the immediate predecessor of a certain requirement. Refer to the last section of our sysreq example.
BTW, in some companies the practice is to document the top requirement within the derived requirement details. Not the most comfortable solution in my opinion but a viable solution nevertheless.
Note this tracking table solution is not relevant to small-scale systems simply because of scale and ease of use.
There is an “however” here. As much as we aspire to reach an “ideal world” we do not live in one. First, keeping track of all the requirements may be very time-consuming. Let an AI agent of your choice assist you in this task as much as possible.
Second and more important, not always do we have a top-level requirement to be derived from and especially in System Requirements. In these cases, if there is a doc master in your facility and if “allowed” by your doc master, keep these top-level requirements floating, i.e. make them as the top-level requirements. If you don’t have a doc master breathing down your neck in your facility, enjoy it while it lasts 
.
If your doc master does not approve, create one System Requirement which generally reads as “top performance requirement”, link it to an arbitrary Product Requirement and link all the “orphan” requirements to this requirement. I’ve never met a doc master that caught this kind of chain and it serves the exact same purpose. Remember, rules are rules until we start serving the rules instead or them serving us. The same goes for templates.
A Word about Templates
Most requirement templates were formed as practice for two main reasons: document consolidation and uniformity of requirements or after something went terribly wrong and lessons learned went into the best-practice template. Both are very solid causes!
However, very much like the rules mentioned above, the templates come to serve us. When our only purpose in writing a certain section is to force some information into an existing template or, even worse, if we have to bend the correctness of the requirement formulation to fit into a certain template then the template no longer serves us and may even harm us. I have already mentioned the use of templates in a previous post in the context of creativity. Requirements share the same – use the templates wisely and, in cases where needed, be brave and break the template.
All this so as to create the best requirement and specifications document possible for the current development stage.
Requirements Technical Hierarchy
As a reminder, this is our sysreq and here is our go-to block diagram
Up till now we have discussed the “dry” facts of the System Requirements.
The technical hierarchy has the same characteristics – what derived requirements must be met in order to make such-and-such requirement work – technically.
System Engineering wise, the technical hierarchy is the art of system-level understanding.
Let’s take for example the up-to-15mm thickness of Aluminum metal Product Requirement.
- Aluminum 15mm thickness requires for laser cutting a 1070-1080nm laser unit with 12kW power according to this research that was cited also in another post.
- Breaking it down further, 12kW power in a 220VAC means 54A current, which is not standard to begin with, and we already discovered that these units come with a 480VAC which will grade a 25A current for the same 12kW power.
- Further, on another deeper level, if we apply 12kW where does all that heat go to? Dissipation into air at room temperature is not an option with 12kW power so active cooling is required.
- If any kind of cooling is required we need a control mechanism for the cooling loop.
- Active air cooling will not do the trick so liquid cooling is required.
- If liquid cooling is required, we need coolant infrastructure.
- When having a coolant infrastructure on the machine we also need an inlet \ outlet interface to the client’s facility.
- Another branch would be the “up-to” statement, which means that we may need to deal with 10mm Aluminum plate thickness. That implies that power control is required.
- If power control is required, we need a reliable method to measure the laser power.
- Furthermore, calibration of this power control mechanism is required.
- All of the controls mentioned above need their SW interface and control.
And so on and so on. I’ve made sure to have this requirement thread in the example sysreq for review. In addition, below is the tree representation of the thread described above
We have to remember no human knows everything (we will revisit this statement in the next post), so the process of covering such deep derivation of specifications and requirements usually requires interviewing all the technical engineers in the project, sometimes individually and often all together in the same room (or e-meeting ).
This is the bit of team work that will probably make the System Requirement a better fit for the project, which is always a good start.
To sum up, this is our System Requirement document for all the matters discussed in this post-series. It is obviously only a small portion of what is needed for a large-scale project like our laser-cutting machine but it serves as a very good example of what to do.
As mentioned previously, this is a fully human solution. No input was taken from any AI model to create any of the content published in the first four posts of this series. In our next post we would do the ultimate test – compare, as much as possible, between the output of AI agents to my human-created example.