What? What does this system need to do?
This is fairly simple and most of this information is going to come from interviews. If
you have the time, have the person you are interviewing show you how they do their job.
Have them go over it until you have a good understanding as to why this system will help
them and why they need this. Remember, a long interview can be priceless when it comes to
learning what the user wants and needs.

A good portion of this question is going to be answered by design questions after you have
all the interviews completed. Here is where the designer needs to have great listening
skills. I always ask questions along the lines of what colors they like and what is easy
on their eyes. I have found that some users place a lot of importance on the colors and
other cosmetc attributes of the appl. I lets them feel that they play a bigger part in
the process.

After I had finished up with my interviews I came to the following conclusion. I had a
lot of reports with not a lot of data entry. (My database was about billing and mostly
included invoicing and aging reports). I also found need to keep track of dates. Lots of
dates. Date due, date client was first invoiced, date of second or third invoice, if any,
as well as, the date of a payment or cancellation. Knowing about all this date tracking
helps me with the aging report, in the long run. I, of course, had to keep track of who the
company was. (The name, address and phone number information.) I also needed to knoe what
they were being billed for and the cost of these service. Another thing that I picked up
in the interview, was that the prices change, depending on the ad that the client may have
infront of them. So there was going to be a need for tracking extensive price changes too.
The reports that I need included an invoice, an aging, and just a list of who has paid and
who has cancelled their order. Reports that tells totals.

It is normally the easiest question to get answered in the interview, but can be a
difficult question for the DBA to work around. When is this data is going to be used? Is
it going to be up 24/7 or is it only going to be used during normal working hours? If it
is going to only be used 8 to 5, then that leaves lots of time for maintenance, backups and
such. But if its going to be used 24/7 then you are going to have to find time or make time
to do this maintenance. If you are fortunate enough to be working on a SQL Server 7.0, then
back ups won’t cause any major problems. Although I have never used it myself, I have
seen demonstrations that prove that performance will not be an issue, with SQL Server 7.0.

The situation that I found myself in was this, I have a SQL Server 6.5 database with an
6 am to 9 pm shop. The good news to this, was that I had some time for maintenance. I would
start my maintenance process at 10 pm with a DBCC check DB, then the back up. This process
will leave me with ample time for the database to be ready at 6 am. I did, however, need to
find time to run some stored procedures that are very processor intensive and would almost
render the database useless because of the speed. To solve this I had the weekends.

I find this question helps me the most, and, when answered correctly, can be the most
satisfying part of the process. Let me explain. Why do the users need the database? Why
do the users want this database? If this question is answered well, then it will save the
user time and money. Smart work on a designer’s part, saves a lot of hard work on the
user side. The users and the management could have a lot to thank you for with this one.

When I first was told about the billing database they wanted me to design, I was told
there was some double data entry occuring on the users end. My original database design
provided only the services that the company was selling. The database also provided a means
of providing administration to the clients that we have. The database did not, however,
keep track of clients that needed to be billed nor did it create invoices. To compensate
for this the users used a separate billing program that did this for them. The problem with
this is that the users had to input all the client information again. By incorporating
billing with our current clients list, it removes the need for double data entry. In my
scenario, the question of why would be to save time, work, and money. Another problem we
had with double data entry, is that it gives the user a greater chance of mistake. It looks
really bad when you bill a client and his named is misspelled.

I use the how question to tie up all the loose ends.
When I answer the question of how, I then start to put the database components together in
my mind. I then expand my thoughts using a data model tool and a huge white board. I lay
out the tables and then test my design with as many combinations as possible. Then I return
to the same people that I originally interviewed and give them examples of what it would
look like and how it would act. I make sure that this design will meet the needs of the
users. With all additional questions answered, I have an even better understanding of what
the users need and want. I also have a better understanding of what would be the best way
to approach the design process and the programs I should use while doing it. With all
these questions being answered, the hardest part is over.