Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on.

Slides:



Advertisements
Similar presentations
Systems Analysis and Design Feasibility Study. Introduction The Feasibility Study is the preliminary study that determines whether a proposed systems.
Advertisements

Chapter 3 Project Initiation
1 Problem Analysis CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 9, 2004.
Analyzing the Problem : Concepts and Techniques 3.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
The use of information systems to add value to the organization is strongly influenced by organizational structure, culture, and change Identify the value-added.
1 Team Skill 1 - Analyzing the Problem Sriram Mohan/ Steve Chenoweth 371 Ch 5 in Requirements Text.
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.
7M822 Software Requirements A Use Case Approach 14 September 2010.
1 Team Skill 1 - Analyzing the Problem (Chapters 5-7 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
Waniwatining Astuti, M.T.I
Chapter 5 Initiating and Planning Systems Development Projects
Initiating and Planning Systems Development projects
Foundation Degree IT Project Methodologies (for reference)
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
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.
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.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
From Research Prototype to Production
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 6 Initiating.
1 Requirements Engineering Southern Methodist University CSE 7316.
111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.
Software Requirements Engineering: What, Why, Who, When, and How
1 Requirements Engineering Southern Methodist University CSE 7316.
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.
Requirements Engineering Southern Methodist University CSE 7316.
1-1 System Development Process System development process – a set of activities, methods, best practices, deliverables, and automated tools that stakeholders.
Project Life Cycle – Project Initiation © Ed Green Penn State University All Rights Reserved.
Lecture 7: Requirements Engineering
Welcome to Session 3 – Project Management Process Overview
INFO 627Lecture #21 Requirements Engineering and Management INFO 627 Analyzing the Problem Glenn Booker.
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.
Developing Business/IT Solutions Chapter 12 McGraw-Hill/IrwinCopyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Software Requirements and Design Khalid Ishaq
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
1 SYS366 Lecture Requirements Gathering: Stakeholders.
Systems Development Life Cycle
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
Supply Chain Management Purchasing/Inventory/Materials.
Requirements Management with Use Cases Module 3: Analyze the Problem Requirements Management with Use Cases Module 3: Analyze the Problem.
Lecture: The Importance of Stakeholders SYS366. Identifying Requirements Objective of the requirements capture and analysis phases is to understand business.
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.
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages Requirements Text.
Main tasks of system analysis ? 1-study exit=sting information system 2-identify problem 3-spelify system requirement 4-asalysis decision ========= How.
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 6 Initiating.
Writing the Requirements
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
Principles of Information Systems Eighth Edition
Fundamentals of Information Systems, Sixth Edition
Location Planning and Analysis
Introduction to Projects
Unit 6: Application Development
Production and Operations Management
Applied Software Project Management
What is your impact pathway?
Presentation transcript:

Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on the problem definition Understand the root causes – the problem behind the problem Identify the stakeholders and the users Define the system boundary Identify the constraints to be imposed on the solution

1. Gain Agreement on the Problem Definition Write down the problem and see if everyone agrees Have the customer describe the benefits Seems simple but this step can cause much discussion and emotion

Problem Statement Format Element Description The problem of Describe the problem affects Identify stakeholders affected by the problem the result of which Describe the impact of this problem on stakeholders and business activity benefits of Indicate the proposed solution and list a few key benefits

2. Understand Root Causes Gain understanding of real problem and real causes “Root cause” analysis Total Quality Management techniques Ask people directly involved what the problems are!

Fishbone Diagram Too much scrap Inaccurate sales orders Damaged in shipment Customer returns Too much scrap Finished goods Obsolescence Other Manufacturing defects

Addressing the root cause Quality data demonstrates that many root causes are simply not worth fixing

Sales order problem statement Element Description The problem of Inaccuracies in sales orders affects Sales order personnel, customers, manufacturing, shipping, and customer service the result of which Is increased scrap, excessive handling costs, customer dissatisfaction, and decreased profitability benefits of A new system to address the problem include; Increased accuracy of sales orders at point of entry Improved reporting of sales data to management Higher profitability

3. Identify the Stakeholders and the Users Stakeholder; anyone who could be materially affected by the implementation of a new system or application Many stakeholders are users Others are indirect users Affected by the business outcomes that the system influences Non-user stakeholder needs must also be identified and addressed

Questions Who are the users of the system? Who is the customer (economic buyer) for the system? Who else will be affected by the outputs that the system produces? Who will evaluate and bless the system when it is delivered? Who will maintain the system?

Users and stakeholders of new system Other stakeholders Sales and order entry clerks MIS director and development team Sales order supervisor Chief financial officer Production control Production manager Billing clerk

4. Define the solution system boundary Boundary defines the border between the solution and the real world that surrounds the solution inputs outputs system

System boundary World divided into two parts Our system Things that interact with our system

Actors Someone or something, outside the system, that interacts with the system System boundary I/O Our solution I/O Other systems users

Finding actors Who will supply, use, or remove information from the system? Who will operate the system? Who will perform any system maintenance? Where will the system be used? Where does the system get its information?

System Perspective Sales Order clerk Legacy System With Pricing data New sales Order entry Billing clerk System boundary Shipping clerk Production foreman

5. Identify the constraints to be imposed on the solution Constraints are restrictions on the degrees of freedom we have in providing a solution Various sources of constraints Schedule ROI Budget for labor and equipment Environmental issues Operating systems and databases etc

Constraints Constraints may be given to us before we start or we may have to actively elicit them Should understand the perspective of the constraint Should understand when the constraint no longer applies to the solution The less constrained the better!

Potential system constraints Source Sample considerations Economic What financial or budgetary constraints are applicable? Are there costs of goods sold or any product pricing considerations? Are there any licensing issues? Political Are there any internal or external political issues that affect potential solutions? Interdepartmental issues? Technical Are we restricted in the choice of technologies? Are we constrained to work with existing platforms or technologies? Are we prohibited from any new technologies? Are we to use any purchased software packages?

Potential system constraints Sample considerations Source Sample considerations System Is the solution to be built on our existing systems? Must we maintain compatibility with existing solutions? What operating systems and environments must be supported? Environmental Are there environmental or regulatory constraints? Legal? Security requirements? Schedule and resources Is the schedule defined? Are we restricted to existing resources? Can we use outside labor? Can we expand resources?

Summary – 5 steps of problem analysis Gain agreement on the problem definition Understand root causes Identify stakeholders and users Identify the system boundary Identify the constraints on the system

Constraints Purpose of the product Client, customer, other stakeholders Users of the product Requirements constraints Naming conventions and definitions Relevant facts Assumptions