use case - introduction
DESCRIPTION
Use case introduction and best practices, based on IBM paperTRANSCRIPT
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