Use cases and user scenarios: These design constructs are a long-time favourite in the Cersys project toolbox. The origin lies in larger-scale software development – early 1990’s – and we now apply them to consultation for software configuration and customization for our customers in the legal vertical.  They sound impressive and helpful, but what does it really mean? “Use cases are wonderful but confusing. People, when asked to write them, do not know what to include or how to structure them. ” – Alistair Cockburn

Use cases: common thread

Use cases and following scenarios play an important role, tying together a project from requirements to launch:

• communicating with the customer during requirements definition. They are very useful as an artifact resulting from user interviews… shows that ‘we heard what you told us’.
• structuring the demos during development
• inspiring end-to-end test cases for User Acceptance Testing
• providing scenarios for training

The scenarios should be reasonably abstract so that it is applicable to both the pre-project workflow, and how things behave with the project once delivered.  These overarching scenarios will show commonality with old and new, and even improvement with the new system.

The goal of our use cases is to describe ALL of the project scope in strategic, summarized, business terms – in order to get customer buy-in that the solution describes the in-scope functionality. In other words, it’s a different slant on the requirements, and a more effective tool for communicating and getting agreement.  Specific exceptions, variations, and contradictions are explored and documented… as a Business Use Case is expanded into Business Scenarios and Functional Scenarios.

Functional Scenarios are intended to be refined iteratively.

Each use case evolves into Functional Scenarios as the project progresses. As you move through requirements definition and prioritization into design, you will be creating functional scenarios that embody those high-level use cases. Spend more time elaborating the most important scenarios, and the most likely ones to be implemented.  Spend less time describing the simplest scenarios and/or the scenarios less likely to be implemented.

Business use cases can show how a particular business goal was carried out in the old world (often in multiple ways), and then the recommended way(s) to accomplish it in the new world.

In one particular project, we wanted to help build distance from the ‘old way’ of doing things – saving substantive emails in personal PST files.  Thus it was preferable to frame the lawyer’s goal as ‘I keep track of a matter’s emails’ rather than ‘I use a PST file’.  By describing it abstractly, we more easily emphasize how the new system will continue to meet their needs, vs highlighting that we are taking away an ability to use a PST file.

How a use case evolves

In their first incarnation, user scenarios should describe what the user is accomplishing, in terms of the user’s work-related goals.  Few lawyers would describe their lawyering as ‘I accessed a folder this morning, then had to work with some databases’.

So for example, here are informal imaginary comments from the customer that would each be slightly formalized into a User Scenario.

• Lawyer says: I like to keep together all the emails I send on a given matter, and also the emails I receive.
• Lawyer says: Sometimes I need to get a particular email I sent regarding a matter, knowing only the rough timeframe that I sent it. Other times, I need an email that someone else sent.
• Assistant and Lawyer: Lawyer marks up a draft. Assistant makes those revisions, then returns it to the lawyer for review. Lawyer OKs it and it’s sent to the client.
• Lawyer says: I need to find the stuff I am working on currently, whether in one matter or in several.
• Assistant: I have to take care of email for 2 different lawyers (filing to matters).
• Lawyer says: find me that document that Chris did for client x about a thing four or so years ago.
• Assistant (or associate) – I need to get at what ‘the boss’ is working on for a given matter.

The difference here is that a user scenario applies to the practice of law, and often consists of multiple steps: it may not mention or even require software. In fact, if there is only one (software-based) way to carry out a user scenario, then that scenario is too specific to be a business use case.  A pet example of a specific software action is ‘Relate document A to document B’.  Why? Who? When?

More background on user stories

Are user stories better than other types of requirements specification? It depends on the situation, but in a collaborative environment, my experience leads me to say yes.

User stories will not make your project agile, and the lack of them will make it challenging to become agile. However, user stories encourage a number of principles from the Agile Manifesto:

• Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer’s competitive advantage.
• Business people and developers must work 
together daily throughout the project.
• The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation.
• Working software is the primary measure of progress.

via Defining Requirement Types: Traditional vs. Use Cases vs. User Stories | TechWell.

 

And Dilbert: design