Database request form

[Seth Schrock]

Does anyone who develops new databases have a database request form that you fill out? The last database that I worked on was very complicated because what I thought was the purpose was not the purpose, so I kept having to change my design to fit the changing requirements. I know a form doesn't keep the requirements from changing, but it does at least provide a baseline that isn't just in my head. I'm looking online, but so far I haven't been able to come up with too much.

[zmbd]

I have a basic word template with a table inserted
Title: Project Worksheet
Row 1: Task Name
Row 2: Abstract of project
Row 3: Short description of workflow.

+ Once these first rows are filed in I go back to the requester and make sure that this is what they are after.

+ From there I take the workflow and fit it into a Nassi-Shneidermand chart. Not specifics details, just each workflow step to make sure the logic flows.

+ I then take each step and look at the Data required, is the data something that is used as Input for the task, Reported to user or another task, if the data will be modified and retained in task but needs to be saved (but usually not if calculated), then of course housekeeping or calculating of the data. Of course the data might fall into more than one "category" for instance, contact names for a lab supplier might need to be entered, given to another task (email), updated... or a quoted price calculated for ordering supplies etc... given that the final price might change I'll sometimes store the quoted price and quantity and then the actual price and quantity actually ordered.

Once I have that in place, I go back to the requester and walk thru the "High level" chart. This just lists the step and the required data. I usually find out that there's something they want that I've missed.

Report design is a whole other can of worms.

of course, I often start out with this and then have to "play it by ear" as the end user sometimes doesn't have a clue to what they actually want - and the user is more often than not me! :)

[jforbes]

It's been a while since I've been in the position you are in, but I did pretty much the same thing as zmbd. I'll see if I can find an old requirements Form, but don't hold your breath. =)

One other significant part of the Requirements Gathering was to get a copy of every form of existing Source Data as well as a copy of every Form of current Outputs/Reporting. For the project at hand and any possible process the project could integrate with. So a screen shot, an electronic file, or printed report of every thing being used:

• Any and Every printed Form being used
• Backend System Screens
• Excel Spreadsheets
• Actual emails and Email templates
• Word Documents and Merge Documents
• Vendor and Customer Web pages or websites
• Printed reports from current backend systems
• And a copy of every report currently being used

Usually in the overkill of information gathering, the things that the customer felt weren't important were discovered. Which eliminated a lot of the possible scope creep.

[zmbd]

jforbes; that's not overkill at all!
Better to have that information to start with! Something that comes to mind, is that with all of that information, one can start asking about how much of it is actually valuable to the user. I used to generate tons of paper and email just to find out that many of the people I was sending the information to couldn't careless about it... flavor of the day reporting!

[Seth Schrock]

I usually get called into a meeting with no advanced warning what it is about and get told that I need to do a database with xyz requirements. I usually don't have time to get my brain working in that direction until half the details are already stated and then I'm trying to figure out what information that I need so that I can ask the questions. This last time turned into a nightmare. It was supposed to be just a simple log and then the requirements just kept changing on me. It is always fun when you think that you have finished the project and they ask how to do X and you didn't know anything about it and then your boss says "that was why we decided to do the database". That is mostly what I'm trying to avoid this next time (which will be soon).

Thanks everyone for your insight. I will leave this thread open for anyone else to share their ideas.

[jforbes]

I found it!

I've attached a blank copy of a Software Design Doc that I used to use years ago in both Word and PDF Format. Maybe it will help you.