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.

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.
Chapter 5 – Enterprise Analysis
Designing an Architecture 1.Design Strategy Decomposition Designing to Architecturally Significant Requirements Generate and Test This generate-and test.
Inception: Starting a New Project Needs Features Vision.
Understanding User and Stakeholder Needs
1 Chapter 4 The Software Team Requisite’s 6 team skills for effective requirements management.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Chapter 4 After Green Light. After the Green Light Contractual Agreement Marketing Requirements Document (MRD) Project DefinitionBudget Project Approval.
CHAPTER 19 Building Software.
Release & Deployment ITIL Version 3
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
IT 244 Database Management System Data Modeling 1 Ref: A First Course in Database System Jeffrey D Ullman & Jennifer Widom.
Chapter 4 Requirements Engineering
Module 8: Risk Management, Monitoring and Project Control We would like to acknowledge the support of the Project Management Institute and the International.
RUP Requirements RUP Artifacts and Deliverables
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 2 Introduction to Requirements Management
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher with material from: Wiegers: Software Requirements, Chapter 5.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
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
Identify steps for understanding and solving the
Software Requirements The starting point of software development “He kept changing the requirements on us” 1 540f07reqelic4sep4.
Requirements Traceability: Planning, Tracking and Managing Requirements Presenter: Paula R. Maychruk, BV/TEd., CAPM, CBAP.
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.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
CIS 499 Senior Seminar Introduction to IT project management.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
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.
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.
Lecture-3.
Software Requirements and Design Khalid Ishaq
1 6 C H A P T E R REQUIREMENTS DISCOVERY. 2 Chapter Six Requirements Discovery Define system requirements and differentiate between functional and nonfunctional.
CS 5150 Software Engineering Lecture 7 Requirements 1.
Chapter 31 Your Prescription for Requirements Management.
Team Skill 6: Building the Right System Assessing Requirements Quality (29)
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Team Skill 1 Analyzing the Problem
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
Problem Analysis 1. What is Problem Analysis?  The process of understanding real-world problems and user needs and proposing solutions to meet those.
Smart Home Technologies
Requirement Engineering
Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages Requirements Text.
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.
Requirement Discipline Spring 2006/1385 Semester 1.
Team Skill 2 Understanding User and Stakeholder Needs The features of a Product or System (9)
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
Ondřej Přibyl L3: System Development Life Cycle page 1 Lecture 3: System Development Life Cycle Doc.Ing. Ondřej Přibyl, Ph.D. Department of applied mathematics.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
List 3 – 5 guiding principles that will serve as foundation and guide rails for the project. See slide 4 for further details ObjectivesGuiding PrinciplesKey.
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.
CS 790M Project preparation (I)
The Features of a Product or System
Team Skill 6 - Building The Right System Part 1: Applying Use Cases
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

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 stakeholders and the users. 4.Define the solution system boundary. 5.Identify the constraints 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System Definition 6. Building the Right System

The Features of a Product or System  Stakeholders and user needs  Features and examples  Attributes of features Chapter 9

Recall: The Requirements Pyramid

Stakeholder and User Needs A stakeholder need is a reflection of the business, personal, or operational problem that must be addressed in order to justify consideration, purchase, or use of a new system. The development team will build a better system only if it understands the true needs of the stakeholder. That knowledge will give the team the information it needs to make better decisions in the definition and implementation of the system.

Stakeholder and User Needs Often, these stakeholder and user needs will be vague and ambiguous. For example: "I need easier ways to understand the status of my inventory" "I'd like to see a big increase in the productivity of sales order entry" These statements set an important context for all the activities that follow. Therefore, it is important to spend some significant time and energy trying to understand them.

Features A feature is a service the system provides to fulfill one or more stakeholder needs. It is A High-level expressions of desired system behaviour. A convenient way to describe functionality without getting bogged down in detail. Features are often not well defined and may even be in conflict with one another. Example: “I want an increased order processing rates” and “I want to provide a far more user-friendly interface to help our new employees learn the system”

Examples of Features

Needs and Features Without an understanding of the need behind the feature, there will be a real risk. If the feature does not solve the real need for any reason, then the system may fail to meet the users' objectives even though the implementation delivered the feature they requested.

Managing the complexity of the system By picking the level of abstraction which depends on the number of features. Recommendation: for any new system or an increment to an existing one, the number of features should be between features. Although, fewer than 50 is preferred. Later on, these features will be refined to get the software requirements.

Managing the complexity of the system In This way, the information will be Small and manageable Comprehensive and complete for product definition, communication with stakeholders, Scope management and Project management Decision can be made for each feature to either Postpone to a later release, Implement immediately, Reject entirely, or Investigate further

Attributes of Features Attributes are data elements that help provide additional information about the features. They are used to relate the features to other types of project information. used to track, prioritize, and manage the features.

Attributes of Features

Key Points The development team must play a more active role in eliciting the requirements for the system. Product or system features are high-level expressions of desired system behaviour. System features should be limited to 25–99, with fewer than 50 preferred. Attributes provide additional information about a feature.