General Guidelines

The following are general use case guidelines that have proven effective when performing use case modeling during the requirements engineering of operational requirements:

Provide Training

Guidelines

• Provide initial classroom training for all relevant personnel who will either develop, inspect, or read the use case section of the system requirements specification:
  • Requirements Team
  • Requirements Inspection Team
  • Project Management Team
  • Architecture Team
  • Hardware Development Team
  • Software Development Team
  • Independent Test Team
  • Customer Representatives
  • Domain Experts
• Provide ongoing on-the-job training for all members of the requirements team.

Rationale

• Use case modeling is still relatively new to most people.
• Requirements engineers who are new to use case modeling tend to produce many defects in the use case model and resulting system requirements specification.
• Developers, who are used to traditional requirements specifications, also often have difficulty interpreting and understanding use case-oriented specifications, especially items intended for others (e.g., the use case categorization that is used by independent test team to prioritize testing).

Functional Requirements Only

Guidelines

• Use a use case model to analyze and specify the functional requirements of an application or business.
• Do not use case modeling for specifying quality requirements (e.g., extensibility, operational availability, portability, reliability, and reusability).

Rationale

• Use cases provide a powerful, industry-standard technique for analyzing and specifying functional requirements in a user-centered manner.
• However, quality requirements typically cannot be reasonably stated in terms of interactions.

Exception

• The relevant parts of a use case model may reference relevant data requirements, quality requirements, and business rules, which may well impact:
  • A collection of use cases.
  • A single use case.
  • One or more of use case paths.

Document in Requirements Specification

Guidelines

• Document the use case model in the operational requirements section of the appropriate requirements specification.

Rationale

• This places the operational requirements in the context of the other requirements (e.g., quality requirements, design constraints).

Use Standard Terminology

Guidelines

• Use the standard terminology of the application domain (i.e., the language of the customer and user communities.
• Avoid the technical jargon of the development organization.
• Don’t unnecessarily invent new terms.
• Define the terms used in the use case model in the glossary.
• Further elaborate the business domain concepts mentioned in the use case model in the domain model document.
• Use standard requirements engineering terminology:
  • The word “shall” signifies a requirement (i.e., madatory and binding).
  • The word “will” expresses a non-binding declaration of intent.
  • The word “should” expresses a recommendation among multiple possibilities.
  • The word “may” expresses a permissible action.

Rationale

• This makes the use case model easier for the customer representatives and domain experts to understand and review the use case model for correctness.

Use Technical Writers

Guideline

• Use technical writers to capture and maintain the use case model.

Rationale

• Technical writers can:
  • Ensure consistency of format.
  • Ensure conformance to the associated standard and these guidelines,
  • Provide less expensive updates of text and diagrams as part of the highly iterative development cycle.
• Technical writers allow the requirements engineers and domain experts to concentrate on requirements engineering.

Validate Requirements

Guidelines

• Manually use:
  • The use cases to validate the actor descriptions.
  • The use case paths to validate the use cases.
  • Specific test cases to validate the use case paths.
• Perform use case driven testing to validate the implemented application against the use case model.

Rationale

• This guideline ensures the quality of the use case model.
• Functional test cases (usage scenarios) can be chosen to exercise use case paths because they capture the operational requirements.

Avoid Use Case Driven Design

Guidelines

• Do not drive the architecture or design from the structure of the use cases.
• Instead, use domain experts and object modeling to identify the key business abstractions.
• Use externals and the information passed with the interactions of the use cases to identify additional classes of objects.

Rationale

• Use cases are functional abstractions that are often functionally decomposed.
• Thus, use case driven design often results in a functional decomposition design based on god-like controller objects violating the encapsulation of dumb data objects.

Verify Architecture and Design

Guideline

• Verify the structural and behavioral architecture against the use case model by tracing use case paths through the architecture.
• Verify the [object-oriented] design against the use case model by tracing paths through the design.

Rationale

• The architecture must implement the operational requirements captured in the use case model.
• The design must implement the operational requirements captured in the use case model.

Use an Appropriate Development Cycle

Guidelines

• Iterative. Iterate the use case model during the course of development to fix defects.
• Incremental.
  Develop nontrivial use case models in a series of increments associated with the builds.
• Parallel.
  Develop the use case model in parallel with the rest of requirements engineering, architecture, design, implementation, integration, and testing.
• Time-Boxed.
  Develop the use case model within fixed milestones and time limits.

Rationale

• Iterative:
  • Requirements engineering is a human activity that is therefore subject to human error.
  • Domain experts and users are much better at identifying what is wrong or incomplete with a partial model than specifying it perfectly up front.
  • The requirements are never known completely and correctly at the start of requirements elicitation, analysis, and specification.
  • Iteration allows the endeavor to make course corrections that insure that the delivered application is not obsolete as soon as it is released.
• Incremental:
  • The use case model of any nontrivial application is much too large to develop efficiently in a single sequential phase.
  • Incremental development allows the associated application to be incrementally developed and tested.
• Parallel:
  • Concurrent architecting, design, coding, and testing against the evolving use case model will rapidly identify defects and holes, providing more time for them to be fixed before the requirements must be frozen.
• Time-Boxed:
  • This avoids requirements engineering degenerating into “analysis paralysis.”
  • It is better to change functionality and cost than quality or schedule.
• All:
  • These guidelines result in higher productivity.
  • These guideliens promote increased developer user (e.g., requirements engineer, architect, designer, and tester) satisfaction.

Schedule Later Builds by Use Cases and Paths

Guideline

• Although the initial builds should provide a foundation of core classes that capture an object-oriented architectural framework, later builds and releases should be scheduled in terms of use cases and paths in the use case model.

Rationale

• Schedules based on use cases and use case paths provide:
  • Incremental value to the users (actors).
  • Testable increments to the independent test team.
• However, scheduling all builds on use cases without an overriding architectural vision tends to produce a functional design that requires significantly more iteration than is necessary.

Use a Standard Modeling Language

Guidelines

• Use a single industry standard modeling language to document the use case model.
• Start with UML, but extend it with the latest approved version of the OPEN Modeling Language (OML).

Rationale

• A standard modeling language promotes communication among developers.
• It also promotes increased productivity and model quality.
• This extension of the Unified Modeling Language (UML):
  • Is easier to learn
  • Is more expressive.
  • Is more intuitive than vanilla UML.
  • Better supports:
    • Different kinds of externals.
    • Relationships between use cases.
    • Use case path logic.

Choose Appropriate Tools

Guidelines

• During requirements elicitation, use actor cards and use case cards to initially capture information about actors, use cases, and use case paths.
• During requirements analysis, use an upperCASE tool that supports all necessary aspects of the chosen modeling language to electronically capture the results of use case modeling.
• However, do not let the choice of tool drive the choice of modeling language.

Rationale

• Actor cards and use case cards are appropriate for requirements elicitation, but not for requirements analysis.
• This guideline ensures that the tool actually does what is intended.