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.Tags: children requirements, derived requirements, implementation, levels, levels of requirements, organizing requirements, parent requirements, requirement, requirements, What vs how
By Lou Wheatcraft March 20, 2013 - 2:29 am
Comment from LinkedIn: Generally good advice, but we want to be careful to not avoid legitimate design constraint requirements. Requirements are, after all, what the customer wants in terms of system attributes, and can range from behavioral attibutes to HMI user screens to specific implementation needs. We do need to keep them explicitly separate (a design constraint is not externally visible), and should ensure that the customer really knows what they want, but sometimes a design attribute is a valid requirement.
Lou response: I agree with the intent of this comment, there are times when implementation is acceptable. The key is to include clear rationale as to why the implementation requirement is needed. Also, understand that when stating implementation you are also saying it doesn’t matter if there is a better way, the implementation requirement is how you want it done.
By Lou Wheatcraft March 20, 2013 - 2:31 am
Another comment from LinkedIn: Lou … Thanks for a very good post. I have had the same conversations with many engineers; even with customers.
By Lou Wheatcraft March 20, 2013 - 11:18 am
A comment from LinkedIn: That is a good article I remove requirements that state implementation. But sometimes you have to use them and they actually assist the designer.
By Bob Barrett January 30, 2017 - 8:38 am
I see this thread is old 2013, but stumbled on it and am hopeful you are still interested in dialog on a couple of topics. What you have here is helpful. My experience is with medical devices. I also like to start with a requirements plan that defines the levels and how each of the requirements ties to each other as well as how risk is addressed. This plan is helpful for teams to know the context as well as describe how the intended (user) needs at the highest level is the parent. This identification of needs allows us to validate needs of the system and verify requirements as a part of V&V. Have you used this approach in your experiences?
I have another question for you. This is an interesting topic regarding ‘design to’ and ‘build to’. It touches on the problem we have around the different expectations by each the stakeholders of the requirements. In the section in this blog describing understanding the relationship of requirements between levels it is stated that we end up with “…a set of ‘build to’ or ‘code to’ requirements where the design is complete…”. I find that when writing software requirements in a system there needs to be further delineation of the objectives of the levels of requirements. I think with software requirements a defined system architecture is needed before the software requirements can be fully elaborated. For example for a system with multiple processors, would you expect the functions of each to be already allocated so the software engineer that is designing that software knows what that code base must do in order to design it? Also are you indicating that the requirements set includes both (build to and code to), meaning once ‘code to’ is done design is done?
Another tricky part of handling software requirements is writing GUI requirements. I know I struggle with different team’s expectations of defining the objectives of GUI versus specifying specific GUI elements that are to be expected on screens. Have you experience in GUI requirements, and whether the ‘design to’ and ‘code to’ rules of thumb help there?
By Lou Wheatcraft February 19, 2017 - 10:33 pm
Have you used this approach in your experiences?
Lou: I always advocate that stakeholder needs and expectations be defined first. This includes defining use cases, user scenarios, user stories, operations concepts, etc. From these the stakeholder needs and expectations can be extracted. Once the needs and expectations have been agreed to and baselined, then these are transformed into requirements for the overall system. (The transformation includes asking: “For the user to be able to do XXX, what does the system need to do?”) To make sure the developers understand the context and intent of the requirements they need access to the use cases, etc. It also helps to include rationale for each requirement.
The system level requirements will need to be verified to be well written and validated that they clearly communicate the stakeholder needs and expectations. Next, the system architecture is defined (a design activity) and all the baselined system requirements are allocated to the next level of the architecture. The organizations at next level will write children requirements through either derivation or decomposition and trace those children requirements back to the allocated parent. Then the whole process repeats.
For many medical devices, this approach can be difficult because of the integrated nature of implementation of requirements in a hybrid hardware/software system. Many organizations are organized as: electrical, mechanical, and software, rather than a traditional system/subsystem/assembly/component approach used for larger systems. For these organizations, the system level requirements are allocated to these organizational groups, which work together, to define the interfaces, write requirements for the parts they are responsible, and develop the system.
Note your use of V&V is not clear. For an explanation see my blog: “What do the terms Verification and Validation Really Mean?”
For example, for a system with multiple processors, would you expect the functions of each to be already allocated so the software engineer that is designing that software knows what that code base must do in order to design it?
Lou: I agree the system requirements need to be allocated as stated in my previous comment. The concept of design-to and build-to requirements is a big problem for many organizations. It is important to first focus on the “what” at each level and avoid implementation “how”. You want to communicate to the designers what functionality, performance, quality, standards, and physical constraint requirements are. Let the design team figure out how to meet these requirements, and then document the design “how” in a set of build-to requirements. The form of these requirements is different from the design-to requirements. The build-to requirements can contain screen shots, algorithms, logic diagrams, and pseudo-code.
Also are you indicating that the requirements set includes both (build to and code to), meaning once ‘code to’ is done design is done?
Lou: I advocate that the build-to and design-to requirements be documented in separate sets of requirements. The design-to requirements drive design, once the design is complete, the build-to requirements drive coding and manufacturing activities.
Have you experience in GUI requirements, and whether the ‘design to’ and ‘code to’ rules of thumb help there?”
Lou: GUIs are an interesting case. During the user scenario, user story, etc. activities, you may be able to develop example screens that communicate the stakeholder expectations. As long as the design team is part of these activities, I don’t see why you can write requirements to include the example screens, which seems to be code-to” requirements. This approach assumes you have an organizational standard and/or industry standards or government regulations that define basic requirements for GUIs for your type of product including colors, readability, contrast, fonts, font sizes, etc. You will need requirements that address these standards and regulations. It is also important that you capture the reasons for the layout of the screens, the types of screens, what needs to be communicated, the purpose of the screens etc. This information can be captured either as requirements (if they drive design) or rationale (to explain why a requirement). If your stakeholders agree to work with the design team to develop the GUIs, an agile approach works well. In this case, you can have fewer detailed requirements and just focus on the basic need for the various screens, driving standards and regulations, and not address the detailed layout of each screen.
I hope I have answered your questions sufficiently. If not, feel free to continue this dialog.