Post on 21-Jan-2016
transcript
Requirements Management with Use Cases
Module 3: Analyze the Problem
Requirements Management with Use Cases
Module 3: Analyze the Problem
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 2
0 - About This Course1 - Best Practices of Software Engineering 2 - Introduction to RMUC3 - Analyze the Problem4 - Understand Stakeholder Needs5 - Define the System6 - Manage the Scope of the System7 - Refine the System Definition8 - Manage Changing Requirements9 - Requirements Across the Product Lifecycle
Course Outline
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 3
Analyze The Problem: Module Objectives
Learn the steps in analyzing a problem Begin building our use-case model Establish common vocabulary Develop Requirement Management Plan
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 4
Where Are We in The Requirements Workflow?
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 5
Analyze The Problem: Activities and Artifacts
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 6
Analyze the Problem: Focus on The Problem
Problem
Solution Space
Problem Space
Needs
Features
SoftwareRequirements
Test Procedures Design User
Docs
The The Product Product To Be To Be BuiltBuilt
Traceability
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 7
Why Is Analyzing the Problem Important? To avoid the “Yes...but...”
“Yes, it meets the requirements, but it doesn’t solve my problem.”
To avoid extra work It pays to focus on the real problem
To understand requirements Problem statement
• Subject is the customer
“I need to …” Requirement statement
• Subject is the system
“The system provides …”
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 8
Gause & Weinberg, 1989
Definition of a Problem
“A problem can be defined as the difference between
{Problem}
things as perceived
things as desired”and
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 9
Activity: Develop VisionSteps in Problem Analysis 1: Gain agreement on the problem being solved 2: Identify stakeholders
3: Define system boundaries
4: Identify constraints imposed on the system
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 10
Step 1. Gain Agreement
What is the problem? We technologists tend to rush headlong into solution
providing - rather than taking time to truly understand the problem
Suggestion: Write it down, see if you can get everyone to agree on it
What is the problem, really? Searching for root causes - or the “problem behind the
problem” - often leads to a clearer understanding of the real problem
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 11
What Is the Problem Being Solved?
Fishbone Diagram: One Method for Root-Cause Analysis in Solving our Sample Problem
List contributing causes to the identified problem.Keep asking “Why?” (expand each rib). How much does each contribute?
We NeedATM
Machines Banking at night
Too much waiting
Privacy when banking
Banki
ng in a
irports
More
ban
king lo
catio
ns
Bank
telle
rs to
o cost
ly
Our Customer’sStated Problem:
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 12
Focus on the Largest Contributors
Rank in order and use the 80-20 Rule to focus on the top contributing causes to address the greatest portion of the problem.
05
101520253035404550
Contributing Causes
Banking at Night
More banking locations
Banking at airport
Tellers too costly
Privacy while banking
Other Reasons
Pareto Diagram
% C
on
trib
uti
on
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 13
Exercise: What Problem Are We Solving?
What is the “problem behind the problem” for our class project?
Which of these causes contribute most to the identified problem?Pick the largest contributor and repeat (putting this item at the head of the fishbone) until the most significant root causes are identified.
What the customer
believes to be the problem
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 14
Exercise: Step 2. Identify the Stakeholders
A stakeholder is anyone who is materially affected by the outcome of the system.
Which stakeholders will be actors in our system?
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 15
Step 3. Define the System Boundaries
LegacySystem
Communications Reports
New System
Other SystemsOther SystemsUsers
Maintenance
Which of these will be actors in
our system?
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 16
Actor
Use Actors to Help Define System Boundaries
An actor is A user of the system Outside the system
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 17
Example: Actors Help Determine System Boundaries
PC
Systemboundary?
Server
PC
PC
PC
Is the client software part of the system or is the client an actor?
Server
End User
PC
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 18
Is the Answering Machine an actor or part of the system?
Example: Actors Help Define System Boundaries
Caller
System boundary?
Simple PhoneSystem
AnsweringMachine
(voice mail)
Callee
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 19
Passenger Travel Agent Airline Booking system
The passenger never touches this system; the travel agent operates it. Or perhaps you are building an Internet application ...
Internet Booking system(airline www page)Passenger
Activity: Find Actors. Who Is the Actor? Who is pressing the keys (interacting with the system)?
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 20
Withdraw Cash
SamActs as a Bank Customer
JodyActs as a Bank Customer
Instances of Actors
Use-Case model
Bank Customer
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 21
Charlie
Charlie acts as aMaintenance Crew
Charlie acts asa Cashier
A User Can Act as Several Actors
Maintenance Crew
Cashier
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 22
Actor
Useful Questions in Identifying Actors
Who will use the system? Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system
used? Who will support and maintain the system? What are the system’s external resources? What other systems will need to interact with
this one?
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 23
Exercise: Find Actors
OurSystem
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 24
Step 4. Identify Constraints
Economic
Technical
Environmental
System
Political
Feasibility
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 25
Exercise: Formulating a Problem Statement
Now, using the results of the four Problem Analysis steps just completed, let’s formulate
a Problem Statement for our class project.
The problem of (describe the problem)
affects (the stakeholders affected by the problem)
The impact ofwhich is
(what is the impact of the problem)
A successfulsolution would
(list some key benefits of a successful solution)
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 26
Activity: Capture a Common Vocabulary
Why develop a glossary? Defines terms used in the project Promotes common vocabulary
Helps prevent misunderstandings When to develop a glossary?
Start as soon as possible Continue throughout project
Glossary
RMUC Glossary and TP1: Glossary Template
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 27
Capturing Vocabulary: Make A Domain Model?
Visual model of business objects Benefits:
Formalizes the vocabulary for the project Simplifies reasoning about different terms Describes relationships between terms Provides visual representation of relationships
Savings Acct.
Bank Account
Checking Acct.
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 28
Activity: Develop Requirements Management Plan
Up-front planning helps What is in a Requirements Management Plan?
Types of requirements to collect
Types of attributes to collect Types of requirements to trace Types of documents to produce Management guidelines
TP2: RM Plan TemplateUC8: RM Plan
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 29
Defining the Problem
Don’t mistake a solution method for a problem definition
Especially if it’s your own solution method!
Gause & Weinberg, 1982
Requirements Management with Use Cases v2000Copyright © 1998, 2000 Rational Software, all rights reserved 30
Review: Analyze the Problem1. What are the four steps in problem analysis?2. How can you apply the “Pareto Principle” after
determining the root causes of your problem?3. Who are the stakeholders in your project?4. What determines the boundaries of a system?5. What boundaries must be considered when
building your product?6.How can actors be used to help determine the
boundaries of a system?7. What are some of the constraints that will be
imposed on your system?8. Why is it important to establish a glossary?