use case - introduction

USE CASEIntroduction and Best Practices

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

Why should you be interested ? IDEO Story:

Biker water bottle – heart valve

Multidiscipline cooperation

What are RequirementsIt covers : Functional

requirements User requirements

Nonfunctional requirements Quality attributes:

performance, security, archiving, database

definedoperationalcapabilities

businessneeds

satisfy

Software Requirements Three perspectives:

Business level User level Technical level

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)

User Level Use cases :

are “voice of customers”

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

Technical Level

Technical requirements Functional requirements based on user

requirements Nonfunctional requirements

Software Requirements Recap:

Business level User level Technical level

5 Best Practices

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

requirements Develop a project glossary

1. Scope the Domain Manage avoidable

scope creep Be flexible on

unavoidable market and business condition changing

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

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

2. Scope Your Use Cases

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

2. Scope Your Use Cases

Frame each use case with: triggering events event responses

3. Validate Use Cases Questions to validate:

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

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.

5. Develop Glossary communication gaps between

software vs business people each side has its acronyms and

jargon glossary should be a living, vital part

Summary Software

Requirements: Business User Technical

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

Q & A

Reference: Ellen Gottesdiener, “Use Cases: Best

Practices”, IBM, 6/11/2003