In the context of product design, the proper definition of the System or Product Requirements is one of the most important stages of a project. This defines the “What” and will ultimately have a direct impact on design decisions, budgets, product quality and development time, among others. The “What” is really the driver (driving force) behind your requirement definition, and will give shape and structure to the product you are working on, laying down boundaries with respect to what it should be and what it should not be. These are just some examples of what is considered here:
Basic mechanical: dimensions, tolerances, material requirements, dynamic response to physical excitation
Basic electrical: power source and power consumption, EMI, PCB materials, smd vs through hole components
Functional requirements: what functions shall the product possess?
Quality and reliability requirements
Standards: are there specific standards that the product will need to comply with? Which ones and why are those important?
Safety: what safety considerations are required or must be satisfied by the product?
Feedback controls: performance of a mechatronic system operated under closed-loop conditions
Reaching Consensus
Technical teams will be faced with two key challenges:
How can each of us, individually, best serve the definition of the requirements?
How can we as a team extract the most of the team’s common knowledge to optimize requirement definition?
Individually, each team member can resort to common knowledge available online, in literature, within the team or the organization or otherwise, concerning best practices on requirement definition. A significant amount of information has been generated over time, by academia as well as by successful enterprises, that will provide tips on best ways to define and convey the message of what exactly the product needs to do (the “what”). The second point is a little bit more complicated, as it involves debate and communication with others in the team or organization. Discussions and debate are common practices in engineering when evaluating ideas or proposals, and they can greatly enhance the product development phase if the thoughts and ideas tend to converge within the team and are duly compiled (i.e. are documented, somehow). That’s easier said than done! In reality there is a fine line between too much discussion (or discussion for the sake of proving that I’m right and you’re not!) which risks resulting in divergence of opinions, and no discussions at all (maybe because the idea came from a self-proclaimed VIP individual, who is not to-be contradicted or challenged!). In other words, there is an optimal point to the problem and it’s not always easy to find.
In an interview with Everyday Astronaut published on October 1, 2019, Elon Musk shared some of the secrets he has used to expedite high quality Engineering development in both of his technology-transforming companies: Space X and Tesla. Musk indicated that one should not carry on with a design of a module (i.e. product, part, subsystem, etc.) based on constraints given to you by other teams, without first questioning the reasoning and the source of these constraints – what assumptions were made to reach them? And to some extent, one should assume that such constraints are wrong, therefore you are in the right to question them and try to shape them for the better (careful here… for the better, not for personal or professional gratification), and ultimately find or help find the best compromise. This could be considered a local optimal point, or a local maximum of the function being optimized: arriving at good requirements.
So it’s OK to think that there is always room for improvement, while knowing that a non-perfect compromise will need to be reached to get to a starting point. Coming into a requirements review with this in mind can help teams and individuals move forward faster, as critics are better accepted by the owner of the requirements, and reviewers have realistic expectations of what needs to be done without demanding perfection. Another good way to look at review sessions is to think of them as a negotiation. In his book “Never Split the Difference” former FBI hostage negotiator, Christopher Voss, recommends to never come to a negotiation so sure of what you know and want, that you are willing to reject something better if offered. This also seems to be an appropriate attitude, when entering a technical conversation with a highly skilled group, while trying to reach consensus.
Origin of Requirements: from System-level to the Individual Components
In a proper design process, product requirements are defined from system-level to part-level (e.g. what the final portable electronic product must be capable of doing, first; the specs of the microcontroller that will run the algorithm and actuate outputs based on sensed signals, second), while test and validation are done from part-level (check the microcontroller functionality, first) to system-level (check product functionality, last). If a given requirement cannot be verified, then it must be redefined in a way that it can be; otherwise the requirement becomes invalid. Proper understanding of how the requirements came to exist and why, is a key step before going into the implementation phase, and even more so before validation. Following a systematic approach during requirement definition, from system level to part level, allows for better visualization and scrutiny.
Recap
There are at least two key points to keep in mind during requirements definition:
There needs to be proper understanding as to where and why the requirements (the “what”) came to exist: what must my product achieve?… and, why? Once this is reached, requirements can be derived from system level to part level.
Always assume the requirements are wrong, to some degree. In their most recent state, requirements have been derived from the best compromise between all variables considered, and based on the collective knowledge of the team members.
Comments