USE CASE
Introduction
and
Best Practices
Why are Requirements
important
 1/3 budget to correct errors
originate from requirements
 Defining requirements is cruci...
Why should you be
interested ?
 IDEO Story:
 Biker water bottle –
heart valve
 Multidiscipline
cooperation
What are Requirements
It covers :
 Functional
requirements
 User requirements
 Nonfunctional
requirements
 Quality att...
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 soft...
User Level
 Use cases :
 are “voice of
customers”
• interaction
• has name
• step-by-step
• exception conditions
• varia...
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
require...
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 act...
Best practices
 action verb + [qualified] object
 eq: place order, request product or
service
 avoid vague verbs, such ...
2. Scope Your Use Cases
 A use case
 addresses a single actor goal
 is not overly complex
 avoid partial processes in ...
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 differenti...
4. Determine Your
Elicitation Strategy
 Commercial software: market surveys,
on-site visits, facilitated workshops
 In-h...
5. Develop Glossary
 communication gaps between
software vs business people
 each side has its acronyms and
jargon
 glo...
Summary
 Software
Requirements:
 Business
 User
 Technical
 Best Practices:
 scope domain
 scope use cases
 valida...
Q & A
 Reference:
 Ellen Gottesdiener, “Use Cases: Best
Practices”, IBM, 6/11/2003
Use Case - Introduction
Use Case - Introduction
Upcoming SlideShare
Loading in …5
×

Use Case - Introduction

1,063 views

Published on

Use case introduction and best practices, based on IBM paper

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,063
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Here is how we visualize a software project
  • Typical software projects spend roughly one-third of their overall budget correcting errors that originate in requirements
    project stakeholders such as clients, end users, develoeprs, testers and managers
    Years of experience led to development of a number of techniques and models to assist the process
    Use case model is the most well-known
  • Toastmasters:
    How innovation is produced from multidiscipline cooperation.
    Maybe you are interested to change job ?
    Traditional water bottle designs require the user to bite a dispensing spout to pull it out, but this new bottle features a self-closing valve that opens only when the bottle is squeezed.
  • To understand Use Case, first let’s take a look at Requirements.
    Requirements are the defined operational capabilities of a system or process that must exist to satisfy a business need.
    User requirements: tasks that users need to achieve using the software.
  • Requirements don’t come out of thin air.
    They are products of systematic discovery and definition process where analyst plays a key role.
    Software requirements came from process of thinking through three perspectives of requirements.
  • At the highest level (or business level), you begin by understanding and clarifying the business’ goals and objectives. Then you define the vision on how to achieve it. You ensure that you will build the right software. In addition, you also define the correct project stakeholders.
  • This is where use cases come in.
    Use cases describes the interaction between an external actor and the system, thereby documenting a major function that the system will perform. At a minimum it has a name and contains of step by step actions. It sometimes include exception conditions and variant paths.
  • Technical requirements include functional requirements based on user requirements and nonfunctional requirements
  • use cases lie in-between the business and technical perspectives and provide the basis on which all development and testing is based
  • scope creep: scope of the projects expands as the work proceeds
    requirements may change because of changing market and business conditions -> unavoidable
    manage the avoidable scope creep
  • The first step to manage the scope is to create use cases and just name the use cases, and not the details.
  • Fifth Third
  • Ensure that each one is necessary to meet the business opportunities in your product vision.
    To validate, answers the following questions;
    How does this uc help us achieve our goals and visions
    Does this use case address some aspect of the problem in our problem statement ?
    Does this use case differentiate our product in some way ?
    Do we have use cases to address all the stakeholder and user groups we identified in our vision statement
    Which use cases will be implemented in our initial release ?
  • A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?" The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field."
    "You must be a software developer," says the balloonist.
    "I am," replies the man. "How did you know?"
    "Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone."
    The man below says, "You must work in business as a manager." "I do," replies the balloonist, "but how did you know?"
    "Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."
  • Use Case - Introduction

    1. 1. USE CASE Introduction and Best Practices
    2. 2. 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
    3. 3. Why should you be interested ?  IDEO Story:  Biker water bottle – heart valve  Multidiscipline cooperation
    4. 4. What are Requirements It covers :  Functional requirements  User requirements  Nonfunctional requirements  Quality attributes: performance, security, archiving, database defined operational capabilities business needs satisfy
    5. 5. Software Requirements  Three perspectives:  Business level  User level  Technical level
    6. 6. 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)
    7. 7. User Level  Use cases :  are “voice of customers” • interaction • has name • step-by-step • exception conditions • variant paths
    8. 8. Technical Level  Technical requirements  Functional requirements based on user requirements  Nonfunctional requirements
    9. 9. Software Requirements  Recap:  Business level  User level  Technical level
    10. 10. 5 Best Practices  Scope the domain  Scope your use cases  Validate use cases  Determine the strategy to elicit requirements  Develop a project glossary
    11. 11. 1. Scope the Domain  Manage avoidable scope creep  Be flexible on unavoidable market and business condition changing
    12. 12. 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
    13. 13. 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
    14. 14. 2. Scope Your Use Cases  A use case  addresses a single actor goal  is not overly complex  avoid partial processes in the business
    15. 15. 2. Scope Your Use Cases  Frame each use case with:  triggering events  event responses
    16. 16. 3. Validate Use Cases  Questions to validate:  help achieve goals and visions ?  address the problem ?  key differentiator ?  address all stakeholders ?  priority for initial release ?
    17. 17. 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.
    18. 18. 5. Develop Glossary  communication gaps between software vs business people  each side has its acronyms and jargon  glossary should be a living, vital part
    19. 19. Summary  Software Requirements:  Business  User  Technical  Best Practices:  scope domain  scope use cases  validate use cases  elicit requirements  glossary
    20. 20. Q & A  Reference:  Ellen Gottesdiener, “Use Cases: Best Practices”, IBM, 6/11/2003

    ×