1 / 50

Introduction to Information Systems Analysis Systems Analysis Joint Application Development

Introduction to Information Systems Analysis Systems Analysis Joint Application Development. INFO 503 Glenn Booker. What is System Analysis?. System Analysis (logical design) is the dissection of a system into pieces (subsystems), and the study of how those pieces interact and work

Download Presentation

Introduction to Information Systems Analysis Systems Analysis Joint Application Development

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. Introduction to InformationSystems AnalysisSystems AnalysisJoint Application Development INFO 503 Glenn Booker Lecture #3

  2. What is System Analysis? • System Analysis (logical design) is the dissection of a system into pieces (subsystems), and the study of how those pieces interact and work • It is followed by System Design (Synthesis), where you take the pieces and put them back together • Terminology varies, but that’s ours! Lecture #3

  3. FAST & Systems Analysis • The FAST model covers systems analysis in the first four phases • Scope Definition: Survey and plan system scope • Problem Analysis: Study the existing system and similar ones • Requirements Analysis: Definition of requirements for the new system • Logical Design: to verify the requirements Lecture #3

  4. Systems Analysis Methods • Model-Driven Analysis Approaches • Structured Analysis • Information Engineering • Object-Oriented Analysis (OOA) • Accelerated Analysis Approaches • Discovery Prototyping • Rapid Architected Analysis Lecture #3

  5. p. 188 (122) Structured Analysis • Structured analysis focuses on examining the processes which are used by the system to model business requirements • Models include processes, inputs, outputs, and files - such as a Data Flow Diagram (DFD) • Models describe how the system responds to various actions (such as placing an order) Lecture #3

  6. Information Engineering • Information Engineering focuses more on the data for an organization, with lesser concern for processes • Develops the data model first (Entity Relationship Diagram, or ERD) then will create the process model (e.g. a DFD) and deal with communication issues • Both structured analysis and information engineering create an ERD and a DFD; the difference is which model is done first Lecture #3

  7. Object Oriented Analysis • In contrast, object oriented analysis defines objects, who may contain data • Data is only obtained or manipulated through methods • Methods are little programs, associated with a class, which perform a very specific function • Object oriented languages include C++, C#, Java, Smalltalk (the first!), and Ada Lecture #3

  8. Discovery Prototyping • Prototyping develops partial, but working, versions of a system or application • Feasibility prototyping is to test the technology’s capabilities (Is this tool capable of doing what we want?) • Discovery prototyping is to refine the requirements by presenting them visually (Is this content correct?) • Must accompany other design methods Lecture #3

  9. Rapid Architected Analysis • Uses existing systems to develop system models • May use reverse engineering to determine what the existing system does (i.e. create models from code), then improve on the existing system based on its current structure • Often involves CASE tools Lecture #3

  10. Requirements Discovery Methods • All analysis methods depend on determining system requirements, using one or more of the following methods: • Fact-Finding Techniques (see last week) • Joint Requirements Planning (JRP) • Part of Joint Application Design (JAD) • Uses trained facilitator to run a JRP workshop • Business Process Redesign Lecture #3

  11. Joint Application Development • JAD uses participative development, and complements both model-driven and accelerated development • Joint Requirements Planning (JRP) is that part of JAD which helps to define the requirements through collaborative discussion among stakeholders Lecture #3

  12. Joint Application Development • Joint Application Development (JAD) is an intense, structured group activity to reach agreement on system requirements and high level design • Like any other tool, it may be used or not • Blends disparate views to help reach agreement, and reduces fact-finding time Lecture #3

  13. JAD Champion • JAD sessions are typically all-consuming, and may take from 1-10 days • Sponsor “champions” the JAD session; • Plans the attendees • Picks the JAD Leader • Chooses the time and place of the session • Kicks off and closes the session Lecture #3

  14. JAD Leader • The JAD Leader may be an outsider who: • Can communicate well • Can negotiate and resolve conflict • Understands the business environment • Can organize and manage a group • Is impartial • Does not report to any of the JAD participants Lecture #3

  15. JAD Participants • The Leader facilitates the session • Users, analysts, and managers are common participants • Someone is appointed “scribe” to record what was discussed and distribute it quickly • IS people may help provide a sanity check of the ideas discussed Lecture #3

  16. Planning JAD • Planning a JAD session must include definition of high level scope and requirements for each session • Select a remote location for the sessions, to improve focus on the task at hand • Select participants who can contribute specific relevant knowledge Lecture #3

  17. JAD Agenda • Agenda must define the scope of discussion and how much time is allocated to each • Opening to define ground rules and expectations • Body to actually get the work done • Conclusion to summarize the key points and decisions, and remind all of unresolved issues • Stay focused, yet strive for consensus! Lecture #3

  18. JAD Benefits • Encourages ownership of the decisions reached • Reduces time for early development, primarily by working out different needs and perspectives together • May blend prototyping benefits as well Lecture #3

  19. Business Process Redesign • Business process redesign (or reengineering) focuses on improving the business processes, regardless of existing computer technology usage • Study each process for bottlenecks, value added, wasted effort, and chances for streamlining • Often adds automation of processes Lecture #3

  20. FAST Analysis Approach • Now we’ll start to outline the contents of the FAST methodology in detail • Scope Definition Phase • Problem Analysis Phase • Requirements Analysis Phase • Logical Design Phase Lecture #3

  21. Scope Definition (Study) Phase 1.1 Identify baseline problems and opportunities 1.2 Negotiate baseline scope (may be concurrent with 1.1) 1.3 Assess baseline project worthiness 1.4 Develop baseline schedule and budget 1.5 Communicate the project plan Lecture #3

  22. 1.1 Identify baseline problems and opportunities • Evaluate each problem, opportunity, and directive; write a Problem Statement • Done by system owner, user, and analysts using fact finding methods and keen interpersonal skills • Determine: urgency, visibility, benefits, priority, and optionally, possible solutions p. 196 (132) Lecture #3

  23. 1.2 Negotiate baseline scope • Determine the preliminary scope of the system and the project • Involves system owner and analysts, others as needed • Write a Prelim. Problem Statement with Scope: identify types of data and existing business functions affected, system context for interfaces, and operating locations Lecture #3

  24. 1.3 Assess baseline project worthiness • Based on the project’s Problem Statement, system owners determine if project is worth continuing • Full feasibility analysis not yet possible • Result is a Yes/No decision whether to proceed, or negotiation of the scope before approval is given Lecture #3

  25. 1.4 Develop baseline schedule and budget • Develop a project plan, containing an overall plan for the entire project, and a detailed plan for the first phase of the project (See also INFO 638) • Done by project manager • Define phases for the project, key activities for each phase, and the personnel needed Lecture #3

  26. 1.5 Communicate the project plan • Present the project plan to an executive ‘steering body’ or whoever is needed to approve it • This activity also presents the project plan (except sensitive parts) to all who will be involved in it, often via a kickoff meeting • Results in a project charter, containing the results of all previous tasks Lecture #3

  27. Problem Analysis (Study) Phase 2.1 Understand the problem domain 2.2 Analyze problems and opportunities 2.3 Analyze business processes (BPR only) 2.4 Establish system improvement objectives 2.5 Update or refine the project plan 2.6 Communicate findings and recommendations Lecture #3

  28. 2.1 Understand the problem domain • Create models of the existing system • Define the data, processes, interfaces, and geography of the existing system in 1-2 page diagrams or short descriptions • Avoid too much detail (analysis paralysis) by avoiding perfectionism • Ensure everyone agrees on the models Lecture #3

  29. 2.2 Analyze problems and opportunities • Identify every problem, opportunity (including existing good features you want to keep) and directive • This refines and expands on the earlier problem and opportunity analysis • Conduct cause and effect analysis of each problem and opportunity, without seeking a solution yet, using the PIECES structure Lecture #3

  30. 2.2 Analyze problems and opportunities • Consider what has caused each problem, and describe the effect of the problem on your business • Focus on business functions and system capabilities – no technology yet! • Define effects of new opportunities; how will they affect the system? Lecture #3

  31. 2.3 Analyze business processes • This task applies to BPR projects only • Lead by an analyst; no builders or designers • Create process analysis models (like DFD) • Show the volume of data and response or processing times • Identify bottlenecks by looking at the cost and value-added of each function • What loss if a process were removed? Lecture #3

  32. 2.4 Establish system improvement objectives • Define objectives to measure system improvement and development constraints • Predict the effect of fixing each problem, and taking advantage of each opportunity • Remember not to describe specific implementation technology (how it’s done) • Add results to the cause and effect analysis (Fig. 5-11 on page 207 (Fig. 4.12)) Lecture #3

  33. 2.4 Establish system improvement objectives • Make sure you can measure the amount of improvement or benefit • Objectives describe system success criteria • Avoid writing detailed requirements for the system at this point (“generate blah report”) • Focus on what type of system capability will be created or enhanced, and how that will help improve the business value of the system Lecture #3

  34. 2.4 Establish system improvement objectives • Avoiding specific requirements here allows more flexibility later • Identify constraints, which may be due to schedule, cost, technology, or policy (including legal directives) • The only place system technology details might belong in Fig. 5-11 (4.12) is under the constraints column Lecture #3

  35. 2.5 Update or refine the project plan • Based on better understanding of project goals and objectives, update the project plan • Re-assess the scope; determine if all objectives can be met • Re-estimate time for each activity, and refine the overall project plan • If needed, re-negotiate project scope with system owner Lecture #3

  36. 2.6 Communicate findings and recommendations • The System Improvement Objectives and Recommendations report should be written, and presented to the system owners • Summarize all analysis results so far • The owners make the final decision as to the scope of the project, or cancel it • Then communicate the decision to all affected project team members Lecture #3

  37. Requirements Analysis (Definition) Phase 3.1 Identify and express system requirements 3.2 Prioritize system requirements 3.3 Update or refine the project plan 3.4 Communicate the requirements statement Lecture #3

  38. 3.1 Identify and express system requirements • Describe all system requirements, based on system improvement objectives • Include both functional and non-functional requirements • Functional requirements are the activities and services performed by the system, such as inputs, outputs, processes, and stored data needed to meet the system objectives Lecture #3

  39. 3.1 Identify and express system requirements • For each system objective: • Identify events or inputs to which the system must respond • Identify how the inputs are processed, and what decisions need to be made • Identify outputs which result, and any other information which is produced along the way • Identify data which needs to be stored Lecture #3

  40. 3.1 Identify and express system requirements • Nonfunctional requirements are other features and constraints – performance (e.g. speed, throughput), cost, schedule, controls, documentation, training, and constraints • Look out for growth in the system scope • Introduce system architect as new analyst • Creates a draft requirements statement Lecture #3

  41. 3.2 Prioritize system requirements • Categorize requirements as mandatory, desirable, or optional, then rank each within those categories • Stage (timebox) the requirements to ensure the highest priority ones are built first • Define system version history to implement features in order of descending priority Lecture #3

  42. 3.3 Update or refine the project plan • Update the project plan to: • Reflect changes in project scope, and having prioritized requirements • Include the detailed schedule for implementation of features • Create a Requirements Statement • Get approval to proceed from owneror sponsor Lecture #3

  43. 3.4 Communicate the requirements statement • Once the requirements have been agreed upon, communicate them to affected members of the project team and the user or customer community (if applicable) Lecture #3

  44. Requirements Management • Requirements are never static! • Need to have clear processes for managing requirements • Is it a new requirement, or refinement of an old one? • Analyzing and prioritizing new requirements • Approving new requirements • Communicating new requirements Lecture #3

  45. Logical Design Phase • [Is part of Requirements Analysis phase in 4th edition of text] 4.1a Structure functional requirements and/or 4.1b Prototype functional requirements 4.2 Validate functional requirements 4.3 Define acceptance test cases Lecture #3

  46. 4.1a Structure functional requirements • Create a logical (essential) model of the proposed system • Often use existing models as foundation for the new ones • May need to create data, process, interface, and distribution models; or object models, depending on the analysis strategy Lecture #3

  47. 4.1b Prototype functional requirements • Prototyping is sometimes an alternative or a prerequisite to system modeling (step 4.1a) • Typically includes preparing sample inputs and outputs, then having users review them • Usually helps most with definition of functional requirements Lecture #3

  48. 4.2 Validate functional requirements • Trace system models back to the requirements, to ensure every requirement is implemented somewhere • Also look for duplication and redundancy • Check where nonfunctional requirements apply to functional requirements • Review with owners and users Lecture #3

  49. 4.3 Define acceptance test cases • While not required this early, outlining the test cases for system testing can help verify that the requirements will fulfill the intended functions • System test cases often mimic user activities, such as use cases or scenarios • Test cases should be able to help prove whether objectives were met Lecture #3

  50. Next FAST Phases • The Decision Analysis Phase will be discussed in week 5 with the other design phases Lecture #3

More Related