1 / 95

Chapter 4: Requirements Determination

Key Ideas. Goal of the analysis phase:Truly understand the requirements of the new systemDevelop a system that addresses them -- or decide a new system isn't needed.The line between systems analysis and systems design is very blurry. Key Ideas. The first challenge is finding the right people to p

mandana
Télécharger la présentation

Chapter 4: Requirements Determination

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. Chapter 4: Requirements Determination

    2. Key Ideas Goal of the analysis phase: Truly understand the requirements of the new system Develop a system that addresses them -- or decide a new system isnt needed. The line between systems analysis and systems design is very blurry

    3. Key Ideas The first challenge is finding the right people to participate. The second challenge is collecting and integrating the information

    4. Requirements

    5. What is a Requirement Business Requirement Statement of what the system must do Focus on what the system must do, not how to do it There are 2 kinds of requirements Functional Nonfunctional

    6. Functional Requirement Defines the functions the system must carry out Specifies the process that must be performed Examples: Must search for inventory Must perform these calculations Must produce a specific report

    7. Nonfunctional Requirements Deals with how the system behaves Operational Physical/technical environment Performance Speed and reliability Security Who can use the system Cultural & Political Company policies, legal issues

    8. Requirements Definition Report that lists the functional and nonfunctional requirements All requirements must be traceable back to business requiremets

    9. THE ANALYSIS PROCESS

    10. Analysis Across Areas Analysis of the IS system is: A business task An IT task Need to balance expertise of users and analysts

    11. The SDLC Process

    12. Three Steps of the Analysis Phase Understanding the As-Is system Identifying improvement opportunities Developing the To-Be system concept

    13. Three Steps of the Analysis Phase Understanding the As-Is system To-Be derived from As-Is Cant focus just on what users want, need to understand what they need Cant focus just on dry analysis need to listen to users experience

    14. Three Steps of the Analysis Phase Identifying improvement opportunities Need business and technology skills Business skills Improvements in business processes improve what we do Technology skills improve how we do it

    15. Three Steps of the Analysis Phase Developing the To-Be system concept Starts out as a fuzzy set of possible improvement ideas Refined into a viable system concept Analysis ends with a system proposal Proposal presented to approval committee in the form of a system walk-through

    16. Proposal Outline Table of contents Executive summary System request (from chapter 2) Work plan (from chapter 3) Analysis strategy Summary of analysis tasks from this chapter Recommended system Summary of system concept with justification Possibly different alternatives

    17. Proposal Outline (contd) Feasibility analysis (from chapter 2) Behavioral and structural models (from chapters 5, 6, 7) Appendices Survey results, interviews, industry reports, potential design issues etc. Anything needed to support recommendation

    18. Three Fundamental Analysis Strategies BPA Business process automation BPI Business Process Improvement BPR Business Process Reengineering

    19. BUSINESS PROCESS AUTOMATION (BPA)

    20. Business Process Automation Makes almost no changes to business processes Just makes them more efficient Improves efficiency by automating the business processes Least impact on users They do the same things, just more efficiently

    21. 1. (BPA) Understanding the As-Is System Much effort spent here To-Be system continues to support As-Is system Will be doing essentially the same things Build detailed behavioral and structural models To document As-Is system

    22. 2. (BPA) Identifying Improvement Opportunities Most improvements come from problems in the current system Two techniques for identifying improvements: Problem Analysis Root Cause Analysis

    23. Problem Analysis Problem Analysis Most commonly used Asks users to identify problems and solutions (users love to do this anyway) Very good at improving users efficiency But Rarely finds significant monetary benefits

    24. Root Cause Analysis Identify symptoms Trace each back to its causes

    25. Root Cause Analysis Root Cause Analysis Tracing symptoms to their causes Problem analysis focuses on solutions to symptoms of problems Root cause analysis focuses on the problems themselves Generate list of all problems Prioritize the list Tracing symptoms to their causes

    26. Root Cause Analysis Root Cause Analysis Users generate list of problems with As-Is system Prioritize the list Generate all possible root causes Investigate each, until true root cause is identified Look for root causes that fix more than one problem

    27. Root Cause Analysis Example

    28. 3. (BPA) Developing To-Be System Concept To-Be system is quite similar to As-Is system No real change is business processes Models of To-Be system not much different from As-Is system Often models are just copied and small changes are made

    29. BUSINESS PROCESS IMPROVEMENT (BPI)

    30. Business Process Improvement Goal is to improve the business processes Change what the users do, not just how efficiently they do it Changes to business process must be decided first Decisions to change the business processes cannot be made by the analyst

    31. 1. (BPI) Understanding the As-Is System Still need to spend significant effort to understand As-Is system The new system will support most of the As-Is system New system will do many of the same things But some processes will be very different

    32. 2. (BPI) Identifying Improvement Opportunities Focus considerable effort here Looking for improvements to business processes Users and managers actively seek out new business ideas and opportunities

    33. 2. (BPI) Identifying Improvement Opportunities Four techniques for identifying improvement opportunities Duration Analysis Activity-Based Costing Informal Benchmarking Formal Benchmarking

    34. Duration Analysis Calculate time for each process step Calculate time for overall process Compare the two If sum(time for each individual step) is much less than sum (time for overall process) Then there is a problem Will need to develop Process integration or Parallelization

    35. Duration Analysis When many different people work on small parts of the overall process Process integration Change fundamental process so fewer people work on the input Parallelization Change the process so the people can do their part at the same time

    36. Activity-Based Costing Calculate cost of each process step Consider both direct and indirect costs Identify most costly steps and focus improvement efforts on them

    37. Benchmarking Studying how other organizations perform the same business process Informal benchmarking Check with customers Pose as customers Formal benchmarking Establish formal relationship with other organization

    38. 3. (BPI) Developing To-Be System Concept A small amount of information gathering is needed To-Be system is still very similar to As-Is system But some (often very few) processes are completely reworked

    39. BUSINESS PROCESS REENGINEERING (BPR)

    40. Business Process Reengineering Fundamental rethinking and radical redesign of business processes to achieve dramatic improvements Throw away everything Start with a blank page Appealing, but very expensive and risky

    41. 1. (BPR) Understanding the As-Is System Little effort spend here Just get a basic understanding of the As-Is system Its going to be scrapped anyway

    42. 2. (BPR) Identifying Improvement Opportunities Focus is on radical improvements These are not easy to identify Need techniques that are more powerful than is BPA or BPI Need to be pushed to think outside of the box

    43. Techniques for Identifying Improvements Opportunities Outcome Analysis Breaking Assumptions Technology Analysis Activity Elimination Proxy Benchmarking Process Simplification

    44. Outcome Analysis Consider desirable outcomes from customers perspective Pretend to be the customer Consider what the organization could enable the customer to do Insurance company fixes cars

    45. Breaking Assumptions Identify fundamental business rules Systematically break each rule Identify how the the business would benefit if rule is broken Bank accepts NSF checks & draws funds from credit card

    46. Technology Analysis Analysts & managers list important and interesting technologies The group identifies How each can be applied to business The benefits of each scenario Saturn building intranet with suppliers for JIT parts delivery

    47. Activity Elimination Identify what would happen if each organizational activity were eliminated Use force-fit to test all possibilities, even though some results might be silly Mortgage company removes approval process

    48. Proxy Benchmarking List different industries that have a similar structure Look for techniques from other industries that could be applied by the organization Throw in a few radically different industries Hotel might look at: Airlines, newspapers, rock concerts

    49. Process Simplification Eliminate complexity from routine transactions Concentrate separate processes on exception handling Online course registration Handle lack of prerequisites separately

    50. 3. (BPR) Developing To-Be System Concept New system is radically different Requires extensive information gathering

    51. DEVELOPING AN ANALYSIS PLAN

    52. Developing an Analysis Plan Analysis Plan: plan for activities during the analysis phase Select analysis strategy first Determined by project sponsor It is a business decision Potential business value Project cost Breadth of analysis Risk

    53. Analysis Strategies Potential business value BPA: benefits are tactical and small BPI: potential benefits are moderate BPR: largest potential benefits

    54. Analysis Strategies Project cost BPA Narrow scope, lest expensive BPI Depending on scope, can be moderately expensive BPR Almost always very expensive

    55. Analysis Strategies Breadth of analysis The extent to which the analysis looks throughout the entire business function and beyond BPA Very narrow focus on current systems only BPI More extensive, but usually in just one narrow area BPR Broad perspective, focusing on many business processes

    56. Analysis Strategies Risk of failure due to: Being unable to complete the system The completed system being unable to deliver the business benefits BPA Low risk (same processes used) BPI Low to Moderate BPR High (completely new system)

    57. Characteristics of Analysis Strategies

    58. Avoid Classic Analysis Mistakes Reduced analysis time Solution? Use RAD and timeboxing Requirement gold-plating Unnecessary features are added Users over-specification of features Solution? Expensive requirements should be re-verified with requester Lower cost solutions should be looked at

    59. Analysis Tasks How do we do the following? Understanding the As-Is system Identifying improvements Developing a concept for To-Be system

    60. Analysis Tasks To accomplish these tasks: Need to gather information Many projects go wrong due to a poor understanding of the requirements early on

    61. 1st challenge of Info Gathering Finding the right people to participate

    62. 2nd challenge of Info Gathering Deciding how to gather the information Five techniques: Interviews Joint Application Design (JAD) Questionnaires Document Analysis Observation

    63. 1. INTERVIEWS

    64. Interviews Most commonly used technique Very natural If you need to know something, you ask someone There are 5 basic steps to interviewing

    65. Interviews -- Five Basic Steps Selecting interviewees Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up

    66. 1. Selecting Interviewees Need an interview schedule list all people to be interviewed when each will be interviewed for what purpose they will be interviewed The list may be informal or it may be part of the Analysis Plan List is based on info. needed

    67. 1. Selecting Interviewees Good to get different perspectives Managers Users Ideally, all key stakeholders Select people for political reasons Interviewing is iterative List often grows by 50% to 75 %

    68. 2. Designing Questions Don't ask for information that can be obtained elsewhere Want to show interviewee respect Will get better information anyway

    69. 2. Designing Questions

    70. Closed-Ended Questions Requires a specific answer Often multiple choice Good for specific, precise info. not "are there a lot of requests?" but "how many requests are there?" Analyst is control Doesn't uncover "why"

    71. Open-Ended Questions Leave room for elaboration Gives interviewee more control Yields more rich, deep info

    72. Probing Questions Follow-up questions For clarification Encouraged to expand answer Show your listening and interested

    73. 2. Designing Questions No one type of question is best Initially use unstructured interviews to determine As-Is system (open-ended questions) As the analyst gains knowledge, structured interviews will be used (closed-ended questions)

    74. 2. Designing Questions Unstructured interview Broad, roughly defined information Structured interview More specific information

    75. Interviewing Strategies

    76. 3. Preparing for the Interview Prepare for the interview in the same way you would for a presentation Prepare general interview plan List of question Anticipated answers and follow-ups Segues between related topics Confirm interviewee's area of knowledge Don't ask questions that can't be answered Set priorities in case of time shortage

    77. 3. Preparing for the Interview Structured Interviews with closed-ended questions take longer Don't try to "wing it" will need follow-up interviews user's don't like you to waste their time

    78. 4. Conducting the Interview Appear professional and unbiased Build rapport (and trust) with interviewee 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

    79. 4. Conducting the Interview Practical Tips Dont worry, be happy Pay attention Summarize key points Be succinct Be honest Watch body language

    80. 5. Post-Interview Follow-Up Prepare interview notes Prepare interview report within 48 hours Get buy-in from interviewee Look for gaps and new questions

    81. 2. JOINT APPLICATION DESIGN (JAD)

    82. JAD Key Ideas Allows project managers, users, and developers to work together May reduce scope creep by 50% Avoids requirements being too specific or too vague

    83. Joint Application Design (JAD) Important Roles Facilitator Scribe

    84. Joint Application Design (JAD) Setting U-Shaped seating Away from distractions Whiteboard/flip chart Prototyping tools e-JAD

    85. JAD Meeting Room

    86. The JAD Session Include 10 to 20 users Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and groundrules Facilitator activities Stay neutral Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

    87. Managing Problems in JAD Sessions Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor

    88. 3. QUESTIONNAIRES

    89. Questionnaire Steps Selecting participants Using samples of the population Designing the questionnaire More important than interview questions Prioritize questions to grab attention Distinguish between Fact-oriented questions (specific answers) Opinion questions (agree disagree scale) Test the questionnaire on colleagues

    90. Questionnaire Steps Administering the questionnaire Need to get good response rate Explain its importance & how it will be used Give expected response date Give it out in person Follow up on late returns Have supervisors follow up Promise to report results Questionnaire follow-up Send results to participants

    91. Good Questionnaire Design

    92. 4. Document Analysis

    93. Document Analysis Provides clues about the "formal" existing As-Is system Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements Do document analysis before interviews

    94. 5. Observation

    95. Observation Users/managers often dont remember everything they do Validates info gathered in other ways Behaviors change when people are watched Keep low profile, dont change the process Careful not to ignore periodic activities Weekly Monthly Annual

    96. Selecting the Appropriate Techniques

More Related