Successful systems require clearly defined behavior. Use Cases and Business Rules help define the behavior and identify requirements. A Navigation Map can also be used to help facilitate communication between the development team and the end users and help identify Business Rules. The Use Cases and Business Rules are then mapped together to help identify undefined areas of the project or areas that may be out of scope.
A use case focuses on what the actor intends to do and what happens inside the system (not how or why) in response. Each use case should begin with an event triggered by an actor and contain:
- Name - should be in verb-noun form (e.g., edit item, issue payment, delete user, etc.)
- Short Descriptions - what the use case does for the actor and how it should work.
- Preconditions - conditions that must be met before the actor triggers the Use Case.
- Basic Flow - an actor/system dialogue beginning with the triggering event.
- Alternate Flows - defines the system behavior when the basic flow is interrupted, and the expected outcome.
- Post Conditions - the expected outcome of a successful completion of the Use Case.
Individual Use Case steps focus on the what, not the how. The following list provides an example of the Basic Flow of a Use Case:
1. [Actor] issues a request to edit an item.
2. System retrieves and presents a list of items.
3. [Actor] selects item to edit.
4. System retrieves and presents the selected item details.
5. [Actor] edits item details.
6. System validates and records updated item and presents confirmation message.
In the previous example, an alternate flow exists if the user in step 1 is not authorized or if the retrieval fails in step 2 or step 4. An alternate flow could also result if the validation or the recording fails in step 6.
The following questions may be used to aid in the discovery of information which must be captured in the Use Case Specifications document:
User Goals
1. What are the user goals? (the user wants to do something)
- Provide a title <User Goal>
- Validate preconditions by verifying there is a use case with a post condition that supports the precondition, otherwise create the use case
2. Identify the actors <Actor Hierarchy>
- What is the actors' business role while performing this action?
- What is the relationship between the actors?
- What external system dependencies are present?
3. Basic flow
- <actor... action... direct object... [prepositional phase, e.g. to the system]
- The use case begins with the trigger used by the actor to start the use case
- The use case ends by satisfying the post conditions
4. Alternate flows
- Identify all actions listed in the basic flow, i.e. retrieve, record
- For each action determine what can go wrong or affect the flow (for each answer, create an alternative flow)
- Alternative flow elements include:
- Outcome, i.e. use case ends, use case resumes at basic flow step [...]
- For each alternative flow, repeat starting at step 1
5. Business Rules
- Identify all actions and direct objects, i.e. information, criteria, selection
- For each action and direct object, identify the details, constraints and other information about the action/object. These answers are captured as business rules.
See the Use Case Workshop Process Questions document for a printable version of the questions above.
SDLC use case flow statements follow a string pattern of language usage. Use case flow statements adhere to the simple sentence structure of an independent clause, consisting of a subject and a predicate. A simple example of this standard consists of a noun, verb, and direct object. For instance:
Example: The clerk selects one or more shareholders. Constituent: (noun)-(verb)----(direct object)
A prepositional phrase compliments the direct object of the sentence flow. It adds more information to the content of the action being performed. Prepositional phrases are optional while writing use cases, based upon how pertinent the information is. An example using a preposition phrase can be:
Example: The clerk selects one or more shareholders from the list. Constituent: (noun)-(verb)--(direct object)------(prep. Phrase)
This type of pattern is applicable to the basic course of events in a typical use case. For instance:
Example: The clerk selects one or more shareholders from the list. Constituent: (noun)-(verb)--(direct object)------(prep. Phrase) Pattern:-------(actor)-(action)-------------(interaction with system)
Verbs - When choosing verbs to represent the actions of the use case, it is important to be consistent in their application. The following lists are best practice examples of verb usage in use cases.
> The System - The following terms are common usage for actions in regards to the system of a use case:
- Validates (a request) - Retrieves (information) - Presents (information) - Records (information) - Calculates (a value) - Generates (a value) - Prompts (a user) - Requests (from external systems) - Returns (to external systems)
> The Actor - The following terms are common usage for actions in regards to the system of a use case:
- Requests (information of or from the system) - Selects (information presented by the system) - Enters (information the system has prompted for) - Updates (presented information) - Confirms
|
