Use Cases: The Win Win Scenario

A Use Case For Using Use Cases

Primary Actor:
	Project Manager

Other Actors:
	Customer (Business Representative), Implementation Lead

Motivations & Goals:
	The project manager wants to reduce the risk of the project failing to
	meet the customer's needs. The project manager also wants to avoid the
	project producing something that goes beyond what the customer requires.
	He also needs to validate the project plan and budget against the
	requirements at some point in time.

	The customer wants to gain an understanding of what they might get,
	and through that have confidence that the project will satisfy their
	needs.

	The implementation lead wants to define the scope of the customer
	requirements and through that gain confidence that the project is
	achievable within time and budget.

Flow of Actions:
	Define a level 1 use case for the whole project - the "view from
	the moon". If it is hard to do then perhaps there is more than one
	project in scope.

	Expand the level 1 use case into the next level of detail and establish
	system level 2 use cases. This will form the basis of your acceptance
	tests. Use diagrams where complex relationships between use cases
	and other use cases or actors exist.
	
	Where necessary expand further and iteratively add information on goals
	and motivation as understanding grows.

Result:
	An expression of the system requirements that can be easily read and
	digested at a number of levels and by all the involved actors.

Notes:
	Don't worry too much about the format and the style. Any expression that
	is clear and consistent is a good one.
	You are allowed to write whatever you need to.
	

Properties of Good Use Cases

Good use cases...

• Have a primary actor that has a goal and performs a role using the specified system.
• Generally take the form of subject-verb-object action sentences.
• Have one or more scenarios in which the same actor-goal-role is realised.
• Are written to describe what and why something needs to happen, not how.
• Deal with all scopes of goal. I.e. from "reduce costs to help pay for the bubbly at the shareholder's meeting" to "User wants to do X with the system".
• Can be easily read, changed and distributed.
• Describe only that which directly relates to a stakeholder's interest.

Abuse Cases

Use and Abuse Cases is the title of a 1998 article by

• The use of excessive decomposition (symptom: lots of «includes», «uses» and «extends», stepwise refinement, use cases calling each other)
• jumbled actions (symptom: jumping around, looping)
• the over abstraction of actors and use cases which makes them harder to understand and reuse
• referencing UI design which taints customer expectations
• expressing context by defining data types which inhibits flexibility
• explicitly mentioning implementation details (e.g. exceptions, queues, equations etc.) which cuts implementation choices
• including interface detail which inhibits maintainability

Actors Are Important

Actions enforce a contract between stakeholders, and that every action it ^{[the use case]} takes is either to protect one of the stakeholder's interests, or to further one of the stakeholder's interests.

This is a useful check. If the action is not related to an actor then you might have missed out an actor or more likely you are defining an action that is irrelevant to the requirement. Also if the action only indirectly relates to an actor's interests then chances are you are implying context somewhere in the description, and you should carefully review the scenario.

For example, in the above use case the action that contains the statement "This will form the basis of your acceptance tests" implies that there is an actor missing for the role of tester. In this case it would be sufficient to add that role to the defined motivations of the implementation lead actor, but in a different context you might consider using a separate actor.

A high percentage of first time Use Case developers concentrate more on the oval use cases than their stick men. As a result the use cases get weaker and less meaningful as you expose requirements.
To get away from this:

• use a context diagram that shows all your high level actors
• keep an actor catalogue that records the roles that an actor represents in this context, the motivations and interests of that actor both in context and externally, and the goals of the actor in relation to the high level use case.

Developing Use Cases

It is the concept of completeness of use cases that causes headaches at this stage. Quite often systems are created to please the few rather than the many. Being able to consider all the interested parties is a key part of 'fleshing out' use cases.

As actors are important then they form part of this process; so you should go though each use case, and play the part of that actor in each case, and see if you have a stake in any of the steps. What this will normally do is prompt you to think of undisclosed interests that firstly lead to extra steps in the flow and secondly provide insights into the more esoteric (admin or exceptional) use cases. So whatever the system, you should cross reference the actors with the use cases. If you discover a new actor then start again with that actor and see where else they have a stake.

At this stage there is always a temptation to go to far, especially if you are going to do the design imminently. If you find yourself thinking of an event based system when you are writing the use cases then by all means consider that as an architectural decision, but be sure not to put that in the use case. It is better to have a slightly scant use case than one that prescribes an implementation. Vague issues can be cleared up by the technical design.

It is important to be consistent on the depth of the use case. For example, you may be vague in one area where you might try and avoid implying an implementation, but then go much deeper in another area where there is no risk of implying an implementation style because there is none. This is a judgement call, is there a need to go to that extent to express the requirement or are the details more of a description of how rather than why? Obviously this is a very grey area.

Requirements Traceability

The set of Use Cases form the set of the requirements for a project. And so most projects opt to use a numbering scheme for their Use Cases that they can track through the project as a whole. One such numbering scheme might be as follows where the Use Cases are numbered sequentially by importance and then the main flow is scenario number 1 followed by the alternative flows in order of likelyhood and then finally the step number of that flow:
usecase#.scenario#.step#

Having got a unique reference for every part of every requirement you can then begin to cross reference those with each subsequent artefact that you produce. This is especially useful for justifying elements of the design, and the ordering by importance makes it easier to resolve conflicting requirements.

Modelling Time

Time can really pollute a set of Use Cases if you let it. You need to capture the timing requirements, but exceptional scenarios for timeouts and other such time sensitive operations should never take over a Use Case. The trick with time is not to go into the details too much. It is important to remember also that Use Cases can describe long running scenarios.

A typical solution to modelling time involves a Time or Clock actor that has a role as a secondary actor in a Use Case. That actor interjects at appropriate moments to indicate that some time has passed. You can then take that indication of time and describe how that may affect the flow of the scenario.

Designing From Use Cases

So now you are finally allowed to say how the the thing will work. There are a number of ways to start this process, but most of them involve making decisions. The following paragraphs describe one possible technique.

Take a selection of project critical Use Cases from your set. Critical Use Cases can be a mixture of those that are most important for the key goals of the project with those that are going to be the hardest to do. Either way you will need to start with a maneagable set of important scenarios.

Step one is to take each element of the flows of the Use Cases and try and come up with as many different ways to meet that requirement as you can. Try and think outside your normal box, so if you are used to data centric applications then consiously think about message centric solutions too. You will normally begin to notice common groups of ways of meeting the requirements, and you are likely to find conflicts between alternative solutions in different cases. For example you may find youself saying "we can use an XML interface for that" or "then we show a popup window". You may find that the obvious solution that you had in mind would now conflict with some of the requirements.

Step two is to pick the best candidate group of solutions to the critical use cases and try and define the theme that characterises them, which might be something like "we write everything to a database" or "all changes fire events". Take those candidate solutions and, bearing in mind the theme, follow the impact of those decisions through all of the remaining Use Cases. This is the double check that you are heading in a valid direction. It is also now that you may realise that you can't meet the requirements in full. Allow yourself to 'go functional' for a while and describe how each step of each Use Case will be achieved.

Finally, you look at your actors and you design how each one is going to interact with the system in as much detail as possible. You should then be ready to design the system tests.

Summary

• Don't let the detail get in the way of the goal - describing the means does not describe the end.
• Use Cases are all about providing a bridge between the real world and the world of the technical solution, so they should use non geek speak.
• Good actors are the key to success.
• Write what you need to write and nothing more.
• Actors in the use cases are ultimately real stakeholders in the project, so make sure you let them know that.