Guidelines At The Use Case Level

The following guidelines concerning use cases have proven effective when performing use case modeling during the requirements engineering of functional requirements.

Make Use Cases Functionally Cohesive

• Make each use case functionally cohesive.
• Make each use case fulfil all related business or application responsibilities involved in achieving a single of a primary actor’s.
• Do not base use cases on:
  • GUI screens (i.e., one use case per GUI screen).
  • Major business or application functions or features.

• These guidelines makes use cases easier to understand.

Identify Use Cases

• For each actor, identify a use case corresponding to each functionally cohesive:
  • Goal of the actor that will be fulfilled by the blackbox business enterprise, application, framework, component, or application domain being specified.
  • Set of responsibilities that the actor will delegate to the business enterprise, application, etc to perform on his/her/its behalf.
  • Set of interactions that the actor has with the business enterprise, application, etc.
• Identify a use case for each functionally cohesive operation that the business enterprise, application, etc. needs to perform in order to fulfil its mission and to meet its objectives.
• Determine if the actor needs to create, read, update, or delete information stored by the application.
• Determine if the actor needs to notify the application of an external event, or if the application needs to notify any actors about internal or external events.
• Factor out common sets of interactions to identify new subordinate use cases.

• This information can be used to identify functionally cohesive use cases.

Use Essential Use Cases

• Use essential (i.e., requirements-only) use cases to specify:
  • Requirements.
  • The “what,” not the “how”.
  • An actor’s intended goal or benefit, not how the goal will be implemented.
• Avoid unnecessarily specifying architecture or design decisions in use cases.
• Avoid screen navigation details by using preconditions.

• By including design information in use case models, the distinction between requirements and design is blurred.
• Design-level use cases require more maintenance because they must be updated each time the design changes.
• Being technology free, essential use cases are more robust when technology changes.
• Design-level use cases can lead to more traditional user interfaces that unnecessarily constrain the creativity of user interface designers.

• The user presses the on-off button on the panel of the digital thermostat.
• The user presses the soft button corresponding to the requested account type on the touch screen of the automatic teller machine.

• The user turns the digital thermostat on.
• The user requests the desired account type from the ATM.

Do Not Specify Security Mechanisms

Do not unnecessarily specify the choice of security mechanisms to meet the security requirements.
Rationale: There are many security mechanisms that can be used to implement the security requirements. For example, identification and authentication can be performed in terms of user identifiers and passwords, smart cards, hand print scanners, and retina scanners. Security mechanisms are therefore design decisions, not requirements. Security requirements should be specified in the quality section of the system requirements specification. Hardware security mechanisms should be documented in the system architecture document, and software security mechanisms should be documented in the software architecture document.
Bad Examples (system boundary):

• The system shall prompt the user to enter his or her user identifier ( how the system implements the identification security requirement).
• The system shall prompt the user to enter his or her password. If the user does not enter the correct password within 3 tries, then the system shall notify the security officer ( how the system implements the authentication security requirement).

Properly Name Each Use Case

• Name each use case with a unique, unambiguous, meaningful active verb phrase.
• Capture the primary actor’s goal (i.e., how the use case benefits the actor).
• Name the use case from the actors’s external viewpoint rather than the internal viewpoint of the business, application, or component.
• Where practical, include the name of the primary actor that benefits from the use case.
• Name the entire use case rather than just one of the success paths.
• Avoid system development technical jargon.
• Avoid mentioning unnecessary user interface constraints.

• Unique unambiguous meaningful names are easier to understand and remember.
• Use cases are functional abstractions that are best described using verb phrases.
• Active verb phrases are more likely to be meaningfully descriptive.
• Adding the primary actor’s name makes it easier to understand who benefits from the use case.

• Temperature Control.
  (This is not a verb phrase.)
• Desired temperature is changed.
  (This is not an active verb phrase and is from the wrong viewpoint.)
• User increments the digital thermostat.
  (This is really a use case path; what about decrementing the desired temperature? Also, why is this increment instead of increase or change? That sounds like a user interface design decision based on traditional implementations with increment and decrement buttons.)
• Turn on the digital thermostat.
  (This is really a use case path; what about turning the digital thermostate off?)
• User presses On/Off button.
  (Unnecessary user interface design constraint that does not directly capture the user’s goal.)

• User turns the digital thermostat on and off.
• User changes the desired room temperature.
• User schedules the desired room temperatures.

Specify Use Case Requirements

Provide a uniquely identified, textual requirement for each use case that captures its functional abstraction and external’s goal.
Rationale: This guideline provides an overview of the use case. A textual requirement is also the information expected by domain experts who are used to textual requirements specifications. This guideline also supports the creation of an executive requirements summary document containing only the names and primary requirements of use cases and their paths.
Bad Examples:

• The user changes the desired temperature of the room.
  (This is not a requirement, but rather an observation.)
• The user shall change the desired temperature of the room.
  (This constrains the user. It is not a requirement on the digital thermostat).

• The digital thermostat software shall permit the user to change the desired temperature of the room.
  (Written as a requirement - "shall" - on the digital thermostat.)

Create Use Case Diagrams

Create a top-level use case diagram for each primary external that summarizes the behavioral context of the application in terms of the primary actor’s use cases, any related actors, and the important relationships between them. Optionally create a lower-level use case diagram for each use case that has numerous relationships to other use cases. Identify the primary actor associated with each use case on the use case diagram. Provide narrative English descriptions of the use case diagrams that clarify anything that is not totally obvious in the diagram. Also, document the boundaries of the blackbox application on each use case diagram, and label the scope of each diagram.
Rationale: Applications often have too many actors and use cases to document on a single top-level use case diagram. By limiting the scope of the diagram, the diagram becomes simpler, more focused, and therefore easier to understand. The diagrams also become easier to maintain because the impact of changes is more localized.
Warning: Do not waste significant time debating the relationships (e.g., invokes, extends, inherits) between use cases. If the relationship is unclear, do not label it. The distinction between relationship types is often unclear and the subject of many unnecessary arguments. The extends relationship is typically quite confusing to readers and should be avoided on most projects. The extends relationship should also not be misused to represent what is really the distinction between normal and exceptional paths through a single use case.

Provide a Business Context

Use an activity diagram to optionally document the larger business context of the use case.
Rationale: A user may perform multiple use cases in order to achieve an overall goal. This guideline helps the reader understand the overall work flow to which the use case contributes. For example, a user of an ATM machine may first check the balances in several accounts before deciding from which account to withdraw funds. This guideline is optional because the individual goals of many use cases are identical with the overall business context of the use case.

Annotate Business Rules

Optionally note the business rules or policies (e.g., quality requirements) that impact a use case or its paths.
Rationale: Although use cases themselves are not intended to capture quality requirements, providing a link to them makes it easier to see from where the operational requirements of the use case and its path come.

Provide a Business Justification

Document the business justification for each use case. Ensure that the business justification actually justifies the use case and is more than merely a restatement of the use case requirement.
Rationale: This guideline ensures that the use case specifies a real requirement.