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
Latest Articles
Comments on all Articles
