Traceability is a key aspect of requirements management. When non-requirements management tools (such as Excel) are used to manage requirements; true traceability is lost. The objective of this post is to discuss the tools needed to trace requirements, the requirements needed to perform tracing and the benefits of tracing.
Tools Needed
To trace requirements, a requirements management tool that allows traceability is required. Most of my experience has been with Rational RequisitePro by IBM (http://www-01.ibm.com/software/awdtools/reqpro/). However, I have used other tools that perform the job equally as well. Rational tools have been around for a very long time and most large organizations and agencies prefer this tool. But, research can be conducted to find a comparable tool for your project, if necessary.
Requirements Needed
To perform a complete trace all levels of requirements must be captured as follows: Features (FE), Business Rules (BR), Use Cases (UC), and Functional Requirements (FR). In this post I will briefly cover each requirement type and provide a basic example.
The Features of a system provide the highest level of grouping for requirements. For example, FE1: Manage Customer Sales is an example of a Feature. The next level consists of use cases. For example, UC1: Add a Customer Record, UC2: Add an Employee Record and UC3: Place a Customer Order.
Business Rules can also be captured. For example, BR1: All customers must be associated with a primary salesperson. It should be noted that some BRs will be implemented by a system and some will not. Either way, it's best to capture all BRs and add annotations to clearly mark the stakeholders' decision regarding implementation. If a complete list of BRs is managed, as stakeholders look at the list, they are able to more easily determine whether or not a BR is missing.
Functional Requirements are the lowest level of requirements. For example, FR1: Once a customer purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status. Now our list of requirements is as follows:
FE1: Manage Customer Sales
UC1: Add Customer Record
UC2: Add an Employee Record
UC3: Place a Customer Order (Includes UC1 and UC2. In other words, you must perform UC1 and UC2 to perform this use case.)
BR1: All customers must be associated with a primary salesperson. (System Implementation)
FR1: Once a customer purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.
If the Project Manager wants an accurate reporting of the impact a change has on time-lines and project costs, the requirements management tool can be configured to also support managing Test Cases (TCs) and Test Procedures (TPs). For example, TC1: Place an Order will include the following UCs: UC1: Add a Customer Record, UC2: Add an Employee Record, and UC3: Place a Customer Order. We also need test procedures to test the business rule and the functional requirement. Therefore, our test items are as follows:
TC1: Place an Order
TP1: Test procedure for UC1 not included in this example.
TP2: Test procedure for UC1 not included in this example.
TP3: Test procedure for UC1 not included in this example.
TP4: Test procedure for UC2 not included in this example.
TP5: Test procedure for UC2 not included in this example.
TP6: Add a customer record (No salesperson). Expected Result: An error message displays "Salesperson is required" and save is not executed. (Test procedure for UC3.)
TP7: Add a customer record (with salesperson) Expected Result: The record is saved. (Test procedure for UC3.)
TP8: Customer order total < $1000. Expected Result: A notification is NOT sent. (Test procedure for UC3.)
TP9: Customer order total = $1000. Expected Result: A notification is sent. (Test procedure for UC3.)
TP10: Customer order > $1000. Expected Result: A notification is sent. (Test procedure for UC3.)
In our requirements management system FE1 is traced to UC1, UC2 and UC3. UC3 is traced to BR1, FR1 and TC1. TC1 is traced to TP1 through TP10.
Benefits of Tracing
In supporting IT projects sometimes business decisions impact the requirements gathered. If this occurs there are only two ways to assess the damage: guess or analyze facts. In today's market, inaccurate guesses can result in loosing a customer. For example, guessing a shorter time frame than what is required means the team rushes to meet the deadline; but, the work is not completed accurately. Or, over guessing may result in providing inflated costs and time-lines, which may cause mistrust. Generating an Impact Analysis report provides the facts needed to make sound decisions for an IT project.
For example, initially a customer agrees to wait three weeks for the Place a Customer Order component. However, the customer's company has been invited to a trade show in 1 week. Now the customer wants the component completed by then. Below is a copy of our Impact Analysis report:
Impact Analysis Report for UC3: Place a Customer Order
UC3: Place a Customer Order
BR1: All customers must be associated with a primary salesperson. (System Implementation)
FR1: Once a customer purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.
TC1: Place an Order
TP1: Test procedure for UC1 not included in this example.
TP2: Test procedure for UC1 not included in this example.
TP3: Test procedure for UC1 not included in this example.
TP4: Test procedure for UC2 not included in this example.
TP5: Test procedure for UC2 not included in this example.
TP6: Add a customer record (No salesperson) Expected Result: An error message displays "Salesperson is required" and save is not executed.
TP7: Add a customer record (with salesperson) Expected Result: The record is saved.
TP8: Customer order total < $1000 Expected Result: No notification is sent,
TP9: Customer order total = $1000. Expected Result: A notification is sent and
TP10: Customer order > $1000. Expected Result: A notification is sent.
UC1: Add a Customer Record
FR2: Functional requirement for UC1 not included in this example.
UC2: Add an Employee Record
FR3: Functional requirement for UC2 not included in this example.
------------------------END SAMPLE IMPACT ANALYSIS REPORT--------------------------
The Project Manager meets with the customer and provides a copy of the Impact Analysis report. The Project Manager negotiates holding off on implementing BR1 and FR1 to meet the new deadline; and, the customer agrees. Therefore, the following items do not have to be completed for the upcoming release: BR1, FR1, UC2, FR3, TP4, TP5, TP6, TP7, TP8, TP9, TP10.
Tools Needed
To trace requirements, a requirements management tool that allows traceability is required. Most of my experience has been with Rational RequisitePro by IBM (http://www-01.ibm.com/software/awdtools/reqpro/). However, I have used other tools that perform the job equally as well. Rational tools have been around for a very long time and most large organizations and agencies prefer this tool. But, research can be conducted to find a comparable tool for your project, if necessary.
Requirements Needed
To perform a complete trace all levels of requirements must be captured as follows: Features (FE), Business Rules (BR), Use Cases (UC), and Functional Requirements (FR). In this post I will briefly cover each requirement type and provide a basic example.
The Features of a system provide the highest level of grouping for requirements. For example, FE1: Manage Customer Sales is an example of a Feature. The next level consists of use cases. For example, UC1: Add a Customer Record, UC2: Add an Employee Record and UC3: Place a Customer Order.
Business Rules can also be captured. For example, BR1: All customers must be associated with a primary salesperson. It should be noted that some BRs will be implemented by a system and some will not. Either way, it's best to capture all BRs and add annotations to clearly mark the stakeholders' decision regarding implementation. If a complete list of BRs is managed, as stakeholders look at the list, they are able to more easily determine whether or not a BR is missing.
Functional Requirements are the lowest level of requirements. For example, FR1: Once a customer purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status. Now our list of requirements is as follows:
FE1: Manage Customer Sales
UC1: Add Customer Record
UC2: Add an Employee Record
UC3: Place a Customer Order (Includes UC1 and UC2. In other words, you must perform UC1 and UC2 to perform this use case.)
BR1: All customers must be associated with a primary salesperson. (System Implementation)
FR1: Once a customer purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.
If the Project Manager wants an accurate reporting of the impact a change has on time-lines and project costs, the requirements management tool can be configured to also support managing Test Cases (TCs) and Test Procedures (TPs). For example, TC1: Place an Order will include the following UCs: UC1: Add a Customer Record, UC2: Add an Employee Record, and UC3: Place a Customer Order. We also need test procedures to test the business rule and the functional requirement. Therefore, our test items are as follows:
TC1: Place an Order
TP1: Test procedure for UC1 not included in this example.
TP2: Test procedure for UC1 not included in this example.
TP3: Test procedure for UC1 not included in this example.
TP4: Test procedure for UC2 not included in this example.
TP5: Test procedure for UC2 not included in this example.
TP6: Add a customer record (No salesperson). Expected Result: An error message displays "Salesperson is required" and save is not executed. (Test procedure for UC3.)
TP7: Add a customer record (with salesperson) Expected Result: The record is saved. (Test procedure for UC3.)
TP8: Customer order total < $1000. Expected Result: A notification is NOT sent. (Test procedure for UC3.)
TP9: Customer order total = $1000. Expected Result: A notification is sent. (Test procedure for UC3.)
TP10: Customer order > $1000. Expected Result: A notification is sent. (Test procedure for UC3.)
In our requirements management system FE1 is traced to UC1, UC2 and UC3. UC3 is traced to BR1, FR1 and TC1. TC1 is traced to TP1 through TP10.
Benefits of Tracing
In supporting IT projects sometimes business decisions impact the requirements gathered. If this occurs there are only two ways to assess the damage: guess or analyze facts. In today's market, inaccurate guesses can result in loosing a customer. For example, guessing a shorter time frame than what is required means the team rushes to meet the deadline; but, the work is not completed accurately. Or, over guessing may result in providing inflated costs and time-lines, which may cause mistrust. Generating an Impact Analysis report provides the facts needed to make sound decisions for an IT project.
For example, initially a customer agrees to wait three weeks for the Place a Customer Order component. However, the customer's company has been invited to a trade show in 1 week. Now the customer wants the component completed by then. Below is a copy of our Impact Analysis report:
Impact Analysis Report for UC3: Place a Customer Order
UC3: Place a Customer Order
BR1: All customers must be associated with a primary salesperson. (System Implementation)
FR1: Once a customer purchases and pays for $1000 in products; the customer shall be sent a notification of eligibility for "Preferred Customer" status.
TC1: Place an Order
TP1: Test procedure for UC1 not included in this example.
TP2: Test procedure for UC1 not included in this example.
TP3: Test procedure for UC1 not included in this example.
TP4: Test procedure for UC2 not included in this example.
TP5: Test procedure for UC2 not included in this example.
TP6: Add a customer record (No salesperson) Expected Result: An error message displays "Salesperson is required" and save is not executed.
TP7: Add a customer record (with salesperson) Expected Result: The record is saved.
TP8: Customer order total < $1000 Expected Result: No notification is sent,
TP9: Customer order total = $1000. Expected Result: A notification is sent and
TP10: Customer order > $1000. Expected Result: A notification is sent.
UC1: Add a Customer Record
FR2: Functional requirement for UC1 not included in this example.
UC2: Add an Employee Record
FR3: Functional requirement for UC2 not included in this example.
------------------------END SAMPLE IMPACT ANALYSIS REPORT--------------------------
The Project Manager meets with the customer and provides a copy of the Impact Analysis report. The Project Manager negotiates holding off on implementing BR1 and FR1 to meet the new deadline; and, the customer agrees. Therefore, the following items do not have to be completed for the upcoming release: BR1, FR1, UC2, FR3, TP4, TP5, TP6, TP7, TP8, TP9, TP10.
In addition to being able to generate an Impact Analysis report, traceability provides other benefits. For example, when a requirement changes the requirements management system will typically mark the associated requirement(s) as invalid. For example, if UC3 changes the requirements management system marks its relationships with BR1, FR1 and TC1 as invalid. The analyst rechecks those items to make sure the relationships is still accurate and makes any necessary changes. Also, a trace matrix can be used to ensure 100% testing coverage of all requirements. This provides a tangible way to guarantee all requirements and business rules have been accurately implemented to ensure a successful implementation.
