1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.

Slides:



Advertisements
Similar presentations
Inception: Starting a New Project Needs Features Vision.
Advertisements

Chapter 2.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Chapter 6 Initiating and Planning Systems Development Projects 6.1.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
Solid Palette Gradient Palette I Gradient Palette II APPLYING THESE COLORS Click on the desired color Click on the paintbrush tool located.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Modern Systems Analysis and Design Third Edition
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 1.Gain agreement on the problem definition. 2.Understand the root causes 3.Identify the.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Waniwatining Astuti, M.T.I
Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on.
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
Chapter 4 Requirements Engineering
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 4.1.
RUP Requirements RUP Artifacts and Deliverables
Requirements Management with Use Cases Module 6: Define the System Requirements Management with Use Cases Module 6: Define the System.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 4.1.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Chapter 3 Systems Planning and Selection 3.1.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Project Life Cycle – Project Initiation © Ed Green Penn State University All Rights Reserved.
Chapter 7 Applying UML and Patterns Craig Larman
Lecture 7: Requirements Engineering
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
Lecture-3.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Requirements Overview.
Rational Unified Process Fundamentals Module 3: Disciplines I.
Software Requirements and Design Khalid Ishaq
Use Case Model Use case diagram. Relevant Requirements Artifacts Use-Case Model Supplementary Specification Use-Case Specifications... Glossary Actors.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
Requirements Management with Use Cases Module 3: Analyze the Problem Requirements Management with Use Cases Module 3: Analyze the Problem.
Team Skill 1 Analyzing the Problem
NURHALIMA 1. Describe steps involved in the project initiation and planning process Explain the need for and the contents of a Statement of Work and Baseline.
Requirements Engineering Process
Problem Analysis 1. What is Problem Analysis?  The process of understanding real-world problems and user needs and proposing solutions to meet those.
Rational Requirements Management with Use Cases v 5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Requirement Engineering
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
Requirement Discipline Spring 2006/1385 Semester 1.
Requirements Management with Use Cases Module 5: Define The System To Be Built Requirements Management with Use Cases Module 5: Define The System To Be.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
Requirements Management with Use Cases Module 0: About this course Requirements Management with Use Cases Module 0: About this course.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 6 Initiating.
Systems Analysis & Design 7 th Edition Chapter 2.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
1 Team Skill 1 Analyzing the Problem … Part 1: 5 steps in Problem Analysis Based on “Software Requirements Management, A use case approach”, by Leffingwell.
Team Skill 1 - Analyzing the Problem
Business System Development
Chapter 4 Systems Planning and Selection
Introduction to Projects
Presentation transcript:

1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem

2 Objectives  Define “problem analysis” and its goal.  Describe activities for problem analysis.  Identify the stakeholders.  Gain agreement on the problem.  Find actors and define system boundaries.  Start development of the project Vision.  Define a problem statement.  Identify constraints on the project.  Establish common vocabulary.

3 Where Are We in the Requirements Discipline?

4 Analyze the Problem: Activities and Artifacts

5 Problem Analysis  Is the process of understanding real-world problems, how they relate to stakeholder needs, and proposing solutions to meet those needs.  What is the goal of problem analysis?  Gain a better understanding before development begins.  Identify root causes.  Help find the right solution. Avoid the “Yes, but…”  Minimize extra work. What is the real problem?

6 Gause & Weinberg, 1989 Definition of a Problem A problem can be defined as the difference between things as perceived and things as desired. (Problem) perceived desired

7 Problem Analysis Steps  Identify stakeholders.  Understand the root causes.  Gain agreement on the problem definition.  Identify constraints on the system or project.  Identify and validate the solution against the root causes.  Define the solution system boundary.

8 Elicit Requirements Expand stakeholder list for solution. Problem Analysis Roadmap Choose the best solution(s) to meet the goals. Best solution identified Problem validated/adjusted Business problem definedActual problem identified and defined Identify stakeholders for problem. Root cause analysis. Reassess that the solution idea is the best solution. Understand the problem in the context of the business goals. Business Problem Solution idea or Opportunity

9 Stakeholders: Definitions  Stakeholder  An individual who is materially affected by the outcome of the system or the project(s) producing the system.  Stakeholder Representative  A stakeholder representative represents one or more stakeholders. They are directly involved in the steering, shaping, and scoping of the project.

10 Identify the Stakeholders  Each group of stakeholders needs a representative.  Not all stakeholder groups need to be consulted.  Some will provide requirements. Customers, users, system administrators  Some may not provide requirements. Shareholders Who are some of the stakeholders for your projects?

11 Describe Stakeholders in the Vision Document StakeholderRegistrar RepresentativeKelly Hansen DescriptionUser TypeThe Registrar is typically a college-educated professional with full computer skills. The Registrar is trained and experienced with the use of the current batch-oriented registration. ResponsibilitiesThe Registrar is responsible for administering course registration for each school term. This includes supervising administrative and data entry personnel. Success CriteriaThe registrar’s primary responsibility will be maintaining student and professor databases, and opening/closing courses to registration. The registrar’s office will also be required to perform …. InvolvementThe registrar’s primary responsibility will be maintaining student and professor databases, and opening/closing courses to registration. The registrar’s office will also be required to perform….. DeliverablesManagement reviewer – especially related to functionality and usability of features required by the Registrar staff. Comments/ Concerns None

12 What Is the Problem Behind the Problem? Fishbone Diagram Techniques List contributing causes to the identified problem. Keep asking “Why?” (expand each rib). The perceived business problem. No Banking at night Too much waiting Want Privacy when banking Customers are dissatisfied with our service. Banking in airports Want more banking locations Queues in the branches are too long

13 Problem Analysis – Validating a Solution List the reasons why the solution is the right solution. Keep asking “Why?” (expand each rib). No Banking at night Too much waiting Customers are dissatisfied with our service We need ATMs. Banking in airports Want more banking locations Queues in the branches are too long The perceived solution to some ill-defined problem.

14 Benefit Effort 20% 80% Focus on Largest Contributors - Pareto’s Law Rank in order. Use the Rule to focus on the top contributing causes to address the greatest portion of the problem. 20% of the effort yields 80% of the benefit.

15 Understand the Broader Context of the Problem  A lack of understanding the business and its goals increases risk.  Does the problem have an organization/process component?  Does the team understand the domain in which the problem exists?  Does solving the problem present the opportunity to make process improvements?

16 Business Modeling and Requirements Disciplines The connection between disciplines. Business ModelingRequirements

17 Business Models  Model organization structure and dynamics.  Business processes  Organizational structure  Roles and responsibilities  Visualize the organization and its processes.  Help understand current problems.  Identify potential improvements.  Derive and validate system requirements needed to support the organization.  Products  Deliveries  Events

18 Exercise 4.1: Identify the Problem  Discuss the class project.  Identify and rank root causes.  Fishbone diagram

19 Describe the Problem in the Vision Document User Documentation Specifications Design Specifications Stakeholder Requests Vision Document Supplementary Specification Use-Case Model Problem Definition

20 Vision Document  Communicates information between management, marketing, and the project team.  Provides initial customer feedback.  Fosters general understanding of the product.  Establishes scope and priority of high-level stakeholder requests and features.  A system-level document that describes the “what” and “why” of the product. A document that gets “all parties working from the same book.” Vision

21 Vision Document Outline 1.Introduction 2.Positioning 3.Stakeholder and User Descriptions 4.Product Overview 5.Product Features 6.Constraints 7.Quality Ranges 8.Precedence and Priority 9.Other Product Requirements 10.Documentation Requirements 11.Appendix 1 - Feature Attributes

22 Gain Agreement on the Problem Definition Problem Statement Vision 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 business benefits of a successful solution)

23 Identify Constraints Economic Technical Environmental System Political Feasibility

24 Identify the Best Business Solution  Identify a number of solutions for the main contributing problems.  Technical, non-technical, or both.  Choose the ones that:  Best solve the root causes.  Support the business’ goals.  Gather the requirements to implement the solution.

25 Define the Solution System Boundary Maintenance Communications Reports New System Other Systems Users Legacy System

26 Actors Help Define System Boundaries PC System boundary? Server PC Is the client software part of the system or is the client an actor? Server User PC

27 Capture a Common Vocabulary  Define terms used in the project.  Help prevent misunderstandings. Glossary Capture common vocabulary Start as soon as possible. Continue throughout the project. RUCS2: Glossary

28 Visualize the Glossary With a Domain Model Trade Customer Trading Acct. Transaction ** Market transactionTransferLimit Transaction

29 Exercise 4.2: Describe the Problem  Start the Vision document.  Identify project stakeholders.  Find actors and system boundaries.  Identify constraints on the project.  Formulate a problem statement. Vision

30 Review: Analyze the Problem 1.What are the activities in problem analysis? 2.How do you gain agreement on the problem? 3.Who are the stakeholders in your project? 4.How can actors be used to help determine the boundaries of a system? 5.Why is it important to establish a glossary? 6.What should be included in a problem statement?