4squareviews

Now that we have used process 5.2 Collect Requirements to not just collect, but to analyze, prioritize, and finally decide upon which requirements will go into the project, it is time to document them so that they can be referred to during the course of the project.   That is what this post is for:  to show the kind of documentation that you can use for requirements.

5.2.3.1 Collect Requirements:  Outputs

5.2.3.1 Requirements Documentation

All requirements should have the following characteristics–they should be …

• Unambiguous (measurable and testable)
• Traceable (someone should be assigned the responsibility for managing each requirement and there should be a stakeholder whom can be consulted if there are questions about the requirement)
• Complete
• Consistent (no contradictory requirements)
• Acceptable to key stakeholders

Here is a review from my post about the inputs to this process regarding the types of requirements a project can have.

1. Business requirements–these high-level requirements a) help the project align with the strategic objectives of the company, as well as b) assuring that the business need, i.e., the reason why the project has been undertaken, will be filled by the product, service or result that the project will create.   The source of these requirements can be found in the project charter and/or business case document.
2. Stakeholder requirements–These are requirements from a particular stakeholder or group of stakeholders.   These requirements are found by engaging with the stakeholders.
3. Solution requirements–What are the particular features, functions, and characteristics of the product, service or result that will meet the business and stakeholder requirements listed above.   Now we are getting into the details of what the product will turn out to be, and for that reason the source of these requirements will be subject matter experts.   There are two sub-types of solution requirements:
   • Functional requirements–what are the data, actions, or processes that the product should execute?
   • Non-functional requirements–these supplement functional requirements and describes the environmental conditions or qualities required for the product to be effective.   How reliable is the product?   How easy is it to use?   What technical or other support will it require for continued use?
4. Transition and readiness requirements–these are the temporary capabilities, such as a training requirements, that will need to be in place to transition to using the product.
5. Project requirements–these deal not with the scope of the product, as the categories above do, but with the scope of the project itself.    For example, what are the constraints on the budget and schedule?   (The quality requirements are a constraint that are dealt with in the category below.)
6. Quality requirements–scope is a constraint that deals with the completeness of the work, quality is a constraint that deals with the correctness of the work.    What are the conditions or criteria needed to validate the end result of the project?   Are there tests that need to be performed?   What is the inspection procedure going to consist of?   Is it important to get this spelled out at the beginning of the project so that the process of validation of the end result is a) objective and b) understood by the customer or the sponsor of the project.

So, these requirements range from the high-level (category 1) to the specific (category 3 and 4); stakeholder requirements (category 2) can be either high-level or specific.    The requirements can be related to either the scope of the product (categories 1-4) or the scope of the project (5-6).

Documentation of requirements should contain at a minimum

• the person responsible for managing the requirement
• the stakeholder to consult regarding the requirement
• the priority of the requirement

and can also contain additional explanations such as

• an executive summary of the requirement (for management)
• detailed descriptions of the requirement (for relevant stakeholders, subject matter experts, and project team members)
• attachments to illustrate or give further technical details on the requirement

One specific form of the requirements documentation is the requirements traceability matrix described in the paragraph below.

5.2.3.2  Requirements Traceability Matrix

The requirements traceability matrix is a grid that links product requirements to their origin (are they based on the project charter, the business case, specific stakeholders, etc.) and to the deliverables that satisfy these requirements.   It helps link the requirements to the business value of the project by linking to the business and project objectives.   By having them documented in this way, it helps the customer successfully validate (accept) the product at the end of the project.   And more importantly, it allows a framework for managing changes to the product scope during the course of the project.

Typical attributes used in the traceability matrix are:

1.  Identification–a unique identifier (001, 002, etc.), and a textual description of the requirement
2. Source–what business needs or strategic company objectives the requirements are linked to, or which stakeholder is the origin of the requirement (to consult regarding the requirement if necessary)
3. Owner–who is managing this particular requirement (usually someone on the project team or a subject matter expert)
4. Deliverables–what are the deliverables that satisfy the requirement
5. Status (approved, cancelled, active, assigned, completed)
6. Priority (used during the selection process, but can be referred to if changes need to be made during the course of the project)
7. Acceptance criteria (very important for the 5.5 Validate Scope process)

There is an example of what the Requirements Traceability Matrix looks like in Figure 5-7 on page 149 of the 6th Edition of the PMBOK® Guide.

The next process in elaborating the scope is 5.3 Define Scope, and that is the subject of the next few posts.

Filed under: Uncategorized |