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 is a document that captures the requirements of a design project in a quasi-formal way, plus all the supporting documentation necessary to justify and explain those requirements.
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.
A PRS is the second step of any major design project (the first being establishing a strategy and documenting that strategy in a PSS). Designs cannot be conceived of before really understanding the “problem” that is being “solved,” so developing a PRS must come before any actual design work.
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.
An excellent way to achive 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.
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?
As you build your PRSs, you will begin by feeling quite comfortable with the items you put into it. However, as you flesh it out further, you will begin to feel rather ambivalent. As you increase the level of detail of the PRS, your confidence in the detailed information will decrease. This is natural. You should stop adding detail to the PRS when your team finds itself uncomfortable with the implied reliability. Save the PRS, then set it aside and begin the next step of the design process. Your team can further refine it when it revisits the PRS later in the process.