Requirements Gathering

By Allen Holub

September 15, 2005 —

At the center of the design process is the notion of “requirements gathering,” but I think the entire notion is misguided. There is no such thing as a “requirement,” at least not in the way that most programmers or marketing people use the term. The only real requirement is that the program solve a real problem that vexes real users, that the program provide answers to specific questions about the real world.

When you focus on gathering discrete “requirements,” you focus on the minutiae: menu items, dialog-box contents and the like. All too often, the big picture—the problem that you’re trying to solve—gets lost and the program is a failure. It doesn’t actually do anything useful.

When designing, I think about problem definition, not requirements gathering. If presented with a specific requirement, I always ask: “Why do you need that? What task are you doing or what problem are you solving that would be made easier were that requirement implemented.” That, is I focus on the problem itself. The methodologies I use don’t use requirements lists. Instead, they use two documents that look more like essays than bullet lists.

First, a “problem statement” defines the user’s problem and any solution to that problem that can be expressed in domain terminology. It doesn’t describe a computer program; rather, it focuses on the real-world problems of the users. For example, I’m currently working on a system that solves problems associated with secondary-school administration—grant management in particular. The problem statement describes how the grants are administered, not how the program will look. In fact, words like “computer,” “system,” “database” and “user interface” don’t even appear in the problem statement. The audience is a school administrator, not a programmer.

The second piece of the puzzle is “use-case analysis.” The use cases define the tasks that the user has to perform to solve the problem you just identified. Like the problem statement, the use cases are defined using the vocabulary of the users, and are written in the context of the problem. They don’t describe how you might use a computer program; they describe how you solve the problem at hand. How do grant administrators set up and administer the grants? At the core of the use-case analysis are the activities that the user performs, and the sequence in which the activities are performed. There’s even a UML diagram for capturing this information, called an activity diagram.

The use cases, in turn, form the foundation of the program design. Most of the UML—the class diagram, the object-interaction diagrams, and so forth—emerge from the use cases.

So, how do you verify that you have captured the use cases correctly? I do it by mocking up the user interface. That is, the user interface is a central component of the design process itself, providing you with a way of testing the validity of the problem definition and use-case analysis. A UI mock-up is one of the most effective communication tools that you have when you’re trying to make sure that the design is on track. Conversely, for a user interface to be effective, it must closely reflect the activities that you identified in your use-case analysis. The use cases and the UI are tightly coupled.

Moreover, the UI provides you with a lot of interesting information about the object model. I see a screen as a composite, where various objects in the system are responsible for providing those parts of the UI that represent their own state. That is, a screen is actually showing you the internal state of several objects, and the organization of the screen can tell you a lot about how the object-model should be organized.

I’m not advocating a Visual Basic style of working. A program is not a user interface with intelligent warts hanging off the widgets. A program is an object model in which some of the objects present their state to the user. The UI should be constructed (or at least populated) at runtime by those objects.

Even my server-based programs work this way. The core application runs in its own server (which I call an “app server,” even though it typically doesn’t use EJB), and the application tells the Web server what the UI should look like. I usually use custom JSP tags to “attach” pieces of the interface to the objects in the app server. A typical JSF/Struts application, which is usually built using the Visual Basic attach-intelligence-to-controls metaphor, is poorly organized.

There are lots of good books on UIs. I had thought to discuss them this week, but I’m out of room, so I’ll continue this subject in my next column by discussing a few of them.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.

Share this link: http://www.sdtimes.com/link/28847

Seapine adds requirements management Issue tracking and source code management are tied into new requirements management software from makers of TestTrack

iRise, Ravenflow add visuals to Requirements Composer Coming on the release of IBM's Requirements Composer, two companies have created tools for visualizing requirement cases. iRise's visualizes requirement scenarios created in IBM's tool, while Ravenflow's automatically generates visual models from use cases.

IBM releases Jazz-based requirements definition tool set Rational Requirements Composer brings requirements definition to the beginning of the life cycle and enables several methods for team members to communicate with each other. IBM added that Requirements Composer can use Jazz to integrate with Telelogic's Doors.

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST