Introduction

Crumb’s definition for a use case is simple. A use case is an actor’s goal. Slightly more complex definition is that a use case describes how an actor would use the features of a given solution to achieve their goal.

Neither the UML nor the RUP define how to write the textual contents of a use case. UML defines how to draw the use case model diagram, and the RUP contains many best practices to help a team with their use case modeling, but neither describes a disciplined language for writing detailed use cases.

This apparent lack is not an omission but is actually done by design. The UML and RUP do not specify the syntax or style for writing a use case for the same reason that neither one force the use of a specific programming language for coding object-oriented designs. Both RUP and UML will work regardless of what programming language you select, such as Java, C++, Small Talk, Visual Basic, etc. Likewise each will work regardless of how you decide to write your use cases.

However, if we did have a disciplined language for writing use cases, this could help to ensure consistency from one use case author to the next, facilitating follow on activities such as design, test, and maintenance. A disciplined syntax could also help lead to better automation tools. Specifically tools to help analysts consistently write higher quality use cases and to help generate design models right from the well written use case specifications! It is the expectation that tool vendors will be able to create valuable automations to speed up the writing and especially the maintenance of use case specifications by automating a well defined syntax.

Crumb is such a syntax. Crumb is to a use case model as a programming language, such as Java or C++, is to a design model. In other words, programming languages implement a design model much as Crumb defines a use case model.

Crumb is based on a number of use case modeling best practices including the ones in the list below. If you agree with these best practices, compare your current technique to this list to evaluate how well it enforces these best practices. Crumb has been specially crafted to support all of them and more:
Use cases should be black boxed
Use cases should not include design
Anchored alternate flows should be identifiable from the main scenario
All requirements, including use cases, should strive to minimize vocabulary
Use cases should strive to be more maintainable as use cases tend to be hard to modify, especially in the step numbering and in alternate flow step numbering

If you would like the detailed Crumb spec, contact the author of this blog.