The informal use case is the tool of the Agile Requirements Manager. It is a paragraph describing the user’s goals and steps. Also referred to as a basic use case.
Pros:
- Easy to create – quick development, iteration, and collaboration. This enables a rapid approach to documenting use cases, and minimizes the cost of developing the use cases.
- When done correctly, yields the most bang for the buck of any use case approach.
Cons:
- Challenging to be rigorous – the short format makes it difficult to capture all the relevant information (and difficult to avoid capturing irrelevant information).
- Lack of consistent structure – can be transition from use case to use case, since the format is free-form
- Capturing the right level of content for your team can be tricky.
Note that the paragraph format can also be replaced by a numbered series of steps – the key differentiator of this form relative to a formal use case is the lack of structured fields for “everything else†about a use case (preconditions, assumptions, etc).
An example of the informal use case format in the wild, in direct contrast to a formal format for the same use case.
[Update 2007/01/20: Download our free informal use case template today]
Rosenberg and Scott published a series of articles about incorporating use cases into their ICONIX software development process – the first article is here – Driving Design with Use Cases free subscription. They describe a “semi-formal†use case format, which is between informal and formal. They also describe ICONIX as a process that lives in the space between RUP (Rational Unified Process) and XP (Extreme Programming). Their process is a UML-centric approach to system representation, which incorporates the use case information into a structured and larger framework.
The rest of the articles in the series are:
Driving Design: The Process Domain
Successful Robustness Analysis
Sequence Diagrams, One Step at a Time
The goal in this agile approach is to be “just barely good enough.â€
That does range an interesting question – is good enough good enough? And how do we define it? There are several factors that weigh into making this decision.
- Domain expertise of the current team, and are there any switch-hitters?
- Amount of time the current team has spent working together (and how well they know each other).
- Geographic and temporal displacement of team members (are we working through emails and document repositories, or are we scribbling on white-boards togetherâ€)
- Language barriers, pedants and mavens – the personalities on our team
The bottom line is that it all comes down to communication. If brevity is inhibiting our ability to be unambiguous, we should use a semi-formal or formal format for our use cases. If project schedule requires, and our team enables rapid iteration, we should use informal structure for our use cases.
Quick links to posts in this series
- Use case series: Introduction
- Use case series: Formal use case
- Use case series: Informal use case
- Use case series: UML 2.0 use case diagrams
In your discussion, to my opinion, two things get mixed up:
– writing a Use Case specification using a formal (more or less structured) or informal style
– what to include in the Use Case, how much details get in (the brevity arguement).
I agree with you that it all comes down to communication, but I prefer less ambigous documents above short documents. It’s generally not a good idea to speed up your project by shortcutting the requirements work: slow down if you are in a hurry!
We’re using Use Cases extensively in our projects and write them iteratively as RUP suggests.
Use Cases pass the stages RUP defines:
– “Identified” (You name the Use Case)
– “Shortly described” (You add a short description, e.g. reference the user goals)
– “Outlined” (You add detail up to an agreed-upon level)
– “Fully described” (All details included that are needed by both the designer, tester and user documentation specialist).
Our fully described Use Cases are much like your “Formal” Use Cases documented using a template with a sound structure (see http://blogs.infosupport.com/harryn/archive/2006/01/04/3341.aspx for a sample).
The level of detail you go into for the “Outlined” Use Cases depends on the goal you have for them. They are mostly used to define the scope of the project and/or make estimates on the development time and cost. If the estimates need to be very accurate, much detail is needed in the outline. If the estimates need to be in man-months, less detail is done.
Not all fully described Use Cases need the same level of detail. E.g. mainenance Use Cases where reference data are maintained can be described very briefly, without the need to go into all the details of alternative flows.
So to recap: we use both formal and informal Use Cases, and add different levels of detail.
During the courses I teach (e.g. the IBM/Rational course Mastering Requirements Management with Use Cases) must students have trouble getting the first lines on paper. Once they got started things get better. To my opinion, you can use this as counter evidence for the statement that informal Use Cases are easy to create.
When I count the numerous requests for templates and samples I get, I’m confident to say that most (beginning) Use Case specifiers prefer a structured template with some guidance above an unstructured one.
Thanks Harry.
One thing from your comment about what defines the level of detail that you go into in writing a use case. There are really three variables at play – what level of detail, when you go into it, and who does it.
What level of detail
Is a function of trust. How much does your customer trust you to “do something great”, and how much do you trust your development team to “do something great”. Those two trust-factors determine how much specificity your customer requires in the spec, and how much restriction you place on the developers.
When you go into it
When doing estimations, you can use vague and high level use cases to help create order-of-magnitude estimates. You still need to specify more detail down the road.
Who does it
This is where design meets requirement. The more control you give to the developer, the more she is going to define and design the way a use case is enabled by the software. Ultimately, someone decides. The only question is if it is part of a documented “approval” process, or an undocumented “acceptance” process. Either way, if the customer’s expectations are not met, they aren’t met.
Personally, I strongly prefer the informal use case, because of the level of energy that comes from a team when reviewing or defining them. It becomes a self-sustaining fusion reaction of ideas. There is definitely merit to the formal use case too – when customers want more control over how you choose to interpret their needs, it can be a very effective instrument for managing expectations and relationships. As I talk about in the “dance steps” section of the Foundation series post on software processes – the right use case framework is a function of the customer and the team.