One of several reasons for emphasizing product requirements includes enabling modeling and simulations of designs, as well as ensuring adequate verification and validation testing.
Recall the fundamental framing of a requirement as:
Note the framing (within the requirement) of a mathematical and/or experimental relationship where “Y” is the output as a function of “(x)” as the input….Y = f(x) or as a function of multiple inputs Y = f (x1, x2, x3…xn). Let’s expand on this for a moment:
Mathematical Relationship: framing the requirement as an output as a function of input(s), we’ve enabled design performance to be modeled with design simulation tools (“design by analysis”). Assuming accurate modeling/simulation of design performance, we can predict our ability to meet requirements and optimize design performance before we begin potentially expensive prototyping.
Experimental Relationship: we’ve also enabled design performance to be tested through experimentation, or a more formal test methodology, design of Experiments (DoE). Here we can determine the performance of a response variable (“Y”) as a function of input variables (x1, x2, x3…xn). We can also obtain a mathematical relationship through regression analysis and use it to our advantage as outlined above.
Referring to the diagram below, we can see where modeling/simulation of design performance fits into the requirements-design-requirements hierarchy.
Also, we can see where verification testing occurs, including the (potential) purpose of verification testing to validate the models/simulations. Finally note verification traceability from/to the requirement. With the requirement we asked “what the design shall provide” and verification testing we’re determining “does the design provide” the required performance.
Of course, waiting for a prototype to test may cost a lot of time and money, whereas an accurate model/simulation can be significantly advantageous. Much of this hinges on requirements, however, hence the emphasis on requirements in several previous articles.
Using Hierarchy In Complex Systems Requirements and Design
Emphasizing Product Requirements