390 likes | 562 Views
From Planning to Analysis. Deliverables so far: system request feasibility study project plan Next up: requirements definition (today) use cases process models data models. Systems Analysis and Information Gathering. Systems Analysis can be broken into three phases:
E N D
From Planning to Analysis • Deliverables so far: • system request • feasibility study • project plan • Next up: • requirements definition (today) • use cases • process models • data models
Systems Analysis andInformation Gathering • Systems Analysis can be broken into three phases: • understanding current (as-is) system • identifying potential improvements • developing a concept for the new (to-be) system
Objectives of Systems Analysis • System Integration: Developing a System which can readily be modified, enhanced, and data can be accessed by any new program(s).
Requirements Analysis • Key Steps in this Process: 1: Get User’s Definition of the ‘Ideal’ System 2: Modify this Definition to Accommodate Constraints 3: Trade Off Marginal Factors Against Added Costs timing depends on methodology during the project after the project (Version 1 – Version 2)
Requirements Analysis • Issues: • 1: Targeting User’s Expectations • 2: Preconceptions of the System Builders • 3: Changing Environment Over Time
Requirements Analysis • Requirements • What the new system must do ‘Computerize the lease application status process’ • Characteristics the new system must have ‘Show department currently working on a lease application from any authorized workstation’
Requirements • Business Requirements • a business process ‘handle payroll’ • System Requirements • a technical conversion of the business process ‘access pay/time data for the current period, calculate net pay, automatically direct deposit to prespecified account, and update accounts’
Requirements • Functional • relates directly to a process the system has to perform or information it needs to contain ‘retain current price data and availability on all inventory items’ • Nonfunctional • behavioral properties of a system ‘any number of users can access current price data and product availability in real time on the web’
Approaches to Analysis • The 4th edition of the textbook outlined three approaches. Each approach varies in the level of “intensity” with which change is desired: • business process automation • business process improvement • business process reengineering • The three approaches differed rather dramatically
Business Process Automation • The least “intense” form of analysis. Also cavalierly referred to as “Paving the cow path” • leaves the manual system essentially unchanged but makes processes more efficient by automating them. • Focuses on detailing the “As-is” system. Most energy is placed on understanding current system as new system is based on it. • BPA does not impact the way things are done, but rather how fast they are accomplished.
Business Process Automation • Things to think about: • Think about whether there is a root cause to the problem. By focusing on the problem rather than the solution, you may get an indication that a more revolutionary design of the system is necessary. • Question: What do you get if you automate a bad manual system?
Business Process Improvement • A notch up on the analysis “intensity” level. • This approach takes an evolutionary view of the system. • No radical changes but constant search for improvements. • Changes are made to the way things are done, not just the computer system but the business system as well.
Business Process Improvement • Things to consider: • more effort required in identifying potential opportunities. • Requires an analysis strategy and more information about alternatives. • Activity based costing • Benchmarking • Add more time when considering this improvement. Sometimes difficult to find an “end” to the project.
Business Process Reengineering • BPR = High level of “intensity” • a radical and fundamental rethinking of the business processes currently used • looking for dramatic improvements • high risk • increased time • very often associated with “downsizing”
Business Process Reengineering • Things to think about • BPR is concerned with radical change, so we need radical techniques to use BPR. • Resistance to change is highest here, because the stakes are highest.
Requirements Analysis Strategies • Problem Analysis • least intrusive • ask users and managers what the problems are and how to solve them • incremental approach • Root-Cause Analysis • deeper approach • find problems, then rather than looking to solutions, try to determine why these problems exist • typically results in a more in-depth analysis
Requirements Analysis Strategies • Duration Analysis • look at each business process and determine how long each individual activity takes • if the total time is much longer than the sum of the process durations, the activity is badly fragmented • a solution approach involves process integration or parallelization • Activity-based costing • rather than the duration, consider the cost of performing each business process • look for potential reductions or ways to streamline
Requirements Analysis Strategies • Informal Benchmarking • look to others’ performance and try to mimick ‘best of breed’ outcomes • Outcome Analysis • define success, usually in terms of the customer’s perspective and measure the ability of your system to lead to that success
Requirements Analysis Strategies • Technology Analysis • a newer approach as technology becomes more pervasive • explore how newer technologies can affect new opportunities and solutions • i.e. BYOD, microbrowsers, NFC
System Analysis Milestone: Developing an Analysis Plan • Once you have decided on the general approach to analysis you can create an analysis plan • An analysis plan outlines the activities that will be performed to understand current system, create alternatives, and suggest a new system. • For an example, see the Tune Source case at end of chapter.
Gathering Information • Chapter 3 discusses a number of methods for gathering information. These include • interviews • Joint Application Design (JAD) • Questionnaires • Document Analysis
‘Traditional’ Approaches • Interviews • time consuming • expensive • Observation • marginal value in isolation • Questionnaires • cheap, fast • low response rate • non-response bias issues • Document Analysis • important, but again not in isolation
Less Traditional • Joint Application Design (JAD) • Fast • Fuller participation • In conjunction with newer techniques: • prototyping • RAD
Interviewing: 5 steps • Select interviewees • talk to people at different levels and different perspectives. • Design questions • use more “open ended” questions to understand perceptions and usage problems • Use closed ended questions to get facts (“How many users log on to the network”)
5 Steps in Interviewing • Preparation • Over half the work in interviewing is preparation. Do your homework and make your life easy. You need to set the agenda. • Conducting the Interview • requires a particular skill set • two-way communication • glean insights • manage expectations • Follow-up • Write-up your interview and then hand it to the interviewee to read. This cuts down of confusion and protects you in a fight.
Joint Application Design (JAD) • An information gathering technique that brings together developers, managers, users, and analysts to work together to develop requirements. • A structured technique with 10-20 people and a facilitator. • JAD sessions can last a day, weeks or even months.
5 Steps for JAD • Selecting participants • should be from a number of levels , technical, and non-technical. • Designing session • How long will session last, what are he agenda items to cover • Preparing session • understand the objective of the JAD meeting (for example discussing the “As-is” or “To-be” model.
5 Steps for JAD • Conducting the session • set agenda and ground rules • look for JAD facilitator with experience. Running a good JAD is difficult. • Follow-up • sometimes necessary to provide a written report of the JAD session.
JAD Participants • Analysts • passive role except to manage unrealistic expectations
JAD Participants • Observers • to provide technical details
JAD Participants • Scribes • often replaced by technology: take notes for later consensus
JAD Participants • Session Leader • a new, professional role • qualifications are vaguely defined • good listener • organized
JAD Participants • Executive Sponsor • to add credibility to the entire exercise
JAD Participants • Users • as many as possible, cross-area representation
Questionnaires • Best use when there are a large number of people who need to contribute. • Select participants • (use random sampling (very important) • Design questionnaire • try to be clear and unambiguous. Ask important questions early in questionnaire while you have their attention. • Try to group similar questions together • remain consistent with style of question.
Questionnaires • Administering Questionnaire • response rates are generally dismal (less than 20%) • give them a reason to fill it out • minimize time needed to finish and return it. • Follow-up • provide feedback on what you have learned. People like to know that they have contributed.
Document Analysis • A critical part of analysis phase. Documents tell us a large amount about the company and the business process • Very important to understand the flow of documents and how things are done. • Documents are also essential for database design as they provide the fields and record of interest. • Many Systems Analysis tools exist to support this form of analysis
Selecting the Appropriate Technique • Each technique for gathering information has strengths and weaknesses.
Documenting the requirements • Reports (e.g. after interviews, JAD sessions) • Requirements tables - for each specific requirement • Use cases - describe system functions from the perspective of users, with their terminology • Decision tables - to document an organization’s complex business policies and decision-making rules • DFD’s and ERD’s