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
Callback before_footer in local_aigrade component should be migrated to new hook callback for core\hook\output\before_footer_html_generation
  • line 7225 of /lib/moodlelib.php: call to debugging()
  • line 7292 of /lib/moodlelib.php: call to {closure}()
  • line 71 of /lib/classes/hook/output/before_footer_html_generation.php: call to get_plugins_with_function()
  • line 987 of /lib/classes/output/core_renderer.php: call to core\hook\output\before_footer_html_generation->process_legacy_callbacks()
  • line 154 of /mod/book/view.php: call to core\output\core_renderer->footer()