Before one can develop software, one must have a fairly good idea as to its intended behavior. The activities associated with requirements management/analysis/engineering are for the purpose of coming to an understanding of, and describing, the desired behavior of a software system that one is proposing to build, either from scratch or by modifying an existing system.
Naturally, every software process model (including, of course, the classic Waterfall model) puts activities pertaining to software requirements (e.g., elicitation, specification) first on the list of things to do when developing software. In the case of models that describe an iterative approach to software development (e.g., Boehm's Spiral model), each iteration begins with a requirements-related phase whose purpose is to determine in what state the software should be (i.e., what features it supports, etc.) at the end of that iteration. After all, you can't build software (or just about anything else) without first knowing what you're trying to build.
Fred Brooks famously wrote in his classic 1987 essay, No Silver Bullet: Essence and Accidents of Software Engineering
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Davis notes [intro to Section III] that
Requirements activities span the range of activities from trying to understand/analyze the world of the customers and users to the detailed documentation of individual descriptions of external desired behavior of a system ...
Davis recounts [Essay 20] that he spent many years "trapped in the belief" that requirements X (where X is any of specification, management, analysis, or engineering) is all about documentation (i.e., about describing a desired system's external behavior). Eventually, he came to realize that requirements X has more to do with understanding than with documentation. That is, the essential (and most difficult) part of requirements management is coming to an understanding of the customer's needs; documenting those needs is the easy (or, more accurately, less dificult) part.
Work in the area of requirements involves not only technical (left-brained) skills (as may be involved in applying various analysis techniques/notations) but also touchy-feely (right-brained) skills in dealing with other people (e.g., communication, empathy, feeling, listening). This is one aspect of requirements that fascinates Davis.
It seems that every author on the subject has a different definition. Among them are the following:
Davis, in Encyclopedia of Software Engineering, says
A requirement is an externally observable characteristic of a desired system.
Note: The above definition says that a requirement is a characteristic of a system, as opposed to being a description of a characteristic. This distinction is often ignored, even by Davis himself.
Stokes, in Software Engineer's Reference Book, says
Requirements are a collection of statements that should describe in a clear, concise, consistent, and unambiguous manner all significant aspects of a proposed system.
Harwell, et. al., in "What is a Requirement?" ... (1993), say
If it mandates that something must be accomplished, transformed, produced, or provided, it is a requirement --- period.
Dorfman and Thayer (1990), say that a requirement is
1. a software capability needed by the user to solve a problem (in order) 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.
The IEEE Standard Glossary of Software Engineering Terminology (1990) defines a requirement as either
1. A condition or capability needed by a user to solve a problem or achieve an objective.(Note that 3 acknowledges the distinction between a condition/capability and a description thereof.)
2. A condition or capability that must be met or possessed by a system (or system component) to satisfy a contract, standard, specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.
Sommerville and Sawyer say
Requirements are ... a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.(Note that the last sentence describes what is often referred to as a non-functional requirement, as distinguished from a functional requirement, which relates to behavior.)
Let's clarify Davis's definition, which is repeated from above:
A requirement is an externally observable characteristic of a desired system.
By externally observable he means that there exist some means by which an observer (whether it be human or machine) can sense ---from a perspective external to the system--- whether or not the system possesses the characteristic.
By desired he means that some stakeholder "wants to have that characteristic present in the system".
Note: At least in the articles in Great Software Debates, Davis leaves the impression that the stakeholders are of one mind, or at least that their desires are consistent with one another, which is typically not the case, at least when the stakeholders are numerous or come from widely differing points of view. End of note.
What vs. How
Some people have defined a requirement to be something that "describes what a system is to do without specifying how it is to do it". Davis criticizes this by pointing out that it is often difficult to distinguish what from how. Indeed, the same thing could be a what from one perspective and a how from another.
As an example, he refers to a hypothetical hotel owner who says I want a telephone system. From one point of view, a telephone system is a what. But suppose that the owner is pressed to give a reason for desiring a telephone system, and his response is that he wants to provide his customers with a means of communicating with people outside the hotel. So from another perspective, the means of communication is the what and the telephone system is the how, in that it answers the question, "How (i.e., by what mechanism) will you provide a means of communication?" Going back even one more step, suppose that the owner's reason for wanting a communication system is his desire to keep his customers happy. So then we can view this wish as the what and the means of communication as the how. Go back yet another step by imagining why the hotel owner wants to make his customers happy!
Leffingwell and Widrig say
Requirements Management is a systematic approach to eliciting, organizing, and documenting the requirements of a system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.
Davis says
Requirements management is the discipline of elicitation, triage, and specification of the initial and evolving requirements for a system.
Activities in Requirements Management/Engineering
Here is where right-brained skills are needed, as one must be able to interact with people effectively.
A good elicitor also should know a variety of elicitation techniques and know in what circumstances/environments each one tends to work well. Among the techniques are the following (see Essays 24 and 26):
As an example, the requirement elicitors may learn that "hotel guests need to communicate with people in the local community, without leaving their rooms" is a desired feature. This may lead to the following requirements (which look suspiciously like a use case!):
TO PROVIDE LOCAL PHONE CALL SERVICE:
See Figure 24.2 (Essay 24, page 148) for an example list of features.
A critical aspect of feature specification is to assess each feature with respect to various qualities/attributes (see below) and to record all this information (e.g., in a database or table) (see Figure 24.3, page 149).
Example: it makes no sense to provide a "billing for feature X" capability if X itself is not provided.
Triage cannot be done algorithmically; that is, it requires human judgement. To do it properly requires mature knowledge of technology, finance, project management, sales, and marketing. Hence, it calls for a group effort, as no one person is likely to have enough expertise in all these areas.
Some of the factors that should be considered are listed on page 150 in Essay 24.
The goal is to arrive at an optimal set of product features that is compatible with
A requirements specification is a document that records all externally observable behaviors of a system to be built, including
Desirable Characteristics of (the description of) a (single) Requirement
According to Davis, in addition to being externally observable and desired, each (description of a) requirement should be
In order to avoid the pitfalls of ambiguity in natural language, one can employ formal notations for describing requirements. Drawbacks to this approach include the fact that relatively few software professionals are properly trained/educated to employ them, let alone the stakeholders with whom the requirements analysts must work to establish the requirements.
Advantages to using a formal notation include the possbility of automatic testing for, e.g., consistency.
Bertrand Meyer, in his article On Formalism in Specifications (from Jan-Feb 1985 issue of IEEE Software), argues that natural language is so inherently ambiguous that some degree of formalism in specification is necessary.
David Parnas makes a similar point in a one-page abstract, Requirements Documentation: Why a Formal Basis is Essential, citing the impossibility of testing "a set of English language statements for completeness and consistency".
Davis defends the use of English (or, more generally, natural language) by pointing out that requirements should be understandable by stakeholders.
In Karl Wiegers' book, Software Requirements (2nd ed.), he distinguishes between three levels of requirements:
Example: "The product will allow users to correct spelling errors efficiently".
Following the word processing example of correcting spelling errors, at this level we might include use cases corresponding to "find and highlight spelling errors" and "add word to dictionary".
Desirable Characteristics of a Requirements Specification
Leffingwell, citing some studies that have been done over the years, argues that (in general) a significant portion of the total cost of software development can be attributed to requirements-related errors (or deficiencies of some kind). This is due not only to the fact that many such errors tend to be made, but also to the fact that some of them are not detected until late in the software development lifecycle (e.g., coding, or even maintenance), by which time they are very expensive to fix. (Consider that to fix a faulty requirement during the coding phase may necessitate that the design be reworked, which could necessitate that a significant amount of code be reworked.)
Hence, he argues that it makes sense to invest a lot of effort in requirements management (including elicitation, specification, etc.), which, if done well, will minimize requirements-related errors.
Stakeholders tend to be a varied lot and, collectively, are unlikely to have a coherent and consistent vision of the product. In addition, they frequently have little idea of what they want, or, at the least, lack the ability to articulate it. (In cases such as this, it helps to use a rapid-prototyping approach, which gives the stakeholders the opportunity to "experience" the product's interface (and react to it) before lots of resources have been poured into building the product.) Adding to this is the fact that, typically, stakeholders speak a language that is foreign to developers! (This is why it is important for there to be people who can bridge the gap between the two groups and act as mediators.)