Gathering Requirements

You manage a successful small business, you have decided that you need to update or replace a portion of your business using new computer technology. You know your business intimately, the people who will help you to make the changes do not. It is your responsibility to make sure that they commit you to a path that will take your company where you want it to go.

The first step is called Gathering the Requirements. Think of the requirements like a combination of the rulebook and the playbook in football. The rulebook being those rules you have to follow to stay in business and the playbook being those things that are unique to your company. Gathering the Requirements is like writing these two books. This step must be done whether you are buying a packaged system or building one in-house.

Suppose that we want to automate your quotation and sales process. First we might identify what you currently do:

1) Call potential customers.
2) Write a quote for the customer and Fax it over.
3) Customer accepts quote with minor changes.
4) Write up Order and fax to customer
5) Customer faxes purchase order back.

To you this is very simple and straightforward; to a computer this is incomprehensible. Most people are so used to seeing a computer after the months it took to make it seem smart or powerful, when in reality, computers only really knows how to do about three things. If you give a process like this to a software developer what you get back may bear no resemblance to what you intended.

For example, even step 1 can be assisted by computer and broken down into many steps:

a) Input a list of names and phone numbers.
b) Have the computer dial each number.
c) If the computer get a person, proceeded to 'd', else go back to 'b'
d) Show the user the information on the person called.
e) Let the user take notes during the call.
f) Let the user schedule follow up calls.

Similarly all of these steps could be broken down further: What does a note look like? What information do you want to keep about each prospect? Forgive me if this is starting to sound a little complex; the point is to demonstrate levels of specification. In areas where it is not critical what the system does, a vague brief description is sufficient, but in areas where it really matters, the requirements must be very specific.

The requirements are the objective screen or lens you use to evaluate the possible solutions. You want glasses that put the issues in very clear focus, not rose-colored glasses that make every solution look good or ones that are out of focus that make all solutions look bad. Your requirements should help answer these (and more) questions:

· How well does this solution meet these requirements?
· How much will my business need to change to use the solution?
· What questions do I need to ask the vendor?

Gathering requirements is a complex and time-consuming process but it is well worth the effort in the long run. When you do it thoroughly you are far better prepared to ask the right questions when you are meeting with the people trying to sell you a new system, or the people who will build your new system.