This section explores what requirements are and why they are important.
As a general rule, if you intend to build something, you should decide upon what it is before building it! Otherwise the final product is not likely to be satisfactory. This rule applies especially strongly to software development, due to its intricate and precise nature.
Members of the software development team must work together in close coordination; things will not go smoothly if they are not in agreement as to how the software is to behave. The needs and wishes of members of the intended user community must play a prominent role in deciding what to build, too, or else the finished product is not likely to satisfy them.
The primary reason, then, for writing requirements is to document a common understanding of what system is to be built.
Davis defines a requirement to be
an externally observable characteristic of a desired system.
By externally observable, Davis means that there exists 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 the characteristic helps to satisfy some need of some stakeholder.
Note: A somewhat less awkward phrasing of Davis's definition might be "A requirement is a desired and externally observable characteristic of a system". (That is, the adjective "desired" should modify "characteristic" rather than "system", it seems to me.) End of note.
Note: The idea that it is possible to determine, from "external" observation, whether or not a system possesses a given characteristic seems questionable. Consider the Calculator program that comes with MS Windows. Among its functions is to compute square root. One expects that a requirement of the program is for the sqrt button to yield an approximation (accurate to some specified error tolerance) to the square root of whatever number was given. How can one observe whether the program satisfies that requirement? Even if we test it on a thousand different inputs, all of which yield correct results, how can we be sure that it works for all possible inputs?
The analogous question applies to any requirement that imposes some
constraint upon how the system should react to any of an infinite number
of possible inputs (or in any of an infinite number of circumstances).
It would seem to be more realistic to insist that, for any one of those
possible inputs, the reaction of the system to it should be observable
and it should be determinable whether that reaction satisfies the requirement.
End of note.
Davis criticizes the following, more common, definition:
A requirement defines what a system is supposed to do, without defining how it is to do it.
Davis points 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 one more step, suppose that the owner's reason for wanting a communication system is 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! In general, then, if you take any desired what and ask why it is desired, the answer becomes the new what and the old what becomes the how!
Another popular definition that Davis does not like is
A requirement defines a problem of the customer without reference to any solution to that problem.
Just as there is no bright line between what and how, there is no bright line between requirement and solution! If the customer wants a particular solution, then that solution is the requirement!
The issue here is really the specificity of requirements. To illustrate this, on page 5 Davis discusses requirements related to functions typically provided by a mouse (namely, moving forwards and backwards in a slide show, and displaying a menu).
One possible requirement is
The system shall have three buttons.
The implication is that one button would be for moving forwards in a slide show, one would be for moving backwards, and one would be for displaying a menu. Depending upon what the users want, this might be an appropriate requirement. On the other hand, a less precise requirement might be more appropriate:
The system shall provide a means to enable users to move forwards, to move backwards, and to display a menu.
Or it is possible that the "correct" requirement not only indicates that there are to be three buttons, but also indicates their exact sizes and positions relative to one another. (This would be appropriate in a situation where the mouse buttons are to be pressed by a robotic finger.)
The bottom line here (see page 6) is that no one can simply read a requirement and make a judgement as to whether it is too precise or too vague. The correct level of detail is completely dependent upon the needs of the customers.
Davis take the view that the outcome of software development is not a single software product, but rather a sequence of releases of that product. Hence, requirements management is an activity that continues for as long as there are plans for future releases. (See Figure 1-1, page 7.)
Initially, requirements elicitation is used for compiling a list of candidate requirements. Requirements triage (a term that seems to be unique to Davis) is an iterative process that is used not only to clarify the requirements but also to whittle down the candidate list to arrive at a set of requirements that can be satisfied with an "acceptable level of risk" (of taking too long to implement, etc.) These are documented (so as to describe the system to be built), at which time design, coding, etc., can begin.
Throughout the development process, requirements elicitation continues, because new candidate features will arise, as will the desire to change features that had already been approved for implementation. Each time this happens, triage activity must occur, leading to a decision to do one or more of the following:
This section explores the question of how much effort should be expended upon requirements-related activities.
At one extreme, organizations that hope to gain CMM level 3 (or above) certification sometimes adopt very "heavy" (i.e., cumbersome, slow, overly methodical) processes. In a market where it is vital to beat competitors by releasing products before them, this can be deadly.
At the other extreme is the agile development approach, which Davis compares to the common practice of the 1960's, when little or no process was employed.
Davis finds many problems with agile development, in which requirements are rarely documented but instead are provided, in "real time", by a customer representative (who must be available at virtually all times to answer developers' questions):
In general, Davis seems to think that agile development pays too little attention to establishing a firm, clearly stated set of requirements, and hence leads to an environment in which requirements are changed on a whim (of either coders or the customer representative), taking little or no account of product quality/usability, customer satisfaction, and probability of completing within schedule/budget.
Figure 1-2 (page 9) illustrates the Range of Rigor in Requirements Processes scale, which measures
Davis makes the point that the "right" place to be on the scale depends upon the project (in particular, upon corporate culture, time-to-market pressure, criticality of the application, and other factors). For example, software whose failure can lead to catastrophe (e.g., loss of life, huge financial loss) should be held to the highest standards of quality, and hence should be developed using rigorous processes.
In general, you want to employ just enough process to minimize your risks sufficiently while still achieving desired outcomes.
Figure 1-3 (page 10) shows a graph relating Amount of Requirements Activity to Risk. Too little of the former results in too much of the latter (due to the increased likelihood of the product not meeting the customer's needs). But too much of the former also increases the risk, namely that of taking too long and spending too many resources in development.
This section explores the different contexts in which software development (and, specifically, requirements-related activity) occurs, according to the relationship between the developers and the customers.
In custom software development (CSD), the relevant actors (see Figure 1-4, page 11) are typically
What typically happens is that the customer issues an RFP (request for proposal) that sketches what they want, one or more SDC's (software development companies) answer with a proposal that outlines its intended approach, a preliminary list of requirements, proposed schedule and budget. The customer will choose which SDC to hire and negotiate a contract with it. The SDC will then (after some requirements activities) prepare a requirements document and proceed with development. Whenever the customer comes up with new requirements, negotiations and triage are needed. Whenever the development team realizes that it is going to exceed the budget or be late, negotiation and triage is repeated.
With custom embedded system builders, things work in the same way as with custom software developers. The requirements, though, are system requirements, which mean that they can include some that pertain to hardware and some that pertain to software. Typically, the project manager has as underlings a software manager and a hardware manager. (See Figure 1-5, page 12.)
The situation with ISVs (and mass marketed embedded system builders) is quite different. (See Figure 1-6, page 13, and Figure 1-7, page 15.) Here, there is no particular customer who has declared that he has some particular problem (that could be fixed by software or some combination of hardware/software). Rather, there exists a (perceived) market of potential customers, some of whom may not even be aware that they are "in need" of a solution to a problem.
Ascertaining requirements in this situation is quite different, because there is no well-defined group of users with whom to consult about their wants/needs. Instead, needs are identified via market research, demographic studies, sales force feedback, and related vehicles. The primary spokesman for the "customer" is the marketing division within the SDC.
The steps involved in deciding upon a set of requirements (see pp. 13-14) in this context are very much influenced by calculations involving marketing and other business considerations.
Regarding internal IT organizations (see Figures 1-8 and 1-9, page 16), these usually exist in moderate-to-large companies, and their purpose is to satisfy the IT-related needs of executives, middle-managers, and employees.
What typically happens is that the desire to increase revenue/efficiency and/or decrease expenses/errors leads employees or managers to submit some kind of request for improved software/services to the IT organization.
Then analysts (who work for IT) interact with the employees to elicit their requirements and then translate them into a (preliminary) list of features that the software developers (in IT) can understand.
Then the developers estimate how long it will take them to implement the requirements. Typically, this is not fast enough for the employees, so requirements triage is undertaken.
Eventually, all parties agree upon a set of general features, a schedule, and a budget. Then the appropriate persons (developers?) write a complete software requirements document.
Davis remarks that negotiating a set of requirements in this situation (in which all the players are employees of the same company) should be easier, but, in practice, it is not, because "politics" and "power games" are more prevalent here than when the "customers" and "developers" are from different companies.
Requirements consultants are typically hired when a company knows that it has a problem that could probably be solved via software, but lacks the expertise to determine its own requirements or to evaluate commercial software that might satisfy its needs. (See Figure 1-10, page 17.)
The consultants carry out requirements elicitation, etc., and deliver a requirements document (or database of requirements).
At this point (possibly with the continuing help of the consultants), competing commercial software systems that could serve as solutions are evaluated and compared (on characteristics such as price, functionality, etc.).
If no viable commercial software is found, the company issues an RFP as the first step towards getting it developed via CSD (custom software development), as described earlier.
Davis remarks that, despite a relatively recent and widespread debate in the software development field on the relative merits of Royce's Waterfall model and Boehm's Sprial model, he never perceived that there was much difference between the two!
Davis's interpretation of the waterfall model is that it says, for each new software product, to go through a series of phases (requirements, design, etc.) to build that product. The spiral model says to build a software product iteratively, with each iteration involving the same series of phases. Note: So is Davis's point that, if you view the result of each iteration as a "new product", the two models coincide? End of note.
Davis remarks
Perhaps the only difference is whether you originally planned to do it iteratively or are just doing it iteratively as an afterthought.
He interprets the debate to have been about whether, in your next iteration, you should try to satisfy all of your requirements or only a subset of them.
If, indeed, that was the crux of the debate, he states emphatically that the correct answer is: only a (small) subset! "Shorter iterations are better than longer iterations", he says.
How Much Time to Spend on Requirements?
This varies greatly from project to project. Among the reasons are these:
Davis cites Forsberg's and Mooz's study of NASA projects (see Figure 1-11, page 19) showing that, generally, cost overruns decreased as the proportion of resources allocated to "planning activities" (including requirements) increased (up to about 20%).
Who Should Define the Schedule?
Contrary to the way that most organizations do it, Davis thinks that customers/marketing should "drive" the desired schedules (just as they drive the requirements), rather than developers. Why? Because customers/marketing are in a much better position to define a desired delivery date (which depends upon such things as urgency, criticality, and market window) than are developers.
The right way to plan a project is to determine the desired requirements and the desired schedule, and then to compare the two to see if they are compatible. If they are not (and are they ever??), one or both must be modified (via requirements triage) in order to arrive at compatibility.
Davis claims that, if developers decide upon the schedule, conflict occurs. A better approach is for customers/marketing to decide on the schedule, with developers assisting them by estimating the probability of success, as a function of time/resource constraints, and to help them understand the tradeoffs (e.g., earlier delivery, but with less functionality vs. later delivery, but with more functionality).
Schedule Should Drive Requirements
Davis also asserts that schedule should drive requirements, rather than the other way around. As an example in the realm of commercial software, imagine that the market window demands that some product be delivered within six months (because later delivery, even of a superior product, would result in a large loss of market share). Then the goal should be to identify that subset of requirements that can be implemented (with a reasonably high probability) within that time.
How Much Time Between Releases
Here, Davis claims
The shorter the cycle, the more likely you are to achieve on-time delivery.
To explain this, he sets forth the following scenario (see Figure 1-12, page 21):
A company is six months into its typical one-year development cycle (with the next release, 2.0, scheduled to be delivered in six months time), and a new requirement becomes evident.
Either we add the new requirement to the current release's (2.0's) baselined list of requirements, or we defer it to a later release.
In Davis's experience, the first choice is the more common, which leads (in our scenario) to release 2.0 being late (by, say, a few months), which means that release 3.0 will be behind schedule when its development begins, which is likely to lead to it being delivered late, too, etc., etc. That is, every release gets delayed by constantly changing requirements.
Now contrast this with a scenario in which releases are scheduled for every three (rather than twelve) months. (See Figure 1-13, page 22.) Say that the new requirement becomes evident half-way through the development cycle leading to release 2.0.
Now consider our two choices, as above: either we put the new requirement into release 2.0's baseline, or we defer it to release 3.0. In the former case, we deliver release 2.0 late. But in the latter case, we defer it to release 3.0, which is to be delivered in only 4.5 months (rather than the 18 months from the earlier scenario)!
Note: Is this argument convincing? Aren't there certain overhead costs associated to "delivering" a release? If so, cost goes up with frequency of release.
These are (as pointed out earlier) elicitation, triage, and specification.
Elicitation is a two-way interaction between the requirements team and the stakeholders. The former should include not just experts in requirements techniques but also subject-matter (or domain) experts (SMEs). It should include "left-brained" persons (who demand precision), as well as "right-brained" persons (who can "feel" the pain of customers).
Contrary to many authors, Davis does not believe that the requirements team should avoid discussing potential solutions (or small bits thereof) with stakeholders; indeed, he thinks that such discussions often lead to stakeholders providing better feedback, which leads to their needs being clarified more quickly.
During the elicitation process, candidate requirements should be recorded in a list. It is not possible to say what their appropriate level of detail should be, and, in practice, the items in the initial list of requirements will vary widely in terms of detail level. Typically most will not be very detailed and are worthy of being referred to as features.
Comparing the list of candidate features (and, in particular, the effort expected to be needed to satisfy them) with the desired schedule and available resources will almost inevitably lead to the conclusion that some features will have to go unsatisfied. This is where requirements triage comes in! Triage is the process through which it is decided towards which candidate features effort will be expended to satisfy them. The selected features are refined and clarified (to get rid of ambiguity) in order to produce a software requirements document (SRD) (or SRS ("... specification")).
Davis notes that elicitation, triage, and specification do not, however, occur in strict sequential fashion. More typically, what happens is that, over time, persons come to realize that some existing (automated or manual) system/process can be improved (or replaced by something better), and pressure for change slowly builds until the decision is made to pursue a software "solution".
Sources of requirements typically include
So as to allow the candidate features to be analyzed in a variety of ways, each feature should have certain pieces of information (i.e., attributes) attached to it. Among the most important attributes are priority and estimated cost to satisfy.
Generally, it is the job of marketing (or the stakeholders in the case of custom-built software) to assign relative priorities to features and for development to estimate the cost of development efforts. However, they must coordinate their efforts in order for this to work. There are at least three reasons:
There is often disagreement among developers regarding the cost of implementing a feature/requirement. This is often the result of the feature/requirement being too abstract. Davis suggests that, when this occurs, the requirement should be refined into a set of sub-requirements. This usually results in a greater degree of consensus. (See page 30 for an example having to do with producing an accounts receivable report.)
Internal disagreements among marketing people, too, are likely to occur. Two likely causes are
After the requirements have been annotated, sufficiently refined, and estimated for cost/effort, the estimates are added. The sum will usually be many times larger than the budget. This is where triage is employed to choose which subset of the candidate requirements will be satisfied in the next release. (See Figure 1-21, page 31.)
At the triage meetings, the interests of each of marketing (which represents customers), development, and finance (which represents those paying for development of the system) must be adequately represented. Consider what could happen otherwise:
In any case, two things are almost inevitable:
Thus, it is wise for the baseline requirements identified by triage to need only an estimated 50 to 90 percent of available resources to satisfy.
Where on the scale between 50 and 90 is the right percentage? That depends upon answers to several questions, including
Once the baseline requirements are agreed to, work on a more detailed SRD can commence, and the development team can begin to define and document the system's architecture.
Davis does not believe that design should not begin before all requirements are agreed to (when, then??), because
Davis asserts that designers should be allowed to see not only the agreed-to requirements, but all of them, including their priorities. This helps them to build into the software appropriate hooks to accommodate these requirements in future releases.
At some point, before product development is finished, an agreement on the full set of requirements to be satisfied should be made. Ideally, these will include all those in the baseline, plus some combination of others that were excluded from the baseline and new ones that have appeared since the last agreement.
No matter how carefully these steps are managed, new requirements will continue to appear. (Of course, each of these should be evaluated to determine its relative priority and estimated cost/effort.) This is called requirements creep. When this happens, another triage meeting is needed. In some organizations, the commitee that has the authority to make decisions regarding proposed changes to the requirements of an ongoing software development project is called the change control board (CCB).
Requirements management overlaps with other disciplines, including
Several studies indicate that more time and attention should be devoted to requirements than is currently the norm. In part, this is because (as shown by Boehm, Daly, and Fagin in the 1970's) errors made during requirements but not found until later cost a lot to fix (and the later, the costlier). Also, several studies show that a relatively large percentage (between 40% and 50%) of errors occur in the requirements phase (or are "requirements-related", at least)! (See Figures 1-26, 27, and 28 on page 37.)
The obvious conclusion is that cutting down on requirements errors would be an effective way to reduce software development costs.
Davis identifies three categories of requirements errors:
Some requirements are not known by anybody, however! Prototyping, or delivering the product incrementally, are two ways to help to reveal such requirements, because the more functionality that a customer experiences, the more new functionality he will tend to want (and be able to identify).
Some developers find it upsetting when customers continually identify more functions that they want, but Davis sees this as healthy, as it provides evidence that the current software is satisfying real needs.