Waniwatining Astuti, M.T.I

Slides:



Advertisements
Similar presentations
Project management Project manager must;
Advertisements

The System Development Life Cycle
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.
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.
1 Team Skill 1 - Analyzing the Problem Sriram Mohan/ Steve Chenoweth 371 Ch 5 in Requirements Text.
Fundamentals of Information Systems, Second Edition
ESD.83Cory R. A. Hallam1 An Introduction to Systems Engineering The Art of Managing Complexity Presented By Cory R. A. Hallam B.Eng., M.Eng., ISU SSP,
1 Team Skill 1 - Analyzing the Problem (Chapters 5-7 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman.
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Systems Engineering of Software-Intensive Systems 1.
Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on.
Release & Deployment ITIL Version 3
Chapter 4 Requirements Engineering
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.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
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.
Engineering System Design
Chapter 12: Systems Investigation and Analysis. Agenda  How to Develop a CBIS?  Systems Development Life Cycle (SDLC)  Prototyping  Join Application.
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.
Software Requirements Engineering: What, Why, Who, When, and How
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.
Chapter 7: A Summary of Tools Focus: This chapter outlines all the customer-driven project management tools and techniques and provides recommendations.
Approaching a Problem Where do we start? How do we proceed?
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 3 Identification and Selection of Development Projects.
Lecture 7: Requirements Engineering
Systems Analysis and Design 8 th Edition Chapter 2 Analyzing the Business Case.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.
Lecture-3.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 1 what is systems analysis? preparation of the system’s requirements/definition,
Software Requirements and Design Khalid Ishaq
1 SYS366 Lecture Requirements Gathering: Stakeholders.
Systems Development Life Cycle
Chapter 6: THE EIGHT STEP PROCESS FOCUS: This chapter provides a description of the application of customer-driven project management.
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.
Lecture: The Importance of Stakeholders SYS366. Identifying Requirements Objective of the requirements capture and analysis phases is to understand business.
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.
Modelling the Process and Life Cycle. The Meaning of Process A process: a series of steps involving activities, constrains, and resources that produce.
Software Requirements Specification Document (SRS)
Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution Structured programming Product SW.
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.
UTA/ARRI. Enterprise Engineering for The Agile Enterprise Don Liles The University of Texas at Arlington.
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
44222: Information Systems Development
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
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.
The System Development Life Cycle
Team Skill 1 - Analyzing the Problem
Fundamentals of Information Systems, Sixth Edition
The Systems Engineering Context
Software Requirements
The System Development Life Cycle
Business Modeling.
Presentation transcript:

Waniwatining Astuti, M.T.I Analyzing the Problem

The five steps in Problem Analysis Business Modeling System engineering of software – intensive systems Development teams tend to forge ahead, proiding solutions based on an inadequate understanding of the problem to be solved.

A. The five steps in problem analysis Key points : Problem analysis is the process of understanding real – world problems and user’s needs and proposing solution to meet those needs. The goal of problem analysis is to gain a better understanding of the problem being solved, before development begins To identify the root cause, or the problem behind the problem, ask the people directly involved. Identifying the actors on the system is a key step in problem analysis.

The specific steps that must be taken in order to achieve the goal are listed below Gain agreement on the problem definition. Understand the root causes – the problem behind the problem. Identify the stakeholders and the users. Define the solution sysem boundary. Identify the constraints to be imposed on the solution.

Step 1. Gain agreement on the problem definition The problem statement Example : problem statement format element description The problem of ..... Describe the problem Affects ...... Identify stakeholders affected by the problem And results in .... Describe the impact of this problem on stakeholders and business activity Benefit of a solution .... Indicate the proposed solution and list a few key benefits.

Step 2. Understand the root causes – the problem behind the problem. Quality data demonstrates that many root causes are simply not worth fixing Fishbone diagram Pareto chart

Problem to solve & technique applied Problem to solve technique applied Lack of profitability total quality management Cost of nonconformance fishbone diagram Too much scrap pareto chart Inaccurate sales order new software solution

Step 3. Identify the stakeholders and the users The following questions can be helpfull in this process Who are the users of the system? Who is the customer (economic buyer) for the system? Who else will be affected by the outputs the system produce? Who will evaluate and approve the system when it is delivered and deployed? Are they any other internal or external users of the system whose needs must be addressed? Who will maintain the new system? Is there anyone else who cares?

Understanding the needs of the users and other stakeholders is a key factor in developing an effective solution.

Step 4. Define the solution sysem boundary. We defide the world into two interesting classes of things : Our system things that interact with our system Input system output

How do we find these actors? Here are some helpful questions to ask 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? What over external system will interact with the system?

Potential sources of system constraints Step 5. Identifying the actors on the system is a key step in problem analysis Potential sources of system constraints Economics Politics Technology Systems Environment Schedule and resources

B.Business Modeling Key Points : Business modeling is a problem analysis technique especially suitable for the IS/IT environment. The business model is used to help define systems and their applications. A business use-case model, consisting of actors and use cases, is a model of the intended functions of the business. A business object model describes the entities that deliver the functionality to realize the business use cases and how these entities interact.

Why build a system at all? Where should it be located? In these contexts, it would be helpful to have a technique to determine answers to an even broader set of questions such as the following. Why build a system at all? Where should it be located? How can we determine what functionality is optimum to locate on a particular node in the system? When should we use manual-processing steps or workarounds? When should we consider restructuring the organization itself in order to solve the problem?

The Purpose of Business Modeling In any case, the purpose of business modeling is threefold: To understand the structure and dynamics of the existing organization To ensure that customers, end users, and developers have a common understanding of the organization To understand how to deploy new systems to facilitate productivity and which existing systems may be affected by that new system

Using Software Engineering Techniques for Business Modeling With the right choice of business modeling technique, some of the work products, such as use cases and object models, will be useful in the solution activity. Business modeling is not something we recommend for every software engineering effort. Business models add the most value when the application environment is complex and multidimensional, and when many people are directly involved in using the system.

Business Modeling Using UML Concepts One of the goals of business models is to develop a model of the business that can be used to drive application development. Two key modeling constructs that can be used for this purpose are a business use-case model and a business object model.

Business use-case model A business use-case model, then, consists of business actors and business use cases, with the actors representing roles external to the business (for example, employees and customers) and the business use cases representing processes Examples of a business use-case model might be "Deliver electronic pay stub to employee." "Meet with customer to negotiate contract terms." Examples of business actors are "Customer" "Employee" "Software developer"

Business object model A business object model may also include business use-case realizations that show how the business use cases are "performed" in terms of interacting business workers and business entities. To reflect groups or departments in an organization, business workers and business entities may be grouped into organizational units.

From the Business Model to the Systems Model

C. Systems Engineering of Software-Intensive Systems Key Points Systems engineering is a problem analysis technique especially suitable for embedded-systems development. Systems engineering helps us understand the requirements imposed on software applications that run within the solution system. Requirements flowdown is primarily a matter of ensuring that all system requirements are filled by a subsystem or a set of subsystems collaborating. Today, the system design must often be optimized for software costs rather than for hardware costs.

What Is Systems Engineering? According to the International Council on Systems Engineering [INCOSE 2003]: Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations Performance Test Manufacturing Cost and Schedule Training and Support Disposal

Pragmatic Principles of Systems Engineering Systems engineering provides eight pragmatic principles. Know the problem, know the customer, and know the consumer. Use effectiveness criteria based on needs to make the system decisions. Establish and manage requirements. Identify and assess alternatives so as to converge on a solution. Verify and validate requirements and solution performance. Maintain the integrity of the system. Use an articulated and documented process. Manage against a plan.

The Composition and Decomposition of Complex Systems A system in its environment

A system composed of two subsystems

Requirements Allocation in Systems Engineering Requirements flowdown allocates system functionality to subsystems.