Freigeben über

Clarifying the Use Case

  • Artikel

A Use case is a cool thing.  A little too cool.  The term has been occasionally misused, and in some respects, that misuse diminishes the value of a use case.  To succeed, we have to know what a use case is.   When you are done reading this post , you will still know what a use case is... but you will also know what a use case isn't.

What a use case is

The following section is a direct excerpt from “Writing Effective Use Cases” by Alistair Cockburn.

“A use case captures a contract between stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and the conditions surrounding the request. The use case gathers those different scenarios together.” (Cockburn, 2001)

With all due respect to Cockburn, his discussion doesn't so much define a use case as describe one.  There are very few formal definitions available in the public domain or in reference works.  Here is my attempt at a more formal definition:

A use case is a formal description of an interaction between an actor (usually a person) and a system for a specific purpose or goal.

Many of the discussions of use cases in the literature go into great detail about the requisite parts of this formal description.  Most include the concept of 'actors', 'use case scenarios,' 'preconditions,' 'postconditions,' and a stated 'goal.' 

Things to notice

  1. In a use case, there are always at least two actors, and one of them is a system.  The use case is a description of system level interaction... in rich detail. "Enter name and address and click the 'enter' button."  There is very little about a use case that is abstract or high level.
     
  2. The amount of formality is not part of the definition.  In fact, Cockburn specifies that you should create a use case in a fairly informal way at first, when the system is still being understood.  Only in a later iteration of the requirements, when the project is funded and the scope is reasonably well understood, should the specifics of the use case be added.

What a use case is not

As I mentioned before, the term "use case" has been used in many ways, and it has been applied in some pretty unusual things.  To be effective, we should recognize that a use case is a tool that is tailored to one purpose, and using it for a different purpose may not be optimal. 

  1. A use case is not a description of a business process.  The use case describes the interaction between a single actor and a system.  At best, that interaction can be considered a single (atomic) activity in a business process.  A business process is much more than that, including many activities from inputs to outputs in support of a goal.  Let's not pretend that use cases describe business processes.  One activity, perhaps two... that I will buy.  Rarely, if ever, anything more.
     

  2. A use case is not decomposable into other use cases.  It is the atom.  Break it down and you have parts that are not atoms.  Combine use cases and you have composites (molecules) that are not atoms.  A use case is the description of an interaction between person and machine.  That is all.
     

  3. A use case is an inappropriate tool to describe system to system interaction.  Certainly you CAN use a use case this way, just as you CAN drive a screw into wood with a hammer.  But it is not optimal to do so.  A much better set of tools include UML Interaction diagrams, protocol descriptions, standard identifier formats, and WSDL.   
     

  4. A use case is used to elicit requirements but it is not the requirement itself.  Requirements need to be collected and called out as statements.  A couple of noted authors have weighed in on the skills needed to describe and understand requirement statements.  Both analysts and developers should learn these skills.  
     

  5. It is optional to use the use case approach.  While I'm a fan of use cases, I'm also in a role where we have to draw clear distinctions between the work that someone must do and the work that someone should do.  The requirements must be collected.  Use cases should be used.  If you can collect requirements in a different way, that is not wrong.  That said, I'm fairly comfortable stating that the use case approach is a 'best practice' for describing requirements to software developers.
     

  6. For traceability and requirements validation, use cases are not the source of requirements.  Requirements come from the business needs, and most of the business needs are fairly easy to connect to specific stages of the business processes (with some fascinating exceptions).  As I pointed out in my prior post, I view the source of most business requirements to be the business processes and customer experience scenarios that software must support.  

    Therefore, if you want to determine if a requirement is needed, or provides value, or has been completely met, it is better to trace the requirement back to the business process.  The use case is an abstraction along the way.  (This is my opinion, of course, and your mileage may vary).

    (note to contributors: the distinction between functional and non-functional requirements is too vague to clearly delineate the requirements that are not easily traced back to business process or user experience scenarios.  There's another blog post in there somewhere.)

In short, a use case is an essential and valuable tool in the Business Analysts' toolkit.  Let's use it wisely.

Comments

  • Anonymous
    July 23, 2008
    Good post.  Do business analysts really do "system" use cases or "business" use cases?  If a business use case is defined as "business goal achieved by business actor absent technology considerations", I would prefer my business analysts focus on defining those critical business objectives, while systems analysts and architects delve into the use cases that outline desired system objectives.

  • Anonymous
    July 24, 2008
    The comment has been removed

  • Anonymous
    July 25, 2008
    Iron Ruby/DLR Part 3 and 4 of the excellent series, Learning Ruby via IronRuby and C# IronRuby at OSCON

  • Anonymous
    September 02, 2008
    Nick, Nice post, you were thinking about the same book in the same time. But I do not fully agree with points (2) and (3).   Ad 3> A use case is an great tool to identify system-to-system interaction. I agree, interfaces must be designed in other way of course. Ad 2> There are various levels of use cases (as described by  Alistair Cockburn). When you have business level use cases (i.e. not connected to one system - e.g. when new product is introduced, it can influence many systems - ordering/CRM, collection management system, billing, invoicing, self-care...), I prefer to decompose use-cases to the level of one-system. It is natural and working...

  • Anonymous
    September 03, 2008
    Hello Peter, It should come as no surprise that my views on use cases are somewhat different than some published materials, even if the authors of those materials may have moved forward in their thinking.   Much of the published material on use cases comes from the original thinking of the three amigos, and they did not use business process modeling in any kind of systematic way.  Therefore, "business use cases" were the best thing that they had.  I don't think that any of the original thinkers around use cases would state that they are a better mechanism for diagramming a business process than BPMN. Now that BPMN is adopted into UML, and we have an intelligent visual language to express processes and activities, it makes sense to put away the less effective tools (business use cases) and leverage BPMN to describe the business process.  Decompose all you want in BPMN. Then, when you get to the atomic activity, then describe the system-to-user interaction in a use case. The books will catch up eventually.  It takes time.

  • Anonymous
    September 03, 2008
    Nick, I see your point, but I do not accept it :) Use cases (especially textual description of scenarios) are much better for reading than BPMN diagrams (or ARIS diagrams). Even use-case with 10 alternative flows is readable in document (in opposite to process diagrams you have to print on plotter - what leads often to oversimplified diagrams). On my current project there are two parallel representations - use cases and process diagrams (I do not want to describe the reason...). Use cases are great in description of exception/alternative scenarios (separation of main scenario and exception/alternative scenarios is really great idea). Personally, I always skip process diagram pictures and I read always only textual description... There are few good use case tools (UML tools are not oriented use-cases), so people preffer process diagrams. I do not see the evolution in the direction, you have described...

  • Anonymous
    September 03, 2008
    Hello Peter, I accept that we differ on this minor point. Personally, my opinion is that there is not "one true way."  The process that any particular development team uses to communicate will frequently be determined by the people involved in that team.  As you have noted, your team made the compromise to illustrate using both use cases and process models.  It worked for you.   And that is the key.  Use what works for you.  Because you have software to deliver.  I fully support that. On the other hand, my post reflects my perspective.  I am attempting to understand and clarify the role of the use case for my team. I have to include the "future viewpoint:" how I see software development evolving in the future (I'm often asked to "look five years out").  I am not in the Visual Studio product team... not even close.  I'm in IT, and we are "first customers" of MSFT products.  I have no more "crystal ball" than any of you do. So I keep my ear to the ground.  I speak with other dev shops and architects around the world.  I read everything I can get my hands on, looking for trends and taking careful note of changes in the strategic landscape. Given that perspective, I can see a clear and very visible trend away from describing business processes within use cases and towards using use cases as they were originally intended: to describe an atomic interaction between a person / role / actor and a single system. In my opinion, Use case modeling is useful for many things: describing a business process is not one of them. That said, there is no restriction against providing text along with your BPMN model.  Most good UML and BPMN modeling tools will allow you to capture a textual description of the business process, complete with 10 alternative flows (an unusually large number, but entirely possible in many situations). The fact that the use case folks go into detail about how to provide textual descriptions does not mean that business process descriptions are somehow 'prevented' from providing textual descriptions.   Text + diagram = a good thing. Peace. --- Nick