The Requirements Review in Quality Programming

Requirements are the driving force behind a software project. Every activity in the software project is affected by the requirements, while serving them at the same time. The initial analysis of the product under development, the project planning, the design of the product, its implementation and of course the testing of the product – are all tightly coupled with the requirements specification which in fact defines the product.

This is why taking the software requirements, out of all the artifacts that are being produced during software development, for granted is a potential risk. Not only will flawed requirements have a bad effect on the software development, they might even have legal and financial implications.

The following discussion will address the issue of requirements review: its importance, its benefit and how it should be done.

The Importance of Requirements

It seems like most software development organizations recognize the importance of requirements to the software development process and to the quality of the software product. Still, it is important to start this discussion with reflecting back on why requirements specifications are so important.

I believe that some of us tend to take software requirements for granted. In the “good” scenario, this leads to focusing on having a formal requirements specification without thinking about its content. In the bad scenario, this may lead to forgetting the necessity of requirements altogether.

The first, and most obvious, benefit of having a requirements specification is establishing the contract with the customer. The requirements specification should formally describe the customer’s expectations and our consent to deliver a product that fulfills them. Now, this may seem like a pure legal issue, however, this issue has more to it than just legal stuff.

No matter how good the product we are creating is, if it isn’t what the customer expects we cannot really say it is a quality product. To emphasize this point, consider a case where the customer is an internal customer in your organization (for example the marketing department).

Although “the contract” between you and this kind of customer is not a contract in the legal sense, you will want to keep the customer happy by supplying the software she needs. You have a much better chance in doing so if you will take the time to formally phrase what it is she needs.

At this point it is important to clarify that the entire discussion is relevant for both external and internal customers. It is true that there are no legal issues when the customer is internal. Nevertheless, I guess none of us want upset an in-house customer as well.

The second issue that requires well defined requirements, which is at least as important as the first one, is project planning. Without knowing what needs to be designed, implemented and tested, no one can really estimate how much time will each activity consume Needless to say that this issue is often the root of all evil when it comes to poor quality software.

A badly planned project is bound to create scheduling problems: there will be no proper time to design the product; developers will have to work overtime and might not have time to test their code;

QC will not have the proper time to design and implement a proper testing environment; “luxury” activities such as design and code reviews will probably not even be considered due to the tight schedule. Of course, having a defined set of requirements does not guarantee proper project planning; however it is a necessary condition for planning a project.

Next there is the issue of guidelines for the development team. Without a good set of requirements the developer cannot possibly know what to do. Even if developers have a vague idea about what the product should do, certain issues in the requirements can have great influence on the design and implementation of the product.

Now, in theory, this sounds pretty much obvious. Unfortunately, it is not rare to find development teams storming into implementing the product before someone properly defines its scope and goals.

I do not suggest that this is their fault. Many times, it is management who pushes development forward prematurely, before one could design and implement a product that will be of benefit to the customer. Such attempts usually result in waste of valuable resources at best.

The last issue, which makes requirements specifications so important, is the requirements being a basis for testing and verifying the functionality of the software product. As you can guess, this issue is closely related to the previous issue.

Without a well-defined set of requirements developers will not be able to know what is expected from them; similarly the QC team cannot possibly verify the correctness of the software, since the expected behavior of the product is not clearly defined.

0 thoughts on “The Requirements Review in Quality Programming”

Write a Reply or Comment

Your email address will not be published. Required fields are marked *