The Project Scope Management knowledge area contains 6 processes, 4 of them in the Planning Process Group and 2 of them in the Monitoring & Controlling Process Group. The first planning process is that which creates the Scope Management Plan. The next 3 planning processes go from 5.2 Collect Requirements, where the requirements from key stakeholders are collected and analyzed, to 5.3 Define Scope, where the high-level scope from the Project Charter is defined in more detail in the Project Scope Statement, and finally to 5.4 Create WBS, where the detailed scope is broken down through the process to deliverables down the level of work packages.
This post goes into some detail of the two outputs of the first of these three planning processes, 5.2 Collect Requirements: Requirements Documentation and Requirements Traceability Matrix.
2. Requirements Documentation and the Requirements Traceability Matrix
How are these two outputs different?
The Requirements Documentation is the collection of the requirements from various stakeholders. The Requirements Traceability Matrix is the connection between the requirements, the stakeholders who originated them on the one hand, and the project deliverables which will fulfill them.
3. Requirements Documentation
The following is a list of the categories of requirements, together with an explanation of what purpose they serve, and a list of examples of these types of requirements.
|1.1.||Business requirements||Higher-level needs of the organization.||Business and project objectives|
|1.2||Business rules for the performing organization|
|1.3||Guiding principles of the organization|
|2.1||Stakeholder requirements||Needs of various stakeholders||Impacts to other organizational areas|
|2.2||Impacts to other entities|
|2.3||Stakeholder communication and reporting requirements|
|3.1||Solution requirements||Features, functions, and characteristics of product.||Functional (behaviors of product) and non-functional requirements (environmental conditions for product).|
|3.2||Technology and standard compliance requirements|
|3.3||Support and training requirements|
|3.5||Reporting requirements (with texts, models, etc.)|
|4.1||Project requirements||Actions, processes, or other conditions of product||Levels of service, performance, safety, compliance, etc.|
|5.1||Transition requirements||Temporary capabilities required to utilize product||Data conversion, training requirements|
|6.1||Quality requirements||Condition or criteria needed to validate successful completion of project deliverable.||Acceptance criteria|
|7.1||Requirements boundaries||Describes assumptions behind requirements, and interactions between requirements.||Requirements assumptions, dependencies, constraints|
4. Requirements traceability matrix
The requirements are traced back to the stakeholders who originated them. This is so that these stakeholders can be consulted if there is any change to the project which would affect these requirements. The requirements are traced to the external business needs and the internal strategic plan of the organization.
Finally, the requirements are translated into the overall project objectives, and then the detailed deliverables. Within the organization, the requirements are linked to the various life cycles of the product development and the functional areas of the organization that handle them.
The purpose of this matrix is to enable the analysis of the potential impact of any changes in the scope of the project as the project goes forward.
The requirements of the stakeholders are translated into the deliverables of the project through the creation of the Work Breakdown Structure, or WBS, which is the subject of the next post.
Filed under: Uncategorized |