Using Use Cases for Requirements Capture

Use Cases have proved to be an effective mechanism for the capture of requirements. This document uses Alistair Cockburn's format for Use Cases and adds in ideas about how to create and review Use Cases, see for the original.

Some sample use cases have been formatted for the web to assist projects that want to use html to document their project requirements. Enjoy.

Developers have always used typical scenarios to try to understand what the requirements of a system are and how a system works. Unfortunately although developers have done this, it has rarely been documented in an effective manner. Use Cases are a technique for formalizing the capture of these scenarios.

Although Use Cases, as defined in the Objectory book (Object Oriented Software Engineering, Jacobson, Christerson, Jonsson & Overgaard. Addison Wesley 1992), are associated with Objects, the technique is actually independent of Object Orientation. Use Cases are an effective way of capturing both Business Processes and System Requirements, and the technique itself is very simple and easy to learn.

Making Requirements available for Review

The reason for formally capturing the scenarios is to make them available for review by both the users and the developers. There are 2 specific criteria that any functional requirements notations needs to meet:-

  1. it should be easy for the sources and reviewers of the requirements to understand and
  2. it should not involve any decisions about the form and content of the system.

Functional Requirements are external requirements that are to be used to evaluate the design and final implementation of the  system.

What these requirements have to do is capture in an implementation-independent manner what the needs and expectations of the stakeholders are.

See Alistair Cockburn's Writing Effective Use Cases book.

Some thoughts on the requirements capture process

The ootips site contains a summary of an interesting debate that occurred on Usenet, about when are the use cases done? The suggestion that you can start designing after you have one use cases provoked quite a lot of reaction.

(C) 2000 Software Craftsmanship Inc., all rights reserved.