Chapter 31 Your Prescription for Requirements Management.

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

Requirements Management & Communication Chapter 4
Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
Configuration Management Managing Change. Points to Ponder Which is more important?  stability  progress Why is change potentially dangerous?
PRJ270: Essentials of Rational Unified Process
Use-case Modeling.
NJIT From Inception to Elaboration Chapter 8 Applying UML and Patterns Craig Larman.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
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.
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 30 Agile Requirements Methods. Mitigating Requirements Risk  The entire requirements discipline within the software lifecycle exists for only.
Copyright  Larry Dribin, Ph.D. SE470_EngFlows_v1.ppt SE470 EngFlows - 1 Excellence in Software Engineering Repeatable Level Defined Level Manage.
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.
From Inception to Elaboration Chapter 8 Applying UML and Patterns -Craig Larman.
Recall The Team Skills Analyzing the Problem
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Release & Deployment ITIL Version 3
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 3: Phase Management - Inception.
Chapter 30 Agile Requirements Methods. Mitigating Requirements Risk  The entire requirements discipline within the software lifecycle exists for only.
What is Business Analysis Planning & Monitoring?
Chapter 4 Requirements Engineering
RUP Requirements RUP Artifacts and Deliverables
Requirements Management with Use Cases Module 6: Define the System Requirements Management with Use Cases Module 6: Define the System.
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
RUP Fundamentals - Instructor Notes
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
Rational Unified Process Fundamentals Module 4: Disciplines II.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Identify steps for understanding and solving the
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
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.
Software Requirements Engineering: What, Why, Who, When, and How
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.
Chapter 7 Applying UML and Patterns Craig Larman
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
The Long Tail Why the future of business is selling less of more ▫ISBN = ▫Chris Anderson Low Distribution and Inventory costs allow companies.
Develop Project Charter
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
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.
Rational Unified Process Fundamentals Module 3: Disciplines I.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Team Skill 6: Building the Right System Assessing Requirements Quality (29)
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
RequisitePro Software Requirement Management Tool A peresentation by: Mojdeh Jalali-Heravi Maryam Daneshi.
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.
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Analyzing the Problem Continued and Product Features and Challenges Steve Chenoweth & Chandan Rupakheti RHIT Pages Requirements Text.
Software Testing Process
UML - Development Process 1 Software Development Process Using UML.
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.
T Iteration Demo Tikkaajat [PP] Iteration
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Project Management Processes for a Project Chapter 3 PMBOK® Fourth Edition.
Requirement Discipline Spring 2006/1385 Semester 1.
Assessing Requirements Quality in Iterative Development 1.
Agile Requirements Methods 1. Mitigating Requirements Risk  The purpose of a software method is to mitigate risks inherent in the project.  The purpose.
1 Week 5 Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
Recall The Team Skills Analyzing the Problem (with 5 steps)
Software Requirements
Guidance notes for Project Manager
Presentation transcript:

Chapter 31 Your Prescription for Requirements Management

Prescription for Requirements Management: Steps  Step 1: Get Organized  Step 2: Understand the Problem Being Solved  Step 3: Understand User and Stakeholder Needs  Step 4: Define the System  Step 5: Continuously Manage Scope and Manage Change  Step 6: Refine the System Definition  Step 7: Build the Right System  Step 8: Manage the Requirements Process

Step 1: Get Organized A.Meet with your team and agree on the basic software processes you will employ. B.Decide how you will manage requirements on the project and document this process in a short one- to two-page requirements management plan. C.Decide what types of software tooling you will apply to the project. D.Determine a configuration management plan for your code and requirements artifacts. E.Establish an iteration plan and determine the basic project metrics and reporting disciplines.

Step 2: Understand the Problem Being Solved A.Execute the five-step problem analysis process. 1. Gain agreement on the problem being solved. Write it down. 2. Understand the root cause of the problem (if applicable to your situation). 3. Identify the stakeholders and users, or actors, in your system. 4. Define the system boundary. Document the boundary and the identified stakeholders and actors in a system context diagram or preliminary use-case model. 5. Identify constraints imposed on the solution. Write them down.

Step 2: Understand the Problem Being Solved B.Circulate the problem statement to external stakeholders and insist that you gain agreement on the problem statement before moving forward.

Step 3: Understand User and Stakeholder Needs A.Create a structured interview using a generic template B.Interview 5–15 users/stakeholders identified in step 2. C.Summarize the interviews by aggregating the top 10–15 user needs. D.Use the quotes or the restated needs to start your requirements pyramid. E.Facilitate a requirements workshop for your project. 1.Run a brainstorming session to identify/refine features. 2.Perform idea reduction and feature prioritization. 3.Use the critical, important, and useful classification.

Step 3: Understand User and Stakeholder Needs F.Rerun the workshop once or twice during the project to provide a format for ongoing customer input. G.Create storyboards for all innovative concepts. Present them, propose an initial set of use cases to your users, and get user feedback. H.Ensure that your process yields early iterations that the users can test in their environment.

Step 4: Define the System A.Adopt the Vision document concept and create a template to suit your project's needs. B.Create a product position statement. Circulate it widely and make sure your customer agrees with it. C.Enter in the Vision document all features identified in step 3 and through other inputs. Trace these features back to user needs. Use attributes of priority, risk, effort, stability, and release. Define the commercial requirements (licensing, documentation, legal, regulatory, and so on) in the whole product plan.

Step 4: Define the System D.Make the Vision document be the living document for your project. Publish it for easy access and review. Use a Delta Vision document as you move forward. E.Develop the use-case model for your project so that all stakeholders can see what actors the system supports and how it supports them.

Step 5: Continuously Manage Scope and Manage Change A.Based on effort estimates from the team, determine the baseline for each release in the Vision document, using an attribute of "version number." B.Get customer agreement on scope. Help the team make the hard scope decisions and get the decisions behind you. C.Preach and teach iterative development. Build iterations monthly or weekly. Communicate and manage expectations everywhere. D.Manage change by using the baseline. Use the Delta Vision document to capture all new features that arise through the normal course of events. Make sure that all suggested features are recorded so that none are lost. Empower a change control board to make the hard decisions.

Step 5: Continuously Manage Scope and Manage Change E.Install a change request management system to capture all requests for change, and ensure that all requests go through that system to the change control board.

Step 6: Refine the System Definition A.Refine the use-case model, use-case specifications, and supplementary specifications to whatever level of detail is necessary to assure that your team members are all developing the same system. B.Have the development team and test team adopt and manage this workload. Assist them with training and find them help if they need it. Use formal analysis methods only when you cannot afford to be misunderstood. C.Trace nonfunctional requirements to and from use cases and features.

Step 6: Refine the System Definition D.Ensure that you have discovered all the nonfunctional requirements for your system, including design constraints. The template you use should prompt you to make sure that you have asked the right questions.

Step 7: Build the Right System A.Engage the test department in the requirements management challenge now. Have testers involved in test planning from the beginning. Have the test team review the use cases as they are developed, and look for additional alternative flows and events. Brainstorm potential exception conditions. Develop scenarios and test cases directly from the use cases. Determine a strategy for testing nonfunctional requirements.

Step 7: Build the Right System B.Rely on the use cases and use-case realizations in the design model to integrate design elements with the requirements. Use implicit traceability through the use-case realizations for impact assessment as change occurs. C.Develop regression testing processes that are as automated and efficient as possible, with the goal being the ability to fully regression test the system at every new iteration.

Step 8: Manage the Requirements Process A.The product manager or project champion should maintain responsibility for the Vision document, attend weekly reviews with the team to assess status, and set up default reports and queries to assist this effort. B.Monitor the software requirements management process to assure that the vision is fulfilled in the use-case model and in the implementation. C.Engage the quality assurance team to help monitor the requirements maintenance, change management, and test processes.

Step 8: Manage the Requirements Process D.Participate or drive the change control process, assuring that impact is assessed before significant changes are allowed into the system.

On to the Next Release!  Now, go back to (about) Step 3-E and build the next significant release of your new product or system.