1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.

Slides:



Advertisements
Similar presentations
PaceSetter in HMRC Competitive Dialogue Procurement Invitation to Participate in Dialogue Supplier Outline Solution Template NB: This is intended only.
Advertisements

Inception: Starting a New Project Needs Features Vision.
NEES Project Management Workshop June 16 June 18 1 Segment 2.
Informatics 43 – April 16, Homework 1 What is the purpose and goal of each section in the document? Two audiences: non-technical users and technical.
Systems Analysis and Design 9th Edition
Chapter 2.
1 Problem Analysis CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 9, 2004.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
1 Team Skill 1 - Analyzing the Problem Sriram Mohan/ Steve Chenoweth 371 Ch 5 in Requirements Text.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
1 Team Skill 1 - Analyzing the Problem (Chapters 5-7 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman.
Analyzing the Business Case
Rose-Hulman Institute of Technology Sriram Mohan 18.September.2008 CSSE 497 Requirements Review.
7M822 Software Requirements Introduction 7 September 2010.
Waniwatining Astuti, M.T.I
Requirements Engineering
Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
RUP Requirements RUP Artifacts and Deliverables
1 BTS330 Vision & Scope. 2 IT Projects What defines project success? On time Within budget Delivers what the clients want The reality Less than 20% of.
12/28/08 - L6 ProcessesCopyright Joanne DeGroat, ECE, OSU1 The Request for Information (RFI)
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher with material from: Wiegers: Software Requirements, Chapter 5.
Team Skill 1 - Analyzing the Problem Steve Chenoweth & Sriram Mohan Pages 43 – 52 in Requirements Text.
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
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.
BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders.
Lecture: The Importance of Stakeholders.  Objective of the requirements capture and analysis phases is to understand business processes and develop requirements.
Systems Analysis and Design 8 th Edition Chapter 2 Analyzing the Business Case.
1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.
1 SYS366 Week 4, Lecture 2 Requirements Part 4: Constraints, The Problem Statement.
Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University Department of Computer Information Systems CIS 499 Yarmouk University.
Software Requirements and Design Khalid Ishaq
Chapter 7 The Practices: dX. 2 Outline Iterative Development Iterative Development Planning Planning Organizing the Iterations into Management Phases.
Requirements Engineering Lesson 2. Terminologies:  Software Acquisition is where requirement engineering significantly meets business strategy.  Software.
1 SYS366 Lecture Requirements Gathering: Stakeholders.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Requirements Management with Use Cases Module 3: Analyze the Problem Requirements Management with Use Cases Module 3: Analyze the Problem.
Initiation Project Management Minder Chen, Ph.D. CSU Channel Islands
Team Skill 1 Analyzing the Problem
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.
The Vision Document & Product Management CSSE 371, Software Requirements and Specification Steve Chenoweth, Rose-Hulman Institute September 27, 2004 In.
Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages Requirements Text.
Requirements Analysis
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
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.
Team Skill 3 - Defining the System (Chapters of the requirements text ) Sriram Mohan 1.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders.
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.
CHAPTER 2 SYSTEM PLANNING DFC4013 System Analysis & Design.
Team Skill 1 - Analyzing the Problem
CMPE 280 Web UI Design and Development August 29 Class Meeting
Unit 6 Application Design Practice Assignment.
Requirements Engineering Process
Buffalo Trace District Health Department
Systems Analysis and Design
Fishbone Diagram/ Cause & Effect Diagram
Interviewing Sriram Mohan.
Managing Change and Quality
Applied Software Project Management
CAUSE AND EFFECT DIAGRAM
Presentation transcript:

1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan

2 Outline  The five steps in problem analysis  Business modeling  System engineering issues

3

4 Problem Analysis “ the process of understanding real world problems, user needs and proposing solutions to meet those needs” “ problem is defined as the difference between things perceived and things desired” Not every problem needs a new solution

5 The Five Steps in Problem Analysis 1.Gain agreement on the problem 2.Understand the root causes 3.Identify the stakeholders 4.Define the solution system boundary 5.Identify the constraints imposed on the solution

6 Step 1: Identify Stakeholders “ anyone who can be marginally affected by the implementation of a new system or application”  Who are the users?  Who is the customer?  Who else will be affected?  Who will approve the system?  Who will maintain the system? Who else cares?

Team Work  As a team try to identify stakeholders for our sample project. I will be the client as far as the sample project is concerned, you can question me for 5 minutes and at the end of 10 minutes, type in your answers in a word document and turn it in using Angel (Lessons – Week 01 – Day 02 – Stakeholder Drop Box) 7 05

8 Step 2: Agree on the Problem  Write the problem statement A problem statement is the problem to be solved, written in a standardized format It helps to know the benefits the proposed system will offer from a customers perspective. There may be more than one statement.

9 One Format for Problem Statements  The problem of: A description of the problem solved by the system  Affects: The people affected by this new system  And results in: The impact of the problem on stake-holders  Solution Benefits: Indicate the solution and list a few benefits

Elevator Statement  According to Wikipedia In business jargon an elevator statement (or elevator pitch) is a short concise and compelling statement about a business or a business situation that can be delivered in the time it takes for an imaginary elevator ride. 10

Team Work  Download the template from Angel. (Lesson – Week 2 – Day 2). Once you are done drafting the problem statement and the elevator statement, turn it back in using Angel (Lesson – Week 01 – Day 02 – Problem Statement Drop Box). You have 10 minutes. 11

12 Step 3: Find Root Causes  How do you find problems and their causes? Don’t Assume “ ask and ask again ”

Fishbone or Ishikawa (Kaoru Ishikawa) diagrams Problem in head of fish Draw major bones for different aspects or viewpoints Draw causes as smaller bones (recursively) 13

14 An Example Fishbone Diagram Lousy Meals Same old every day Lousy cooks Too far from suppliers Lousy kitchen Poor education Poor attitude Have to get up early Underpaid

Tool for Drawing Fish Bone Diagrams  15

16 Step 4: Define Boundaries “define the boundary between the solution and the real world”  Draw a picture: Solution system is a black box in the middle of the picture Users of the software are shown Systems that interact with the solution are also shown Users and interacting systems are collectively known as “Actors”

17 Here Are Some Actors Source: Rose-Hulman Drama Club website

Actors Can Also Be Something Rather Than Someone

19 Some Questions to ask  Who will supply, use or remove information from the system?  Who will operate the system?  Who will perform system maintenance?  Where will the system be used?  Where does the system get its information?  What other external systems will interact with this system?

20 Step 5: Identify Constraints “ A restriction on the degree of freedom we have in providing a solution” Frequently-Used Constraint Classifications Economics Politics Technology Existing Systems Environment Schedule and Resources

21 Two Domain-Specific Problem Analysis Techniques  Business Modeling Information Systems/IT domain  Systems Engineering Embedded systems domain