1.1 First and Least of All . . .

Technical people often pay much more attention to an entity relationship diagram or class diagram than to a requirements list.

Each time a team of systems people sets out to provide a computer system for a group of business people, they proceed through a set of activities that is fairly consistent:

• Requirements gathering

• Analysis

• Design

• Construction

• Testing

• Deployment

• Maintenance

The emphasis that the team gives each phase determines the direction and quality of the resulting computer system. If one activity is not given its due, there will be predictable problems with the project and the end product. In reality, however, certain activities usually receive more attention than do other activities. It is not easy to explain why this occurs, but it does. The activities that are usually ignored or paid lip service are

• Requirements gathering

• Testing

• Deployment

• Maintenance

Traditionally, fewer vendors brandish flashy tools to accomplish these activities, and maybe that's why they are less interesting and less appealing to practitioners . Certainly, a great deal of creativity and a wide range of skills are required by each activity, but the perception has been that anything other than the big three ”analysis, design, and construction ”does not require much attention or imagination .

This perception is slowly changing, in no small part because vendors are building tools to manage requirements (Rational RequisitePro, Borland Caliber RM, Telelogic DOORS), automate testing (Segue SilkTest/SilkPerformer, Mercury Interactive WinRunner/LoadRunner, Rational Robot/TeamTest/TestManager), and to facilitate rollout (Borland Deployment Server/Java, Marimba Desktop/Mobile, BEA WebLogic). Maintenance has also received a small boost with the need for Y2K remediation in recent years . We have opinions on ways to improve the visibility, appeal , and effectiveness of these other underappreciated activities, but we'll spare you those points until our next book.

We wrote this book because we care about requirements. In the first place, effective requirements are pivotal to producing a system that meets the needs of the users. It's no exaggeration to say that the requirements themselves are the needs of the users.

Moreover, we have grown to care about requirements because we have seen more projects stumble or fail as a result of poor requirements than for any other reason. Because requirements are meant to drive the rest of systems development, any small misstep is amplified into a major flaw by the time deployment is in progress. Correcting those flaws becomes extremely time-consuming (read: expensive!) because so much work has been put into heading in the wrong direction. Unfortunately, requirements do not translate neatly into one discrete module in a coded computer system. Sometimes, they are embodied in principles that cut across many code libraries and components . Because requirements are so abstract and so different from computer programs, it is difficult for people whose skills lie in the concrete aspects of computer programming to get them right.

Traditionally, requirements gathering

• Takes too long

• Documents the wrong thing

• Makes assumptions about activities that haven't happened yet

• Is often completed just in time to do it over again, thanks to swift and dramatic changes in the business

A short time ago, we came across a requirements definition document that contained more than 160 pages of "requirements." The sheer volume of this requirements list was enough to cause us to be filled with panic (or at least dread ) at the thought of reading it and attempting to put the pieces together. Table 1.1 contains a sample of the requirements list (which is not very different from many other lists we've seen).

Table 1.1. Example of a Requirements List

Requirement	Definition
6.7.1.4.2	The system must provide the capability to capture all of the customer transactions for the fiscal year.
6.7.1.4.3	The system will provide restricted remote inquiry access (via dial-in) to view images and data separately or simultaneously .
6.7.1.4.4	The system will barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned.
6.7.1.4.5	When a workflow is initiated, the system must be able to prefetch the documents that are in electronic image format by document type or grouping of documents by process.
6.7.1.4.6	The system must create an entry in the journal file whenever a letter is created.
6.7.1.4.7	The system must maintain a list of current, open work processes and identify the work process to be executed and the workflow queue for the process. When particular documents are scanned, the system will determine whether there is a process open for that Social Security Number (SSN). If there is an open process, the system will route the document to the appropriate workflow queue, display the work process script, and highlight the current work process.

Don't forget this list continues for another 159 pages!

We dissect these and other requirements statements later, but you can imagine how difficult it would be to read large volumes of information at this level, much less to separate the true requirements from trivialities. If you are reading this book, you have probably lived this problem.

One reason that requirements documents are often so bad is that requirements gathering frequently follows an unproductive route. For example, it may be ignored; in that case, the development team jumps to a solution, resulting in a design based on unwritten and not agreed-upon assumptions about how the system should work. Or requirements gathering becomes an end in itself, and pages of "requirements" are gathered, documented, cross-referenced, and distributed, resulting in analysis paralysis and cancellation of the project before the rest of the lifecycle can even be started. Or the requirements may be dictated by a single user , system owner, or high-ranking manager, resulting in a system that works only for that person, to the dissatisfaction of everyone else. None of these methods produces satisfactory input to the analysis activity.

Hundreds of application lifecycle activities definitions, taken from various methodologies and processes, litter our bookshelves and the Internet. In Table 1.2 we provide our definitions of these terms because we build on these definitions to explain how to best approach requirements gathering.

Table 1.2. Activity Definitions

Activity Name	Description
Requirements gathering [a]	Gather and document the functions that the application should perform for the users in the users' language and from the users' perspective.
Analysis	Begin with the requirements and build a logical solution that satisfies the requirements but does not necessarily take the physical constraints into account.
Design	Begin with the logical solution and change it to work effectively with the physical constraints (network latency, database performance, user interface, caching, availability, and so forth) and produce specifications that can direct the construction effort.
Construction	Use the physical solution to produce working code, which involves making the lowest -level design decisions, writing code, compiling, debugging, and testing by increment.
Testing	Use the constructed application to produce a complete working system by system testing, detecting, and recording issues, fixing problems, and getting user acceptance of the result.
Deployment	Fit the tested application into the production environment by deploying the code libraries to the destined machines, training the users, and fine-tuning the business procedures surrounding the new system.
Maintenance	Administer and make changes to the working system in the production environment to adapt to ongoing business changes (legislative, competitive), technology changes (hardware, software, and communications), physical changes (location, configuration), personnel (information technology [IT], user), system issues (code bugs , design problems) and even office politics.

^[a] We consider requirements gathering a separate activity from analysis. This is perhaps contrary to other prominent industry luminaries, who lump them together. Neither way is ultimately correct or incorrect; we have simply chosen to separate these activities to emphasize their importance.

Our definitions of lifecycle activities are not taken from any specific methodology. Instead, we've attempted to choose the most commonly used names and definitions for each term . Notice we've chosen the word activity instead of the word phase . We do this deliberately. In waterfall lifecycles, activities (or workflows), and phases are synonymous. However, activity relates to something that a person or group does. Phase implies specific start and stop times, dependencies, and a sequence. With iterative/incremental lifecycles, on the other hand, phases and activities are quite different. (We explain our approach to iterative/incremental lifecycles in Chapter 7.) Activities are done iteratively and incrementally, but phases are simply project management milestones that indicate a number of increments or a natural break in the lifecycle. For example, the Rational Unified Process (RUP) has the following workflows (activities): business modeling, requirements, analysis and design, implementation, test, deployment, configuration/change management, project management, and environment. It also has the following phases: inception, elaboration, construction, transition, and evolution. We see most methodologies moving in the same direction as the RUP to accommodate developers' as well as project managers' viewpoints.