4 Systems Analysis and Design in a Changing World, Fourth Edition.

Slides:



Advertisements
Similar presentations
Slide 1 Systems Analysis and Design with UML Version 2.0 Alan Dennis, Barbara Wixom, and David Tegarden Chapter 5: Requirements Determination John Wiley.
Advertisements

Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.
Topics: Interviewing Question Type Interviewing techniques
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
2Object-Oriented Analysis and Design with the Unified Process Overview  Requirements discipline prominent in elaboration phase  Requirements discipline.
Systems Analysis and Design Kendall and Kendall Fifth Edition
Systems Requirements 10/4/2010 © Abdou Illia MIS Fall 2010.
Systems Analysis Requirements determination Requirements structuring
Systems Analysis and Design in a Changing World, Fourth Edition
Systems Analysis and Design in a Changing World, Fifth Edition
Jump to first page Chapter 2 System Analysis - Determining System Requirements.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Chapter 7 Determining System Requirements 7.1.
Chapter 5 Determining System Requirements
Chapter 4: Beginning the Analysis: Investigating System Requirements
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Chapter 4: Beginning the Analysis: Investigating System Requirements
Ways of Collecting Information Interviews Questionnaires Ethnography Joint Application Design Books and leaflets in the organization Prototypes.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.
5-1 © Prentice Hall, 2007 Chapter 5: Determining Object-Oriented Systems Requirements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 7 Slide 1 Chapter 6 Determining System Requirements.
Determining System Requirements Classes 9,10. SDLC Project Identification & Selection Project Initiation & Planning Analysis ** Logical Design Physical.
Chapter 4 Investigating System Requirements
CIS 321—IS Analysis & Design Chapter 4: Analysis— Investigating System Requirements.
BIS 360 – Lecture Five Ch. 7: Determining System Requirements.
System Analysis and Design Dr. Taysir Hassan Abdel Hamid Lecture 5: Analysis Chapter 3: Requirements Determination November 10, 2013.
2Object-Oriented Analysis and Design with the Unified Process The Requirements Discipline in More Detail  Focus shifts from defining to realizing objectives.
Modern Systems Analysis and Design Third Edition
Team-Based Development ISYS321 Determining Object- Oriented Systems Requirements.
ITCS311 Systems Analysis and Design Dr. Taher Homeed Feb 2010 Department of Computer Science College of IT University of Bahrain.
1 4 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 4 Beginning the Analysis: Investigating System Requirements.
 Describe the activities of the requirements discipline  Describe the difference between functional and nonfunctional system requirements  Describe.
Chapter 6 Determining System Requirements. 2 2 What are Requirements? “Requirements are … a specification of what should be implemented. They are descriptions.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.
Slide 1 Requirements Determination Chapter 5. Slide 2 Objectives ■ Understand how to create a requirements definition. ■ Become familiar with requirements.
Objectives Describe the activities of the requirements discipline Describe the difference between functional and nonfunctional system requirements Describe.
Ways of Collecting Information Interviews Questionnaires Ethnography Books and leaflets in the organization Joint Application Design Prototyping.
Systems Analysis and Design in a Changing World, Thursday, Feb 1.
IFS310: Module 3 1/25/2007 Fact Finding Techniques.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Information Gathering: Interactive Methods
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
Kendall & KendallCopyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall4-1 Interactive Methods to collect Information Requirements Interviewing.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 7 Determining.
IAD 2263: System Analysis and Design Chapter 3: Investigating System Requirements.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 4 Systems Requirements Determination.
Chapter 6 Determining System Requirements. Objectives:  Describe interviewing options and develop interview plan.  Explain advantages and pitfalls of.
© 2005 by Prentice Hall Chapter 6 Determining System Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph.
2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
1 Requirements Determination (Analysis) Lecture 3 Courtesy to Dr.Subhasish Dasgupta.
5-1 © Prentice Hall, 2004 Chapter 5: Determining Object-Oriented Systems Requirements Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall 5.1.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Essentials of Systems Analysis and Design Fourth Edition Joseph S. Valacich Joey F.
4 Chapter 4: Beginning the Analysis: Investigating System Requirements Systems Analysis and Design in a Changing World, 3 rd Edition.
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
Chapter 5 Determining System Requirements
Modern Systems Analysis and Design Third Edition
Chapter 5 Determining System Requirements
Chapter 5 Determining System Requirements
Essentials of Systems Analysis and Design Fourth Edition
Chapter 7 Determining System Requirements
Systems Analysis – ITEC 3155 Requirements
Chapter 4 Determining System Requirements
Systems Analysis and Design Kendall and Kendall Fifth Edition
Modern Systems Analysis and Design Third Edition
Presentation transcript:

4 Systems Analysis and Design in a Changing World, Fourth Edition

4 2 Learning Objectives u Describe the activities of the systems analysis life cycle phase u Explain the effect of business process reengineering on activities of the analysis phase u Describe the difference between functional and nonfunctional system requirements u Describe the kind of information that is required to develop system requirements u Determine system requirements through review of documentation, interviews, observation, prototypes, questionnaires, vendor research, and joint application design sessions u Discuss the need for validation of system requirements to ensure accuracy and completeness and the use of a structured walkthrough

4 3 The Analysis Phase in More Detail u Gather information u Define system requirements l Functional and nonfunctional u Prioritize requirements u Prototype for feasibility and discovery u Generate and evaluate alternatives u Review recommendations with management

4 4 Activities of the Analysis Phase and Their Key Questions

4 5 Stakeholders—The Source of System Requirements u People with interest in successful system implementation u Three primary groups of stakeholders l Users (use system) l Clients (pay for and own system) l Technical staff (ensure system operation) u Every type of stakeholder is identified by analyst

4 6 More On Users as Stakeholders u Horizontal user roles – information flow across departments u Vertical user roles – information needs of clerical staff, middle management, and senior executives l Business users perform day-to-day operations l Information users need current information l Management users need summary information l Executive users need strategic information l External users may have access to system

4 7 Techniques for Information Gathering u Analysis phase done to understand business functions and develop system requirements u Original structured approach l Create model of existing system l Derive requirements from existing system model u Current approach l Identify logical requirements for new system l Balance the review of current business functions with new system requirements

4 8 Relationship Between Information Gathering and Model Building

4 9 Themes for Information-Gathering Questions

4 10 Characteristics for Successful Requirements Determination u Question everything u Be impartial u Assume anything is possible u Pay attention to details u Reframe

4 11 Sampling Sampling is the process of systematically selecting representative elements of a population. We use sampling to make assumptions of the population as a whole. We sample to: l Contain costs l Speed up data gathering l Improve effectiveness l Reduce bias

4 12 Sampling Design To design a good sample, analysts need to: u Determine the data to be collected u Determine the population to be sampled u Choose the type of sample u Decide on the sample size (not covered)

4 13 Fact-Finding Methods u Review existing reports, forms, and procedure descriptions u Interview and discuss processes with users u Observe and document business processes u Build prototypes u Distribute and collect questionnaires u Conduct joint application design (JAD) sessions u Research vendor solutions

4 14 Review Existing Reports, Forms, and Procedure Descriptions u Source: External industry-wide professional organizations and trade publications u Source: Existing business documents and procedure descriptions within organization l Identify business rules, discrepancies, and redundancies l Be cautious of outdated material l Obtain preliminary understanding of processes l Use as guidelines/visual cues to guide interviews

4 15 Conduct Interviews and Discussions with Users u Effective way to understand business functions and rules u Time consuming and resource expensive u May require multiple sessions to l Meet all users l Understand all processing requirements u Can meet with individuals or groups of users u List of detailed questions prepared

4 16 Sample Checklist to Prepare for User Interviews

4 17 Interviewing u Planning the Interview u Conducting the Interview u Writing the Interview Report u Join Application Design (JAD)

4 18 Question Types – Open-Ended Questions Benefits u Interviewee at ease u Use interviewee vocabulary u Detail u Generate new questions u More interesting for interviewee u More spontaneity u Phrasing is easier for interviewee u Could use them when not prepared Drawbacks u May result in too much detail u Possibly lose control of interview u Response may take too much time u Appear unprepared u Appear that objectives are lacking

4 19 Question Types – Closed-Ended Questions Benefits u Save time u Easy to compare interviews u Getting to the point u Control over interview u Cover lots of ground u Getting only relevant data Drawbacks u Boring to interviewee u Lack of detail u Miss main ideas u Fail to build rapport with interviewee

4 20 Question Types – Probes u Follow-up question u Used to get more meaning out of an answer u Can be either open or closed-ended questions u Indicates that you are listening

4 21 Question Pitfalls u Avoid leading questions u Avoid double-barreled questions u Avoid ambiguity, especially in closed-ended questions u Pretest questions before use

4 22 Arranging Questions u Pyramid Structure l Open with a specific question and close with a general one l Used to warm up the interviewee l Used for reluctant interviewees u Funnel Structure l Open with a general question and close with a specific one l Easy, non-threatening way to start interview l Used when interviewee feels emotional about the topic u Diamond-shaped Structure l Uses a combination of the two approaches above l Combines strengths of two approaches l Takes longer l Keeps interviewee’s interest by using a variety of questions

4 23 Making a Record of the Interview Making an Audio Recording u Provides accurate record u You can listen and respond more rapidly u Allows better eye contact u Allows replay u Can make interviewee nervous u Difficult to locate messages on long tapes u Cost (need to transcribe tapes) Note taking u Keep the interviewer alert u Show interest in interview u Demonstrates prepareness u Lose vital eye contact u Interviewee stops when notes are taken u Cause attention to facts and little attention to feelings and opinions

4 24 Conducting the Interview (my suggestions) u Arrive early u Shake hands u Inform interviewee how you will work (note taking, recorder) u Check equipment u Start with open-ended questions to warm-up interview and get a feeling of attitudes u Cover all questions in 45 min to 1 hour interview u Reflect back to the interview u Ask if something was not covered u Summarize and give feedback

4 25 Writing the Interview Report u Write a report as soon as possibly after the interview u Note the main points of the interview and your own opinions u Review the report with the respondent at a follow- up meeting

4 26 System Requirements u New system capabilities and constraints u Functional requirements l Activities system must perform (use cases) l Based on procedures and business functions l Documented in analysis models u Nonfunctional requirements l Technical environment or performance objectives l Usability, reliability, and security requirements

4 27 Distribute and Collect Questionnaires u Limited and specific information from a large number of stakeholders u Preliminary insight into business u Not well suited for gathering detailed information u Closed-ended questions direct person answering question u Open-ended questions encourage discussion and elaboration

4 28 Conduct Joint Application Design Sessions u Expedites investigation of system requirements u Seeks to compress fact-finding, modeling, policy formation, and verification activities into shorter time frame u Critical factor is to have all important stakeholders present

4 29 Joint Application Design Participants u Session leader trained in group dynamics and JAD group facilitation u Knowledgeable business and system users and policy makers u Technical staff representatives to handle l Computer and network configurations l Operating environments l Security issues u Project team members

4 30 Joint Application Design Facilities u Conducted in special room l Limit interruptions l May be off-site u Resources l Overhead projector, white board, flip charts, work material l Electronic support (laptops) l CASE tools l Group support systems (GSS)

4 31 A JAD Facility (Figure 4-16)

4 32 What Is Prototyping? u A repetitive process in which analysts and users build a rudimentary version of an information system based on user feedback u Prototyping is good when: l Users are unclear about their requirements. l The system affects a relatively small number of users. l Designs are complex. l Communication between users and analysts needs to be strengthened. l Rapid application development tools are available.

4 33 Build Prototypes u Preliminary working model of a larger, more complex system component l Discovery, design, evolving prototypes u Prototype should be l Operative u Working model to provide “look and feel” l Focused to accomplish single objective l Quick u Built and modified rapidly with CASE tools

4 34 Validating the Requirements u Make sure gathered information is correct u Structured walkthrough l Effective means of implementing quality control early in project l Verify and validate system requirements l Review of findings from investigation and of models based on findings u Project manager responsible for system quality l Systems analyst, project manager are partners

4 35 Summary u Analysis phase activities l Gather information l Define system requirements l Prioritize requirements l Prototype for feasibility and discovery l Generate and evaluate alternatives l Review recommendations with management u Gathering system requirements l Functional and nonfunctional l Work with various stakeholders (users, clients, technical staff) u What kind of information do I need? l What are the business processes and operations? l How are the business processes performed? l What are the information requirements? u Primary information-gathering techniques l Review existing reports, forms, and procedure descriptions l Conduct interviews and discussions with users l Observe and document business processes l Build prototype working models l Distribute and collect questionnaires l Conduct JAD sessions l Research vendor solutions