The previous chapters discussed databases in general terms. Chapter 1, “Database Design Goals,” explained the goals of database design and described some of the types of databases that are available. Chapter 2, “Relational Overview,” and Chapter 3, “NoSQL Overview,” described some specific kinds of databases in slightly greater detail. With this basic understanding, you're ready to take the first step in designing an actual database to solve a particular problem: understanding the user's needs.

Designing any custom product, whether it's a database, beach house, or case mod (you can search online for images of case mods), is largely a translation process. You need to translate the customers’ needs, wants, and desires from the sometimes fuzzy ideas floating around in their heads into a product that meets their needs.

The first step in the translation process is understanding the user's requirements. Unless you know what the user needs, you cannot build it. Designing the best order-processing database imaginable won't do you a bit of good if the customer really wants a circuit design database or an ostrich race handicapping system.

Just as the database design forms the foundation on which the rest of the application's development stands, your understanding of the user's needs forms the foundation of the database design. If you don't know what the user needs, how can you possibly design it?

If you don't understand the customer's needs thoroughly and completely, you may as well pack it in now. There's little satisfaction in wasting months of your life and a pile of your company's money to build something unusable. Make sure you're on the right road before you stomp on the accelerator and burn rubber down a dead-end alley.

This chapter explains techniques that you can use to learn about the customer's needs. It describes methods that you can use to record those needs in a concrete and verifiable way.

The sections that follow describe some of the steps that you can take to better understand your customer's needs. In some projects, you may not need to follow all of these steps. For example, if your customer is a single person with very concrete ideas about what needs to be done, then you may not have to spend much time learning who's who or brainstorming. If your customer works with government classified data, you may not be allowed to “walk a mile in the user's shoes,” and you may have access to only some of the business's documentation, so there's no point in trying.

In other projects, the steps may work best in a different order. You might find it better to brainstorm before visiting the customers’ site and watching them work.

These are just some steps that I've found useful in trying to understand a customer's situation. You'll have to adjust them as necessary to fit each of your projects.

In this chapter, you learn how to:

• Understand the customers’ needs and motivations.
• Gather and document user requirements.
• Cull requirements from existing practices and information.
• Build use cases to understand the user's needs and to measure success or failure.
• Anticipate changes and future needs to build the most flexible database possible.

After you master these techniques, you'll be ready to move on to the next step and actually start designing the database.

MAKE A PLAN

Although the steps described in this chapter sometimes occur in different order, the following list summarizes the order that's most typical. Feel free to add, remove, and rearrange them as necessary.

1. Bring a list of questions.
2. Meet the customers.
3. Learn who's who.
4. Pick the customers’ brains.
5. Walk a mile in the user's shoes.
6. Study current operations.
7. Brainstorm.
8. Look to the future.
9. Understand the customers’ reasoning.
10. Learn what the customers really need.
11. Prioritize.
12. Verify your understanding.
13. Create the requirements document.
14. Make use cases.
15. Decide feasibility.

This list isn't perfect but it makes a good meta-plan—a plan for making the project's plan. (Hopefully, it won't be as useless as the traditional pre-meeting agenda planning meeting.)

BRING A LIST OF QUESTIONS

From the very first day, you should start thinking of questions to ask the customers to get a better idea of the project's goals and scope.

The following sections list some questions that you can ask your customers to help understand their needs. You'll see many of them described in greater detail later in this chapter.

This list is by no means complete—the questions that you need to ask will depend to a large extent on the type of project. Use them only as a starting point. It's helpful to have something to work from when you start, however. Then you can wander off in promising directions as the discussions continue.

MEET THE CUSTOMERS

Before you can start any project, you need to know what it is about. Are you building an inventory system, a supply chain model, or a stock price tracker and predictor (also called a random number generator)?

The best way to understand the system that you need to design and build is to interrogate the customers. I use the rather unfriendly word “interrogate” because, to do the job right, you need much more than a simple chat over tea and crumpets. Learning about the customers’ requirements can be a long and grueling process. It can take days or even weeks of cross-examination; studying existing practices; poring over dusty scrolls, tomes, and other corporate documentation; and spying on the customers while they do their daily jobs.

When it's over, the customers shouldn't hate you outright, but they might wish you would go away and leave them alone for a while. A good question and answer session should leave everyone feeling exhausted but with the warm glow of satisfaction that comes from moving a lot of information from their brains to yours.

Customers who are truly dedicated to the company are usually willing to field even the most obtuse questions as long as you're willing to dish them out. Former Prime Minister of the United Kingdom Benjamin Disraeli once said, “Talk to a man about himself, and he will listen for hours.” Most customers are more than happy to share the ins and outs of their corner of the business universe with you for as long as you can stand it.

The goal isn't to torture the customers (although it may sometimes seem like it to them) but to give you an absolute and complete understanding of the problem that you're attempting to solve. You want as few surprises as possible after you're done researching the problem. Unexpected difficulties and feature requests are the biggest reasons why software projects finish late, come in over budget, or fail completely.

The sooner you identify a system's features and the more completely you anticipate potential problems, the easier it will be for you to plan for them and the less they will mess up your meticulously crafted plan. Your initial encounters with the customer give you your first chance to address these issues so that they don't bite you later.

So when you first start a project, meet the customers. Get to know them and what they do. Even if the problem you are trying to solve is only a small part of their business, get a feel for the overall picture. Sometimes, you'll find unexpected connections that may make your job easier or that may lead to surprising benefits in a completely unrelated area.

When you first meet the customers, it usually doesn't hurt to warn them that you're going to be a major pest for a while. This can also help you figure out who's who. Those who are committed to the project and are eager to succeed will take your warning well. Those who are less than dedicated may tip their hand at this point. This idea leads naturally to the next section.

LEARN WHO'S WHO

Ideally, a project team works well together, everyone does the best possible job without conflict, and the project moves along smoothly to create a finished product that meets the customers’ needs. In practice, however, it doesn't always work out that way. Like the bickering superheroes in an X-Men movie, everyone has their own personal abilities, agenda, and motivation that don't always coincide with those of the other team members.

As you get to know the customers (and your team members), it's important to realize that not everyone shares the same vision of the product. You need to figure out what customer is the leader, who are team players, who have little or no say in specifying the project, and who will be supervillains.

The following list describes some of the roles that customers (and developers) often play in a project. Naturally, these cannot categorize everyone, but they define some characteristics that you should look for.

• Executive Champion—This is the highest-ranking customer driving the project. Often, this person doesn't participate in the project's day-to-day trials and tribulations. The Executive Champion will fight for truth, justice, and getting you that extra laptop you need. In the end, the Executive Champion must be able to take on any supervillains, or you might be in trouble.
• Customer Champion—This person has a thorough understanding of the customers’ needs. Lesser champions may help define pieces of the project, but this is the person you run to when the others are unclear. For the purposes of this chapter, this is the most important person on the project. This person must have enough time and resources (also known as “people”) to help you define the project and answer your questions. Ideally, they also have enough clout to make decisions when the heroes start bickering over who has to fight Magneto and who gets to fly the invisible plane.
• Customer Representative—A Customer Representative is someone assigned to answer your questions and help define the project. Often, they are people who do the day-to-day work of your customers’ business. Sometimes, they are experts in only parts of the business, so you need more than one around to cover all of the business's issues.
• Stakeholder—This is anyone who has an interest in the project. Some of these folks fall into other categories like Customer Champion or Customer Representative. Others are affected by the outcome but have no direct say in the system's design. For example, frontline clerks rarely get to toss in their two cents when you design a point-of-sales system, and sales and marketing people may eventually need to sell your system (although sales and marketing people are usually prohibited from knowing anything about the systems they sell—I think there's a law or something). Stakeholders are like the civilians whose fate is determined by the battling superheroes and who are easily crushed by falling debris and exploding robot monsters. Although many of them have no direct power over the outcome, you should keep them in mind and try to minimize collateral damage. (In a really well-run company, these people have their own representatives on the project to watch out for them.)
• Sidekick/Gopher—This is someone who can help you get the more mundane resources that you need, such as conference rooms, airline tickets, donuts, and kryptonite. Although this isn't a glamorous job, an effective Sidekick can make everything run more smoothly. (Sometimes, they also provide comic relief. On one project, the Sidekick invited everyone out to a huge celebratory lunch, his treat, only to find that the restaurant didn't take credit cards, so we all had to chip in. In all fairness, though, that could have happened to any of us.)
• Short-Timer—This is someone who is only going to be around for a short while. This may be someone who is about to be promoted to a new division, who will retire soon, or who is just plain fed up and about to walk out. A dedicated short-timer can be a huge asset, particularly those who are about to retire and take a lifetime's worth of experience with them. Others don't care all that much whether the project succeeds or fails after they're gone. (These are like the red-shirts on Star Trek who don't contribute much. When Kirk says, “Spock, Bones, and Smith, meet me in the transporter room,” guess who isn't coming back?)
• Devil's Advocate—This is an important role for avoiding groupthink. Left unchecked, some groups become irrationally optimistic and can make extremely poor decisions. A Devil's Advocate can help bring the hopeless dreamers back to Earth and keep the project realistic … as long as the Devil's Advocate doesn't get out of hand. The purpose of the Devil's Advocate is to maintain a reality check, not to defeat the entire project. If this person shoots down every idea anyone comes up with, you might gently mention that eventually you need to decide on an approach and get something done or you may all need to update your résumés.
• Convert—This is someone who originally is against the project but who you convert to your cause. Strangely, both finding and converting this person is usually surprisingly easy, at least for bigger projects. If you talk to the disenfranchised stakeholders (the frontline users who have no say in the matter), you can usually find some who are dead set against the project, if for no other reason than it represents change. Take one or two of these people who have a fair amount of experience and make them Stakeholder Representatives. Get them involved early in the process and take their suggestions seriously. If you act on some of their suggestions, you'll show that you have the Stakeholders’ interests in mind and you'll win their loyalty. They'll tell the rest of the Stakeholders, and if all goes well, you'll have more support than you can imagine. And who knows, you may build a better product with their input.
• Generic Villain—These range from simple defeatists and layabouts to Arch Supervillains actively trying to sabotage the project. Try to identify these people early so you know what you're up against. (On one project, we had a supervillain at the vice president level. We also had an Executive Champion at the same level, so we were able to hold our own, but it was pretty tough going. It's easy to get squashed when such heavy-hitters collide.)

Don't feel constrained by this list. These are just some of the characters that I've encountered, and you may meet others.

I don't mean to imply that every project is subject to continual harassment, interference, and sabotage. I've worked on plenty of projects where everyone really was pulling for the common good and we achieved impressive results. Just keep your eyes open. Identify the main players as quickly as possible so you know who to ask questions and where to run when the fighting erupts.

PICK THE CUSTOMERS’ BRAINS

Once you figure out more or less who the movers and shakers are, you can start picking their brains. Sit down with the Customer Champion and Customer Representatives and find out what the customers think they need. Find out what they think the solution should look like. Find out what data they think it should contain, how that data will be presented, and how different parts of the data are related.

Get input from as many Stakeholders as you can. Always keep in mind, however, that the Customer Champion is the one who understands the customers’ needs thoroughly and has the authority to make the final decisions. While you should consider everyone's opinions, the Customer Champion has the final word.

Depending on the scope of the project, this can take a while. I've been on projects where the initial brain-picking sessions took only a few hours, and I've been on others where we spent more than a week talking to the customers. One project was so complex that part of the project was still defining requirements after other parts of the project had been underway for months.

Take your time and make sure the customers have finished telling you what they think they need.

WALK A MILE IN THE USER'S SHOES

Often following the customers’ day-to-day operations can give you some extremely helpful perspective. Ideally, you could do the customers’ jobs for them for a while to thoroughly learn what's involved. Unless you are in your customers’ industry (and if you are, why are they hiring you?), however, you probably aren't qualified to do their jobs.

While you may not be able to actually do the customers’ jobs, you may be able to sit next to them while they do it. Warn them that you will probably reduce productivity slightly by asking stupid and annoying questions. Then ask away. Take notes and learn as much as you can. Sometimes, your outsider's point of view can lead to ideas that the customers would never have discovered.

Take notes while you're watching the customers do their jobs. Draw pictures and diagrams if that helps you visualize what they're doing. Pictures can also be very helpful in asking the customers if you have the right idea. If the customers will let you, print screenshots and even take photographs. (However, keep in mind that many businesses are required to safeguard the privacy of their clients’ data, so don't expect them to let you walk out with screenshots or photographs showing credit card information, medical histories, or records of political contributions. Be sure you ask before you try to take any material away and ask before you even bring a cell-phone camera into the building.)

STUDY CURRENT OPERATIONS

After you've walked a mile or two in the customers’ shoes, see if there are other ways that you can study the current operation. Often, companies have procedure manuals and documentation that describes the customers’ roles and responsibilities. In fact, that kind of documentation is required for certain kinds of International Organization for Standardization (ISO) certifications. Some bigger companies like to display huge banners that say things like “ISO-9000 Certified.” These may just be there to cover holes in the wall, but if they have such a banner then they probably have more documentation than you can stomach.

Make sure the documentation is up-to-date and that the customers’ practices actually match the documentation. If they differ, find out which version of reality your database should support.

Look around for any existing databases that the customers use. Don't forget the lesson of the earlier chapters that there are many different kinds of databases. Don't just look for relational databases. Look also for note files, filing cabinets, boxes of index cards, tickler files (cubbies where customers place items that should be examined on a certain date), and so forth. Generally, snoop around and find out what information is kept where.

Figure out how that information is used and how it relates to other pieces of information. Different physical databases often contain redundant information and that forms a relationship. For example, a filing cabinet holding information about customers includes all of the customers’ data. A pile of invoices also includes the customers’ names, addresses, ID numbers, and other information that is duplicated in the customer files. Paper orders probably contain the same information. These are the sorts of pieces of data that tie the whole process together.

BRAINSTORM

At this point, you should have a decent understanding of the customers’ business and needs. To make sure that the customer hasn't left anything out, you can hold brainstorming sessions. Bring in as many Stakeholders as you can and let them run wild. Don't rule out anything just yet. If a Stakeholder says the database should record the color of customers’ shoes when they make a purchase, write it down. If someone else says they need to track the number of kumquats eaten by assembly line workers, write it down.

Continue brainstorming until everyone has had their say and it's clear that no new ideas are appearing.

Occasionally, extra creative people (sometimes known to management as “troublemakers”) look like they're going to go on forever. Let them speak for a while, but if it's clear that they really can't stem the flood of ideas, split up. Have everyone go off separately and write down anything else relevant that they can think of, then come back and dump all of the ideas in a big pile.

Try not to let the Customer Champion suppress the group's creativity too early. Although the Customer Champion has the final say, the goal right now is to gather ideas, not to decide which ones are the best.

The goal at this point isn't to accept or eliminate anything as much as it is to write everything down. You want to be sure that everything relevant is considered before you start designing. Later, when you've started laying out tables and indexes and changes are more difficult to make, you don't want someone to step in and say, “Owl voltages! Why didn't someone think of owl voltages?” Hopefully you have owl voltages written down somewhere and crossed out so you can say they were considered and everyone agreed they were not a priority.

LOOK TO THE FUTURE

During the brainstorming process, think about future needs. Explicitly ask the customers what they might like to have in future releases. You may be able to include some of those ideas in the current project, but even if you can't it's nice to know where things are headed. It will help you design your database flexibly so that you can more easily incorporate changes in the future. (It also shows that you care.)

For example, suppose your customer Paula Marble runs a plumbing supply shop but thinks that someday it might be nice to add a little café and call the whole thing “Paula's Plumbing and Pastries.” After you hide your snickers behind a cough, think about how this might affect the database and the rest of the project.

Plumbing supplies are generally nonperishable, but pastries must be baked fresh daily and some of the ingredients that go into pastries are extremely perishable. You may want to think about using separate inventory tables to hold information about nonperishable plumbing items that clients can purchase (for example, gaskets, thread tape, pipe wrenches, and so forth) and perishable cooking items that the clients won't buy directly (like flour, eggs, raspberries, and so on).

You might not even track quantity in stock for finished pastries (the clients either see them in the case or not), but you probably want to be able to record prices for them nonetheless. In that case, you will have entries in an inventory table that will contain prices but that will never hold quantities.

You don't necessarily need to start planning the future database just yet (after all, Paula may decide to name the business “Paula's Plumbing and Tattoo Palace” instead), but you can keep these future changes in mind as you study the rest of the problem.

UNDERSTAND THE CUSTOMERS’ REASONING

Occasionally, you'll come across customers who think they know something about database design. They may say that you should use a particular table structure, an object-relational hierarchical data model, or an acute polar space modulator.

Sometimes, these suggestions make perfect sense. Other times, you'll think the customer clicked the Google “I'm Feeling Lucky” link and stumbled into an endless morass of techno-babble and database conspiracy theories.

Even if the suggestions seem to make no sense whatsoever, don't dismiss them out of hand. Remember that customers have a different perspective than you do. They know a lot more than you do about their particular business. They may or may not know anything about database design, but it's entirely possible that they have a reason for their obscure requests.

For example, suppose you're trying to design a sales and inventory system for Thor's Thimbles. The president and CEO, Thor, says he thinks you need to use a temporal database, although the way he pronounces it makes you think he probably doesn't understand what that means (or perhaps it's just his Scandinavian accent). You think, “How hard can it be to sell thimbles?” and ignore him.

After you spend a month building a really slick relational database, you discover that old Thor isn't so naive after all. It turns out that the company sells hundreds of different models of thimbles made from such materials as stainless steel, anodized aluminum, gold, and platinum. The value of the more exotic models changes daily with precious metal prices. Almost as volatile are the collectors’ models, such as the Great Scientists of History series and the Sports Immortals (the Pete Rose Hall of Fame model can bring up to $200 at auction).

Suddenly what you thought was a simple problem really does have hundreds of variables changing rapidly over time, and you realize that you probably should have built a temporal database. You have egg on your face, and Thor decides that his brother-in-law, who originally suggested the temporal database to Thor, might be able to do a better job than you.

Even if a customer's suggestion seems odd, take it seriously. Dig deeper to find out why the customer thinks that will be useful. Take the approach my doctor takes when I tell him that I think I have scurvy, the plague, or some other nonsense. He keeps an absolutely straight face and asks, “Why do you think that?” I won't be right, but the symptoms I used in my incorrect diagnosis may help him decide that I really have a cold. (I envision him with the other doctors sitting in the break room later, laughing and saying, “You'll never guess what my patient thought he had today! Ha, ha, ha!”)

LEARN WHAT THE CUSTOMERS REALLY NEED

Sometimes, the customers don't completely understand what they need. They think they do and they almost certainly understand the symptoms of their problems, but they don't always make the right cause-and-effect connections.

They may think a database or a new computer program will magically increase their sales, reduce their costs, walk their dogs, and wash their cars. In fact, a well-designed database will increase consistency, reduce data entry errors, provide reports, and otherwise help the customers manage their data, but that won't necessarily translate into higher profits.

As you look over the customers’ operation, keep in mind that their real goals may not be exactly what they think they are. Their real goals probably include things like making bigger profits, making fewer mistakes so they don't get yelled at as much by managers and clients, and finishing their daily work in time to go watch their kids’ soccer practice.

Look for the real causes of the customers’ problems and think about ways that you can address them. If you can see a way to improve operations, suggest it (always keeping in mind that they probably know a whole lot more about their business than you do, so there's a good chance that your idea won't fly).

PRIORITIZE

At this point, you should have a fair understanding of the customers’ business, at least the pieces that are relevant to your project. You should understand at least roughly which customers will be playing which roles during the upcoming drama. At a minimum, you should know who the Customer Champion and Customer Representatives are so you know who to pester with questions.

You should also have a big list of desired features. This list will probably include a lot of unicorns and pixie dust—things that would be nice to have but that are obviously unrealistic. It may also include things that are reasonable but that would take too much time for your current project.

To narrow the wish list to a manageable scope, sit down with the customers and help them prioritize. You'll need the Customer Representatives who understand what is needed so they can make the decisions. Sometimes, you may need the Customer Champion either in the meeting or available for consultation to make the tough calls.

Group the features into three categories. Priority 1 (or release 1) features are things that absolutely must be in the version of the project that you're about to start building. This should be the bare-bones essentials without which the project will be a failure.

Priority 2 (or release 2) features are those that the customers can live without until the first version is in use and you have time to start working on the next version. If development goes well, you might be able to pull some of these features into the first release, but the customers should not count on it.

Priority 3 (or release 3) features are those that the customers think would be nice but that are less important than the Priority 1 and 2 features. This is where you place the unicorns and pixie dust so you can ignore them for now.

This is another place where different development shops take different approaches. In the more flexible approach that I prefer, these categories are somewhat flexible. If, during development, you discover that some Priority 2 feature would be really easy to implement, you can pull it into the current release. In contrast, if some Priority 1 feature turns out to be unexpectedly hard, you might ask the customers how important it really is and suggest that it be bumped to the Priority 2 list to avoid endangering the schedule.

To make this sort of shuffling easier, it can be helpful to further prioritize the items within each category. If an item is high up on the list of Priority 1 items, then it is not a good candidate for deferral to the next release. Similarly, if an item is high up in the Priority 2 list, you might be willing to spend a little extra effort to bring it into the first release.

In a hardline development approach, the categories are fixed after the requirements phase ends and items never move from one category to another. This prevents the customers from promoting items from Priority 2 to Priority 1, so it can save you some trouble. However, this approach also makes it hard for you to downgrade a feature that turns out to be a real project albatross.

VERIFY YOUR UNDERSTANDING

With your notebook (and brain) bursting at the seams with all of this information, it's almost time to move on to the next chapter and start building a data model. Before you do that, however, you should verify one last time that you really understand the customers’ needs. This may be your last chance to avoid a future filled with tar and feathers, so be sure you've gotten it right.

Walk through your understanding of the system and explain it to the customers as if they were building the system for you and not the other way around. They should make comforting grunts and noises like “yup” and “uh huh.”

Watch out for words such as “but,” “except,” and “sort of.” When they use those words, make sure that they're only emphasizing something that you already know and not adding a new twist to things. Often at this stage, the customers think of new situations and exceptions that they didn't think of before.

Pay particular attention to exceptions—cases where things mostly work one way but occasionally work in another. Exceptions are the bane of database designers and, as you'll see in later chapters, you need to handle them in a special way.

For example, suppose you need to allow for returns. (A client might decide that the Kathryn Janeway sculpture he ordered is too short or clashes with his Predator statue.) While reviewing your understanding of the project, you say, “The receiving clerk enters the RMA (return merchandize authorization number) and clicks Done, right?” Your Customer Representatives look sheepishly at each other and say, “Well … usually but sometimes they don't have an RMA. Then they just write in ‘None.’” This is an important exception that the customers didn't tell you about before and you need to write it down.

For another example, suppose your customers currently use paper order forms that have shipping and billing address sections. You say, “The form needs to hold one shipping address and one billing address?” Your customer replies, “Well, sometimes we need two shipping addresses because different parts of the order go to different addresses.” Someone pulls out an order form where a second address and additional instructions have been scribbled in the margin.

This is a huge exception. It's easy enough to add little notations to a paper form, but it's impossible to add more than one address value to a single set of fields in a database. You can work around the issue if you plan for it, but it can be a major headache if you don't learn about it ahead of time. If you don't plan for this, the users will probably put extra addresses in a comment field where the database can't verify it.

For a final example, suppose a customer record needs a billing address. While you're reviewing your understanding the customer says, “Oh yeah, and a shipping address because sometimes they buy one as a gift.” Now you have to wonder if sometime later someone will decide that you also need a contact address in case you have questions about the order, or a corporate address where you can send legal correspondence. Or perhaps a whole slew of branch-office addresses, or an executive address where you can send golf clubs to bribe the client's CEO.

When your customer expands a single field (or a group of fields such as an address), you should ask seriously whether it's going to happen again. If the record needs to hold many copies of the same field, you can easily pull them into a separate table if you plan ahead of time, but it can be hard to add new copies of fields to a table after you build it and its user interface. A single customer record can hold one or two addresses but not an ill-defined, ever-expanding number. It's better to know ahead of time and plan for an arbitrary number of related addresses.

Sometimes in database design, it's better to only allow one item or many items. There's no such thing as two.

CREATE THE REQUIREMENTS DOCUMENT

The requirements document describes the system that you are going to build. This document is sometimes called the product requirements document (PRD), the requirements specification, specification, or spec. As all of these names imply, this document specifies the project's requirements.

Note that the requirements document is usually not a document. It's often a collection of electronic documents, prototypes, memos, diagrams on sticky notes, emails, captured video conference calls, user stories, diagrams scribbled on napkins, and other artifacts that collectively define the system.

At a minimum, the requirements document needs to spell out what you're planning to build and what it will do. It needs to explain how the customers will use the final application to solve their problems. It can also include any design or architecture that you've already done, and it can include (possibly as attachments or appendixes) summaries of the discussions you've had while deciding on the project's features.

The requirements document keeps everyone on track during later design and development. It can also prevent finger-pointing when someone starts yelling about how you forgot to include the telepathic user interface. You can simply point to the requirements document and say, “Sorry, but the telepathic interface isn't in here.” In fact, if you considered this issue during brainstorming and dumped the telepathic interface into the Priority 3 “unicorns and pixie dust” category, having it listed there will probably allow you to skip the whole argument. The potential wave-maker can see that the issue has been shelved for now and will probably not bother stirring up trouble on a dead issue.

(I've worked on some projects that had enormous requirements documents, sometimes running to 500 or more pages. In that case, it's hard for anyone to remember everything that's in there and you may end up revisiting some issues occasionally. Hopefully you thought ahead and created an index.)

The requirements document should define deliverables (also called milestones, not to be confused with millstones) that the customers can use to gauge the project's progress. These should be tasks that you complete along the way, that you can show to the customer, and that can be verified in some meaningful way. It's important that they be verifiable. Saying that you're 25 percent done thinking about the design doesn't do the user any good. Saying that you have built a database and filled it with test data drawn from a legacy system is much more useful and verifies that the database can hold that kind of data.

If you make the database design a deliverable (usually a good idea), then you need to be able to somehow verify that the design meets the customers’ needs. Usually that means an extensive review where a lot of people put their heads together and try to poke holes in your carefully crafted design.

Prototypes also make excellent deliverables. Customers can experiment with a prototype to better understand what the system will do, and they can give you feedback if you're not heading in the right direction. If you're building a full-blown user interface for the database, then you could mock up some prototype screens (probably with no error checking and possibly with just a little concocted data) to give the customers a feel for the completed application.

Some of the deliverables defined by the requirements document should be final deliverables. These are deliverables that determine whether the project is finished. Like all of the other deliverables, they must be measurable to be useful.

A particularly useful technique for deciding when a project has met its goals is to create use cases, which are described in the following section.

MAKE USE CASES

A use case is a script that the users can follow to practice solving a particular problem that they will face while using your finished product. These can range in complexity from the very simple (such as logging in or closing the application) to the extremely complex (such as scheduling a fleet of trucks to perform in-home dog grooming).

Depending on how complete the user interface design is when you are writing the use cases, they may be sketchy or extremely detailed. They may spell out every keystroke and mouse movement that the user must make, or they may provide vague instructions such as, “The user will use the Order Entry form to place a new order.”

When the project is finished, the customers should review all the use cases and verify that the finished project can handle them all. (In self-defense, you should run through the use cases before you tell the customers that you're finished. That way, you don't look silly when the product cannot handle simple chores during an executive dog-and-pony show.)

Some of the things that you might specify when writing up a use case include:

• Goals—A summary of what the use case should achieve.
• Summary—An executive overview that even your Executive Champion can understand.
• Actors—Who will do what? This includes people, your finished system, other systems, and so forth—anyone or anything that will do something.
• Pre- and post-conditions—The conditions that should be true before and after the use case is finished. For example, a pre-condition to placing a new order might be that the client placing the order already exists.
• Normal Flow—The normal steps that occur during the use case.
• Alternative Flow—Other ways that the use case might proceed. For example, when a user tries to look up a customer, what happens if the customer isn't there?
• Notes—Just in case there are special considerations that the person following the use case needs to know.

Many developers like to draw use case diagrams to show what actors perform what tasks. These seem to usually work at one of two levels.

A higher-level use case shows which actors perform which tasks. For example, the Student actor enrolls in a class and takes the class, the Instructor actor teaches the class and assigns grades, and so forth. (If the student is taking an acting class, then things can get really confusing.) This type of use case diagram provides little detail about how the actors accomplish their tasks. It's useful early on when you know what you want to do but don't yet know how the system will do it.

Figure 4.1 shows a high-level use case diagram. Actors are shown as stick figures, tasks are shown in ellipses, and lines connect actors to tasks. More elaborate use case diagrams use other kinds of arrows, lines, and annotations to provide more detail.

The second kind of use case lists more specific steps that actors take to perform a task, although the steps are still listed at a fairly high level.

Neither of these kinds of use case diagram provides enough detail to use as a script for testing, although they do list the cases that you must test. Because they are shown at such a high level, they are great for executive presentations. For more information on use case diagrams, look for books about Unified Modeling Language (UML), which includes use case diagrams, or search the web for “use case diagram.”

Typical use cases might include:

• The user logging in
• The user logging out
• Switching users (if the program allows that)
• Creating a new customer record
• Editing a customer record
• Marking a customer record as inactive
• Creating a new order for an existing customer
• Creating a new order for a new customer
• Creating an invoice for an order
• Sending out late payment notices
• Creating a replacement invoice in case the customer lost one
• Receiving a payment and recording the invoice as paid
• Defining a new inventory item (for example, when the CEO decides that you should start selling Rogaine for Dogs)
• Adding new items to inventory (for example, when you restock your fuzzy dice supply)

The list can go on practically forever. A large project can include hundreds of use cases, and it might take quite a while to write them all down and even longer to later verify that the finished project handles them all.

In addition to being measurable (you want to be able to tell whether the program can pull its weight), use cases should be as realistic as possible. There's no point in verifying that the program can handle a situation that will never occur in real life.

DECIDE FEASIBILITY

At some point, you should step back, take a deep breath, and decide whether the project is feasible. Is it even possible to design a database to do everything that the customer wants it to do?

Can you really build a database to hold records for 17 million customers, provide simultaneous access for 80 service representatives, log every transaction with timestamps and user IDs, give interactive responses to queries in less than 2 seconds 90 percent of the time, and still fit it all on a 16 MB flash drive?

Okay, the last condition is pretty unrealistic, but seriously someone must think about the project's viability at some point. No one will be happy to hear that you can't solve all the customers’ problems, but everyone will be a lot happier if the project is canceled early instead of after you've wasted a year of everyone's time and a king's ransom in funding.

If it really looks like you can't complete the project, make the tough call and ask everyone to rethink. Perhaps the customers can give up some features to make the project possible. Or perhaps everyone should just walk away and move on to a more realistic project.

SUMMARY

Building any custom product is largely a translation process whether you're building a small database, a gigantic Internet sales system similar to the one used by Amazon, or a really tricked-out snowboard. You need to translate the half-formed ideas floating around in the minds of your customers into reality.

The first step in the translation process is understanding the customers’ needs. This chapter explained ways that you can gather information about the customers’ problems, wishes, and desires so you can take the next step in the process.

In this chapter, you learned how to:

• Try to figure out which customers will play which roles.
• Pick the customers’ brains for information.
• Look for documentation about user roles and responsibilities, existing procedures, and existing data.
• Watch customers at work and study their current operations directly.
• Brainstorm and categorize the results into Priority 1, 2, and 3 items.
• Verify your understanding of the customers’ needs.
• Write requirements documents with verifiable deliverables, including use cases.

After you've achieved a good understanding of the customers’ needs and expectations, you can start turning that understanding into data models. The following chapter explains how to convert the customers’ needs into informal data models that help you better understand the database, and then how to convert the informal models into more formal ones that you can actually use to build a database.

Before you move on to Chapter 5, however, use the following exercises to test your understanding of the material covered in this chapter. You can find the solutions in Appendix A.