use case - introduction
DESCRIPTION
Use case introduction and best practices, based on IBM paperTRANSCRIPT
![Page 1: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/1.jpg)
USE CASEIntroduction and Best Practices
![Page 2: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/2.jpg)
![Page 3: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/3.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/4.jpg)
Why should you be interested ? IDEO Story:
Biker water bottle – heart valve
Multidiscipline cooperation
![Page 5: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/5.jpg)
What are RequirementsIt covers : Functional
requirements User requirements
Nonfunctional requirements Quality attributes:
performance, security, archiving, database
definedoperationalcapabilities
businessneeds
satisfy
![Page 6: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/6.jpg)
Software Requirements Three perspectives:
Business level User level Technical level
![Page 7: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/7.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/8.jpg)
User Level Use cases :
are “voice of customers”
• interaction• has name• step-by-step• exception conditions• variant paths
![Page 9: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/9.jpg)
Technical Level
Technical requirements Functional requirements based on user
requirements Nonfunctional requirements
![Page 10: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/10.jpg)
Software Requirements Recap:
Business level User level Technical level
![Page 11: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/11.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/12.jpg)
1. Scope the Domain Manage avoidable
scope creep Be flexible on
unavoidable market and business condition changing
![Page 13: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/13.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/14.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/15.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/16.jpg)
2. Scope Your Use Cases
Frame each use case with: triggering events event responses
![Page 17: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/17.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/18.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/19.jpg)
![Page 20: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/20.jpg)
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](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/21.jpg)
Summary Software
Requirements: Business User Technical
Best Practices: scope domain scope use cases validate use cases elicit requirements glossary
![Page 22: Use Case - Introduction](https://reader035.vdocuments.site/reader035/viewer/2022070320/55860b04d8b42a8a638b4d38/html5/thumbnails/22.jpg)
Q & A
Reference: Ellen Gottesdiener, “Use Cases: Best
Practices”, IBM, 6/11/2003