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 -&gt; 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.
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: &quot;Excuse me, can you tell me where I am?&quot; The man below says: &quot;Yes you&apos;re in a hot air balloon, hovering 30 feet above this field.&quot; &quot;You must be a software developer,&quot; says the balloonist. &quot;I am,&quot; replies the man. &quot;How did you know?&quot; &quot;Well,&quot; says the balloonist, &quot;everything you have told me is technically correct, but it&apos;s of no use to anyone.&quot; The man below says, &quot;You must work in business as a manager.&quot; &quot;I do,&quot; replies the balloonist, &quot;but how did you know?&quot; &quot;Well,&quot; says the man, &quot;you don&apos;t know where you are or where you are going, but you expect me to be able to help. You&apos;re in the same position you were before we met but now it&apos;s my fault.&quot;
Use Case - Introduction
Why are Requirements
1/3 budget to correct errors
originate from requirements
Defining requirements is crucial to
all project stakeholders
Many techniques and models
USE CASE MODEL
Why should you be
Biker water bottle –
What are Requirements
It covers :
Clarify business’ goals and
Define the vision to achieve it
Ensure building the right software
Define correct project stakeholders:
including direct users (actors)
Use cases :
are “voice of
• has name
• exception conditions
• variant paths
Functional requirements based on user
5 Best Practices
Scope the domain
Scope your use cases
Validate use cases
Determine the strategy to elicit
Develop a project glossary
1. Scope the Domain
Be flexible on
How to name a Use Case
What’s in a name ?
Well named use
customers to easily
infer who the actor
action verb + [qualified] object
eq: place order, request product or
avoid vague verbs, such as do or
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
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
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
5. Develop Glossary
communication gaps between
software vs business people
each side has its acronyms and
glossary should be a living, vital part
scope use cases
validate use cases
Q & A
Ellen Gottesdiener, “Use Cases: Best
Practices”, IBM, 6/11/2003