Database Reference
In-Depth Information
turn those requirements into a usable database. We attack this topic in two
phases: requirements gathering and requirements interpretation. In this
part, we talk through the requirements of Mountain View Music and de-
scribe how we went about extracting them.
Requirements Gathering
In Chapter 5, Requirements Gathering, we look at methods for gathering
requirements and explain which sort of information is important. The tech-
niques range from interviewing the end users to reverse-engineering an ex-
isting application or system. No matter what methods you use, the goal is
the same: to determine what the business needs. It may sound easy, but I
have yet to sit down with a customer and have him tell me exactly what he
needs. He can answer questions about the company's processes and busi-
ness, but you must drill down to the core of the problem.
In fact, a lot of the time, your job is to act like a three-year-old, con-
tinually asking, “Why?” For example, the customer will tell you he wants a
button; you ask why, and he will tell you it's to open a door. Why must you
open a door? The door must open in order to get product out of the ware-
house. Why does the product need to leave the warehouse? We have to get
the product into the hands of our customers. The bottom line is that he
wants a button in order to sell products to the customer. This is the basic
need of the business, and it's this information that is important. If you meet
this need, the customer won't really care whether you did it with a button
or a switch or a magic password.
Often, it's easy to focus our attention on making customers happy at
the cost of giving them what they really need. We simply give the customer
exactly what she asks for; in her mind, widget Z is what she needs, but in
reality widget Z may work beautifully as designed but not solve the actual
business problem. The worst feeling ever is at the end of a project when
the customer says, “It's exactly what we asked for, but it's not what we
need.” In Chapter 5 we go over several options for requirements gathering
so that you can avoid the problem of not meeting your customers' needs.
Requirements Interpretation
Once you have the first cut of the requirements, you start turning them
into a data model. In Chapter 6, Interpreting Requirements, we look at
how you take the requirements, which are in human language, and turn
them into a data model. We look not only at extracting the information re-
quired for the model, but also at extracting business rules.
Search WWH ::
Custom Search