22
USE CASE Introduction and Best Practices

Use Case - Introduction

  • Upload
    ckunta

  • View
    858

  • Download
    0

Embed Size (px)

DESCRIPTION

Use case introduction and best practices, based on IBM paper

Citation preview

Page 1: Use Case - Introduction

USE CASEIntroduction and Best Practices

Page 2: Use Case - Introduction
Page 3: Use Case - Introduction

Why are Requirements important 1/3 budget to correct errors

originate from requirements Defining requirements is crucial to

all project stakeholders Many techniques and models

available

USE CASE MODEL

Page 4: Use Case - Introduction

Why should you be interested ? IDEO Story:

Biker water bottle – heart valve

Multidiscipline cooperation

Page 5: Use Case - Introduction

What are RequirementsIt covers : Functional

requirements User requirements

Nonfunctional requirements Quality attributes:

performance, security, archiving, database

definedoperationalcapabilities

businessneeds

satisfy

Page 6: Use Case - Introduction

Software Requirements Three perspectives:

Business level User level Technical level

Page 7: Use Case - Introduction

Business Level Clarify business’ goals and

objectives Define the vision to achieve it Ensure building the right software Define correct project stakeholders:

including direct users (actors)

Page 8: Use Case - Introduction

User Level Use cases :

are “voice of customers”

• interaction• has name• step-by-step• exception conditions• variant paths

Page 9: Use Case - Introduction

Technical Level

Technical requirements Functional requirements based on user

requirements Nonfunctional requirements

Page 10: Use Case - Introduction

Software Requirements Recap:

Business level User level Technical level

Page 11: Use Case - Introduction

5 Best Practices

Scope the domain Scope your use cases Validate use cases Determine the strategy to elicit

requirements Develop a project glossary

Page 12: Use Case - Introduction

1. Scope the Domain Manage avoidable

scope creep Be flexible on

unavoidable market and business condition changing

Page 13: Use Case - Introduction

How to name a Use Case What’s in a name ?

Well named use cases

enable business customers to easily infer who the actor is

Page 14: Use Case - Introduction

Best practices action verb + [qualified] object

eq: place order, request product or service

avoid vague verbs, such as do or process bad example: do ticketing

Page 15: Use Case - Introduction

2. Scope Your Use Cases

A use case addresses a single actor goal is not overly complex avoid partial processes in the business

Page 16: Use Case - Introduction

2. Scope Your Use Cases

Frame each use case with: triggering events event responses

Page 17: Use Case - Introduction

3. Validate Use Cases Questions to validate:

help achieve goals and visions ? address the problem ? key differentiator ? address all stakeholders ? priority for initial release ?

Page 18: Use Case - Introduction

4. Determine Your Elicitation Strategy

Commercial software: market surveys, on-site visits, facilitated workshops

In-house business system with large user base: review help desk logs, reusing existing requirements, workshops

Smaller user base: facilitated workshops and observation.

Page 19: Use Case - Introduction
Page 20: Use Case - Introduction

5. Develop Glossary communication gaps between

software vs business people each side has its acronyms and

jargon glossary should be a living, vital part

Page 21: Use Case - Introduction

Summary Software

Requirements: Business User Technical

Best Practices: scope domain scope use cases validate use cases elicit requirements glossary

Page 22: Use Case - Introduction

Q & A

Reference: Ellen Gottesdiener, “Use Cases: Best

Practices”, IBM, 6/11/2003