Use Case Analysis in SDLC

Use Case Analysis

• Use case analysis is used in the analysis phase of the SDLC
• Allows describing the various parts of a use case
• Contributes to functional requirements and development of test plans

What is a Use Case?

• Represents how a system interacts with its environment
• Illustrates the activities performed by users and the system's responses
• Creates a set of use cases describing tasks users perform using the system
• Describes system activities from the user's perspective and the interaction they have
• Describes how an event triggers actions performed by the system and the user
• In event-driven modeling, everything in the system is a response to a triggering event
• The system is at rest when there are no events
• When a trigger event occurs, the system responds and performs defined actions

Role of Use Cases

• Expresses and clarifies user requirements and interaction between user and system.
• Helps to fully describe functional requirements.
• Used extensively in the analysis phase in user interviews or JAD sessions.
• Text-based use cases are easy to understand, and they flow easily into the creation of process models and the data model.
• NOT useful in batch processes, computationally intensive applications, or data warehousing.

Elements of a Use Case

• Every use case has a name, number, and brief description
• Priority indicates the relative significance
• Actor is a person, another system, or hardware device that interacts with the system to achieve a goal or user role
• Trigger is the event that causes the use case to begin
• Events Triggers can be external or temporal

Sections of a Casual Use Case Format

• Content, format, and degree of formality can vary by organisation
• Typical sections include basic information, preconditions, normal course, postconditions, and exceptions

Normal Course for a Custom Drone Order

• Customer selects a base model drone from a list.
• System provides availability status for that model.
• If out of stock, the system displays the expected date.
• The customer proceeds to step 4 if they accept a future date otherwise they return to step 1.
• System displays a list of options and upgrades.
• Customer selects desired model options and upgrades
• A preliminary order with a cost estimate is created and displayed.
• Customer may return to step 4, confirm the order, save for future consideration, or exit without saving.
• Unconfirmed orders are stored; confirmed orders are saved, and the shop manager is notified for approval.

Exceptions

• Errors are included to complete use case
• Special situations or errors can occur with each step

Preconditions and Postconditions

• Preconditions define the state that the system must be in before the use case commences
• Postconditions define what is complete when this use case ends
• Example: Customer is authenticated/logged in and the Sales System Order Processing application is online
• Example: Unconfirmed/ Confirmed order is stored and shop manager sent notice of Confirmed Order requiring approval

Use Cases in Sequence

• Use cases are performed in sequence.
• No single use case should be too large.
• It's important to define initial and ending states.

Fully-Dressed Use Case Format

• Very thorough, detailed, and highly structured.
• Adds new sections, including alternative courses, inputs and outputs for steps and summary inputs and outputs.
• Some companies may include additional sections devoted to: Frequency of use, Business rules, Special requirements, Assumptions Notes and issues

Casual Use Case Format

• Customer selects and customizes a commercial drone for purchase
• Trigger is when the customer wants to purchase a commercial drone
• A customer is authenticated by logging into his account, and the Sales System Order Processing application is online
• Preconditions set up and the "normal" course is a customized drone order

How to use the Fully-Dressed format

• Users aren interacting throughout the entire project
• Project has high complexity and high risk associated with system failures and there are comprehensive test cases
• Remote collaborating teams need detailed, shared understanding of user needs.

Practical Tips

• Use gradual refinement
• Focus on describing the user's objectives
• Keep both audiences in mind – users and developers
• Create use cases only when needed to clarify what the system must do from the user's perspective

Use Cases and the Functional Requirements

• Use cases are useful tools to clarify user requirements
• Convey only the user's point of view
• Transforming the user's view into the developer's view is one of the system analyst's key contributions

Detailed Functional Requirements

• Used to create more complete and descriptive functional requirements
• The system displays a list of base drone models
• System accepts customer selection of base drone model
• The system displays in stock/out of stock status for selected drone model.
• The system displays optional features for the selected drone model
• System accepts user choices of options
• The system displays summary and price of selected drone configuration
• The system allows user to continue modifying the drone configuration, save the order for later, confirm the order, or exit without saving.
• For confirmed orders- a completed order summary is displayed for the customer, the order is stored in the Confirmed Custom order, and The system sends a notice of new Confirmed Custom order to the Shop Manager for approval

Creating Use Cases

• Common ways to gather information for the use cases are through interviews and JAD
• Steps include:
• Identify the major use cases
• Identify the major steps within each use case
• Identify elements within steps
• Confirm the use case with users through role-playing