Requirement Gathering Fall 2006/1385 Semester 1 Sharif Univ. of Tech.2 Sources Gather information on what system should do from many sources –Users –Reports.

Slides:



Advertisements
Similar presentations
Fact Finding Techniques
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.
Chapter Two Gathering Information Copyright © 2012 Pearson Education, Inc. Publishing as Prentice HallChapter2.1.
ACTIVELY ENGAGING THE STAKEHOLDER IN DEFINING REQUIREMENTS FOR THE BUSINESS, THE STAKEHOLDER, SOLUTION OR TRANSITION Requirements Elicitation.
Topics: Interviewing Question Type Interviewing techniques
ANALYSIS PHASE Systems analysis is the part of the SDLC in which to determine how the current information system functions and asses what users would like.
IS 421 Information Systems Analysis James Nowotarski 30 September 2002.
Requirements Gathering
Systems Requirements 10/4/2010 © Abdou Illia MIS Fall 2010.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design Copyright 2000 © John Wiley & Sons, Inc. All rights reserved. Slide 1 Systems.
Systems Analysis Requirements determination Requirements structuring
Gathering Information and Use Case Scenarios
Slide 1 Systems Analysis & Design CS183 Spring Semester 2008 Dr. Jonathan Y. Clark Course Website:
Jump to first page Chapter 2 System Analysis - Determining System Requirements.
Requirements Gathering. Adapted from PowerPoint Presentation for Dennis, Wixom & Tegardem, Systems Analysis and Design, John Wiley & Sons, Inc. For CSU’s.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews 2. Workshops 3. Brainstorming.
Chapter 5 Determining System Requirements
1 Gathering Baseline Requirements For Project Success (and ulcer reduction)
Slide 1 IS6112 – Application Modelling and Design.
“Thank you for agreeing to fill out our evaluation survey”
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
Systems Analysis and Design with UML Version 2.0, Second Edition
Chapter 6 Determining System Requirements
Focus groups ScWk 242 – Session 4 Slides.
PRJ566 Project Planning and Management
Data gathering. Overview Four key issues of data gathering Data recording Interviews Questionnaires Observation Choosing and combining techniques.
PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis and Design Copyright 2001 © John Wiley & Sons, Inc. All rights reserved. Slide 1.
Requirements Gathering Chapter 5 Alan Dennis, Barbara Wixom, and David Tegarden John Wiley & Sons, Inc. Slides by Fred Niederman Edited by Solomon Negash.
BIS 360 – Lecture Five Ch. 7: Determining System Requirements.
SYSTEM ANALYSIS Chapter 5.
System Analysis and Design Dr. Taysir Hassan Abdel Hamid Lecture 5: Analysis Chapter 3: Requirements Determination November 10, 2013.
1 SYS366 Week 4, Lecture 1 Introduction to Requirements Gathering: Part 3 – Getting to Software Requirements.
Modern Systems Analysis and Design Third Edition
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.
Effective Note-Taking
Slide 1 Requirements Determination Chapter 5. Slide 2 Objectives ■ Understand how to create a requirements definition. ■ Become familiar with requirements.
Intermediate 2 Software Development Process. Software You should already know that any computer system is made up of hardware and software. The term hardware.
1 SYS366 Week 5 - Lecture 1 Systems Requirements Gathering: Identifying Software Requirements.
HISTORY OF HCI REQUIREMENTS DESIGN USER CENTERED DESIGN PROCESS DATA GATHERING EVALUATION Midterm: 10/2 What do you want it to be?
IFS310: Module 3 1/25/2007 Fact Finding Techniques.
Requirements Collection By Dr. Gabriel. Requirements A requirement is any function, constraint, or property that the system must provide, meet, or satisfy.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
Team Skill 2 Understanding User and Stakeholder Needs Interviewing (10)
Slide 1 Systems Analysis and Design with UML Version 2.0, Second Edition Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination.
CS211 Slide 3-1 ADCS 21 Systems Analysis Phase Overview Systems Requirements Checklist Fact-Finding techniques Documentation (Chapter 3) SYSTEMS ANALYSIS.
4 - 1 Systems Analysis and Design, 2 nd Edition Alan Dennis and Barbara Haley Wixom John Wiley & Sons, Inc. Slides by Roberta M. Roth University of Northern.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Chapter 6 Determining System Requirements. Objectives:  Describe interviewing options and develop interview plan.  Explain advantages and pitfalls of.
Leading Effective Meetings By Jessica Kruse. Key Actions For Leading Effective Meetings  Prepare For a Focused Meeting Prepare For a Focused Meeting.
1 Week 8 - Life cycle vs Methodology IT2005 System Analysis & Design.
Conduct User Analysis Website Design With handout UseNeedsAnalysis.doc.
Slide 1 Systems Analysis and Design with UML Version 2.0, Second Edition Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination.
PRESENTER: MS. CRYSTAL WATSON DATE: OCTOBER 4, 2014 Preparing for a Successful Job Interview.
Cooper Goal-Directed Design: Practice Session Dr. Cindy Corritore Creighton University ITM 734 Fall 2005.
MBI 630: Systems Analysis and Design Toru Sakaguchi, Ph.D.
Modern Systems Analysis and Design Third Edition
Requirements Determination
Requirements Determination
Rekayasa Perangkat Lunak Part-14
Systems Analysis and Design with UML Version 2.0, Second Edition
Recall The Team Skills Analyzing the Problem (with 5 steps)
Systems Analysis and Design
Rekayasa Perangkat Lunak
Chapter 7 Determining System Requirements
Overview Characteristics for gathering requirements.
Modern Systems Analysis and Design Third Edition
Presentation transcript:

Requirement Gathering Fall 2006/1385 Semester 1

Sharif Univ. of Tech.2 Sources Gather information on what system should do from many sources –Users –Reports –Forms –Procedures

Sharif Univ. of Tech.3 Before you start gathering requirements... Identify Stakeholders. Develop a problem statement Develop a “vision” - The project vision aligns all project participants in a common and clearly expressed direction. The vision describes what the project is about and what the product could ultimately become in a perfect world. *

Sharif Univ. of Tech.4 What are some common software requirements? Business rules - “Inventory shipments come on the 25th” Budget - “We only have $1,000 for this project” Interface - “We need a web enabled sales entry system” Reports or outputs - “Stock check; monthly or weekly summaries on...” Performance - “There might be 5000 concurrent users …” Project Completion Date - “Oh, I need that next week …” Security - “Everyone must have their own login and can see..” Hardware - “We don’t want to buy additional hardware…14’’ screens will have to do.” Software - “Everything must coded in Java and XML…”

Sharif Univ. of Tech.5 Requirements Continued... Error - Embedded system for the fire sprinklers; financial. User level - “Mary has been dying to learn Windows...” System maintenance - “Jack, our stock guy, he can…” System location - “The server is located in Dallas and we connect using this here modem. Just wiggle the cord...” No subcontracting - “Due to confidentiality, we ask…”

Sharif Univ. of Tech.6 Requirements Gathering Techniques Review Existing Documents. Review current system input and outputs. Interviews. Role playing. Research Existing Solutions. Storyboarding. Prototypes. Questionnaires. Brainstorming and idea reduction. Workshop.

Sharif Univ. of Tech.7 Interviews

Sharif Univ. of Tech.8 Interviews At first you should try to find right people. This depends on what kind of information you are looking for. Grouping interview: –More effective use of time. –Enables people to hear opinions of others and to agree or disagree. –Difficulty in scheduling

Sharif Univ. of Tech.9 Interviews -- Five Basic Steps Selecting interviewees –Based on information needed –Often good to get different perspectives Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up

Sharif Univ. of Tech.10 Interview Questions Ask Open-Ended Questions. –What do you think about the current system? –What are some of the problems you face on a daily basis? Avoid asking questions like: –Why? –For what? Do not phrase questions in ways that imply a wrong or right answer Avoid asking people to describe things they don’t usually describe.

Sharif Univ. of Tech.11 Interview Preparation Steps Prepare general interview plan –List of question –Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee –Schedule –Inform of reason for interview –Inform of areas of discussion Sometimes it is better not to use tape recorder. You should know the domain and also the characteristics of the interviewee.

Sharif Univ. of Tech.12 Conducting the Interview Appear professional and unbiased Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time

Sharif Univ. of Tech.13 Conducting the Interview Practical Tips Don’t worry, be happy Pay attention Summarize key points Be succinct Be honest Watch body language Listen and Listen and Listen.

Sharif Univ. of Tech.14 Post-Interview Follow-Up Prepare interview notes Prepare interview report with in 48 hours. Look for gaps and new questions Send interviewee a report to confirm the information.

Sharif Univ. of Tech.15 Questionnaires

Sharif Univ. of Tech.16Questionnaires Good for large groups An average response level is usually around 10%, if there is no threat from the boss. When you used correctly, questionnaires can be an excellent supplement to interviewing data. A user can’t tip you off to explore different problem areas with a questionnaire easily. They will want to get through with it as soon as possible, not to mention subjective answers will usually be too brief.

Sharif Univ. of Tech.17 Good Questionnaire Design Begin with non-threatening and interesting questions Group items into logically coherent sections Do not put important items at the very end of the questionnaire Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest the questionnaire to identify confusing questions Provide anonymity to respondents

Sharif Univ. of Tech.18 Storyboarding/Prototyping

Sharif Univ. of Tech.19Storyboarding/Prototyping Passive storyboards - sketches, pictures, screenshots, Powerpoint presentations, or sample outputs. Use stick figures. Active storyboards - automated slide presentation or movie describing the way the system behaves. Interactive storyboardsInteractive storyboards - require participation by the user. Throw away code. Sample interface or reporting outputs; very close to a throwaway prototype. Storyboard elements: –Who are the players –What happens to them –How it happens

Sharif Univ. of Tech.20 Storyboarding/Prototyping Continued... Don’t invest too much in the prototype. A throwaway prototype shouldn’t take more than a week to build. Customers will be intimidated to make changes if it looks to close to the real thing. If the prototype looks too good, customers will want it now or assume that you are almost done. “So you are pretty much done, right?” Have backup plans. Bring a paper version of a interactive prototype. –What prevents a client from taking your code and giving to another developer? “Here is what we want and you can do this for a better price, right?” –Hardware presentation problems - no outlet, machine lockup, screen can’t be seen by everyone, software not cooperating, etc. –Make sure the prototype is portable. Sized to fit screen. Basic colors. Can it run without special software? “Let me just load this calendar control…”