Requirements Management with Use Cases Module 5: Understand Stakeholder Needs Requirements Management with Use Cases Module 5: Understand Stakeholder Needs.

Slides:



Advertisements
Similar presentations
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.
Advertisements

Slide 1 Systems Analysis and Design with UML Version 2.0 Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination John Wiley.
Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Identifying Needs and Establishing Requirements John Thiesfeld Jeff Morton Josh Edwards.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Requirements Analysis 2. 1 Req. Capture b502.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Requirements.
IS550: Software requirements engineering Dr. Azeddine Chikh 4. Validation and management.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Chapter 11 Requirements Workshops
IIBA Denver | may 20, 2015 | Kym Byron , MBA, CBAP, PMP, CSM, CSPO
1 Requirements Elicitation Slinger Jansen. 2  1. Motivation  2. Requirements  3. Continuous RE  4. The RE Framework  7. Fundamentals of Goal Orientation.
Team Skill 2 Understanding Stakeholders Needs
Lean Supply Chain Action Learning Program September 2007.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Chapter 4 Requirements Engineering
Requirements Management with Use Cases Module 6: Define the System Requirements Management with Use Cases Module 6: Define the System.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 5: Understand Stakeholder Needs.
Requirements Analysis
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
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.
Requirements Elicitation Techniques. Interviewing and questionnaires.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Business Analysis and Essential Competencies
Concepts of Engineering and Technology Copyright © Texas Education Agency, All rights reserved.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Storyboarding 1. Purpose of Storyboarding  To gain an early reaction from users on the concepts proposed for the application.  They are an effective.
System Analysis and Design Dr. Taysir Hassan Abdel Hamid Lecture 5: Analysis Chapter 3: Requirements Determination November 10, 2013.
Requirements Engineering Requirements Elicitation Process Lecture-8.
Copyright © 2008 by Nelson, a division of Thomson Canada Limited ENTREPRENEURSHIP A PROCESS PERSPECTIVE Robert A. Baron Scott A. Shane A. Rebecca Reuber.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
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.
Interviewing 1. Goals of Interviewing  Make sure that the biases and predispositions of the interviewer do not interfere with a free exchange of information.
1 ® Mastering Requirements Management with Use Cases Understand Stakeholder Needs.
Approaching a Problem Where do we start? How do we proceed?
Lecture 7: Requirements Engineering
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Slide 1 Requirements Determination Chapter 5. Slide 2 Objectives ■ Understand how to create a requirements definition. ■ Become familiar with requirements.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Develop Project Charter
Job Analysis - Competency Modeling MANA 5322 Dr. Jeanne Michalski
Rational Unified Process Fundamentals Module 7: Process for e-Business Development Rational Unified Process Fundamentals Module 7: Process for e-Business.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Requirements Validation
Requirements Management with Use Cases Module 3: Analyze the Problem Requirements Management with Use Cases Module 3: Analyze the Problem.
Lecture 10 More Innovation SE3821 Software Requirements and Specification Dr. Rob Hasker (based on slides by Dr. Brad Dennis)
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Requirements Engineering Processes. Syllabus l Definition of Requirement engineering process (REP) l Phases of Requirements Engineering Process: Requirements.
Requirements Management with Use Cases Module 4: Understand Stakeholder Needs Requirements Management with Use Cases Module 4: Understand Stakeholder Needs.
CS223: Software Engineering Lecture 8: Requirement Engineering.
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 Gathering
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
Requirement Discipline Spring 2006/1385 Semester 1.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
1 International Institute of Business Analysis Vision: The world's leading association for Business Analysis professionals” Mission: To develop and maintain.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
4 Chapter 4: Beginning the Analysis: Investigating System Requirements Systems Analysis and Design in a Changing World, 3 rd Edition.
Investigating System Requirements
Recall The Team Skills Analyzing the Problem (with 5 steps)
Interviewing S.Vidya,AP/CSE.
How does a Requirements Package Vary from Project to Project?
Chapter 11 Requirements Workshops
Presentation transcript:

Requirements Management with Use Cases Module 5: Understand Stakeholder Needs Requirements Management with Use Cases Module 5: Understand Stakeholder Needs

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 2 Where Are We in the Requirements Discipline?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 3 Objectives: Understand Stakeholder Needs  Identify sources for needs/requirements  List problems in eliciting needs  Identify techniques to elicit needs/ requirements  Explain context-free questions  Describe a requirements workshop  Practice brainstorming techniques  Identify requirements from a customer- generated specification  Describe business modeling

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 4 Understanding Needs: Activities and Artifacts

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 5 What Are Sources for Our Requirements? Customer Users Problem Domain Domain Experts Industry Analysts Site Visits Competitive info Bug Reports Change Requests Requirement Specs Business Plans Personal Goals Business Models Analyst Partners

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 6 Moore, 1991 Time INNOVATORS Technical Influence No Money Discontinuous innovation Company specific EARLY ADOPTERS Have money Strong Influence Specific features EARLY MAJORITY Pragmatists Mission critical systems Reliability Whole product solutions LATE MAJORITY Conservatives Price sensitive Simplify Commodity Demanding LAGGARDS Skeptics Price 0% 5% 10% 15% 20% 25% 30% 35% CHASM” “Crossing the What Are the Characteristics of Our Customers? % of Target Domain Customers Technology Adoption Profile (the lifecycle of the technology)

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 7 What Problems Might Be Encountered?  Stakeholders  Do not know what they really want  Are unable to articulate what they want  Think they know what they want, but don’t recognize it when delivered  Analysts think they understand user problems better than users  Everybody believes everyone else is politically motivated

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 8 What Does this Process Look Like? Customer Development Requirements Spec Approved ! Rejected Reworked Spec Rejected Reworked again Ad hoc requirements

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 9 Techniques for Eliciting Stakeholder Needs  Interviews  Questionnaires  Role playing  Requirements workshop  Use cases  Brainstorming and idea reduction  Storyboards  Prototypes  Review of customer requirement specifications  Business models

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 10 Interviews  Provide a simple and direct technique  Gain understanding of problems and solutions  Consider all perspectives  Users  Customers  Other stakeholders

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 11 Gause & Weinberg, 1989 Context-Free Questions  High-level, abstract questions  Explore needs from stakeholder perspective  User’s problems  Potential solutions  Always appropriate  Unbiased with application or solutions knowledge  Typically posed early in a project

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 12 Gause & Weinberg, 1989 Types of Context-Free Questions  User questions  Who are the users?  What are their key responsibilities?  What are their background, capabilities, environment?  Process questions  What is the problem?  How do you currently solve the problem?  How would you like to solve the problem?  Where else can the solution to this problem be found?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 13 Gause & Weinberg, 1989 Types of Context-Free Questions  Product questions  What environment will the product encounter?  What business problems could this product create?  What are your expectations for usability? reliability?  Meta-questions  Do my questions seem relevant?  Are you the right person to answer these questions?  Are your answers requirements?  Is there anything else I should be asking you?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 14 Non-Context-Free Examples  Leading questions  You need a larger screen, don’t you?  Self answering questions  Are fifty items about right?  Controlling statements  Can we get back to my questions?  Too long and too complex  I have a three part question,... What are better questions to ask?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 15 Interview Tips  Don't ask people to describe things they don’t usually describe Example: Describe how to tie your shoes.  Avoid “Why…?” questions  Ask open-ended questions  Listen, listen, listen! TP3: Stakeholder Requests: Interview Template

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 16  1994 by Alan M. Davis Questionnaires  Give access to a wide audience  Appear scientific because of statistical analysis  Are applicable to broad markets where questions are well-defined  Can be powerful, but not a substitute for an interview  Assumptions:  Relevant questions can be decided in advance  Questions phrased so reader hears as intended

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 17  Tools and techniques  Analyst learns and performs user’s job  Analyst performs a scripted walkthrough  Advantages  Gain real insights into the problem domain  Understand problems users may face Role Playing

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 18 A Requirements Workshop  Accelerates the elicitation process  Gathers all stakeholders together for an intensive, focused period  Is guided by a facilitator  Provides opportunity for all stakeholder feedback  Presents results immediately  Provides a framework for applying other elicitation techniques

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 19 Workshops: Planning and Executing Sell the workshop Establish team Handle logistics Issue warm-up material Prepare agenda Facilitate Keep on track Record findings Summarize conclusions Synthesize findings Condense info Present to customer Determine next steps PRE WORKSHOP SESSIONPRODUCTIONFOLLOW-UP

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 20 Use-Case Model How Do Use Cases Help Elicit Needs?  Provide stakeholders’ point of view  Promote discussion: Why is the system needed?  Who will interact with the system (actors)?  What do users want to achieve by using the system (use cases)?  What interfaces should the system have?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 21 Rules for Brainstorming Brainstorming  Clearly state the objective of the session  Generate as many ideas as possible  Let your imagination soar  Do not allow criticism or debate  Mutate and combine ideas

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 22 Exercise 5.1: Utilize Brainstorming Techniques  Gather ideas for features  Clarify and organize the ideas  Condense ideas  Prioritize remaining ideas

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 23 Shurtleff ‘94 Storyboards  Movies, cartoons, and animated features all begin with storyboards that tell:  Who the players are (actors)  What happens to them  When it happens

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 24 Shurtleff ‘94 Storyboard Benefits  Help gather and refine customer requirements in a user friendly way  Encourage creative and innovative solutions  Encourage team review  Prevent features no one wants  Ensure that features are implemented in an accessible and intuitive way  Ease the interviewing process  Avoid the blank-page syndrome

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 25 Prototypes  Demonstrate some or all of the externally observable behaviors of a system  Used to:  Gain feedback on proposed solution  Demo the problem domain  Validate known requirements  Discover unknown requirements  Prototyping tools  Demo programs  Simulations

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 26 Why are Prototypes Dangerous?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 27 Why Use Prototypes?  Elicit and understand requirements  Prove and understand technology  Reduce risk  Enhance shared understanding  Improve cost and schedule estimates  Improve feature definition

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 28 Review Customer Requirement Specs  Identify requirements  Look for and label: Application behaviors Behavioral attributes Issues and assumptions  Ask the customer! requirements review

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 29 Exercise 5.2: Review System Specifications  Review the 2001 Elevator System Specifications  Look for possible requirements  Mark and number each requirement

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 30 Business Models  Model organization structure and dynamics  Business processes  Organizational structure  Roles and responsibilities  Visualize the organization and its processes  Help understand current problems  Identify potential improvements  Derive system requirements needed to support the organization  Products  Deliveries  Events

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 31 Business Models Are Input to System Requirements  Responsibilities of actors supported by the system  Business processes to automate in the system  Types of information to manage  Traceability between business and system model Traceability

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 32 Business Use-Case Model Business actor: Someone or something outside the business that interacts with the business. Business use case: A sequence of actions a business performs that yields an observable result of value to a particular business actor. Example: Business Use-Case Model for a Generic Software Solution Vendor

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 33 Mapping Guidelines: Business to System Use-Case Model  Business actor  system actor  Business worker  system actor or use case  System actor (if the worker interacts with the system)  System use case (if the worker is automated by system)  Business use case  subsystem or use case Application System or Subsystem Business Workers Business Use Cases Business Actor System Actor

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 34 Business Object Model  Shows structural elements  Business entities  Business workers  Responsibilities  Relationships  Is visualized by  Static views–the class diagram  Dynamic views–sequence diagram, collaboration diagram, and state chart diagram  Behavioral views–the activity diagram

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 35 Capture Vocabulary: Make a Domain Model  Subset of Business Object Model  Visual model of business objects  Benefits:  Formalizes the vocabulary for the project  Simplifies reasoning about different terms  Describes relationships between terms  Provides visual representation of relationships

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 36 Domain Model Example: RU e-st Market transactionTransferTrade CustomerTrading Acct. Transaction ** Limit Transaction

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 37 Eliciting Needs: Which Tools to Use? Developer Experience Customer/User Experience Low Hi Low Hi “Fuzzy problem” “Catch Up”“Mature” “Selling/Teaching” Adapted from Alan Davis  Requirements Workshop  Brainstorming  Use Cases  Interviews  Questionnaires  Role Playing  Business Modeling  Storyboarding  Prototyping  Requirement Reviews Which of these tools might you use for each quadrant of the graph?

Requirements Management with Use Cases Copyright © Rational Software, all rights reserved 38 Review: Understand Stakeholder Needs 1.What are some problems encountered in trying to understand user needs? 2.What are some elicitation techniques for understanding user needs? 3.What is the basis of the “context-free” question? 4.How can a requirements workshop accelerate the elicitation process? 5.How are use cases helpful in eliciting user needs? 6.What would you look for in a customer-generated requirement specification? 7.What is business modeling?