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