I am probably a relative new-comer to use cases, after working in analysis and requirements through Structured Analysis and Design in the eighties, and Information Engineering in the nineties. I found one author’s description of them almost aesthetically appealing, that each one is a case (or example) of the use of a system.
After that, I have seen many variations and permutations and various ‘uses’ of use cases; either that is a testament to their flexibility, or a condemnation of their vagueness. If you are new to Use Cases, be aware that different flavors of use cases are out there, being promoted and being used. When I am feeling the need for some rigor or consistency, I always go back to Alistair Cockburn (pronounced ‘coburn’) at http://alistair.cockburn.us/
Overall, I have seen and used two basic types of use cases:
- A multiple-step interaction between Actor and System, which relates to user interface design, and capturing the required functionality the system must provide to support the interaction. I saw this a lot when working with co-workers who were OO designers and programmers.
- A single step or occurrence format, where an Actor initiates the use case, which is provided some input and/or pre-conditions, and it executes a set of actions (calculate something, retrieve or store something else) that produces a result of interest to the Actor. (There may be multiple Actors, too.) The set of actions that are first defined are those that will normally execute, if no exceptions or other variations occur. I call this the ‘happy path’, as I am sure some author or instructor called it that, but I can’t recall who. However, if it is known that one or more exceptions/variations from the ‘happy path’ could occur (due to certain input values or combinations of pre-conditions), these are documented as alternative paths. Creators of these types of use cases don’t like to see path selection in their use cases, no “IF-THEN-ELSE” statements; use your alternatives instead.
Finally, both of the above types differentiate between the use case itself as the definition or template of the ‘use of the system’, and Scenarios, which are specific instances of the use case given one set of possible input values or pre-conditions; changing the input values produces another scenario, so a large number of scenarios could be defined for one use case, all of which will help the Testers of the information system developed based on the use case(s).
As you might expect by now, I mainly use the second type of use case as part of documenting Information Systems Requirements. They are extremely valuable as, if nothing else, a widely-accepted format for documenting the results of Analysis; anything that effectively assists in communicating Business Requirements to one or more audiences is something that should be used(!).
Now, they are not perfect, and they are not the ultimate format for documenting Requirements… they are only one format of many (five at last count). One issue I had with use cases early on was identifying them in the first place: what was the scope of each use case? How many use cases do you need? There will definitely be more than one. What I can say now is that one way use cases can be identified is by there relationship with Process Models, and I will describe this in a future post.
However, once you do have a set of use cases defined that cover the scope of the business you are analyzing, you can use them to organize the Declarative Requirements Statements I described in my last posting. I often start an Analysis effort by creating a list of High-Level Requirement Statements based on initial discussions with the business subject matter experts; if the these people want a new or enhanced system, they will tell you what they want from that system, which you can capture as Declarative Requirement Statements.
Once I have moved ahead to capture the necessarily detailed description of the business in use cases, I then allocate those Declarative Requirement Statements to the use cases that will actually support the Requirements (if you end up with Requirements that don’t match up to any of your use cases, you might be missing some use cases.) Detailed analysis will also support the definition of more Requirement Statements, again associated with particular use cases.
It might be argued that the detail provided in a use case supersedes the need for Requirement Statements, but I believe they still play an important role in communicating the essence of the use case. Designers/Developers will look to the use case detail for their understanding of the Requirements, but the Requirement Statements are often preferred by Testers as documentation of what they must test, and the Statements provide trace-ability from the Analysis through Design/Development to Testing.
So to this point, we have covered Declarative Requirement Statements and Use Cases, including how the two can be associated with each other… it must be time to discuss Data Requirements… in my next post.
2 comments:
First of all, thank you for the blog. One of the issues I have with Use Cases is that it works well to describe an Actor's interaction with an existing System. But what if the System does not yet exist? (Maybe my definition of System is too restrictive.)
I find I'm writing "Do" cases, in the sense of "what do you do?" or "this is what I do". These mirror the way I frequently elicit requirements (through interviews). The document style is a bit different, in that I present a "case" to the actor, then ask them what they do.
Perhaps...,a Use case can define requirements for a new system (or 'solution') that is to be developed.
I have used other artifacts in the past like Process Action Diagrams in Information Engineering, but Use Cases seem to the common 'language' these days.
Post a Comment