1.5 Issues with the Standard Approaches

Not only are there issues with the documentation typically produced during requirements gathering (the requirements list), but also there are often issues in the way the documentation is produced. This section looks at several common methods that can be used to bring together requirements for an application.

1.5.1 User Interviews

Obviously, conducting user interviews is necessary when you're building a requirements specification. A user interview normally focuses on users talking about how they do their job now, how they expect it will change after the system goes into production, and the typical problems they encounter with the current process. The requirements analyst is usually writing madly, trying to keep up with the users' remarks and trying to think of the next question to ask.

Often, when one interview with one user is complete and the next user is being interviewed, requirements analysts notice that the two people have conflicting views on the same process or business rule. Then, when people at various levels of management are interviewed, the playing field becomes even more interesting. Conflicting views become a multidimensional puzzle, with pieces that change their shape as the game proceeds. The question might arise in the analyst's mind, How can this company (or department) stay in business and continue to be profitable if no one can agree on how things are run? The answer is that the level of detail required to build a computer application is greater than the level of detail needed to run a business successfully. It is the only possible answer, given our experience with numerous user departments that ran perfectly well even though every employee gives different answers to the same questions.

1.5.2 Joint Requirements Planning Sessions

Joint requirements planning (JRP) sessions are similar to conducting all the user interviews at the same time in the same room. All the people who will influence the direction of the application are brought to one place and give their input into what the system will do. A facilitator leads the group to make sure things don't get out of hand, and a scribe makes sure everything gets documented, usually using a projector and diagramming software.

A JRP is similar in structure to a joint application design (JAD) session except that the focus is different. JAD sessions are focused on how the system will work, whereas JRP sessions are focused only on what the system will do. But the processes are similar.

The people involved in JRP sessions are key representatives from a variety of interested groups, or stakeholders : users, user management, operations, executives, regulatory agencies (IRS, SEC, and so on), maintenance programming, and so forth. During the JRP session, high-level topics, such as critical success factors and strategic opportunities, are the first agenda items. Then the application's functional and nonfunctional requirements are identified, documented, and prioritized in the presence of everyone.

The JRP session provides an opportunity to get input from a number of stakeholders at the same time.

JRP sessions are valuable and can be significant timesavers for the requirements team. As hard as it is to get all the interested parties into one room (preferably off-site), it can be even harder to schedule time with each individual, given other distractions, interruptions, and priorities.

Our main issue with JRP is the document produced. In most cases, the document is a contract-style list of requirements ”and you know how we feel about requirements lists.

An all-encompassing resource for successful JRPs is Ellen Gottesdiener's book Requirements by Collaboration: Workshops for Defining Needs (Addison-Wesley, 2002).

1.5.3 Contract-Style Requirements Lists

The requirements list has its problems. In most other areas of the software development lifecycle, we have evolved the documentation into effective diagrams along with text that is elegantly structured and useful. Requirements have lagged behind this trend. The requirements list must be replaced by something with more structure and more relevance to users and designers alike. We suggest that use cases, use case diagrams, and business rules replace the traditional requirements list.

Table 1.5 shows another example of a requirements list that needs to be improved. We have a few comments beside each requirement, but please feel free to add your own insights.

Table 1.5. More Requirements

Requirement	Comment
The system will support client inquiries from four access points: in person, paper-based mail, voice communication, and electronic communication (Internet, dial-up, and LAN/WAN).	Four access points are how; we should focus instead on who needs access from where.
The telephone system must be able to support an 800 number system.	An 800 number? Can't use 888 or 877? Again, what's missing is who needs what kind of access from where.
The telephone system must be able to handle 97,000 calls per year and must allow for a growth rate of 15 percent annually. Of these calls it is estimated that 19 percent will be responded to in an automated manner and 81 percent will be routed to call center staff for response. Fifty percent of the calls can be processed without reference to the electronic copy of the paper file, and approximately 50 percent will require access to the system files.	Valuable statistics; this one is actually pretty good.
For the calls that require access to system information, response times for the electronic files must be less than 20 seconds for the first image located on the optical disk, less than 3 seconds for electronic images on a server, and less than 1 second for data files.	Starts out nicely until we mention "optical disk," which is a design assumption. The response times would be good nonfunctional requirements if they weren't about a design assumption.
The telephone system must be able to support voice recognition of menu selections, touch-tone menu selections, and default to a human operator. The telephone menu will sequence caller choices in order of most frequently requested information to the least requested .	Pretty good one. Can you find anything wrong?
The telephone system must be able to provide a voice response menu going from a general menu to a secondary menu.	This seems to be trying to provide a dumb designer with some pretty obvious advice.
The system must allow for the caller to provide address information through a digital recording and to indicate whether it is permanent.	"Through a digital recording"? Who says? This is a design assumption.
The system must allow for the caller to provide address information through voice recognition and to indicate whether it is permanent.	Sound familiar? (It's redundant.)
The telephone system must be able to store and maintain processor IDs and personal identification numbers to identify callers and to route calls properly to the appropriate internal response telephone.	Simplify it: "The system must be able to identify callers and route calls to the appropriate internal response telephone."
The telephone system must be able to inform callers of the anticipated wait time based on the number of calls, average duration of calls, and number of calls ahead of them.	Great!
The journal will contain entries for key events that have occurred within the administration of an individual's account. The system will capture date, processor ID, and key event description. The system will store pointers to images that are associated with a journal entry as well as key data system screens that contain more information regarding the entry.	This is a design for the journal. Why have it? What is its purpose?
If an individual double-clicks on an event in a member's journal, the system will display the electronic information and the images associated with the event.	Double-click is a user interface assumption.
The system will restrict options on the information bar by processor function. When an icon is clicked, the screen represented by the icon will be displayed and the system will display appropriate participant information.	This one has lots of user interface assumptions.

1.5.4 Prototypes

The prototype wave hit software development in the mid-1980s as fourth-generation languages became popular and usable. Prototypes are mock-ups of the screens or windows of an application that allow users to visualize the application that isn't yet constructed . Prototypes help the users get an idea of what the system will look like, and the users can easily decide which changes are necessary without waiting until after the system is built. When this approach was introduced, the results were astounding. Improvements in communication between user groups and developers were often the result of using prototypes. Early changes to screen designs helped set the stage for fewer changes later and reduced overall costs dramatically.

However, there are issues with prototypes. Users with detail-oriented minds pay more attention to the details of the screens than to the essence of what the prototype is meant to communicate. Executives, once they see the prototype, have a hard time understanding why it will take another year or two to build a system that looks as if it is already built. And some designers feel compelled to use the patched-together prototype code in the real system because they're afraid to throw any code away.

Prototypes will always be a part of systems development. But they cannot be the one and only requirements specification. They contain too much user interface design (which can be distracting to users and designers), and they imply that more of the system is built than is actually completed. They represent only the front end of the system ”the presentation. The business rules are not usually represented unless the prototype is fully functional, and this means that a lot of effort must go into the prototype. Prototypes should be used for what they are best at: user interface specification. This means that perhaps prototypes should come along a little later than the bulk of the requirements work. Iterative/incremental lifecycles often reduce the need for prototypes, since the real application is available to be viewed , commented on, and changed as it is developed (see Chapter 7).