Use Case Leveling Definitions

Very high level, involve multiple user goals, e.g. "Operate a Biospecimen Repository"

Very high level summary, such as Sell books online. Too high up to be of interest to software development projects, and far too high level to generate code.

Most general; high level business processes.

0

High level, a process that takes place over several hours, days or weeks involving many steps "Find Usable Samples"

Summary level. Again, too high level to be interesting to software development projects and generating code.

Diagnostic or treatment specific, but only down to department level for business process flow reasons.

1

User Goals
(Blue)

User Goal, something the actor is trying to get done - "one person, one sitting", involves several underwater or clam level

People familiar with the Rational Unified Process (RUP) should be familiar with this level of use cases, also referred to as user goal level. A single use case at this level describes a single elementary business process, and realizes a single user (actor) goal. An example could be Place order.

Department detail level - test codes included, but still platform independent. Level 2 use cases must drive out the major model dimensions (static/information model, behavioral model, governance model, etc.).  Can include some exception conditions.

2

Subfunction
(Indigo/Black)

Needed to accomplish user goals, typically can be used and reused - "Save as a File"

At this level, use cases are often used and re-used as a part of a sea level use case and describe processes that for instance handle selecting a customer, or validating credit cards with a credit card company. This level is also referred to as sub-function level, and includes use cases such as Select product and Pay order. These use cases, including the sea level use cases, are a good head start for generating code that handles the software's behavior.

Add detail of each exchange of information.  Includes assumptions about system boundaries.

3

Subfunction
(Indigo/Black)

Not usually written out in detail as a use case, "insert record into database"

This is where you hit rock bottom. Use cases at this level should not be defined as use cases, but rather appear as steps in another use case, most likely at fish level. A clear example can be inserting new customers in the database.

Project-specific solution for exchanges detailed in use case level-3 (could be MSG, SOA, or both)

4