Use Case and Traceability Matrix

2012-04-21T05:18:00.001-07:00

Traceability Matrix

The concept of Traceability Matrix is to be able to trace from top level requirements to implementation, and from top level requirements to test.

A traceability matrix is a table that traces a requirement to the tests that are needed to verify that the requirement is fulfilled. A good traceability matrix will provide backward and forward traceability, i.e. a requirement can be traced to a test and a test to a requirements. The matrix links higher level requirements, design specifications, test requirements, and code files. It acts as a map, providing the links necessary for determining where information is located. This is also known as Requirements Traceability Matrix or RTM.

This is mostly used for QA so that they can ensure that the customer gets what they requested. The Traceability matrix also helps the developer find out why some code was implemented the way it was, by being able to go from code to Requirements. If a test fails, it is possible to use the traceability matrix to see what requirements and code the test case relates to.

The goal of a matrix of this type is -
1. To make sure that the approved requirements are addressed/covered in all phases of development: From SRS to Development to Testing to Delivery.
2. That each document should be traceable: Written test cases should be traceable to its requirement specification. If there is new version then updated test cases should be traceable with that.

Traceability Matrix is used in entire software development life cycle phases:

1. Risk Analysis phase

2. Requirements Analysis and Specification phase

3. Design Analysis and Specification phase

4. Source Code Analysis, Unit Testing & Integration Testing phase

5. Validation – System Testing, Functional Testing phase

In this topic we will discuss:

· What is Traceability Matrix from Software Testing perspective? (Point 5)

· Types of Traceability Matrix

· Disadvantages of not using Traceability Matrix

· Benefits of using Traceability Matrix in testing

· Step by step process of creating an effective Traceability Matrix from requirements. Sample formats of Traceability Matrix basic version to advanced version.

In Simple words - A requirements traceability matrix is a document that traces and maps user requirements [requirement Ids from requirement specification document] with the test case ids. Purpose is to make sure that all the requirements are covered in test cases so that while testing no functionality can be missed.

This document is prepared to make the clients satisfy that the coverage done is complete as end to end, this document consists of Requirement/Base line doc Ref No., Test case/Condition, and Defects/Bug id. Using this document the person can track the Requirement based on the Defect id

Note – We can make it a “Test case Coverage checklist” document by adding few more columns. We will discuss in later posts

Types of Traceability Matrix:

· Forward Traceability – Mapping of Requirements to Test cases

· Backward Traceability – Mapping of Test Cases to Requirements

· Bi-Directional Traceability - A Good Traceability matrix is the References from test cases to basis documentation and vice versa.

Why Bi-Directional Traceability is required?

Bi-Directional Traceability contains both Forward & Backward Traceability. Through Backward Traceability Matrix, we can see that test cases are mapped with which requirements.

This will help us in identifying if there are test cases that do not trace to any coverage item— in which case the test case is not required and should be removed (or maybe a specification like a requirement or two should be added!). This “backward” Traceability is also very helpful if you want to identify that a particular test case is covering how many requirements?

Through Forward Traceability – we can check that requirements are covered in which test cases? Whether is the requirements are coved in the test cases or not?

Forward Traceability Matrix ensures – We are building the Right Product.

Backward Traceability Matrix ensures – We the Building the Product Right.

Traceability matrix is the answer of the following questions of any Software Project:

· How is it feasible to ensure, for each phase of the SDLC, that I have correctly accounted for all the customer’s needs?

· How can I certify that the final software product meets the customer’s needs? Now we can only make sure requirements are captured in the test cases by traceability matrix.

Disadvantages of not using Traceability Matrix [some possible (seen) impact]:

No traceability or Incomplete Traceability Results into:

1. Poor or unknown test coverage, more defects found in production

2. It will lead to miss some bugs in earlier test cycles which may arise in later test cycles. Then a lot of discussions arguments with other teams and managers before release.

3. Difficult project planning and tracking, misunderstandings between different teams over project dependencies, delays, etc

Benefits of using Traceability Matrix

· Make obvious to the client that the software is being developed as per the requirements.

· To make sure that all requirements included in the test cases

· To make sure that developers are not creating features that no one has requested

· Easy to identify the missing functionalities.

· If there is a change request for a requirement, then we can easily find out which test cases need to update.

· The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.

Steps to create Traceability Martix:

1. Make use of excel to create Traceability Matrix:

2. Define following columns:

Base Specification/Requirement ID (If any)

Requirement ID

Requirement description

TC 001

TC 002

TC 003.. So on.

3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:
Used cases (all the flows are captured)
Error Messages
Business rules
Functional rules
SRS
FRS
So on…

4. Identity all the test scenarios and test flows.

5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is your one flow/scenario. Now in this scenario, Requirements SR-1.1 and SR-1.2 are covered. So, mark “x” for these requirements.

Now from below table you can conclude –

Requirement SR-1.1 is covered in TC 001

Requirement SR-1.2 is covered in TC 001

Requirement SR-1.5 is covered in TC 001, TC 003 [Now it is easy to identify, which test cases need to be updated if there is any change request].

TC 001 Covers SR-1.1, SR, 1.2 [we can easily identify that test cases covers which requirements].

TC 002 covers SR-1.3... So on...

<><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><>

Requirement ID	Requirement description	TC 001	TC 002	TC 003
SR-1.1	User should be able to do this	x
SR-1.2	User should be able to do that	x
SR-1.3	On clicking this, following message should appear		x
SR-1.4			x
SR-1.5		x		x
SR-1.6				x
SR-1.7			x

This is a very basic traceability matrix format. You can add more following columns and make it more effective:

ID, Assoc ID, Technical Assumption(s) and/or Customer Need(s), Functional Requirement, Status, Architectural/Design Document, Technical Specification, System Component(s), Software Module(s), Test Case Number, Tested In, Implemented In, Verification, Additional Comments,

Use Case

A use case describes the interactions between one of more Actors and the system in order to provide an observable result of value for the initiating actor.

The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain the observable result of value) for a particular actor.

In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer funds between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using the system.

Figure 1: ATM Use-Case Example

Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible ways of using the system. You should be able to determine the goal of a use case simply by observing its name.

A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s) and the system, structured as follows:

1. The actor <<does something>>

2. The system <<does something in response>>

3. The actor <<does something else>>

4. The system ...

Each dialog of this form is called a "Flow of Events".

Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required network connection is currently unavailable), each use case will contain several flows, including one "Basic Flow of Events" and several "Alternative Flows".

The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where everything goes as planned, and the actor's goal (the observable result of value) is met. The basic flow represents the main capability provided by the system for this use case.

As the name implies, Alternative Flows specify alternative interactions associated with the same goal.

Closely related to use cases is the concept of a scenario. A scenario is a specific flow of events, for a specific set of inputs to the system, states of the system, and states of the system's environment. Scenarios are closely related to test cases.

Properties of Use Cases

Name

Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have to be several words to be understood. Note: No two use cases can have the same name.

Brief Description

The brief description of the use case should reflect its purpose.

Flow of Events

Flow of Events - Contents

The flow of events should describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow of events should represent what the system does, not how the system is design to perform the required behavior.

Follow these guidelines for the contents of the flow of events:

· Describe how the use case starts and ends.

· Describe what data is exchanged between the actor and the use case.

· Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system. Specifying user interface details too early will limit design options.

· Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor ... ".

· Describe only the events that belong to the use case, and not what happens in other use cases or outside of the system.

· Avoid vague terminology.

· Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify test cases.

If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and that the meaning of the terms is consistent. To manage common terms, put them in a glossary.

Flow of Events - Structure

The two main parts of the flow of events are basic flow of events and alternative flows of events. The basic flow of events should cover what "normally" happens when the use case is performed. The alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow of events, some of which will return to the basic flow of events and some of which will end the execution of the use case.

The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use case.

Figure 2: Typical structure of a use case flow of events

Both the basic and alternative flows should be further structured into steps or sub-flows. In doing this, your main goal should be readability of the text. A guideline is that a sub-flow should be a segment of behavior within the use case that has a clear purpose, and is "atomic" in the sense that you do either all or none of the actions described.

Special Requirements

In the Special Requirements of a use case, you describe all the requirements associated with the use case that are not covered by the flow of events. These are non-functional requirements that will influence the design. See also the discussion on non-functional requirements in Concept: Requirements.

Preconditions and Post-conditions

A precondition is the state of the system and its environment that is required before the use case can be started. Post-Conditions are the states the system can be in after the use case has ended. It can be helpful to use the concepts of precondition and post-condition to clarify how the flow of events starts and ends. However, only use them only if the audience for the description of the use case agrees that it is helpful. Figure 3 shows an example.

Figure 3: Illustration of preconditions and resulting post-conditions

Examples

A precondition for the use case Cash Withdrawal in the ATM machine: The customer has a personally issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.

A post-condition for the use case Cash Withdrawal in the ATM machine: At the end of the use case, all account and transaction logs are balanced, communication with the banking system is reinitialized and the card is returned to the customer.

Use Case & Traceability Matrix

Use Case and Traceability Matrix