Requirements Traceability

As the PMBOK ^® and your PMP ^® Exam Preparation training tell you, the ability to trace your requirements is key to your ability to verify that the software system you’ve produced is the one that your customer has requested. This holds true whether your customer is internal or external, with or without a contract and Statement of Work. Traceability works hand in hand with sign off to ensure that: A ) that correct and complete requirements are captured, and B) the final product satisfies all the requirements that were approved. Not only will it be difficult to verify that requirements have been met without this element, your stakeholders will have a more difficult time understanding and approving system designs.

Traceability starts with the first document that captures the goals of the project in detail. The goals and objectives captured in the project charter are usually stated in terms which are too broad. You should begin with the contract, if you’re doing the work for an external customer. If the contract contains a Statement of Work (SOW), it may have unique identifiers associated with the requirements captured there already. These should form the base for all subsequent unique identifiers. If you’re doing the project for an internal customer, you should begin with a Scope Statement which will state how the project will meet the goals and objectives set forth in the Project Charter. The Scope Statement actually serves 2 purposes: it states what work will be included in the project and excludes any work not specifically mentioned. There will typically be work in the scope statement that doesn’t pertain to the system under development, project status reporting for example. This work doesn’t require identifiers; it’s under your direct control and you shouldn’t need the help of identifiers to know whether you’re doing the work or not. The unique identifiers you choose to assign to the system related work should be brief enough so that they can be captured in subsequent design documents without placing too much strain on the designers or design tools. If possible, you should use a system that will tell the reader what area of the system the requirement belongs too. For example, if you were developing an equipment order capture and configuration system you would identify the system with the acronym EOC (in case you need to distinguish the requirements for this system from others), the reporting area with RPT (EOC.RPT), and the report with either a number, or another acronym such as MRSR (monthly regional sales report). The resultant identifier would be EOC.RPT.MRSR. The means of relating the identifier to the requirement in this document will be straight forward: each requirement has one, and only one identifier. Identifiers should appear with the requirement they identify.

The software development methodology chosen for the project and the nature of the project will determine what types of design documents will be used, so we’ll use a project which has decided to use a "superset” of design documents and start with a Commercial Specification, or Business Requirements document. By the way, the Commercial Specification is more likely to be used if the system you’re building is being built for sale externally. The business requirements document is more likely if you’re building it for internal customers. These documents will define the attributes of the system in business terms so taking our example above, we might require a monthly regional sales report to be generated dynamically (EOC.RPT.MRSR.1) by only regional sales managers (EOC.RPT.MRSR.2). It might need to include a breakdown of sales by salesperson (EOC.RPT.MRSR.3) and product (EOC.RPT.MRSR.4). Once again, no requirement should be captured here that isn’t supported by your contract’s SOW, or your project’s Scope Statement. The means of relating these identifiers to the requirements must now support tracibility. The identifiers in this document must tie back to the previous document. You should be able to achieve this fairly simply by choosing a naming convention that supports a one to many relationship (such as the one in the examples). The requirements in this document should support one, and only one element in the SOW or Scope Statement. The identifiers should appear next to the requirements they identify and will tie back to the preceding document without further information (e.g. requirements EOC.RPT.MRSR.1, EOC.RPT.MRSR.2, EOC.RPT.MRSR.3, and EOC.RPT.MRSR.4 all support EOC.RPT.MRSR). Collectively, all the requirements for all the reports support the business need for reporting (EOC.RPT).

The document developed in the step described above will now be turned over to the project’s business analysts, or systems analysts. These are the people who will convert the business requirements, or commercial specifications into system features and functions. If you’ve followed our advise in the section describing the approval of requirements, these people will already have been engaged and there will be no requirement captured that can’t be built. The business analysts (or systems analysts) will now produce a Functional Specification which describes how the system must function to meet the business requirements. For example, the Functional Specification might describe a graphical interface with a reports main menu page to facilitate reporting from the order capture system (EOC.RPT.MM). It might describe how the system should check the privileges assigned to the user who attempts to run the monthly regional sales (EOC.RPT.MSRS.2.1). Relating the functional features and functions back to the business requirements is a little more tricky now because we’ve introduced the concept of a many to many relationship to the process. Each business requirement may be supported by many features or functions and a single feature can support several business requirements. For example, the ability to generate reports dynamically may apply to more than one report, but may be handled by a single feature (checking the users privileges). Embedding identifiers in the feature/function description will be useful for downstream users, but will not support relating the feature to the preceding document well. To accomplish this, you’ll need to include 2 matrices with your Functional Specification: Business Requirement to Feature/Function and Feature/Function to Business Requirement. In this way, a reader can identify all the features which will support an individual business requirement and by reading only those specification elements that describe those features get a clear picture of how the system will function to meet the requirement.

The final element in the process of designing your system will be the Detail Design Document. The programmer/analysts responsible for actually building the system will be responsible for producing these documents and the identifying the software components described in them with the requirements in the preceding document. Identification should be done in a similar fashion to the Functional Specification. Let’s take the user privilege check described in the previous paragraph and identified as EOC.RPT.MSRS.2.1, as an example. The programmer/analyst may decide to take a 2 step approach to the check. First capture the users privileges with a query (EOC.RPT.MSRS.2.1.1) , and then check the resultant privilege set against the regional sales manager privilege (EOC.RPT.MSRS.2.1.2) enabling the report for those with the privilege and disabling it for those without it. Functions, modules, and screens may have the ability to support more than 1 feature or requirement in the preceding document, but each feature or requirement may require more than one function, module, or screen so the relationship is many to many. Again, it’s important to embed the identifier in the segment describing the function, module, or screen. There may be a need to embed multiple identifiers in each screen if the screen is broken down into different elements (e.g. a login screen userid window and a login screen password window) so find a way to do this that doesn’t compromise the integrity of the graphic. Matrices will be necessary to support the many to many relationship between the elements in the Detail Design Document and those in the previous document. Implement these matrices the way we’ve described in the preceding paragraph.

Approvals should occur at each design step. These approvals should serve to verify the coverage of the approved requirements in the approved document. Since the business stakeholders may not necessarily be able to understand the language in the Functional Specification, including the 2 matrices described will be very helpful to the business readers of the document. They may not necessarily understand the language used to describe a function, but they can see that each requirement in the Business Requirement to Feature/Function matrix has one or more features or functions supporting it and should be able to get a sense that the function described will completely satisfy the requirement. The approval process verifies the requirements have been met and also trigger the next step in the development process.

The final step in the verification process is to relate test cases to the requirements. This should be done at the Quality Assurance (QA) level; each requirement in the Business Requirements document or Commercial Specification should be covered by one or more test cases. The test case to requirements relationship is many to many so matrices will come in handy again. Approval of the test cases should be dependent on each requirement being supported by one or more test cases. Where a requirement is not supported by a test case, there should be an alternate plan to perform the necessary testing. Unit, function, and system testing can also benefit from the identification of test cases to features/functions the functions, modules, and screens they support. This identification is not essential to the requirements verification process. User Acceptance Testing (UAT) does not need to identify test cases with requirements as there is no implied requirement for the project to verify the completeness of UAT. Should this be requirement of your project, you should approach it using the same methods as you used to verify the completeness of the QA test cases.

This section is meant to describe briefly all the actions you could be required to take in order to adequately verify your project’s requirements have been met. You should choose the actions your project needs based on the software development methodology chosen, the size, and complexity of your project. The concepts this article is based on are described in the Scope Management knowledge area of the PMBOK^®. You can learn more about AceIt^©and how to become certified by checking out that the AceIt Features area of our website.