A product requirements specification (PRS) is the official document of the things a designed artifact must be and do, to address an unbalanced situation.
A product requirements specification (PRS) is the description of an engineering design “problem” in the language of engineering. Most importantly, a PRS specifies the high-level requirements that a designed intervention must satisfy to be considered an appropriate “solution”. Additionally, a PRS must include detailed justifications for the requirements.
Because of the need to justify requirements, a PRS will include all the elements described in the Design Roadmap for the Problem Analysis stage. In this course, we emphasize the needs and expectations of human users; in real life, a variety of other aspects must be included: cost, manufacturing, end-of-life requirements, etc.
Documented requirements are important for three reasons:
If the requirements are not as crisply defined as possible, there is little chance that a design intervention will actually address the underlying imbalance. Furthermore, vague requirements will often lead to designs that just do not work, or are inadequate in one regard or another. Interventions that are not designed in the context of crisp requirements will fail in the marketplace and thus benefit no one at all.
Simple problems do not require detailed specification documents for requirements because they are simple enough to be dealt with directly. However, virtually all “real world” engineering problems are complex, including many coupled requirements, any one of which can result in a failed intervention if they are not carefully specified, studied, and understood by the design team.
On the one hand, the more precisely specified a set of requirements (via a PRS), the easier it will be to design a proper intervention. However, because of coevolution, it is not possible to define all the requirements at the outset of a design project. Designers must balance these two opposing forces: one wishes to have as many requirements defined as crisply as possible at the beginning of a project, without specifying any requirements that imply having already made decisions about suitable interventions.
At the outset of a new design project, you will only be able to specify some of the top-level requirements - the requirements that apply to the intervention as a whole. As the project proceeds, you will find you can gradually increase the number of requirements - this is an outcome of coevolution. This means you will have to revisit your requirements often, to ensure that they are as accurate as possible and as complete as you can make them at that point in the process.
An excellent way to achieve this balance is to focus on only one level of a system hierarchy at a time. For instance, if one is designing a jet liner, one does not focus on the requirements of the engines, but rather only on the requirements of the jet liner as a whole. As coevolution proceeds, there will be ample time to worry about the engine's requirements (assuming there even is one).
A PRS is a collection of certain information, intended to document the engineering requirements for a project. As such, a PRS contains all the deliverables for each step of the problem analysis stage of the design roadmap.
A PRS is never really complete. At every step in a design process, new issues will come to light that impact on the design. The PRS should reflect those discoveries. This means that teams will usually have to revisit their PRSs regularly, to ensure that it reflects the latest information and preferences of the team.
The best time to re-check a PRS is at a major milestone (i.e. each project gate) in the project. For example, once a design concept has been selected for the product, it makes sense to go back to the PRS and make sure that it is still valid with respect to the concept that was selected.
This is facilitated by Google Docs. It maintains automatic revision history for you. You can identify key versions by naming them.
Whenever a team changes its PRS, it should keep the old one in archive, and give the modified one a new version number.
So a PRS is a living document, one that changes with time. A corollary of this, which many people do not realize, is that a team need not have a complete PRS before proceeding with the next stage of a design process. Since the PRS will change, why bother trying to get every detail into it at the outset?
What you do need to do is to make sure that every requirement that can be specified and justified, is specified and justified at any point in the process.