Abstract your requirements up-front (Part 1)

In my experience the best systems are created with methodologies that include the “use case”. In the Unified Processes, the central tenet of the use case method is recording an abstract description of the use case scenarios. In one pithy aphorism this means:

“A Use Case scenario must describe the interaction between a user and a system in terms of inputs and outputs only.”

There must be no detail of the exact physical actions required to enter inputs and receive outputs. In a software project, no descriptions of GUI elements; clicking on buttons, typing in text boxes, no dialog windows appearing, etc. In a purely human process, nothing as detailed as “wrap a product in bubble-wrap”, “give a PowerPoint presentation”, etc.

How many use cases have you seen that steps out scenarios that concentrate on physical actions? E.g.

1. The User opens the “Hello World” program from the Start Menu.
2. The System displays the introduction screen with a menu listing “X”, “Y” and “Z”.

These are not abstracted requirements. This is a written GUI design, which is pretty redundant, you may as well just do the screen mock-ups or workflows in Visio. A better use case example would be:

1. The User initiates interaction with the System from an entry point.
2. The System provides the User with options to continue with this Use Case (go to step 3) or perform other Use Cases (initiate new Use Case).

The point of this abstraction? Who's to say up-front that presenting a menu is the best way to do things? You haven't yet thought about: how this affects other related use cases; if it's consistent with presenting options in the other use cases; whether users will find this approach intuitive; if it's appropriate for every class of user, etc. The problems are multiplied in a large project with a team of analysts producing the Use Case Survey.

Producing an abstracted Use Case Survey for a project iteration allows designers to:

• better avoid duplicated effort by identifying common aspects of system parts;
• up-front identify the high-level duties of required actors, allowing managers to earlier prepare personnel (and unions) for changes in roles, responsibilities and job descriptions; and
• most importantly, forces concentration on the purpose of the system as a whole; the “why and what” rather than the less important “how”.

The project as a whole will save time as producing workflow diagrams and screen mock-ups is more intensive work than writing a few simple use case documents. If you've planned better up-front, less tweaks and changes are going to be required for those graphical tools.

And these are just the benefits I can think of in the time it takes to write a blog post. Abstracting requirements up-front is well worthwhile. Do it every time you can.