Everything you wanted to know about customers but were too busy coding to ask.

In our last column, we discussed some of the customer personalities we have commonly met during analysis and requirements gathering. In this column, we round out the discussion by describing what requirements gathering is and isn't, and putting it in the context of the current state of the art.

Requirements gathering: Where does it fit?

Every project needs requirements gathering, no matter how complex or simple the project, and no matter how experienced or large the programming team. It seems too obvious to state that the result of requirements gathering is a blueprint for what will be built. It seems obvious, but requirements gathering is often undervalued.

This column will not discuss the formal structure of analysis and requirements gathering. There are excellent resources for this, including this issue's article by Ellen Whitney, “Introduction to Requirements and Use Cases.” Other resources are listed at the end of this column.

However, as Andy Pols says in his online article, “Using Viewpoints to Aid Requirements Elicitation,” “Until recently, almost all of the methodologies assumed the prior existence of a requirements specification. The elicitation of the requirements was someone else's problem.” http://www.pols.co.uk/usecasezone/use-case-viewpoint.html

Andy correctly identified that this approach is shortsighted, and we agree, given that coordinating a sometimes-recalcitrant customer and all the stakeholders, can be far more challenging than mere technical issues.

This Would Be So Much Easier Without Clients

There are some common scenarios that are mistaken for being the sum of requirements gathering. It is always important to continue to engage the customer. It's human nature that the customer wants to minimize the burden on her by giving you what she sees as everything you need. Then she can get back to her work. As much as we might like to accommodate her, it has never worked, in our experience, no matter how adamant a customer has been that “this report” or “this point-of-contact” or “this application will tell you everything you need to know.”

The psychology of the moment seems to be “If you're such a great professional, you won't need to ask me any questions.” This is where keeping one's ego out of the equation and implacably driving towards uncovering requirements will help with that nasty stomach acid problem. So, let's look at a few scenarios.

Scenario 1 might involve the customer dumping a stack of reports from either several years or only a few days on your lap and saying, “give me a system that duplicates these.” The problems with this approach are many.

The reports may be too old or incomplete to capture everything the customer needs; reports should have little bearing on the user interface requirements; reports only hint at the business logic behind the data; and, reports may draw on data from outside systems. Instead of debating the value of the reports, engage the customer by asking the following questions: how often is each report used; what is the report's priority; who uses each report (the stakeholders); how does each stakeholder use the report; which reports share information (and is the data consistent); and, what do the users like and dislike about each report?

Often the project's point-of-contact is surprised by what he learns from the stakeholders, and eventually agrees that the reports are probably not the correct place to start.

Take some time to analyze the reports and find the discrepancies that are usually present as a way to validate why you're asking the customer to stay involved. Customers appreciate the effort if they see how a lack of initial care is impacting them in their current system. This technique can be applied to occasions when you're given a copy of the software for the old system, and are expected to create the new system based on the old. In either case, it is desirable to have these work products, but they are only part of the requirements and should be used to raise questions. Besides, as others have pointed out, if your customer wants you to build a system that gives him what he already has, why build a new one?

Scenario 2 might have your customer telling you what business she is in - let's say retail jewelry. She gives you a vague description of the task (an inventory system), and then says, “You're the expert, you tell me what I need.” Or, worse, she says, “...give me what I need.” An excellent way to keep the customer engaged is to learn some of the differences within the industry so you can frame questions as an insider.

What do we mean by that? If you don't know different approaches to running a retail jewelry business, you are in danger of providing, at best, a too-generic solution, in which case one wonders why a custom application is necessary. On the other hand, if you are familiar with the retail jewelry industry, you can ask specific questions, such as, “Do you create custom settings? If so, do you stock raw materials as well as finished pieces? Do you value your inventory based on current world-market prices for the gems and metals? Do you sell pieces on consignment?”

The benefit to this approach is that you and your customer gain a clear idea of what is needed and what will be delivered. Also important to you as a business person, you are likely to uncover additional areas in which you can support your customer. Whether you are an internal developer or independent contractor, you should always be looking for legitimate ways to build your business. Think of requirements gathering as a necessary step in defining the specification of the immediate project, but also as an opportunity to discover other areas of customer need.

Scenario 3 may be a case where you're in a meeting with the stakeholders, discussing the requirements of the new system, but find that there is no one present who uses the system on a daily basis (a “Domain Expert”). When you ask if it would be possible to invite one of these domain experts into the meeting, the manager responds, “No, they have too much to do. Besides, we can decide what needs to be done, and don't really need anyone from data entry.” Your best course of action in this situation is to accept what the manager says, but make sure you ask enough questions about the day-to-day use of the system to fully understand the requirements.

You may indirectly reveal that the manager doesn't know as much as she thought about the system, when she finds herself saying she thinks the answer is X and not Y, but you'll have to talk to someone else to confirm that. This would be ideal, because it clears the way for you to talk to one or more domain experts.

What's worse is when the manager answers questions as if she were the authority, but really doesn't know the story. This is a much more dangerous situation, because talking directly with domain experts can look like you're questioning the manager's judgement. In this case, it's more important than ever to have many interim releases of your software to confirm your understanding of the system requirements.

Leaping Tall Buildings

Meeting with stakeholders, sitting beside users as they perform the tasks you will automate, writing down and reviewing with the customer what you've learned, then having more meetings is, arguably, the only way. As abhorrent as meetings may be, there really is no alternative.

This is a “soft” science that is subjective and hard to define, and programmers aren't always equipped with the skills to handle these tasks effectively. You can probably learn to be competent at it, but you could also team up with someone who is skilled in working with people. For example, those who like animals and medicine but dislike people aren't good candidates for veterinarian school. Why? Because they have to work with people in order to help the animals. It's the same with software development. Software is not about computers; it's about the people who will be using the software.

The Product

The product of requirements gathering is traditionally a functional specification. Within the unified process we have another step that might seem to be extra work. That's the “use case.” Nancy has been working with use cases for a year now, and while that qualifies her as a mere newbie, she has found the technique helpful. In her experience, use cases answer many questions for you. When have you had enough meetings? How do you know when to let a conversation roam and when to rein it in?

In the beginning, conversations will be wide-ranging and free-form. Write down everything you hear people say they want, dislike, like, do, or think about the process. Before meeting with the stakeholders again, review and rewrite a logical summary of what you've heard. Starting the discussion with what you've written, you may prompt the stakeholders to clear up misunderstandings or add additional information.

Use cases provide a structured way to formulate what you've heard in a way that will make sense to the stakeholders. Use cases also help you logically define the design, and provide a guideline for measuring the project's success. There are several variations on use case templates, and there is enough written on the subject to satisfy the most lofty academic. Really, though, it's quite simple in essence. Each use case is a specific scenario that describes how your software will interact with the outside world, whether with a user, or with another system. It does not describe how the software will be implemented.

However, use cases are designed to capture only functional requirements (what the software needs to do). You still need to capture non-functional requirements (the software's look, feel and responsiveness). An example from Mastering the Requirements Process, by Suzanne Robertson and James Robertson, ISBN: 0201360462, is the non-functional requirement that all forms will display the customer's logo and use the customer's color scheme.

Modern Maturity

Although most people who haven't gone through a formal requirements gathering process tend to resist it, those who have experienced it are almost always sold on it. So, how can you overcome the skepticism? One benefit to using a formal process is that you have the weight of the industry behind you. In other words, our customers are sometimes reassured and more amenable to these formal processes if they know it's not “just us” proposing them.

Some customers will like a structured format, while others will prefer less structure. The unified process is nicely adaptable to suit you, your customer, and your project. Once you have the understanding and experience with these techniques, hold to the courage of your convictions. Establish with your customer early on that you work with a specific process, and explain that it is unavoidable, but flexible.

Learning About The Subject: Background And Resources

We've touched on the first steps in designing and modeling a project. A complete discussion of the topic is outside the scope of this column and is the subject of many excellent books. Here are some basic references to get you started.

As we mentioned at the beginning, this issue has an article by Ellen Whitney called “Introduction to Requirements and Use Cases,” based on her series of Wednesday Night Lectures. Her lectures are archived on http://fox.wikis.com, under the Wednesday Night Lecture Series topic. The lecture notes include useful book and online references to the subject.

There are good resources on the website http://www.atlsysguild.com/GuildSite/Robs/MRP.html. Thanks to Ellen Whitney for this resource.

Whil Hentzen's Software Developer's Guide, available at http://www.hentzenwerke.com has useful templates for functional specifications.

Next: Don't Be A Stranger in the Night

During program development, you're often working on your own more than interfacing with the customer. But it's important that he stay in the forefront of your mind. In this phase more than any other, it's vital that you think from the perspective of a user as much as possible.

We'll also discuss delivering interim versions during the programming phase, and the pros and cons of doing so.

Nancy Folsom and Barbara Peisch