Quality and Requirements: A Bond
Quality is the centroid and pillar of any industry, and it is one of the key elements that attracts and holds the customer. In the software industry, quality is defined in terms of usability and fulfillment, which are both established through requirements. Requirements are defined through the expectations of the customer. Ultimately, quality measures the gap between the requirements actually developed and the requirements expected to be developed.
Whether requirements are correct is what determines quality, and thus, efficiency in terms of process, product, cost, and rework. The cost of finding a defect at a later stage of the systems development life cycle (SDLC) is very expensive as compared to detection at an earlier stage. Moreover, the cost of the defect is two-fold, as indicated by William E. Perry in his book Effective Methods for Software Testing (Second Edition): "One to identify it and other to correct it." This means that once the defect passes to other stages of the SDLC, it becomes expensive to track back and identify the defect, as well as the stage in which it was born. Once the defect is found, the other aspect of the cost is the labor hours required to correct the defect while ensuring that no correct requirement is modified or lost.
This article will examine how to ensure integrity of requirements using requirement traceability, and how traceability applies to the SDLC.
Controlling Variability through Requirements Traceability
Variability has always been an enemy of quality. Variability that violates predefined limits leads to uncontrolled behavior in the system. On the other hand, controlled processes are stable processes, and stable processes enable you to predict results. Thus, controlling variability from the very initial stage helps in minimizing the risk of diverging from the actual requirements.
Statistical methods are the best way to measure variability. Moreover, controlling process variability is an ongoing activity. In order to control variability, the best practice is to (1) identify the processes; (2) identify the attributes of the processes that can be measured; and (3) track process variation (through control charts). If the process is in control, keep on polling (that is, keep checking the process at regular intervals). But if the process is not in control, then several steps may be required:
- Identify the cause (using root cause analysis, such as Pareto analysis, histograms, run charts, or scatter diagrams).
- Eliminate the root cause (using Pareto analysis, brainstorming, or Ishikawa diagrams).
- Continue to track process variations.
The requirement traceability matrix (RTM) is very valuable for keeping a check for each requirement and for monitoring whether a requirement is incorporated into the product. The RTM is a matrix that ensures that no requirements are lost or tampered with, and that they are developed according to the functionality required. The RTM also ensures that the user's requirements are converted and mapped to the correct functional requirements, and that what is desired by the customer is delivered.
The RTM is also very beneficial from the maintenance or enhancement point of view. If any future changes are required for the product, then the particular requirement to be changed can be traced and modified. This puts the focus on forward- and backward-mapping between requirements (see figure 1). Requirements tend to change over time, so maintaining the RTM helps trace the requirements and modify them as necessary. The RTM also ensures that changing a particular requirement does not harm other existing requirements. It helps in avoiding repetition of requirements. If requirements are redundantly covered—as when they are hidden in the form of other requirements—then there is a risk of obscuring the function to be developed. Thus, it is very important to exclude such repetitive requirements in order to save both time and money.
Figure 1. Requirement traceability: forward traceability and backward traceability.
In one of my critical projects for an e-shopping system, the requirements gathered were determined to be correct after a complete, high-level requirements analysis and a final draft of use cases at the base level. But as the requirements went through the further stages of the SDLC, they were corrupted.
The requirement of the customer was an e-shopping cart that included all the basic functionalities: user login, adding and removing items to and from the shopping cart, and payment. But as we moved forward from high-level scenarios to low-level scenarios (in other words, from requirement to each and every function and variable used to fulfill this requirement), we missed some requirements that were expected to be part of the functionality.
For instance, with respect to the "add/remove cart items" functionality, the developers neglected to implement the requirement that the user needed to be able to find the items added during the previous interaction upon a subsequent login. This is one example of how requirements can get lost in the process when breaking down high-level data to the base level. What developers developed was good and functional, but one of the requirements necessary to fulfill the customers needs was still missing. We realized this in the testing stage as we mapped the requirements and functionality. We then traced backward in order to identify the broken link. This backward tracing helped to convert the correct requirements into the desired functionality.
Along with requirement traceability, requirements management is also essential. If no RTM is maintained, then it is theoretically possible that a requirement could corrode in the testing stage, with the site going live without the pertinent functionality. Just imagine how much loss the missing requirement could cause the customer!
The SDLC: The Rotating Wheel
Requirements play a very important role throughout the SDLC, as together they form a statement of what the product is supposed to do. The main functionality is determined based on the information gathered during requirement elicitation from the customer.
Figure 2. SDLC: The rotating wheel.
The requirements that enter the SDLC are those of the users, which are mapped to both functional and nonfunctional requirements. They are then converted into design, and move forward along the wheel. Afterwards, the requirements move on to the development stage, and then to the testing stage. The customer receives the user requirements that have been molded into the end product (see figure 2).
It is necessary to maintain the RTM around the wheel to make sure the requirements are not broken. The user's requirements change to functional requirements (and vice versa) from the gathering and freezing stage to the final delivery (production) stage. This process helps to keep track of each requirement important to the customer at each and every stage, and prevents loss of data. In the e-shopping application above, the missing link was the result of files with duplicate names being used to override the split files in the destination location. No attention was given to this requirement (which was implicit); it should have been handled as well, but was somehow lost during the process.
Practical Example
In a company I once worked for (a service-based organization), I worked on different short- and long-term projects. One of the small projects involved a file picker and splitter, which picked files with specific, predefined extensions at regular intervals of time, and then split them into parts at a predefined location. Now, the functional requirement was to split these specific files and to keep them on a particular path with a specific naming convention: TargetFilename[n].ext.
Following is figure 3, a map of the functions and user requirements.
Figure 3. One-to-one relation between user requirements mapped and functional requirements.
This process of mapping will also prevent irrelevant or harmful requirements from creeping into the system. Conversion and mapping between user requirements to function (forward), and also from function to user requirements (backward traceability), highlights the importance of RTM in process flow. Moreover, this process also displays a clear picture of the feasibility of user requirements and what is to be developed as functions. In addition, it gives an idea of what requirements are not covered.
Conversion and mapping determine the traceability and development of correct requirements throughout the SDLC. The RTM is maintained during the SDLC from the requirements freezing stage. In this stage, the requirements are gathered and analyzed for feasibility. The customer then signs off on the requirements. This sign-off document is passed on for use in the development stage, where the customer requirements are coded into functionality. This developed system reaches the testing stage, where these requirements are again cross-checked (tested against what is developed), and each requirement from the matrix is ensured to be developed correctly. Then finally, they are delivered to the customer for further end testing and approval.
Let me elaborate further on the above file splitter example. Starting with the freezing stage, the business requirement, as gathered from the customer, was a file splitter that picked up the files and split them into pieces. Now, as this requirement was frozen after customer sign-off, it was passed to the next stage of SDLC—the development stage. Here, these requirements were further broken down from high-level requirements to low-level scenarios. The requirements specifically pointed to the following steps: (1) pick up specific files; (2) split them into specific file formats; and (3) keep them on the specified path. After the coding of these functions, they passed to the testing phase—a subsystem test (which can be performed by a group of developers or by a separate test group), and then a system test phase by the system test group to ensure end-to-end flow. Then finally, the system went to the user acceptance test (UAT)—the customers final acceptance and approval of the developed product to go into production.
Maintaining the RTM's integrity for the entire SDLC is the responsibility of the test group, as stated earlier. Moreover, the test group is required to ensure the integrity of requirements after every stage in the SDLC, and to prevent unnecessary requirements from creeping into the system. Unnecessary requirements are those that creep into the system when no expected behavior is defined for an object. For example, if we refer to the above instance, the files that were picked up and split were deleted from the target path, which was not exactly what the system was supposed to do. So these requirements crept into the system and remained unnoticed until the customer detected them. Thus, maintaining the traceability of requirements at every stage also helps in rolling back if any divergence in requirements is reported.
Conclusion
In the testing phase, traceability gives a clear picture to validate the business requirement and function developed. From a tester's perspective, it is very important to answer the following questions:
- What is being tested or validated against?
- How is it being tested?
- Is requirement coverage ensured in test design?
- Are reviews fruitful from testing as well as from the development point of view?
- What techniques have been incorporated in testing?
- Is regression covered or not?
If a tester is able to answer these questions, then the product satisfies quality measures from the customers perspective, and it is fit for use. Moreover, when it comes to maintenance or any enhancement, backward traceability is very useful. It will ensure that the current functionality is not harmed, and that only the correct requirement is modified.
From the cost perspective, as said earlier, defects found in the later stages of the SDLC are expensive, which is why it's vital to trap defects in the early stages of the SDLC. This removes the gap between the requirements specified by the customer and the actual product delivered. In turn, this results in low variability rates, and maintains consistency in the process and product, which has a tremendous impact on the reduction of defects in the testing phase.
About the Author
Neha Grover has more than two years of experience as a testing engineer and subject matter expert, and has in-depth knowledge of software testing and requirements analysis. Grover has been a testing engineer for BMC Software, where she worked in the areas of requirements tracing, functional testing, and performance testing. She is currently the testing subject matter expert for Amdocs, and is involved in system testing. Grover holds an MS in information technology from the Veer Narmad South Gujarat University in Surat, India. She is also a certified software tester, holding a CSTE from the Quality Assurance Institute (QAI).