0 оценок0% нашли этот документ полезным (0 голосов)
581 просмотров1 страница
This document provides a checklist for evaluating a requirements traceability matrix (RTM) for a software project. It addresses whether the RTM complies with standards, whether the initial requirements have been approved and put under configuration control, and whether processes are in place to review and update the RTM frequently to reflect changes. The checklist also evaluates whether the RTM demonstrates bi-directional traceability between requirements and other project artifacts like design, code, and test cases, and whether it tracks the verification of requirements.
This document provides a checklist for evaluating a requirements traceability matrix (RTM) for a software project. It addresses whether the RTM complies with standards, whether the initial requirements have been approved and put under configuration control, and whether processes are in place to review and update the RTM frequently to reflect changes. The checklist also evaluates whether the RTM demonstrates bi-directional traceability between requirements and other project artifacts like design, code, and test cases, and whether it tracks the verification of requirements.
This document provides a checklist for evaluating a requirements traceability matrix (RTM) for a software project. It addresses whether the RTM complies with standards, whether the initial requirements have been approved and put under configuration control, and whether processes are in place to review and update the RTM frequently to reflect changes. The checklist also evaluates whether the RTM demonstrates bi-directional traceability between requirements and other project artifacts like design, code, and test cases, and whether it tracks the verification of requirements.
Have standards/guidelines been identified to define the Maintenance Plan?
Does the Maintenance Plan format conform to the specified standard/guideline? Has the project submitted any request for waivers/deviations to the defined work product? Have the following areas been addressed completely? • Approval authority? • Revision approval? • Revision control? Software Requirements Traceability Matrix Contents Verifiability P/F Comment Has the initial Software Requirements Specification (SRS) document been approved? Is the approvied SRS under configuration control (i.e., baselined)? Is the software requirements traceability Matrix (SRTM) part of the requirements management process? Currency P/F Comment Is there a process for reviewing and approving changes to the SRTM? Is a criteria used for identifying reviewers? Is the SRTM updated and maintained with the appropriate frequency? Does the SRTM reflect new/derived/updated requirements? Traceabil ity P/F Comment Are all software requirements from the SRS included in the SRTM? Does the SRTM reflect bi-directional traceability? • Are software requirements mapped back to system requirements?
• Can derived requirements (e.g., functional requirements) be traced back?
• Are software requirements mapped to interfac requirements/design? Are software requirements mapped to coded modules? Are software requirements mapped to test cases? Does the SRTM contain test verification status? If not, does a corresponding software requirements verification traceability matrix (SRVTM) exist? Does the SRTM or SRVTM reflect the method of verification (i.e., test, demonstration, inspection, analysis)? Are the safety critical requirements uniquely identified? Are the security requirements uniquely identified? Format P/F Comment Are unique identifiers used for requirements? If not numbered sequentially, is the numbering scheme traceable?