Definitions

What Is a Software Requirement?

Although many definitions of software requirements have been used throughout the years , the one provided by requirements engineering authors Dorfman and Thayer [1990] is quite workable :

1. A software capability needed by the user to solve a problem to achieve an objective

2. A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation

This definition may appear to be a little vague, but later we'll develop these concepts further. For now, this definition will do quite well.

What Is Requirements Management?

Requirements define capabilities that the systems must deliver, and conformance (or lack of conformance) to a set of requirements often determines the success (or failure) of projects. It makes sense, therefore, to find out what the requirements are, write them down, organize them, and track them in the event that they change. Stated another way, we'll define requirements management as

a systematic approach to eliciting , organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

Let's take a closer look at some key concepts contained in this definition.

• Anyone who has ever been involved with complex software systems ”whether from the perspective of a customer or a developer ” knows that a crucial skill is the ability to elicit the requirements from users and stakeholders.

• Since hundreds, if not thousands, of requirements are likely to be associated with a system, it's important to organize them.

• Since most of us can't keep more than a few dozen pieces of information in our heads, documenting the requirements is necessary to support effective communication among the various stakeholders. The requirements have to be recorded in an accessible medium: a document, a model, a database, or a list on the whiteboard.

What do these elements have to do with managing requirements? Project size and complexity are major factors here: nobody would bother talking about "managing" requirements in a two-person project that had only 10 requirements to fulfill. But to verify 1,000 requirements ”a small purchased software product ”or 300,000 requirements ”a Boeing 777 ”it's obvious that we will face problems of organizing, prioritizing, controlling access to, and providing resources for the various requirements. On even a modest-size project, questions will naturally arise.

• Which project team members are responsible for the wind speed requirement (#278), and which ones are allowed to modify it or delete it?

• If requirement #278 is modified, what other requirements will be affected?

• How can we be sure that someone has written the code in a software system to fulfill requirement #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?

That, along with some other, similar activities, is what requirements management is all about.

This is not something new that we've invented on our own; it's one of those "commonsense" activities that most development organizations claim to do in some fashion or other. It's typically informal and carried out inconsistently from one project to the next , and some of the key activities are likely to be overlooked or short-changed because of the pressures and politics associated with many development projects. So, requirements management could be regarded as a set of organized, standardized, and systematic processes and techniques for dealing with the requirements of a significant, complex project.

We're certainly not the first to suggest the idea of organized, formalized processes; two well-known efforts of this kind are the Software Engineering Institute's Capability Maturity Model (SEI-CMM) and the ISO 9000 quality management standards. (Requirements practices in these processes are described briefly in Appendix F.)