We were recently asked the following question:
“How do you determine that a requirement is talking about “how” not “what”? It is always a problem that bothers us during requirement definition. As requirement engineers, we have less technical knowledge, so sometimes we can’t always be sure that a requirement is stating implementation or not. Furthermore, a requirement can be “how” at one level, and be “what” for another level”.
This is a very common question. The focus on pre-design, design-to requirements should be on the “what” and not the “how”. How is implementation. By stating implementation, the real requirement goes unstated – the “why” is not communicated to the developers. If the real requirement is not stated, it cannot be flowed down (allocated) properly to the next level of the architecture. There may be cases where we have a good reason for stating the “how” but we need to limit doing so. Stating implementation can result in the true requirement not being stated, so you may get what you asked for, but not what you really needed.
Enable innovation and avoid implementation
We want to avoid implementation “how” requirements pre-design, because we don’t want to tell the designers one way of doing something when there may be a better way. By stating implementation, the developer’s solution space is restricted, not allowing the developer to propose the “best” solution to meet your expectations. We want innovation. The design team (or contractor) often has much more knowledge than the customer or requirement development team. You should take advantage of the design team’s experience and knowledge to come up with the best solution to meet your needs. If you omit the “what” you need, they can’t meet that need.
Keep in mind who you are writing the requirement for
When writing requirements, it is important to write requirements based on who you are communicating your expectations to. If you are communicating to the design team, the focus of your requirements needs to be on the “what” not “how”. These are referred to as the design-to requirements.
Understand the relationship of requirements between levels
One problem that can confuse requirement writers is that requirement development is not a linear process. Systems Engineering is iterative and recursive. Thus, once you have a set of requirements at one level, you do design and define an architecture at the next level. Then you allocate the requirements at the previous level to the architecture at the new level. Children requirements are derived to implement their parent requirements. If the purpose of these requirements is to provide guidance to the design team and are still design-to requirements, these requirements should still focus on the “what” and not “how”. When comparing requirements from one level to another, children requirements often seem to look like “how” when compared to the parent “what” requirement.
Once you have repeated the above process to the point that you can’t go to lower levels without design, you are changing from “what” to “how”. The result is a set of built-to or code-to “how” requirements where all the design is complete and the implementers can now implement the requirements as written. All the design work is already done.
Suggestions for avoiding implementation
The boundary between design-to “what” requirements and build-to “how” requirements can be fuzzy. There are several questions you can ask to help avoid implementation.
- Ask “Why?” Whenever we see what looks like implementation, we ask “why”. Often the answer turns out to be the real requirement.
- Ask “What do you want to verify?” If you verify exactly what the requirement says, will your true need be proven to have been implemented? Example: “The aircraft shall contain flight performance instrumentation.” I can verify this by inspection – yes it has instrumentation. However, does the instrumentation work? Does it measure the right things? Do I get the amount of data I need? Maybe a better requirement would be “The aircraft shall measure its flight performance.” Along with other related requirements that define what flight performance needs to be measured. In this case I will conduct a test or demonstration that results in actual flight performance measurements, which is what I really wanted to make sure the system did per my requirements.
- Ask “What would happen if I didn’t state the implementation?” Would the designers have to address the issue anyway? If so, you probably don’t need to state the requirement.
- Ask “Is this requirement stated at the proper level?” A common issue is lower level requirements stated at too high a level. Often when an implementation is stated, the reason is that the requirement belongs at a lower level and that the real (why and what) requirement is missing at the level you are at. Requirements need to be stated at the level they will be implemented and verified at. A lower level requirement included in with a set of higher level requirements looks like implementation. If the requirement is at the wrong level, move it to the proper level. When doing this, make sure that it has a valid parent at the level you are moving it from.
The issue of implementation is also addressed in the following two blogs: “How to Handle Implementation in Customer Requirements” and “Implementation in Requirements – Internal Directive (i.e., Constraint) to use a Legacy Component.”
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
