Which of the following is a component of the project management plan that describes how requirements will be analyzed documented and managed?

National Project Management System
Business Projects-IT-Enabled

TITLE:

Scope Management Knowledge Area

1. EFFECTIVE DATE:

December 2010

2. AUTHORITY:

This policy-related document is issued under the authority of the Deputy Minister, Public Services and Procurement Canada (PSPC).

3. CONTEXT:

This Knowledge Area is to be implemented in conjunction with the PSPC National Project Management System (NPMS) Policy.

4. PURPOSE:

To describe the components and requirements of the NPMS as applied to the management of project scope.

5. DETAILS:

Project scope is the sum of the products, services, and results to be provided by a project.

Scope management considerations must be applied throughout the life of the project. In the NPMS Framework, scope management begins as a component of the preliminary project plan (PPP). Business Projects-IT-Enabled further develop the scope components found in the PPP during the Planning Phase as a component of the project management plan (PMP). In larger, more complex projects, a separate scope management plan document may be created. The project scope management plan describes how the project scope will be defined, developed and verified and how the Work Breakdown Structure will be created and defined. The scope management plan "provides guidance on how the project's scope will be managed and controlled by the project's project management team".

The PPP is used to manage the project during the Identification Stage. The PMP is used to manage scope during the Delivery Stage. Completion of product scope is measured against delivery of the requirements, while completion of the project scope is measured against the PMP.

In the NPMS, a scope management plan is to be prepared for every project, whether as a component of the PMP or as a separate document. Associated documents are linked to the Scope Management Plan, such as the Work Breakdown Structure (WBS) and the work activities in the Project Schedule. The schedule contains the project work packages. These are to be updated throughout the project lifecycle as the project evolves. Updates reflect the scope refinement process or changes approved in accordance with the project Change Management Process. The Scope Management process is described below in relation to the nine phases of the NPMS.

Objectives

The purpose of Scope Management is to ensure the project includes all the work required, and only the work required, for completing the project successfully. In scope management the emphasis is on identifying and controlling what is or is not included in the project.

Consequently, the objective of this scope management process is to provide a methodology for:

• Describing the process and tools used to define the project scope;
• Developing a project scope statement;
• Defining and developing the Work Breakdown Structure;
• Describing the scope verification activities; and
• Describing how the project scope will be controlled.

Scope is defined and then refined during an iterative process that begins in the project identification stage and continues into the Delivery Stage. The process is conducted in consultation with subject matter experts (SMEs) and stakeholders, becoming increasingly detailed as the project progresses. The fully defined project scope will contain the following elements:

• Project goals, business outcomes and objectives;
• Product scope description;
• Project boundaries;
• Specifically excluded activities;
• Deliverables and associated acceptance criteria;
• Project constraints; and
• Project assumptions.

Scope Management Process by NPMS Stage and Phase

Inception Stage

Definition phase:

Conduct a preliminary assessment and document a business need or opportunity in the form of a Statement of Requirement document. The document does not outline high level project scope or refer to a solution at this point. It just requests that management provide seed funding for further analysis of the problem.

Identification Stage

Initiation phase

Provide a high-level preliminary scope statement in the PPP along with a set of proposed milestones and deliverables. During the Initiation Phasse projects define the business requirements and may document a high-level target business vision to address the business need or opportunity. The business vision and the business requirements are the framework upon which the project scope is primarily built; however, constraints such as those related to cost and time may limit the scope.

Feasibility Phase

Projects may conduct an environmental scan to review available technical solutions to the business problem and to assist in the feasibility assessment process. The feasibility report identifies all of the viable options and the potential high-level activities related to each option. These will be subject to further analysis. A Conceptual Architecture Solution document is produced during the Feasibility Phase. A Concept of Operations document is either produced or an existing document is refined to reflect how a solution may operate once implemented. These documents provide support to the scope definition process.

Analysis Phase

During the Analysis Phase the Business Projects-IT-Enabled objective is to produce a Business Case which includes a recommended technical solution and a project charter which will contain a high-level scope statement. This forms the scope baseline, which will be controlled as the project progresses through its lifecycle.

To produce the Business Case and project charter, the Business Projects-IT-Enabled approach to scope management covers the following activities:

• Refine the high-level scope;
• Create the high-level WBS;
• Verify the high-level scope; and
• Control the scope.

In the Identification Stage, the focus is on controlling the scope of activities required to produce a Feasibility report, supporting technical documentation and the Business Case. If the solution is approved, a Project charter is produced. Both the Business Case and the project charter accompany a Treasury Board submission.

Scope control after PPA will include the control of project management scope, product scope and may also include controlling the scope of the business transformation.

The details of scope process activities are as follows:

1. Refine the Scope: The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that were initially documented in the PPP and refined as the baselined scope statement, milestones and deliverables in the project charter.
2. The complete project scope will encompass both product and project scope. Product scope includes the features and functions that characterize a product, service, or result that is to be delivered. Project scope consists of the work that must be done in order to deliver a product, service or result with the specified features and functions".
3. Create the WBS: The Project Manager organizes and defines the total scope of the project in smaller, more manageable pieces of work known as work packages, which together make up the Work Breakdown Structure (WBS). Each descending level of the WBS represents an increasingly detailed definition of the project work.
4. Verify the Scope: Scope verification involves formal acceptance of the project scope by stakeholders through reviews of deliverables to ensure that items identified as "in scope" for the project phase have in fact been completed satisfactorily. Scope verification also ensures that scope creep does not occur; scope verification occurs in conjunction with an assessment of schedule and cost impacts. Scope creep occurs when features and functionality are added without addressing the effects on time, costs, and resources, or without customer approval.
5. The project scope baseline is approved at preliminary project approval (PPA), and thereafter it is fully elaborated during the Planning Phase of the Delivery Stage. Scope is controlled during the Design and Implementation Phases. Proposed and approved changes are managed via the project Change Management Process.
6. Note: Change Management is the process of controlling changes to the infrastructure, to processes, to project deliverables or to any aspect of services, in a controlled manner, enabling approved changes with minimum disruption.

Identification close out phase

The purpose of the identification close out phase is to ensure an appropriate level of assessment, reporting, evaluation, hand-over exchange, and administrative closure has taken place. A formal close out provides enough directional detail for the (delivery organization) Project Manager to seamlessly proceed to the Delivery Stage.

In light of the PPA decision, obtained in the Analysis Phase, project teams ensure that the final records project plan prepared in this phase is updated including the Scope Statement and the high-level WBS.

Delivery Stage

Planning Phase

During the Planning Phase the scope baseline produced earlier is fully elaborated and work packages are produced that capture all of the project management and product delivery activities that need to be conducted.

During the Planning Phase, the Business Projects-IT-Enabled approach to scope management involves a recapitulation of the following scope process activities but at a much more granular level than previously. Project teams:

• refine the scope;
• create the WBS;
• verify the scope; and
• control the scope.

Additional scope products include the functional and non-functional requirements and the Logical Architecture document. During the Planning Phase, the Concept of Operations is updated to reflect the more granular view of the business solution. An initial transition plan is produced:

• to outline how the organization and project team will release the final products and processes to production; and
• to describe how current and new business processes will be maintained during and subsequent to the project.

Design Phase

During the Design Phase, the Logical Architecture document is further updated to reflect the Physical Architecture Design. A Migration Plan is produced to outline how existing elements will be incorporated into the enterprise architecture as final products and processes.

As these products are produced and then updated, it is essential to conduct both scope verification and control activities.

Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with meeting the quality requirements specified for the deliverables. Quality Control is generally performed before scope verification, but these two activities can be performed in parallel. Scope verification takes place at the end of each major project phase or milestone.

The final scope is approved at the effective project approval (EPA) control point.

Implementation Phase

As the project progresses through the Implementation Phase, further changes to scope may be proposed as a result of testing and/or the Quality Control Process. These proposed changes need to be approved and their implementation controlled as follows:

Control the Scope: Changes to scope may impact cost, schedule and quality. Scope control is the process that the Business Projects-IT-Enabled uses to ensure that potential changes to the project scope are carefully analyzed to identify the reason, justification, value, and impact of each change. Changes must be approved by the project governance process described in the project charter and managed in accordance with project's Change Management Process, which is normally contained in the PMP.

Delivery Close-Out Phase

Once the project is complete, the project team prepares the Project close out document, including lessons learned and conducts the administrative and contract close out activities, documenting the project Close Out process thoroughly. The WBS and any other subsidiary scope management documents such as the change log attached to the scope management plan must be updated to summarize all scope changes that were proposed, and if the change was approved the log details the implementation activities and the consequences of the change activities.

6. SCOPE:

This Scope Management Knowledge Area applies to all PSPC Business Projects-IT-Enabled.

7. DEFINITIONS:

8. RESPONSIBILITIES:

All parties responsible for developing scope management plans are strongly encouraged to consult with other project leaders/managers and senior project managers when developing the Scope Management Plan. It is also recommended that Project Managers seek advice from technical experts and other SMEs and consider historical information and lessons learned from similar projects within PSPC when producing/updating the WBS, schedules and plans.

Project Lead (Business Side)

The Project Director/Project Lead defines the business need or opportunity, leads the identification stage activities and represents the client during delivery. The specific responsibilities include:

• Planning, controlling and providing overall management oversight of the entire project in accordance with the NPMS Framework for Business Projects-IT-Enabled;
• Setting general direction and priorities;
• Authorizing all planning documents;
• Reviewing and endorsing the project charter;
• Approving the project management plan and other project deliverables;
• Being accountable for budgets;
• Recommending major changes that impact scope, time and cost;
• Approving changes that do not impact hard milestones and costs;
• Monitoring progress;
• Assigning/authorizing resources;
• Liaising with the project steering committee;
• Acting as primary project interface between the business and the project teams; and
• Being accountable for any project procurement activity (or delegates this to a procurement manager).

Project Manager

The Project Manager is responsible for the overall management of project scope. The specific responsibilities include:

• Developing the Scope Management Plan and ensuring that the project team is aware of and follows its processes in performing their associated responsibilities;
• Developing the project scope statement;
• Eliciting project and product scope input from stakeholders;
• Documenting the project scope;
• Creating the WBS;
• Verifying project scope;
• Controlling project scope; and
• Reporting on project scope.

Project Sponsor

The Project Sponsor is responsible for the following activities:

• Providing input to the scope analysis and definition process;
• Supporting the Project Manager in the development of the scope statement; and
• Approving the project scope baseline and all significant changes to the project scope.

Project Team

The Project Team is responsible for the following activities:

• Providing input to the scope analysis and definition process;
• Supporting the Project Manager in the development of the scope statement and the scope management plan;
• Developing and maintaining the associated project documentation deliverables that contain the fully elaborated project scope;
• Performing their assigned tasks without deviating from the approved scope; and
• Submitting change requests that may impact project scope as and when required.

Requirements Analyst

The Requirements Analyst is responsible for the following activities:

• Maintaining a matrix of all approved requirements;
• Coordinating with competency centres;
• Participating in the requirements change control process;
• Applying changes to the requirements matrix; and
• Maintaining the modification history of requirements.

Business Analyst

The Business Analyst is responsible for the following activities:

• Eliciting the business, functional and non-functional requirements; and
• Producing the business requirements and the Functional and Non-functional Requirements documents.

System Analyst

The System Analyst is responsible for the following activities:

• Defining the system requirements;
• Creating System Requirements Specifications from the functional and non-functional requirements; and
• Testing and delivering functionality to meet the system requirements specifications.

Technical Team

The Technical Team is responsible for the following activities:

• Developing technical specifications and plans; and
• Testing and delivering functionality to meet the technical specifications.

Quality Manager

The Quality Manager is responsible for the following activities:

• Verifying that the delivered product satisfies the approved requirements; and
• Documenting the results of the requirements verification in a system testing summary report.

Stakeholders and Subject Matter Experts (SME)

The stakeholders and SMEs are responsible for the following activities:

• Providing input to the project scope analysis and definition process; and
• Supporting the Project Manager in the development of the scope statement and the Scope Management Plan.

9. REFERENCES:

• Statement of requirements (SoR)
• Project Screening Tool
• Preliminary project plan (PPP) « Full »
• Preliminary project plan (PPP) « Lite »
• Feasibility report (FR)
• Project management plan (PMP)
• Business Case « Full »
• Business Case « Lite »
• TBS Business Case Guide
• Project charter « Full »
• Project charter « Lite »
• TBS project charter Guide
• Change Request Form
• Change Request Log

10. ATTACHMENTS:

• Annex A - Requirements Management Process

11. ENQUIRIES:

Please direct enquiries about this Knowledge Area to the Director, Centre of Excellence, ITSB Project Delivery Office.

Annex A - Requirements Management Process

Introduction to Requirements Management

Background

Requirements management is an iterative process aimed at defining the business, functional and non-functional and technical requirements to design, develop, implement and maintain a product throughout its lifecycle. An effective project requirements management process must take into account changes to plans, designs and products that may occur at any stage up until product implementation.

The requirements management process establishes a baseline for developing a custom solution, for acquiring and integrating a Computer Off The Shelf COTS product or for re-designing business processes without employing a technological component. Requirements management ensures that plans, work products and activities are consistent with the requirements and satisfy the business need.

The purpose of requirements management is to ensure that requirements are traceable and changes are consistently managed.

The purpose of the project requirements management process is to document how customer requirements are to be collected, recorded, managed, modified and reconciled for final delivery of the product's technical solution.

In smaller projects, the requirements management process is contained in the PMP; in larger, more complex projects there may be a need for a separate Requirements Management Plan.

Objectives

The objective of the Requirements Management Process is to provide a methodology for:

• identifying the scope of what is managed;
• identifying the roles and responsibilities of those involved in this process;
• defining how requirements will be recorded, tracked and modified; and
• identifying the tools to be used.

Roles and Responsibilities

Project Manager

The Project Manager is responsible for the overall management of requirements. The specific responsibilities include:

• Ensuring that the project team is aware of and follows this plan, its processes and associated responsibilities;
• Reviewing and approving the requirements management plan;
• Ensuring that requirements management complies with project change management processes;
• Communicating requirements impact to the customer;
• Negotiating requirements modifications when needed; and
• Reporting on requirements activities.

Requirements Analyst

The Requirements Analyst Team is responsible for the following activities:

• Maintaining a matrix of all approved requirements;
• Coordinating with competency centres;
• Participating in the requirements change control process;
• Applying changes to the requirements matrix; and
• Maintaining the modification history of requirements.

Business Analyst

The Business Analyst is responsible for the following activities:

• Eliciting the Business, Functional and Non-functional Requirements; and
• Producing the Business Requirements and the Functional and Non-functional Requirements documents.

System Analyst

The System Analyst is responsible for the following activities:

• Defining the system requirements;
• Creating System Requirements Specifications from the Functional and Non-functional Requirements; and
• Testing and delivering functionality to meet the system requirements specifications.

Technical Team

The Technical Team is responsible for the following activities:

• Developing technical specifications and plans; and
• Testing and delivering functionality to meet the technical specifications.

Quality Manager

The Quality Manager is responsible for the following activities:

• Verifying that the delivered product satisfies the approved requirements; and
• Documenting the results of the requirements verification in a System Testing Summary Report.

Subject Matter Expert (SME)

The SMEs are responsible for the following activities:

• Providing input to the requirements analysis process; and
• Supporting the Technical Team in the development of Specifications, Testing and other Technical Solution documents.

Requirements Management Process

The Requirements Management Process starts in the project identification stage when business needs are identified and business requirements are defined. After PPA when the preferred solution is approved, further analysis is conducted. During the Planning and Design Phases, high-level requirements are progressively refined and detailed. The end result is a highly granular specifications document and a traceability matrix, which will be used by the technical team to build and test the solution in the Implementation Phase. The Requirements Management Process links with the project Change Management Process to manage changes in the Planning and Execution Phases.

The Requirements Management Process covers the following activities:

• Identify Requirements;
• Evaluate Requirements;
• Validate and Prioritize Requirements;
• Obtain Approval and Baseline;
• Conduct Analysis and Detailing of Requirements; and
• Control Changes to Requirements.

Figure 1 - Requirements Management Process

A larger image of this diagram - Requirements Management Process, is available on a separate page.

Identification Stage

In the project identification stage, stakeholder needs are identified through project meetings with various stakeholders. These stakeholder needs are then transformed into high-level requirements and are approved by the client or the project steering committee.

Identify Requirements

The client approves the list of key stakeholders from whom the project will elicit customer needs. Based on this list, the project's Business Analyst identifies customer needs through appropriate elicitation techniques (e.g. interviews and/or Joint Application Development (JAD) Sessions and or workshops and or meetings) with various stakeholders. These stakeholder needs are then analysed and evaluated to determine the high-level requirements. Existing business processes/procedures/manuals and previous studies will be reviewed to determine other high-level requirements.

All policies, legislations, acts and regulations that could potentially be impacted by the project will be identified to determine high-level requirements and recorded in and documented during the Feasibility Phase.

Inconsistencies or conflicts in stakeholder requirements will be addressed through a process of negotiation with the affected stakeholders. All the high-level requirements are recorded in the Business Requirements (BR) document and in the Requirements Traceability Matrix (RTM) that will be created after client approval (PPA).

Evaluate High-Level Requirements

Each high-level requirement is evaluated by the Business Analyst in consultation with the client and or SME, to ensure it is supportable for product development according to the criteria below:

• Correct - Each requirement is one that the system or a component product shall meet. No requirement disagrees with another requirement;
• Necessary - Each requirement is an essential capability, physical characteristic or quality factor. Deletion of the requirement would cause an unacceptable deficiency in the product;
• Clear - Stated so that the requirement is unambiguous. That is, each requirement can have one and only one interpretation;
• Attainable - Feasible within the current environment and achievable at a cost that meets the existing budget, schedule and other project plan constraints; and
• Traceable - The origin of each requirement is clear and can be traced forward to other products.

The Business Analyst will correct, restate and update identified deficiencies in the BR document.

Validate and Prioritize High-Level Requirements

A team of stakeholders validates the high level requirements. A Requirements Management Plan defines a representative sample of stakeholders and specifies which ones will participate in the validation procedure. The list of participants may include all stakeholders, stakeholder representatives, or key stakeholders.

Following validation, requirements will be prioritized as to whether they are critical, important or useful. (Refer to Priority Assignment Criteria below).

The approach for validation and prioritization of high-level requirements may be group meetings and/or another suitable approach.

The approved priority for each requirement will be documented in the RTM that will be created in the next activity.

The Project Manager verifies with the sponsor that the high-level requirements represent the various stakeholders' needs.

Priority Assignment Criteria

Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.

Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.

Features that are useful in less typical applications or for which reasonably efficient workarounds can be achieved will be used less frequently. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.

Obtain Approval & Establish Baseline

Sign-off for the high-level business requirement is obtained from the client in order to ensure a common understanding. The approved requirements will represent the baseline for project planning purposes; any further changes will follow the Change Management Process.

Having obtained approval from the client, the project team creates the Requirements Traceability Matrix (RTM) during the Analysis Phase.

Initially, the RTM will contain the following fields:

• Unique identifiers for each high-level requirement;
• Stakeholder needs IDs (optional);
• High-level statements describing stakeholder needs;
• Requirement Type (see Requirements Analysis section);
• Requirement Priority (note: this is not the same as the stakeholder priority - this is the priority set by the project steering committee);
• Verified - to show if a requirement has been verified. They could be recorded as yes "Y", no "N" or by date; and
• Other fields will be added as required.

Delivery Stage

Planning Phase

In the Planning Phase, after the project has been given preliminary project approval (PPA), the Project Manager reviews the Business Case, project charterandthe high-level business requirements produced in the Identification Stage. In this Phase, requirements are refined and changes are controlled. The documentation that is produced includes the Functional, Non-Functional, System Requirements Specification (SRS) and updated RTM documents.

Conduct Analysis and Detailing of Requirements

During the Planning Phase, high-level requirements are categorized into functional and non-functional system requirements. From these high-level requirements, detailed system requirements are elaborated during the Design Phase. The system requirements are a comprehensive description of the intended purpose and environment for the business process, software or infrastructure that is under development. The requirements fully describe what the process, software or infrastructure will do and how it will be expected to perform.

• Functional requirements capture the intended behaviour of the system (functionality). This behaviour may be expressed as services, tasks or functions the system is required to perform. It is most often represented in the form of declarative statements and use cases;
• Non-functional requirements define the constraints that the new software solution must conform to. These requirements don't describe what the system does, but rather how well it does the things it does. Non-functional requirements include: usability, portability, accessibility, privacy, reliability, availability, efficiency, integrity, security, safety, robustness, performance, testability, maintainability, reusability, etc; and
• The requirements will be documented in the functional requirements document, the non-functional requirements document and in the updated RTM. Any issues identified during the analysis of requirements that could trigger changes to existing policies are documented in the Policy Change Requirements document.

Each requirement is refined into more precise, well-defined system requirements. Properly constructed requirements must be actionable, measurable, testable, ascribable to identified business needs, and defined to a level of detail sufficient to enable system design.

Planned verifications of requirements will follow the Quality Management Process. During requirements verification, the Project Team will verify with the Technical Team that the functional/non functional requirements represent the fully elaborated business requirement.

All requirements not meeting verification standards will be corrected before proceeding to the next activity.

Sign-off for detailed requirements will be obtained from the client in order to ensure a common understanding before proceeding to the Design Stage. Subsequent to approval, the RTM will also be updated to include details of refined requirements.

The detailed requirements are documented in the appropriate section of the RTM. The RTM will also be updated to include details of refined requirements. The additional attributes are listed here and shall be used as required.

• Subsystem (optional - where changes are being made to an existing system where the subsystems are already known - the requirements can be traced to the subsystem);
• Relative Effort - to implement the requirement. They should be recorded as "H or M or L" indicating a high, medium, or low level of effort to implement the requirement. Whether the effort is considered high, medium or low will depend on the availability of qualified resources and project constraints;
• Use Case (optional - to eventually record the use cases associated with the requirement);
• Release (optional - to eventually record which release the requirement will be implemented in); and
• Test Case (optional - to eventually record the test cases associated with the requirement).

Specifications (Product Design)

The detailed requirements will be used by the System Analyst to create a System Requirements Specifications (SRS) document. Each of the system requirement specifications contained in this document must be defined to a sufficient level of detail to enable product development and testing. That is to say, detailed specifications clearly describe what will be done and how well it will be done so that:

• a developer can create what has been described; and
• subsequently, a tester can measure the success or failure of the product to meet the explicit terms of that product specification statement.

The RTM will be updated to include the system requirements specifications.

Planned verifications of specifications will follow the Quality Management Process. During design verification, the Project Team will verify with the Technical team that the system requirements specifications meet the system requirements. The Technical Manager in consultation with the Project Manager will approve the specifications.

All specifications not meeting verification standards will be corrected before proceeding to the next activity.

Across All Project Stages and Phases

Control Requirements

Change Management Process

The Project Change Control Management Process will be used to manage deletions, modifications and additions to requirements, as well as any changes to the supporting schedule, costs and resource allocation.

If new or additional stakeholder needs are discovered after the baseline requirements have been established, the Change Management Process will be invoked to evaluate any changes related to these new needs, before additional requirements are added to the RTM. Once approved, these new requirements will be added to the original baseline. Once this is done, this iteration becomes the new baseline representing the stakeholder needs.

Requirements Traceability

The project will maintain and control the relationship between each unique requirement and its source in the RTM for the use of the design, build, test and deployment teams. As illustrated in the following diagram, a unique specification identifier provides a linkage from business requirements to functional and non-functional requirements, to design specifications and finally to test cases. The RTM is the document that ties all the other requirements documentation together.

Requirements traceability will allow the project to understand how a change (or change request) to a requirement will impact other requirements; upstream and downstream. Requirements traceability will be implemented so that, whenever any requirement is changed, all parent and child requirements, software components, and test cases impacted by the change are identified.

The project will follow the traceability reference model depicted below.

Traceability Reference Model

A larger image of this Traceability Reference Model, is available on a separate page.

Requirements Management Techniques and Tools

The following requirements techniques can be used by the Project Team to gather requirements:

• Joint Application Development (JAD) Sessions;
• Interviews;
• Survey questionnaires;
• Prototype(s);
• Pilot (s); and
• and/or other techniques.

As illustrated in Figure 3 - Requirements Management Tool, requirements may also be derived from the test summary results, user change requests and approved via the change management activities.

Traceability will be implemented using tools such as Rationale Requisite Pro or similar tool(s).

The requirements management tool will allow the Project Team to find, document, organize and track changes to customer requirements, software specifications and test cases.

The diagram below illustrates how an integrated tool suite and add-ons can be used to manage requirements, change and configurations in projects.

Requirements, Change and Configuration Tools Integration

Figure 3 - Requirements Management Tool

A larger image of this Requirements Management Tool, is available on a separate page.

Is a component of the project management plan that establishes the criteria and the activities for developing monitoring and controlling the schedule?

Which document contains the information that describes how the formal verification and acceptance of the project deliverables will be obtained?

Which of the following processes subdivides project deliverables and project work into smaller more manageable components?

What are the three components of project management plan?