Scope Planning

The scope of work defines exactly what will be done as a result of the project work. It's important to know exactly what is to be done to avoid wasting both time and money on tasks and activities that are not necessary to accomplish the project goals. That's why scope planning is so important. This chapter will address how to define the scope of work based on the requirements of the end result and the deliverables of the project.

Requirements Traceability Matrix

The requirements traceability matrix is a table that links requirements to their origin and traces them throughout the project life cycle. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope. This process includes, but is not limited to, tracking:

  • Requirements to business needs, opportunities, goals, and objectives
  • Requirements to project objectives
  • Requirements to project scope/work breakdown structure deliverables
  • Requirements to product design
  • Requirements to product development
  • Requirements to test strategy and test scenarios
  • High-level requirements to more detailed requirements

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved), and date completed. Additional attributes to ensure that the requirement has met stakeholders' satisfaction may include stability, complexity, and acceptance criteria.

Matrix Fields

These are suggestions only and will vary based on organizational and project requirements.

  • A unique identification number containing the general category of the requirement (e.g., SYSADM) and a number assigned in ascending order (e.g., 1.0, 1.1, 1.2)
  • Requirement statement
  • Requirement source (conference, configuration control board, task assignment, etc.)
  • Software requirements specification/functional requirements document paragraph number containing the requirement
  • Design specification paragraph number containing the requirement
  • Program module containing the requirement
  • Test specification containing the requirement test
  • Test case number(s) where requirement is to be tested (optional)
  • Verification of successful testing of requirements
  • Modification field (If a requirement was changed, eliminated, or replaced, indicate disposition and authority for modification.)
  • Remarks