<aside> 🚩 A Product Requirements Specification (PRS) is a document containing all the engineering requirements for a design - i.e., the engineering conditions that are satisfied by all interventions that can be said to satisfy a Design Brief.

</aside>

• On This Page

What is a PRS?

A PRS is a document in which you define, specify, quantify, and justify the engineering Requirements for your project.

Read about the form of requirements.

Simply put all your Requirements into a numbered list, grouped according to which of the five attributes each requirement addresses.

• Putting them in a numbered list makes it easier to refer to them elsewhere in your work.
• This also lessens the amount of duplicated and redundant information, which is always preferred from a project management point of view.
• Grouping requirements according to the five attributes helps ensure that all the aspects of the intervention throughout its life are accounted for.

A PRS is a living document - it will change and grow throughout your project.

• This means you do not have to set all the Requirements at the beginning of the project.
• You must add a Requirement only when you know (i.e., can justify) that it's a necessary result of information and reasoning you have already carried out on the project.
• This means you must review and revise your PRS often and throughout the project.

Requirements in a PRS must be internally and externally consistent.

• Consistency means that satisfying a given requirement cannot lead to a necessary violation of another requirement.
• There is no intervention that can satisfy an inconsistent set of requirements. Maintaining consistency of requirements is therefore essential to any successful project.
• You must review your PRS often, and especially when you change or expand your PRS, to ensure that the set of requirements as a whole remains consistent.

A PRS must not contain redundant requirements.

• Minimizing the amount of information needed to capture the set of requirements for a given problem is important: it reduces overhead work, streamlines project management, and reduces the odds of design errors later in the process.
• A requirement is redundant if it occurs more than once in a PRS, or if it is a logical result of other, existing requirements.
• You must review your PRS often, and especially when you change or expand your PRS, to ensure that the set of requirements contains no redundancies.

See Project Reporting Templates for a template for this document.

However

Situational Requirements will be the first requirements you set.

• At the start of a project, you will only know about the Design Brief and any research you've conducted on the context and environment of use.
• Therefore, at the start of a project, you must focus on the situational requirements.
• As you begin to develop your intervention, you'll be able to add other, internal requirements. Those internal requirements must, however, remain consistent with the situational ones.
• As the course proceeds, your instructors will indicate what other information must be included in your PRS.

Checklist

• Are all the requirements in the correct form?
• Are all the requirements necessary to satisfy the Design Brief?
• Is each requirement consistent with all other requirements?
• Is each requirement justified with respect to the Design Brief, Situational Knowledge Base, and the laws of nature?
• Is each requirement categorized under an appropriate attribute, and is the categorization well justified?
• Have any extra attributes been rewritten as functions or constraints?
• Is there a Design Issue for any named constraint still lacking a value or range of values?