Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages 52-100 Requirements Text.

Slides:



Advertisements
Similar presentations
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 1.
Advertisements

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.
Inception: Starting a New Project Needs Features Vision.
1 Team Skill 2 Chapter 8: The Challenge of Requirements Elicitation Due to The "Yes, But" Syndrome The "Undiscovered Ruins" Syndrome The "User and the.
1 Problem Analysis CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute September 9, 2004.
1 Team Skill 4 - Team Skill 5 - Scope Refining the Systems Definition (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
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.
1 Team Skill 2 - Understanding User and Stakeholder Needs (Chapters 8-13 of the requirements text) CSSE 371, Software Requirements and Specification Don.
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.
1 Team Skill 1 - Analyzing the Problem (Chapters 5-7 of the requirements text) CSSE 371, Software Requirements and Specification Don Bagert, Rose-Hulman.
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.
Brainstorming Steve Chenoweth & Chandan Rupakheti RHIT Chapters 12 & 13, Requirements Text, Brainstorming Techniques document Brainstorming involves generating.
Organizing Requirements & Managing Scope (Chapters of the requirements text ) Steve Chenoweth & Chandan Rupakheti RHIT Which brings up Question 1,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Chapter 4 Requirements Engineering
S/W Project Management
RUP Requirements RUP Artifacts and Deliverables
Team Skill 1 - Analyzing the Problem Steve Chenoweth & Sriram Mohan Pages 43 – 52 in Requirements Text.
ABET’s coming to Rose! Your involvement Monday, Nov 5, 2012.
Why use RequisitePro RequisitePro is a comprehensive tool that supports any of today's requirements management processes. The predominant requirements.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
Software Requirements The starting point of software development “He kept changing the requirements on us” 1 540f07reqelic4sep4.
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.
How to start Milestone 1 CSSE 371 Project Info There are only 8 easy steps…
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
CPSC 372 John D. McGregor Module 2 Session 1 More on requirements and the Investment Decision.
BTS330: Business Requirements Analysis using OO Lecture 7: Understanding User Requirements.
Traceability, Change and Quality – Chapters Requirements Text Steve Chenoweth & Chandan Rupakheti RHIT Question 1.
1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.
Lecture-3.
1 SYS366 Week 4, Lecture 2 Requirements Part 4: Constraints, The Problem Statement.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Instructore: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Requirement engineering.
REQUIREMENTS - WHY WHAT AND HOW? Steve Chenoweth & Chandan Rupakheti CSSE 371 Chapters Requirements Text. Question 6.
Software Requirements and Design Khalid Ishaq
Team Skill 2 Understanding User and Stakeholder Needs The Challenge of Requirements Elicitation (8)
Chapter 31 Your Prescription for Requirements Management.
By Germaine Cheung Hong Kong Computer Institute
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
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
Problem Analysis 1. What is Problem Analysis?  The process of understanding real-world problems and user needs and proposing solutions to meet those.
1 Team Skill 2 - Understanding User and Stakeholder Needs (Chapters 8-13 of the requirements text) Sriram Mohan.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Requirement Engineering
Requirements Analysis
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.
Software Requirements and Design Class 4 Khalid Ishaq.
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
Requirements in the product life cycle Chapter 7.
1 Teams Steve Chenoweth and Chandan Rupakheti. Roles  Contact Client Project Manager  Secretary  Task assigner/monitor 2.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
EXERCISE DDC 3223-SOFTWARE ENGINEERING. CHAPTER 1: INTRO.TO SOFTWARE ENG 1.Briefly explain the terms below: a)Software b)Software engineering c)Software.
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.
Principles of Information Systems Eighth Edition
Requirements Analysis Scenes
The role of the Analyst in requirements Elicitation
Software Requirements analysis & specifications
The Challenge of Requirements Elicitation
The Features of a Product or System
CSE 403, Software Engineering Lecture 2
Applying Use Cases (Chapters 25,26)
Presentation transcript:

Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages Requirements Text

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

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”

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?

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

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

A Team Exercise – We’ll Do It During Class  See quiz question on this - to write some answers ahead of time!  On the board… Identify actors for the degree planner system. What are some known or likely constraints for this system?

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

Barriers to Elicitation 1. Not getting to the people who have knowledge of value to you... Cartoon from

Three Common Barriers  “Yes, But…” Syndrome Develop techniques to get rid of the “But” early.  Undiscovered Ruins Syndrome “the more you find, the more you know remain” --> find the right balance  User and Developer Syndrome Communication gap between the users.

Needs  Each stakeholder will have needs that will hopefully be addressed by the new system Example: “I want to be able to advise my students more effectively.”  Needs are often ambiguous  Users may neither describe their need (Why this product is necessary) nor do they describe the requirement (What this product needs to do) “They are more abstract”

Feature  A feature is a service that the system provides to fulfill one or more stakeholder needs. Example: “This tool will allow the advisor to see the critical path in an advisee’s coursework.”  Look for needs that suggest features  When users talk about features or in other high level abstracts, make sure you understand the real need behind the requested feature.

Feature  Attributes to describe a feature Status Priority Effort Risk Stability Target release Assigned to Reason

Another Team Exercise  See quiz question on this - to write some answers ahead of time!  As a team try to identify some features for the degree planner project. (See Tuesday’s ppt, Slide 7 notes.)  Then, see if you can prioritize these – what are the three most important (in your team’s opinion)?  If there’s time, we’ll put our answers on the board, and compare.