Determining the form of Use Case for a project is a key planning step and is essentially a communication issue. Since each team member will have a different idea of what Use Cases are, clarity is required. This is necessary for organizing work teams, and provides a clear benchmark for quality management.

 

Focus

The purpose for developing the description, which is closely related to the scope of the description to be developed

  • Process Level | To describe the overall process from end-to-end to enable scope discussions
  • Business Activity Level | To describe the process limited to a business activity that comprises a portion of the overall process to enable lower level estimations
  • Component Level | To describe the complete, unambiguous process descriptions to enable simple and accurate design

 

Style

The level of formality in presentation and rules for defining the Use Case

  • Semi-formal | Textual, paragraphs or bulleted; A less formal application of rules or guidelines of Use Case modeling
  • Formal | ‘Structured’ Use Case format; Strict application of the rules for modeling Use Cases, and their Main, Exception, and Alternate Flows

 

Detail

The level of abstraction or granularity to which the process is described in the Use Case

  • High Level | Simple structure; ‘Actor-verb-entity’ syntax; Typically short single sentence / bullet; Typically fewer steps per Use Case
  • Medium Level | The most common format; Typically adds conditional statements, outcomes and / or business rules to the high level ‘Actor-verb-entity’ statements
  • Detailed Level | A complete set of all steps in all variations, fully defined; A comprehensive description of each step in the Use Case; May require multiple sentences or paragraphs to describe the step; Typically a large number of steps

 

Visibility

The level of understanding of the internal behavior of the process

  • Black Box | Not fully understanding the internal behavior of the process / system; e.g. no defining the details of a calculation that is required to be done
  • White Box | Understanding the internal behavior of the process / system; defining the calculations / algorithms

 

Type

The purpose for describing the Use Case – Business or System / Design.

  • Business | To describe the business process that defines the ‘problem’ to be given to the design team
  • System / Design | To describe how the user could interact with a system to accomplish the steps defined in the Business Use Case – a ‘solution’

 

Consider the Audience: Business, Developers & Architects, Quality Assurance / Testers, Technical Writers, Trainers, etc

 

Click here fore more business analysis resources

Powered by wpcustomerservice.com