Make Users Happy by Ignoring Requirements

People talk about the system they want you to build in the language of what they have now. It is natural to not want to give anything up. Writing web applications, I hear over and over that people want to be able to sort by every column, have column headings print out on every page, filter by any value... That's Microsoft Excel - and it is a truly incredible tool for doing all of those things.

On the other hand, most business systems (as opposed to software systems) are dependent on communication to make people with different skills work together. In general, if you can meet those needs, you can always add a CSV download later if people still want to "slice and dice" data in Excel. I have had consistently good results from ignoring the "Excel on the Web" requirements and asking my clients instead to describe the people, the tasks, and the communication involved in their processes.

I try to break a process into the sets of tasks that each person (or type of user) needs to perform. The usual goal is to show someone only the data they really need to perform their task(s), and give them the tools they need to accomplish that task on the same screen. Sometimes, similar tasks can share a screen or multiple screens might be required for a task, but the goal is to compartmentalize and specialize the business system into units that use common sets of data and functionality.

Example 1: Ignoring User Requirements

Below are the requirements I was given for a year-long project:

1. A list of the documents
   
2. Columns showing which one's are ready, which ones are late, and who is responsible for each
   
3. Sort by any column
   
4. Filter by any column
   
5. Print out with column-headings on the top of every page...

Sounds like Excel, no? I only actually met requirement #1, yet the client was delighted. Why? Because the list of Excel features I was given tipped me off that the requirements were not well thought-through.

Here is a list of real requirements that a team of us had to dig for:

1. A draft document needs to be written by an analyst
   
2. The document must be reviewed and approved
   
3. Financial reports need to be produced by a system
   
4. Financial reports need to be approved by a person
   
5. The documents and financials need to be combined into various client reports
   
6. The client reports need to be printed
   
7. The client reports need to be mailed
   
8. A manager needs to keep track of all of the above

Developers understand systems and the benefits and limitations of your technology. Businesspeople know what they need to accomplish, but are often dimly aware of the business systems they use to achieve their goals. Bridging that communication gap is the hardest part of writing good software.

Example 2: Ignoring Systems Requirements

Stated requirements for a reporting web site that I worked on (on-and-off) for 6 years:

1. high availability
   
2. Load balancing
   
3. portal
   
4. pluggable, snappable, replaceable software components
   
5. Thin, rich client
6. Fully denormalized reusable data source
7. Dashboarding
8. 3-tiered communication layer
   

Today, you could add to those requirements:

1. stateless (REST-ful)
   
2. SOA (Service-oriented architecture)
   
3. AJAX
   
4. Web 2.0 (or 3.0, or whatever)
   

What the business actually needed was:

1. Show quarterly reports as soon as the data was approved to show
2. Secure
3. Support a maximum of 20 simultaneous users
4. Available 8AM-8PM Eastern (US) time
5. Show some other marketing information
   

One web server would have been more than adequate, but we had 2. The slow part was actually some of the queries/reports in the database. The only part of the site we ever plugged/snapped/reused were some hand-coded HTML pages and the login code. If we had known enough to discover the actual needs of the users, we could have saved at least 50% of the effort and used some of that time to further optimize the long-running queries, or even redesign the database to make the queries simple enough that they wouldn't need optimization.

Well, 20/20 hindsight is easy. That's how you learn...

Conclusion

When requirements read like a winning "Buzzword Bingo" card, it's almost a sure sign they weren't thought out very carefully. Time spent digging for real requirements pays off in both medium and long-term system usefulness and cost savings.