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:- A list of the documents
- Columns showing which one's are ready, which ones are late, and who is responsible for each
- Sort by any column
- Filter by any column
- Print out with column-headings on the top of every page...
Here is a list of real requirements that a team of us had to dig for:
- A draft document needs to be written by an analyst
- The document must be reviewed and approved
- Financial reports need to be produced by a system
- Financial reports need to be approved by a person
- The documents and financials need to be combined into various client reports
- The client reports need to be printed
- The client reports need to be mailed
- 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:- high availability
- Load balancing
- portal
- pluggable, snappable, replaceable software components
- Thin, rich client
- Fully denormalized reusable data source
- Dashboarding
- 3-tiered communication layer
Today, you could add to those requirements:
- stateless (REST-ful)
- SOA (Service-oriented architecture)
- AJAX
- Web 2.0 (or 3.0, or whatever)
What the business actually needed was:
- Show quarterly reports as soon as the data was approved to show
- Secure
- Support a maximum of 20 simultaneous users
- Available 8AM-8PM Eastern (US) time
- 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...
