Requirements Writing - Identifying Business Needs

Business Requirements are the initial statement of the user's needs. Often this is in the form of a Marketing Requirements document. Business requirements describe:

1. What problem will it solve?
2. What will it do?
3. Who will use it?
4. Are there any constraints?
5. Are there any assumptions or dependencies?

The P.I.E.C.E.S. Approach

(Whitten, Bently, & Dittman. Systems Analysis and Design Methods, 5th Edition. McGraw-Hill. 2001. )

This approach defines business requirements in terms of how the proposed system improves a user's business processes.

• Need to improve Performance (such as low throughput or poor response time).
• Need to improve Information (information may be difficult to produce or is missing).
• Need to improve Economics (existing system may be too expensive).
• Need to improve Control (such as errors or security gaps).
• Need to improve Efficiency (excessive effort or redundant effort).
• Need to improve Service (existing system may be hard to learn or requires frequent repair).

Business Requirements can also be described with Use Cases - a text description of the user's interaction with the system and how the system responds.

Pitfalls in Gathering Business Needs

If a customer is asked "what do you need," they will almost always respond with an implementation that they envision will fill their needs. Unfortunately, this says nothing about the business problem being solved, or whether that implementation is even appropriate. For example, a customer may respond "I need a database to ..." The existence of a database is implementation in the machine domain - not the problem domain. The actual user's need may be "I need to maintain these pieces of employee information..." This is the actual business need.

Of course, if the customer has an existing database system that they wish to use, it is legitimate to add a requirement for the software to interface with the customer's existing system. In this case, interfacing to the existing system is a legitimate business need.

Writing Use Cases

A useful means of capturing the business needs is by writing use cases. These are simply text descriptions of an action that the user performs to accomplish a task. There are may ways of writing use cases, but the most important thing is that they be written. Use cases floating around in people's heads are of little use.
 

Consider the use case for the horror story to the right: 1) User enters initial arrestee's information and charge information into the system during intake. 2) User enters inventory of items taken from arrestee during intake. 3) User takes digital picture taken during booking. System appends picture to the record. 4) Arrestee's information is updated, as needed, during booking. 5) User conducts a background search on arrestee. 6) Arrestee's information is updated, as needed, after background search. Each time the information is updated, any piece of information about the arrestee may change, and the entire history has to be available. For the database design, this means that Name cannot be a primary key; a surrogate key should be used.

True Horror Story My first few days writing jail management software, the group visited a local jail where our earlier software was being installed. The police officers were extremely unhappy! (And there is nothing like having an armed, unhappy customer!) The company's wonderful database application failed to account for the officer's workflow - there was no way for an arrestee's record to have multiple names. Instead, the name had been used as the primary key for the record. This meant that the same person, using different names, had multiple, separate records in the system. "Do you know," one officer acidly remarked, "that in addition to the various crimes that some people commit, that they also LIE about who they really are?" Had the company observed the workflow and learned how the system would be used, they would have been better able to meet the customer's needs.