|
How do you ensure the business requirements defined at the start of the project are successfully transformed into the IT solution? As a project manager, we spend considerable effort tracking project issues, risks and project schedules. How often do we track business requirements to ensure the requirements are correctly developed? Without requirements traceability, projects run the risk of assuming business requirements will be translated into a solution once the initial business requirement specification or use case is defined. According to Carnegie Melon’s Software Engineering Institute, requirements traceability is “the ability to describe and follow the life of a requirement, in both a forward and backward direction”. Traceability indicates the requirement can be tracked from its origins, specification, development, deployment and use as the project executes across the project lifecycle. Cross-referencing and document-integration templates are two techniques to apply traceability. A requirements traceability matrix is one tool that supports the integration technique for traceability. The tool is simply a set of columns that track business requirements as that are developed into system requirements, code packages and test cases. When a requirement is identified, it is assigned an identification number and stored in a requirement repository. The requirement repository can be a MS-Word document or a formal requirement management system. Business requirements can also be translated into functional and non-functional system requirements. These requirements also received an identification number and the traceability matrix maps business requirements to system requirements. Table 1 depicts a sample traceability matrix: Business Requirement Id | Use Case Id | System Requirement Id | Design Specification | Code Package or Class | Unit Test Case | System Test Case | User Test Case | BR001 | UC001 | SYS001 | D100-01 | Person | UT001 | TST001 | UAT001 | BR002 | UC002 | SYS002 | D100-02 | Order | UT002 | TST002 | UAT002 | BR003 | UC002 | SYS003 | D100-03 | Order | UT003 | TST003 | UAT003 |
Table 1: Requirements Matrix Additional columns are added to accommodate use case designs, individual design specifications, the actual code package or class containing the code, and relevant unit, system and user acceptance test cases. Project teams may wish to include hyperlinks to the specific business requirement descriptions, use case scenarios, use case diagrams, code packages and other relevant system documentation. The matrix should be used as a guideline and can be augmented as needed. Depending on the methodology, some of these columns may not be relevant; however, regardless of the waterfall or iterative models, requirements need to be managed. The key is to inventory, track and map business requirements across the solution as they are implemented. The matrix can be created in a spreadsheet, word processing document or in a requirements management software package. HP’s Mercury Test Director supports mapping business requirements to individual test cases. The quality management process is supported with traceability as individual test cases are mapped back to individual requirements. This is a software COTS dependent approach, and those seeking a tool agnostic approach will find MS-Word or MS-Excel as an acceptable solution. Skeptical project teams may be concerned the requirements matrix is yet another project document that must be completed as part of the methodology. Project teams seeking to implement the matrix need to express the value in demonstrating how requirements evolved and are generated into system deliverables. The traceability provides proof that all business requirements were successfully designed, developed and tested. It is a useful tool to communicate with business leads assigned to the project. Compiling the requirements matrix can be a dedicated or shared role. Initially, project teams default to the project manager or a project coordinator for administrative documentation. However, this document should be owned by the lead business analyst or a requirements manager. The lead business analyst can work with technical lead, project manager and test leads to identify the specific business requirements and help map them to the system deliverables. Effective project managers closely track project schedules and the requirement manager or business analysis lead should track requirements with similar vigilance. The matrix is an evolving and changing document. As business requirements change, the matrix can be updated with new requirements, design specification ids and test cases. During a recent ERP implementation, the matrix was frequently referenced when change requests affected business requirements. The impacted components were easily identified with each change and the business stakeholders understood how the requirements change would be reflected in the matrix. IT organizations are often accused of not aligning with their business partners. Without proof, IT organizations simply saying “trust us” to their business organizations. By implementing a traceability matrix, IT organization can gain the rightly deserved trust through the proof found in the requirements traceability matrix. You have a project, you have business requirements…now go get traceability!
|
