Writing use cases for a rather complex scenario

Question

I'm trying to improve my use-case writing skills but I'm stuck on a certain scenario.

The idea is that there are a bunch of entries in a task list (some kind of todo list). Now the user wishes to process the list (divide it amongst other lists). He can do this by answering a series of questions / completing extra data. Based on the choices of the user the system perform different actions on the task.

I'm really confused on how to write this down in a use case.

What I was thinking is something like (I'm only writing down the main success scenario):

Use Case: Process Inbox
Primary Actor: User    

1. User indicates he/she wants to sort his/her inbox
2. System presents the next question and provides possible actions
3. User makes choice

_steps 2-3 get repeated until inbox is empty_

The problem with this is that it's not specific enough so something else I was thinking of is to make sub use-cases for all the different steps in the question process like:

Use Case: Handle Project
Level: Sub Use-case
Primary Actor: System    

1. System requests additional information (description, due date) from user.
2. User completes data
3. System classifies the task as a Project

What I'm puzzled about here is:

• How to include this sub use-case in my main scenario in a proper way
• How to indicate that after this action, the user starts again from step 2 in the main use case.

I was thinking of using extensions in which I include the different sub use-cases but it's getting pretty confusing.

So to bundle this request into one question:

Can someone clear up how you would usually tackle this kind of scenarios and/or provide me a basic possible solution for this example?

Thanks in advance ;)

If anyone is interested, the flowchart of questions I'm intending to use is from David Allen's book Getting Things Done: link to diagram

Answer 1

To be honest it sounds like you need to simplfy your use cases drastically.

Worse still, it also sounds like you have a per-conceived idea of how the system should work and are trying to get the use cases to fit.

Go back and start again using the following rules.

• All use cases titles should be a goal statement. I.E. "User gets can of cold COKE" is good "User enters money into drinks machine" is bad.
• No main scenario should cover more than one A4 page. Split long use cases into several "sub" cases. I.E "User gets a can of cold COKE" can be split into "Machine accepts correct money", "Machine accepts Drink Selection" , "Machine delivers COKE", "Machine give change". Note the switch of actor necessary to keep everything goal driven. Its not the users goal to give money to the machine, Its the machines (or at least its owners) goal to collect money.
• Once you have a working readable use case. Aim to cut it down by 50% either by shoving some of the verbage like "list of coins accepted", "rules for giving change" into appendces. OR getting rid of unnecessary steps if the step does not lead directly to the goal, or, the system would work without it -- get rid of it.

The identification and removal of superfluous processing is the single most valuable aspect of use cases. This only works if you drop any mental models of a possible implementation and keep an open mind as to the actual requirements and functions.

Answer 2

You could have a Use Case for each decision that the user must make. For example:

• The "What is the Next Action Use Case" would be the user decides what the next action is and what to do about it.
• Then the flow would continue to one of the next Use Cases: "Do it", "Delgate it"...

Answer 3

You can make liberal use of preconditions to your use cases.

For instance, you can have several use cases for logging in (normal login, new account creation, password recovery, etc.)

Then you can define use cases for sorting a mailbox, reading a letter, etc. Each of these can have "User is logged in" as a precondition.

If there are operations that are only possible after a mailbox has been sorted, you can has "mailbox has been sorted" as a precondition.