1.4 The Challenges of Requirements Gathering

If requirements gathering were easy, we wouldn't need to write a book about it. Following are the main challenges that we've observed in the process.

1.4.1 Finding Out What the Users Need

Everyone knows how to do this: "If you want to know what they want, just go ask them." When referring to users of a computer system, though, this advice is not very sound. Users do not know what they want, because the question ”what will you want in your new computer system? ”is so complex that users can't be expected to answer it. There are too many variables .

Once you are using new business procedures

and

your job has changed

and

the business your company is in changes

and

you are learning a brand-new computer application

how would you like it to work?

Users have much more on their minds than your computer application, including their own day-to-day responsibilities. The struggle between users' current responsibilities and their involvement in shaping a new system is legendary. Steve McConnell, in his book Rapid Development (McConnell 1996), gives us a number of ways that users can inhibit the process of requirements gathering:

• Users don't understand what they want.

• Users won't commit to a set of written requirements.

• Users insist on new requirements after the cost and schedule have been fixed.

• Communication with users is slow.

• Users often do not participate in reviews or are incapable of doing so.

• Users are technically unsophisticated.

• Users don't understand the software development process.

• And the list continues.

This list makes users sound like some kind of beasts that rise from the muck to interfere with our quest to develop applications. Of course, they're not. There is simply a tug-of-war between what the users need to concentrate on currently and how you need them to participate in helping you develop the application.

One defense against the struggle for users' time and attention during requirements gathering is simply to concentrate on establishing relationships with your users. The stronger the personal relationships between the analysts and the users, the more likely it is that the users will make the time for questions, meetings, and debates.

Another defense is to work on the visibility of the project. If senior executives in the users' organizations are aware of the system implementation and are touting its importance, it is more likely that the profile of the application among your users will be high enough to encourage them to attend requirements sessions and interviews, and to participate. They need to know that this effort is not just going to be another flash in the pan. Finally, it's important to be respectful of their time. To create the fewest disturbances possible, batch your questions and interviews together.

1.4.2 Documenting Users' Needs

As we said earlier, documenting users' needs is called requirements definition . Creating this documentation and then confirming it with them is a difficult process. This book is largely dedicated to making this process easier and clearer for all parties.

The challenge of documenting requirements with traditional techniques is that there are often no real checks and balances . It is hard to tell whether a requirement has already been documented, perhaps in a different way or with a conflicting result. It is also hard to see what's missing.

1.4.3 Avoiding Premature Design Assumptions

Premature design assumptions tend to creep into every requirements specification, especially if they're prepared by designers-at-heart. This also tends to happen if the people gathering the requirements don't trust the designers and want to tell them how the system should be designed so that the designers won't mess it up. This tends to happen, in our experience, when the developers are off-site and removed from the requirements gatherers and users. It also happens when the requirements analysts do not trust the designers and developers to make the right decisions later.

1.4.4 Resolving Conflicting Requirements

If requirements, big and small, are listed one after another in a list, as we showed in Section 1.1, there can be requirements in different places of the list that say opposite things. To combat this problem, you need a built-in mechanism to prevent these conflicts. You can use something with more structure than a list, and you can incorporate reviews when conflicts are identified.

1.4.5 Eliminating Redundant Requirements

Redundant requirements are not as bad as conflicts, but they can be confusing if they say almost the same thing, but not quite. They also add to the volume of the requirements, which can be its own problem.

1.4.6 Reducing Overwhelming Volume

The greater the volume of the requirements specification, the less likely it is that the development effort can succeed. The volume must be reduced in one or all of the following ways:

• Remove conflicts.

• Remove redundancy.

• Remove design assumptions.

• Find commonality among requirements and abstract them to the level that makes the most sense for the users.

• Separate functional from nonfunctional requirements.

1.4.7 Ensuring Requirements Traceability

When you're gathering requirements, the main thought that should be going through your mind is, Am I documenting things that will be understandable to the users and useful to the designers? Requirements must be traceable throughout the lifecycle of development. You should be able to ask any person in any role the questions in Table 1.4.

Table 1.4. Traceability Defined by Role

Role	Traceability
Analyst/designer	What requirements does this class on this class diagram relate to?
Developer	What requirements does the class you're programming relate to?
Tester	Exactly which requirements are you testing for when you execute this test case?
Maintenance programmer	What requirements have changed that require you to change the code that way?
Technical writer	What requirements relate to this section of the user manual?
Architect	What requirements define what this architectural component needs to do?
Data modeler	What requirements drove the design of this entity or database table/index?
Project manager	What requirements will be automated in working code in this iteration?

Unfortunately, these requirements traceability questions can rarely be answered in today's projects. But if they were, they would provide a solid audit trail for every activity in development and maintenance, and they would describe why the activities are being done. It would help prevent developer goldplating : the addition of system functionality that is not required by the users and therefore does not tie in with any documented requirements.

Automated tools are beginning to address the requirements traceability problem, but they're only part of the picture. We still need a little old-fashioned people management to maintain a requirements audit trail , which runs end-to-end throughout the lifetime of an application.