Purpose

The customer requirements delineate, in detail, what the customer needs and how the project will serve those needs. Requirements represent a detailed breakdown of the customer’s expectations for the project, as well as how the project organization will serve those requirements. Requirements documentation provides long-term guidance for development of the work breakdown structure (WBS) and support for
the customer and the project organization as they work toward concurrence on what the project needs to achieve. The customer requirements document serves as an ongoing reference as to what elements of project work are either in scope or out of scope, and in some cases, provides insight into the degree of importance of some elements of scope.

Application

Depending on the nature of the document (functional or technical), it will have radically different applications. The functional requirements document addresses the needs of the customer as expressed in terms of performance. The technical requirements document addresses how those needs are to be met. The functional requirements document is outlined in terms of performance, capability, and customer expectations. The technical requirements document is also outlined in those terms, coupled with the technical response about how those needs will be served.

Because of the unique nature of projects, project requirements documents may look different, even when they are generated by the same organization. The template included here is for use as a frame of reference and may lack elements specific to the environment(s) of some organizations, like the NASA version from wich it was originally adapted.

Content

The project requirements document should include details about the specific needs of the project, rather than details about the environment in which they will be developed or the personnel and resources that may be assigned to the project (unless specific resource needs are essential to project success). Again, as was suggested before, the information embedded in this document will vary from project to project, but these are among the core elements that need to be considered. Let’s look at the project requirements document outline in a little more detail.

1.0 Scope

1.1 System/Product Definition    The system/product definition section serves as an overview of what the system or product is to do, including a general description of the use of the system or product by the end user. This information is normally derived from the contract or memorandum of understanding.

1.2 Basic Approach   The  basic  approach  section  explains  how  the  project organization will develop, produce, organize, or implement the system or product defined in Section 1.1. This information is sometimes described in the project contract or memorandum of understanding, but may also be a product of the project team after the contract has been signed.

1.3 Alternative Approaches    The alternative approaches section contains descriptions of alternatives considered or which may be considered if the basic approach (Section 1.2) is deemed unacceptable or unworkable. These are normally developed by the project team as fallback or fail-safe positions, but may also serve simply as evidence that other approaches were considered.

2.0 Documentation Requirements

This information on documentation requirements is generated by the project team through interviews, process assessments, contract reviews, and other methods and approved by the project sponsor and/or customer. Documentation is stored centrally to afford access to stakeholders, team members, and functional support on an as-needed basis.

2.1 System/Product Documentation   System/product documentation is required to ensure proper implementation or use of the new system, process, or product. The requirements may also include details on the forms and formats the documentation must take.

2.2 Support/Process Documentation   Support/process  documentation  is  required during the development of the system, product, or process to provide background, support, status, and development updates. The requirements should delineate not only the type of documentation, but the frequency with which it should be generated. This will also include the process for approvals and acceptance of documentation, status communications, and change order documentation.

3.0 System/Product Requirements

System/product information  is  generated  by  the  project  team  through  interviews, evaluations, feasibility studies, and other methods and approved by the project sponsor and/or customer. Documentation is stored centrally to afford access to stakeholders, team members, and functional support on an as-needed basis.

3.1 Characteristics/Performance The  characteristics/performance  section  deals with how the system, product, or process should perform and to what degree. This may come from the original contract or memorandum of understanding, but must be documented sufficiently to clarify what is/is not acceptable performance for the project deliverable(s).

3.2 Characteristics/Physical Details on what the system, product, or process should look, feel, taste,  sound, and smell like are provided in the characteristics/physical section. This may come from the original contract or memorandum of understanding but must be documented sufficiently to clarify what are/are not acceptable physical attributes for the project deliverable(s).

3.3 Maintainability/Reliability The maintainability/reliability  details  describe  the level of effort required to keep the project deliverable(s) functional to a level acceptable to the customer and/or end user. This should include any specific long-term maintenance expectations as well as a perspective on the life span of the deliverable(s).

4.0 Design, Development, and Construction Requirements

4.1 Logistics/Maintenance    Facilities, material, and organizational support required during the design and development phases are covered by the logistics/maintenance section. This may include specifications as to what property will be furnished by the client organization and what logistics will be managed by the project organization.

4.2 Personnel/Training    Training and personnel support required during the design and development phases are documented here. This includes personnel needs from both the client and project organizations and any training required to facilitate their efforts during project design and development.

5.0 Inspection and Review Requirements

5.1 Inspections/Validations  The  inspections/validations  section  documents  any mandated inspections or validations that were established contractually.

5.2 Reviews/Status    The review/status section includes any regular reviews, status reports, progress reports, forecasts, or other project assessments required by both the client and project organizations. The requirements should delineate not only the type of documentation, but the frequency with which it should be generated and to whom it goes. (In some instances, this will overlap with or replace Section 2.2.)

5.3 Testing    Any system, process, or deliverables testing established contractually or required by virtue of organizational protocol is documented here. This should include details on the frequency of any such tests.

6.0 Packaging/Support

6.1 Final Preparation The final preparation section details any steps required to take the finished deliverables from their production state to implementation. This may include expectations in terms of packing, crating, formatting, or final presentation.

6.2 Packaging   In some instances, this section will be a reiteration of Section 6.1. In others it will determine the long-term packaging requirements for the deliverables as they are transmitted to the customer and/or end user.

6.3 Transition The transition section includes any lingering training, conversion, or delivery issues. It also defines the maintainability criteria (a metric or performance level required once the system is in operation) and any specific means for quality control after the project is handed off and in operation. This also often includes a list of the final signatories on a project and/or deliverable acceptance.

Approaches

Some organizations use the project requirements documentation as a catch-all tool for every issue from project risk to change control. Because the term requirements reaches across the breadth of the project, such applications are not unreasonable. Although the requirements document may capture a wide range of issues, however, it should focus on the needs that much be met to ensure project success.

Considerations

In building the project requirements document, managers may be tempted to fill in every field, even when the information is not yet available. If information is lacking for a particular component of the template, it is prudent to document such information as “currently unavailable,” rather than filling the void with guesswork. If guesses are mixed with the validated project information, it becomes challenging to discern which information is real and current and which is the author’s best guess.