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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved About This Course 1 - Best Practices of Software Engineering 2 - Introduction to RMUC 3 - Analyze the Problem 4 - Understand Stakeholder Needs 5 - Define the System 6 - Manage the Scope of the System 7 - Refine the System Definition 8 - Manage Changing Requirements 9 - Requirements Across the Product Lifecycle Course Outline

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 4 Where Are We in The Requirements Workflow?

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 5 Analyze The Problem: Activities and Artifacts

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 6 Analyze the Problem: Focus on The Problem Problem Solution Space Problem Space Needs Features Software Requirements Test Procedures DesignUser Docs The Product To Be Built Traceability

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 9 Activity: Develop Vision Steps 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 v2000 Copyright © 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 v2000 Copyright © 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 Need ATM Machines Banking at night Too much waiting Privacy when banking Banking in airports More banking locations Bank tellers too costly Our Customer’s Stated Problem:

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 12 Focus on the Largest Contributors Rank in order and use the Rule to focus on the top contributing causes to address the greatest portion of the problem. Pareto Diagram % Contribution

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 15 Step 3. Define the System Boundaries Legacy System Communications Reports New System Other Systems Users Maintenance Which of these will be actors in our system?

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 17 Example: Actors Help Determine System Boundaries PC System boundary? Server PC Is the client software part of the system or is the client an actor? Server End User PC

Requirements Management with Use Cases v2000 Copyright © 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 Phone System Answering Machine (voice mail) Callee

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 19 PassengerTravel AgentAirline 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 20 Withdraw Cash Sam Acts as a Bank Customer Jody Acts as a Bank Customer Instances of Actors Use-Case model Bank Customer

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 21 Charlie Charlie acts as a Maintenance Crew Charlie acts as a Cashier A User Can Act as Several Actors Maintenance Crew Cashier

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 23 Exercise: Find Actors Our System

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 24 Step 4. Identify Constraints Economic Technical Environmental System Political Feasibility

Requirements Management with Use Cases v2000 Copyright © 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 of which is (what is the impact of the problem) A successful solution would (list some key benefits of a successful solution)

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 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 AccountChecking Acct.

Requirements Management with Use Cases v2000 Copyright © 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 Template UC8: RM Plan

Requirements Management with Use Cases v2000 Copyright © 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 v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 30 Review: Analyze the Problem 1. 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?