Archive for Use cases

Use Cases to make a better has recently been changed. Microsoft did a lot of research to make it easier to find what you look for at

On the about page, some questions about the changes are answered.

One of the reasons the new page is assumed to be better is that “We based our design on data of the most common tasks, products, and services that people come to our site for, and then we validated and improved the design during months of customer testing.”

To me, as seasoned requirements specifier, this seems to be an obvious way to do your analysis and design, but  when teaching classes and when coaching collegues, I often find they don’t take the time to find out the most common “Use Cases” for the system they are building.  Nice to see that Use Cases seem to be working at Microsoft.


Leave a Comment

Use Case guideline: numbering your steps

A Use Case describes a sequence of actions performed by the system yielding a visible result of value to a specific Actor (definition from Dean Leffingwell).

A structured list of numbered actions in a Use Case is called a flow. There are three types of flows in a Use Case: main flows, subflows and alternative flows.

Numbering the actions in a flow is handy for referencing, e.g. when reviewing a Use Case, you can walk throught the flow step by step and argue on its completeness.

In the last years I have seen lot's of numbering guidelines and picked something from all of them and added my own best practices. I prefer my own numbering schema, as I can easily explain ther rationale for every bit of it. This is an example of my numbering schema:

Flow <Name of the flow>
This flow begins when …

1 The System …
2 The Actor …
3 The System
4 The Actor has the following options
   a. The Actor … 
   b. The Actor …
5 The System …

Here ends this flow 

This numbering schemes describes several things:

  • When do you start numbering

The sentence "This flow begins …" is not numbered

  • When do you stop numbering

The flow clearly ends with the sentence "Here ends this flow", which also is not numbered

  • how fine are the steps

All steps from the actor and the system are numered seperately for easy referencing.
In standard RUP a collection of steps (a roundtrip involving actions from the Actor and from the System) are given one number together, with the nasty consequence that you cannot reference precisely (you reference to "the beginning of step 3")

  • how do you handle inline logic (as opposed to alternative flows)Inline logic, e.g. where the Actor has several options which are equally important are sub-numbered with a, b, c etc. The are referenced with there "full names" 4a, 4b etc.
  • how do you link alternative flows to the main flowAlternatives flows directly reference the step in the flow they are an alternative for.So if there is an alternative for step 2, this alternative flow is identified with "A2.1" where "A" stands for Alternative, "2" is since this is an alternative for step 2, and ".1" signifies this is the first alternative flow for step 2. A second alternative flow would be numbered "A2.2".

    If there would be an alternative for step 4b, the alternative flow would consequently be identified with "A4b.1".

I'll elaborate on these guidelines in my next posts

Leave a Comment