Requirements

As has been mentioned in Chapter 4, Software as a Product, requirement formulation has a significant influence on software success. In this subsection, we highlight several issues related to requirements elicitation .

The Method of Up-Front Requirements Elicitation

Current requirements elicitation methods reinforce improper beliefs. Many projects try to follow the Waterfall Software Life Cycle and other, usually linear, software development, life-cycle models. The requirements are gathered first in one big effort [Davis90]. Frequently, these requirements turn out to be rife with omissions and misconceptions. Correcting them costs time and money. The result has been a movement toward more iterative models [Tomayko00]. The history of iterative requirements gathering has itself gone through several cycles, of which agile methods are the latest (See Chapter 8, History of Software Engineering ). The trouble is that with each new iterative method, the requirements elicitation process appears to become less settled.

The attitude toward requirements gathered early in the process is incorrect in that ones missed at that stage are considered defects when added later. The entire point of iterative processes is that requirements are seldom omitted; they are just unknown. There is simply no way that all the requirements of even well- understood problems could be known. Therefore, why even try? Requirements are elicited by agile methods in a more practical way, and thus estimations are better.

Requirements Elicitation in Agile Methods

It seems difficult to identify requirements from stories. However, research has shown that an agile attitude toward requirements is a very effective means of acquiring them [Smith01], and thus doing repeated accurate estimations.

In agile methods, the user stories are just the beginning, points of both the requirements gathering and development processes, and thus of estimates. Early requirements are simply a place to start. One is expected to add more requirements as more is known about the product. Conversely, the method of trying to gather all the requirements before starting development will almost certainly result in errors and surely takes too long. In such a development process, the client is prompted by the product to remember some things and by the marketplace to want others changed. I ll know it when I see it (IKIWISI) [Boehm00] has become a well-known requirements identification method. In effect, the early version of the product becomes a prototype. Agile methods are designed to appeal to clients that insist on IKIWISI. Moreover, in this way, the client is kept from the responsibility of getting the requirements ˜right . There are no wrong requirements; there are simply some waiting to be discovered .

Difficulties for Estimation Caused by Agile Methods of Gathering Requirements

This agilist attitude toward requirements makes estimation and software architecture development more difficult, and verification easier, than traditional methods. Without knowing the final form of the product, or marketplace demands, large-scale product estimation, like COCOMO I, is going to be impossible to get correct [Thayer97]. It is little comfort that requirements omissions and changes caused by reacting to the competition make most estimates incorrect right now. Agile methods are likely to be right about the costs involved in the current cycle, but estimating is poorly understood for the unknown requirements of the next cycle.

As mentioned earlier, one thing that can be done is to fund the project one cycle at a time, which is equivalent to funding an entire project using an older development method now. There will be times, however, when knowing the total cost is necessary, as in contract work. In these cases, the customer expresses the requirements as well as it can, and the estimate is adjusted by the probable cost of later changes. For example, if a project is estimated at $1 million, and prior projects of roughly those same characteristics have had the cost of changed requirements at around 20 percent, then the estimate is $1.2 million. Of course, as with all estimations, this method cannot be used without considerable historical data.

As for the architecture, that chosen by the team during the early cycles may become just plain wrong, as later requirements become known. Rework of the architecture matches the refactoring principle. One developer identified refactoring as rework , with its attendant negative properties, such as deleting some code, notably increased cost. Either way, significant refactoring is to be expected in an atmosphere where requirements are relatively unknown. Confidence in the requirements translates to confidence in the architecture.

Task  

List five client stories from a piece of software. Derive requirements from them.

The Team Software Process Development Manager

A software development process usually associated with heavier weight methods is the Team Software Process (TSP). However, the role of Development Manager as found in TSP is useful in the estimating and tracking methods just described. The primary purpose of the Development Manager is to decide the overall strategy and what will be done in each iteration [Humphrey00].

In other words, TSP depends on cyclical development, much like the more modern development methods we described previously. Perhaps, with the team coach or a lead developer, the client can take on the role of Development Manager.

The basis of the role is as follows : the Development Manager obtains the goals for the entire product and figures out how many iterations are needed to develop the product and what their content is. This is tantamount to obtaining all the stories known at the beginning, and then choosing the subset needed for the first iteration.

Task  

Develop a strategy for making software for an ATM.