As we have stressed throughout this book, it is vital that everyone on the team understands the project requirements. However, it's not practical to wait around until absolutely everyone is totally with the program. That's why we have described iterative development techniques that allow you to progressively refine your understanding as you go along.
But even then, we have seen projects that have done a good job up to this point but still ruin those efforts by diving into disorganized development activities. This is yet another potential project failure mode: when the team does understand the requirements but is still not able to build a system that meets those requirements. In this chapter, we'll focus on a few more key concepts you can master to ensure that you are building the right system right.
Continually confirm that the development is on track.
Confirm that the development results are correct.
Learn how to deal with change during development.
As the design and implementation evolve, the team must be able to continually reassure itself that the project hasn't inadvertently "run off the rails." That is, the team needs to be able to continually verify that the development results conform to the customer's needs.
We'll use the term verification to describe an ongoing process that will help ensure that every step of the development is correct, meets the needs of the next activity, and is not superfluous to the needed activities. Unfortunately, there is a lot of confusion in the industry as to just exactly what verification is. So, we'll discuss this important and powerful concept in more detail.
The IEEE (1994) defines verification as
the process of evaluating a system or component to determine whether the products of a given phase satisfy the conditions imposed at the start of that phase (IEEE 1012–1986, §2, 1994).
That is, verification is largely an analysis-based activity that requires you to confirm that each stage of the development—for example, a software implementation of one or more requirements—conforms to the requirements defined in the previous stage.
At a minimum, we will want to verify that
The features we expressed really meet the needs
The use cases and requirements we derive from the features truly support the features
The use cases are implemented in the design
The design supports the functional and nonfunctional aspects of the system's behavior
The code really does conform to the design and the design objectives
Our tests provide full coverage for the requirements and use cases that have been developed.
So, how do we know what the whole project is? We need some kind of method to make sure that we have verified everything that needs verifying—and no more than that.
In order to do this, you'll need a verification plan, and you'll benefit from some tools to help execute this plan. But most important, the team will need to understand what verification is, and you'll need a commitment to the verification activities. Verification is not just an activity handled by the project's QA team, which may nonetheless be of great assistance during this process.
One method for continually checking up on your verification activities is traceability. We've made passing mention of traceability in Team Skill 5, and Chapter 31 will discuss how we can use traceability to help us organize our verification activities.
Regardless of how we organize it, we must remember that the essence of verification is to reassure ourselves that the step we are working on has the proper antecedents and that it is performed in a consistent and reliable way. Furthermore, we must verify that every activity that we decide to do is needed and that no necessary steps are omitted.
We gain reassurance of these issues largely by effective software processes and by analysis. For example, we can examine the requirements and reassure ourselves that they correctly, completely, and concisely express the higher-level user needs. We can examine the design to reassure ourselves that it is driven by the requirements and use cases, that it is complete, and that it has no extra elements. In some cases, the analysis boils down to inspections and reviews. In other cases, we can use our models and tool automation to assist with checking completeness, semantics, and so on. Remember, we are not trying to ensure that things are working; we'll get to that later. Instead, we are focused on the issue of making sure that we've done the things we need to do and that they follow a logical development progression.
OK, so much for the digression. Now let's get back to discussing some implications of verification.
The dark side of the verification issue is that we can go "verification happy" and spend time in verification activities that do not give us a satisfactory payback. So, we need some way of computing an economic "return on investment" (ROI) for our verification activities.
We will need to have an approach to help us make the right investments in checking our activities. We don't want to overdo the checking, and we don't want to skimp on crucial checking aspects. Chapter 33 considers an overview of the techniques of risk assessment and hazard analysis and offers insights as to how these techniques can be used to get the most out of your development dollars during system review activities.
The team must be able to design and to implement a system that conforms to the requirements. That is, the team must be able to verify that the implementation plans conform to the project needs.
But the previous point begs a significant question: How do we get from requirements to design to implementation? After all, you don't just hold the requirements up to a computer and expect a design and implementation to occur! In Chapter 30, we will examine ways in which you can move from requirements to design, and we'll provide an overview of how you can use artifacts of the requirements process to drive the design and implementation of your system.
You can apply the verification throughout the lifecycle of the project; the technique is not confined to any particular phase. You can and should verify requirements elements, design elements, implementation elements, testing elements, and any other elements that are deemed important to your project, based on your ROI analysis. In general, you will be invoking some amount of verification activity at every stage of the project. You will be invoking verification to ensure the correctness of the
User needs to product features
Product features to requirements
Requirements to architecture
Architecture to design model
Design model to implementation
Implementation to test planning
(Note: We'll cover testing as part of validation.)
Again, we stress that verification is extremely important in the design stages of the project because errors introduced in the design stage are extremely costly to remove after implementation is under way.
We recommend that all projects incorporate a verification process that begins at project inception and continues throughout the life of the project. If you are working on a project whose software development process is regulated, you will likely be forced to do verification, whether you want to or not. If you are developing high-assurance systems—safety-critical systems or those for which the cost of failure is unacceptably high—you will have to do verification, or you will be taking unacceptable risks or perhaps imposing unacceptable risks on others. But every project of any reasonable scope will benefit by the right amount of verification.
As important milestones, such as executable iterations, are reached, it will be important to validate the functionality that has been developed—that it works correctly and conforms to the requirements. After all, there is little point in achieving a particular milestone if the pieces don't work the way they are supposed to, although even then we learn something.
A very special milestone is the completion of the project. In an effective process, the completion milestone is simply one more step in ensuring that the system is designed and implemented in compliance with the customer's needs. In addition, at the completion milestone, we must show that the system really works as it is supposed to.
There's one final and very important checkpoint in the development process. The product has to be demonstrated to work within the customer's environment, and the customer has to like the product enough to accept the result. The bottom line is that the customer must be happy when the project is over, or at least not too unhappy!
Validating the development work has two important aspects: (1) to show that the product conforms to its requirements and (2) to focus on customer acceptance of the final result. Although, in theory, these would be the same thing, in practice, the final acceptance testing will often demonstrate how well we've handled requirements or user need "drift" from the earlier project activities. Chapter 32 will discuss system validation from both of these perspectives, as well as the varying opinions as to what validation means.
Just as for verification, we also need a way to make sure that our validation, or testing, time and resource investments are cost effective. Once again, an ROI review may prove beneficial.
Finally, of course, we have to consider the impact of changing requirements. Have you ever worked on a system that never changed its requirements from day 1?
We must plan for change and know how to manage it. Chapter 34 will discuss the potentially devastating impact of uncontrolled change and will offer an organized way to recognize change, estimate its impact, and incorporate changes in an orderly manner.