6.16. Guideline: What Tests Can Help Find Useful Use Cases?
Which of these is a valid use case?
- Negotiate a Supplier Contract
- Handle Returns
- Log In
- Move Piece on Game Board
An argument can be made that all of these are use cases at different levels , depending on the system boundary, actors, and goals.But rather than asking in general, "What is a valid use case?", a more practical question is: "What is a useful level to express use cases for application requirements analysis?" There are several rules of thumb, including:
- The Boss Test
- The EBP Test
- The Size Test
The Boss Test
Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is your boss happy?If not, the use case fails the Boss Test, which implies it is not strongly related to achieving results of measurable value. It may be a use case at some low goal level, but not the desirable level of focus for requirements analysis.That doesn't mean to always ignore boss-test-failing use cases. User authentication may fail the boss test, but may be important and difficult.
The EBP Test
An Elementary Business Process (EBP ) is a term from the business process engineering field,[5] defined as:
[5] EBP is similar to the term user task in usability engineering, although the meaning is less strict in that domain.
A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state, e.g., Approve Credit or Price Order [original source lost].
Focus on use cases that reflect EBPs. |
The Size Test
A use case is very seldom a single action or step; rather, a use case typically contains many steps, and in the fully dressed format will often require 310 pages of text. A common mistake in use case modeling is to define just a single step within a series of related steps as a use case by itself, such as defining a use case called Enter an Item ID . You can see a hint of the error by its small sizethe use case name will wrongly suggest just one step within a larger series of steps, and if you imagine the length of its fully dressed text, it would be extremely short.
Example: Applying the Tests
- Negotiate a Supplier Contract
- Much broader and longer than an EBP. Could be modeled as a business use case, rather than a system use case.
- Handle Returns
- OK with the boss. Seems like an EBP. Size is good.
- Log In
- Boss not happy if this is all you do all day!
- Move Piece on Game Board
- Single stepfails the size test.
Reasonable Violations of the Tests
Although the majority of use cases identified and analyzed for an application should satisfy the tests, exceptions are common.It is sometimes useful to write separate subfunction-level use cases representing subtasks or steps within a regular EBP-level use case. For example, a subtask or extension such as "paying by credit" may be repeated in several base use cases. If so, it is desirable to separate this into its own use case, even though it does not really satisfy the EBP and size tests, and link it to several base use cases, to avoid duplication of the text."include" relationship for more on linking subfunction use cases p. 494 Authenticate User may not pass the Boss test, but be complex enough to warrant careful analysis, such as for a "single sign-on" feature.