It strikes me how often technical folks like me expect our customers (aka “users”) to know stuff that took us years to figure out. A big part of my job is designing and building computer software systems that enable the business to automate routine and/or complex tasks. Those systems help increase efficiency and thereby help provide (in theory anyway) profit to the bottom line.
I’ve worked with several leading technology vendors and methodologies to elicit the real requirements from the customers in order to build these systems. The purpose of documenting requirements is that we need to have a common understanding of “what” the system is supposed to accomplish. If we’re good, we try to leave out the “how” the system will accomplish that task until we get the requirements (the “what”) fully understood and agreed upon.
We break out these requirements into “functional,” which is a feature such as “allow the report to be sorted by any column,” and “non-functional” requirements. Yeah, we really call it that. Non-functional in this context has to do with things that aren’t really “features,” such as security, usability (remember how complicated it was to set the old VCR clock?), reliability, performance, etc.
Too often, I’ve seen the technologists go off and build something majestic – a real work of art – that becomes totally useless to our customer because it is too complex. The term is “over-engineered,” and that usually means that we’ve managed to make a really cool thing unusable.
So, this “requirements definition” portion of a software project is critical. We need to understand exactly what the user expects the software to accomplish. Only then should the technology folks go to the design table. Part of our job then, is to apply a logical approach to this process of definition of requirements.
A Use Case is an English representation of the interaction between the user of the system and the computer system itself. It is usually in the form of a scenario, whereby we methodically go through all kinds of iterations on how that interaction might go, in order to produce some result. It’s a kind of mini-story that can be told over and over again.
Use Cases were initially introduced to technologists in 1992 by Ivar Jacobson in Sweeden. As part of the “object oriented” approach to programming, it is a model that has gained momentum to the point where virtually all new systems are now build on the object model. Unfortunately, the adoption of the Use Case hasn’t been as quick, even though it is the foundation of all development, according to Jacobson. So, the sparkling new “object oriented” software still doesn’t meet users’ expectations.
The framework of the Use Case is one that lets us find all those hidden “gotchas” early in the process instead of after the software is delivered. It’s a way to capture the logic of the program on paper, before a lot of time is spent on coding. If we can run different scenarios through the Use Case, we know we’re in good shape to begin the next development step.
Our challenge as technical analysts, architects and developers is to help the customer community understand the value of a Use Case, and work with the users to define and build them early in the project. It should be in the top of the toolbox for every person involved in creating new computerized systems.