Srwday 03.ppt PDF

From Last day…. © Copyright 2011 John Wiley & 2-1 Sons, Inc.  How CIO select project ? – Entire portfolio – Resource – Risk levels Methodology Options – Waterfall, parallel, v-model, RAD, Agile – Which methodology to your project Estima...

From Last day…. © Copyright 2011 John Wiley & 2-1 Sons, Inc.  How CIO select project ? – Entire portfolio – Resource – Risk levels Methodology Options – Waterfall, parallel, v-model, RAD, Agile – Which methodology to your project Estimating time frame – Industry standards , Functional point approach Develop work plan – WBS Staffing – Select people, motivation, conflict management.. etc Manage scope – Scope creep, time boxing Risk Mgt © Copyright 2011 John Wiley & So ns, Inc. 3-2 Requirements Determination © Copyright 2011 John Wiley & So 3-3 ns, Inc.  Outline  The analysis phase.  Requirement determination.  Requirement elicitation techniques.  Requirement analysis strategies. © Copyright 2011 John Wiley & So 3-4 ns, Inc.  THE ANALYSIS PHASE  Analysis refers to breaking a whole into its parts with the intent of understanding the parts’ nature, functions, and interrelationships.  The planning phase deliverables are the key inputs into the analysis phase. © Copyright 2011 John Wiley & So 3-5 ns, Inc. (cont’d) The basic process of analysis involves three steps: - Understand the existing situation (the as-is system) - Identify improvements - Define the requirement for the new system (the to-be system). © Copyright 2011 John Wiley & So 3-6 ns, Inc. (cont’d)  The final deliverables of the analysis phase is the system proposal.  The system proposal is presented to the approval committee in the form of a system walk-through to explain the system in moderate detail.  The deliverables from the analysis phase are the first step in the design of the new system. © Copyright 2011 John Wiley & So 3-7 ns, Inc.  REQUIREMENTS DETERMINATION Requirements determination is performed to transform the system request’s high-level statement of business requirements into a more detailed, precise list of what the new system must do to provide the needed value to © Copyright 2011 John Wiley & So 3-8 ns, Inc.  What is a Requirement?  A requirement is a statement of what the system must do or what characteristics it needs to have.  Requirements describe -what the business needs (business requirements) -what the users need to do (user requirements) -what the software should do (functional requirements) -characteristics the system should have (non-functional requirements), and -how the system should be built (system requirements) © Copyright 2011 John Wiley & So 3-9 ns, Inc. (cont’d) Requirement Example Business Increase market share requirement User Schedule a client appointment requirement Functional Determine client availability requirement Find available openings matching client availability Select desired appointment Record appointment Confirm appointment Non-functional Operational – integrate with existing db requirement Performance – availability of the system 24/7/365 Security – who can create the appointment Culture - meetings only from Monday – 3-13 © Copyright 2011 John Wiley & So ns, Inc.  Interviews The most commonly used requirements elicitation technique Basic steps: – Selecting Interviewees – Designing Interview Questions – Preparing for the Interview – Conducting the Interview – Post-Interview Follow-up © Copyright 2011 John Wiley & So 3-17 ns, Inc.  Selecting interviewees  Interview schedule  Including people at different levels of the organization – Managers – Users – Other key stakeholders © Copyright 2011 John Wiley & So 3-18 ns, Inc. Designing interview questions © Copyright 2011 John Wiley & So 3-19 ns, Inc. (cont’d) Unstructured interview –for a broad and roughly defined set of information Structured interview – for very specific information © Copyright 2011 John Wiley & So 3-20 ns, Inc. (cont’d) Top-down vs. bottom-up interview © Copyright 2011 John Wiley & So 3-21 ns, Inc.  Preparing for the interview Prepare a general interview plan Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee – Schedule – Inform of reason for interview – Inform of areas © Copyrightof 2011discussion John Wiley & So 3-22 ns, Inc. Conducting the interview  Appear to be professional and unbiased.  Record all information.  Be sure you understand the issues that are discussed.  Separate facts from opinions.  Give interviewee time to ask questions, and brief explain what will happen next. © Copyright 2011 John Wiley & So 3-23 ns, Inc. Post-interview follow-up After the interview, the analysts needs to prepare an interview report. The report includes interview notes.  The report is sent to interviewee with a request to read it and inform the analyst © Copyright 2011 John Wiley & So 3-24 ns, Inc. Post-interview follow- up… © Copyright 2011 John Wiley & So 3-25 ns, Inc.  Questionnaires  A questionnaire is a set of written questions for obtaining information from individuals.  Selecting participants - using a sample of people who are representative of the entire group.  Designing the questionnaire – following good practice guidelines.  Administering the questionnaire – improving the©ns,Copyright response Inc. rates. 2011 John Wiley & So 3-26 (cont’d) Good questionnaire design © Copyright 2011 John Wiley & So 3-27 ns, Inc.  Document Analysis  Document analysis is used to understand the as-is system.  Forms, reports, policy manuals, organization charts describe the formal system that the organization uses.  The “real” or informal system differs from the formal one, and reveals what needs to be changed.  The indication that system needs to be changed is when users create new forms or make changes to the existing forms/reports. © Copyright 2011 John Wiley & So 3-28 ns, Inc.  Observation  Observation – the act of watching processes being performed.  It is a powerful tool to gain insight into the as-is system, and to check the validity of information gathered from other sources.  Nonetheless, people tend to be extremely careful in their behaviors when they are being watched. © Copyright 2011 John Wiley & So 3-29 ns, Inc.  Joint Application Development (JAD)  JAD is an information gathering technique that allows the project team, users, and management to work together to identify requirements for the system.  Developed by IBM in late 1970s  It can reduce scope creep by 50%,  JAD is a structure process in which 10 to 20 users meet under the direction of a facilitator skilled in JAD techniques. © Copyright 2011 John Wiley & So 3-30 ns, Inc.  Selecting participants  Selecting JAD participants in the same basic way as selecting interview participants.  Facilitator – Expert in JAD and e-JAD techniques – In many cases, the JAD facilitator is a consultant external to the organization. © Copyright 2011 John Wiley & So 3-31 ns, Inc.  Designing the JAD session and Preparing for the JAD sessions  JAD sessions can run from a half day to several weeks depending upon the size and scope of the project.  JAD success depends upon a careful plan.  Most JAD sessions are designed to collect specific information from users.  It is important to prepare the analyst and participants for the JAD session. © Copyright 2011 John Wiley & So 3-32 ns, Inc.  Conducting the JAD session  Most JAD sessions follow formal agenda and ground rules.  The JAD facilitator performs three key functions: – Keep session on track, following the agenda. – Help the group understand the technical terms and jargon. – Record group’s input on a public display area.  The facilitator must remain neutral at all time and help the group through the process. © Copyright 2011 John Wiley & So 3-33 ns, Inc.  Post JAD follow-up Postsession report is prepared and circulated among session attendees The report should be completed approximately a week to two after the JAD session © Copyright 2011 John Wiley & So 3-34 ns, Inc. © Copyright 2011 John Wiley & So 3-35 ns, Inc.  Prototyping  Once following above techniques a prototype can be developed  Then it can be evaluated with users and can get the new suggestions / solutions  Again re-design the prototype and re- evaluate  Then prototype can be used as requirement gathering tool © Copyright 2011 John Wiley & So 3-36 ns, Inc.  Selecting the Appropriate Techniques  Type of information – As-is system(mostly doc analysis/observation) – new improvements – to-be system  Depth of information – How rich and detailed the info  Breadth of information – Range of info  Integration of information – Conflicting facts and opinions  User involvement – They are cost  Cost – Users time, consultancy wages  Combining techniques © Copyright 2011 John Wiley & So 3-37 ns, Inc. (cont’d) Comparison of Requirements Elicitation Techniques © Copyright 2011 John Wiley & So 3-38 ns, Inc.  Exam Question  Point out how do you develop questionnaire to your group project with a example question – Identify existing system, and requirement of to- be-system through interviews/ JAD/ Observation / Doc Analysis – Develop sketch for to-be system – Develop clarification requirements on requirements identified – Sample: © Copyright 2011 John Wiley & So 3-39 ns, Inc. Identify Users ? Sta rt No Identify Satisfied ? Automated Identify System Who Yes Operators Missed ? End Develop Use case / Identify Prototype / Automated Snowballing System (Goodman, Administrators 1961) Identify System users and System administrators © Copyright 2011 John Wiley & So 3-40 ns, Inc.  REQUIREMENTS ANALYSIS STRATEGIES Problem Analysis  Asking users to identify problems and solutions  Improvements from problem analysis tend to be small and incremental  This type of improvements often is very effective at improving a system’s efficiency or ease of use; however, it provides minor improvements in business value. © Copyright 2011 John Wiley & So 3-41 ns, Inc.  Root Cause Analysis  Root cause analysis focuses on problems first rather than solutions. © Copyright 2011 John Wiley & So 3-42 ns, Inc.  Duration Analysis  Duration analysis requires a detailed examination of amount of time it takes to perform each process in the as-is system.  Compare the total time to complete basic steps and the total time for the overall process – a significant difference indicates that the process is badly fragmented.  Potential solutions: – Process integration Change fundamental process / use few people – Parallelization Process simultaneously / check credit whilst title check in mortgage © Copyright 2011 John Wiley & So 3-43 ns, Inc.  Activity-Based Costing  Activity-based costing examines the cost of each major process or step in a business process.  Both direct and indirect costs are considered.  The analysts identify most costly steps and focus improvement efforts on them. © Copyright 2011 John Wiley & So 3-44 ns, Inc.  Informal Benchmarking  Benchmarking refers to studying how other organizations perform a business process.  Informal benchmarking is common for “customer-facing” processes*.  The analysts visit other organizations as customers to watch how the business process is performed. * Processes that interact with the customer © Copyright 2011 John Wiley & So 3-45 ns, Inc.  Outcome Analysis  Outcome analysis focuses on understanding fundamental outcomes that provide value to customers.  Think what the organization could enable the customer to do – In an insurance company, they pay for repair but provide body repair shop / a temporary vehicle to them © Copyright 2011 John Wiley & So 3-46 ns, Inc.  Technology Analysis  Technology analysis involves two steps: 1. The analysts and managers list important and interesting technologies. 2. Then, the group identifies how each and every technology might be applied to the business and how the business would benefit. © Copyright 2011 John Wiley & So 3-47 ns, Inc.  Activity Elimination The analysts and managers work together to identify  how the organization could eliminate each and every activity in the business process,  how the function could operate without it, and  what effects are likely to occur. – No credit check for mortgage ???? – How many application rejected with the good credit notes ??? © Copyright 2011 John Wiley & So 3-48 ns, Inc.  Comparing Analysis Strategies  Each of the requirement analysis strategies has its own purpose.  No one strategy is inherently better that the others. The requirement analysis strategy should be chosen to fit the nature of the project. © Copyright 2011 John Wiley & So 3-49 ns, Inc.  SUMMARY  Analysis focuses on capturing the business requirements for the system  Requirement Determination is the part of analysis in which the project team turns the business requirements stated in the system request into a precise list of requirements.  Five Requirements Elicitation Techniques can be used to elicit business requirements.  Requirements Analysis Strategies are useful for analysts to help the business users think critically about the new system requirements. © Copyright 2011 John Wiley & So 3-50 ns, Inc. Copyright 2011 John Wiley & Sons, Inc. All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without the express written permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back- up copies for his/her own use only and not for redistribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein. © Copyright 2011 John Wiley & So 3-51 ns, Inc.