C H A P T E R

1. 1

2. 2 Chapter Five Systems Analysis Define systems analysis and relate the term to the Preliminary Analysis (preliminary investigation, problem analysis), requirements analysis, and decision analysis phases of the systems development methodology. Describe a number of systems analysis approaches for solving business system problems. Describe the Preliminary Analysis, Requirements Analysis, and decision analysis phases in terms of your information system building blocks. Describe the Systems Analysis phases in terms of purpose, participants, inputs, outputs, techniques, and steps. NOTE: This chapter teaches only the process of systems analysis. The tools and techniques will be taught in the subsequent five chapters. No additional notesNo additional notes

3. 3 Chapter Map No additional notesNo additional notes

4. 4 Systems Analysis vs. Systems Design Systems Analysis is a problem-solving technique that decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact to accomplish their purpose. Systems Design (also called systems synthesis) is a complementary problem-solving technique (to systems analysis) that reassembles a system�s component pieces back into a complete system�hopefully, an improved system. This may involves adding, deleting, and changing pieces relative to the original system. The Hows and the Whats Problem-based; Solution-based.

5. 5 Systems Analysis and Design Systems Analysis - early phases of software development. All about Problem Solving!!! Systems Analysis is defined as those development phases in a project that primarily focus on the business problem, independent of any technology to implement a solution to that problem. No industry-wide total acceptance of a definition of systems analysis or design either. Systems Analysts serve as facilitators of systems analysis.

6. 6 Context of Systems Analysis

7. 7 Repository A Repository is a location (or set of locations) where systems analysts, systems designers, and system builders keep all of the documentation associated with one or more systems or projects. Will contain all your materials � even worksheets used for decision making�. No additional notesNo additional notes

8. 8 Model-Driven Analysis Methods Common approaches to solving problem include structured analysis, information engineering, object-oriented analysis, and rapid-application development (prototyping). The first three of these are Model-Driven Approaches to Analysis. Model-driven analysis emphasizes the drawing of pictorial system models to document and validate both existing and/or proposed systems. Ultimately, the system model becomes the blueprint for designing and constructing an improved system. A model is a (graphical) representation of either reality or vision. Just as �a picture is worth a thousand words,� most models use pictures to represent the reality or vision. Nowadays almost always accommodated by automated tools.

9. 9 Model-Driven Methods � Example 1 Structured Analysis is a model-driven, process-centered technique used to either analyze an existing system, define business requirements for a new system, or both. The models are pictures that illustrate the system�s component pieces: processes and their associated inputs, outputs, and files. . still one of the most widely used approaches today!!! . Emphasis is on the Process Building Blocks � always been the primary focus. . Building blocks are processes and these are modeled by Data Flow Diagrams (DFDs) . Show Processes and their inputs, outputs and files. . Processes are ultimately implemented as programs. 

10. 10 More on Structured Analysis� Because of renewed emphasis on business process redesign, DFDs are studying their fundamental processes to improve throughput, performance, and customer service while reducing waste and other inefficiencies. DFDs are used to model business processes and data flow. Information engineering is more complex and comprehensive than the oversimplified presentation in this edition�s chapter. Few organizations that still practice pure IE. Many organizations still practice data-driven analysis and design. 

11. 11 A Simple Process Model

12. 12 Model-Driven Approaches � Ex. 2 Information engineering (IE) is a model-driven and data-centered, but process-sensitive technique to plan, analyze, and design information systems. IE models are pictures that illustrate and synchronize the system�s data and processes. Here, data models are called Entity-Relationship diagrams IE still uses DFDs from structured analysis, but integrates and synchronizes ERDs into the process so we have data and process models. IE is data centered because it emphasizes studying and modeling of data PRIOR to that of Process and Interface. Data considerations (capture, storage, use, maintenance) actually drive the process design. <That Structured Analysis also uses ERDs is not surprising. But this approach uses ERDs AFTER process is captured.>

13. 13 A Simple Data Model

14. 14 Model-Driven Analysis � Ex. 3 Object-Oriented Analysis (OOA) is a model-driven technique that integrates data and process concerns into constructs called objects. OOA models are pictures that illustrate the system�s objects from various perspectives such as structure and behavior. OOA synthesizes data and process into objects as building blocks. Uses new concepts such as encapsulation, information hiding, inheritance, polymorphism, and more to describe the features of working with objects� Modeling technique uses models as building blocks and message-passing among objects which provide a service to each other. UML (Unified Modeling Language) is a standard for using objects and all that deals with them.

15. 15 A Simple Object Model

16. 16 Accelerated Analysis Methods vis a vis Model-Driven� Accelerated Analysis approaches emphasize the construction of prototypes to more rapidly identify business and user requirements for a new system. A prototype is a small-scale, incomplete, but working sample of a desired system. Prototypes cater to the �I�ll know what I want when I see it� thinking characteristic of many users and managers. Can evolve into operational systems � sometimes; Dangers lurk here, though. No additional notesNo additional notes

17. 17 Accelerated Analysis Modeling Discovery Prototyping�two types 1. Discovery Prototyping � is requirements prototyping identify users� business requirements by having them react to quick and dirty implementations of those requirements.e.g. Might use Microsoft Access, VB, or other prototyping technology.Danger: elegant prototypes; premature focus and commitment to design.Often very inefficient for larger databases, numbers of users, network traffic, etc.Is the preferred and recommended approach. But be aware of real dangers.

18. 18 Accelerated Analysis Modeling � Rapid Application Development (RAD) 2. Rapid Application Analysis Here, we derive system models often from existing system or prototypes Lots of Reverse Engineering from existing models� �Reverse Engineering technology reads the program code for an existing database, application program, and/or user interface and automatically generates the equivalent system model� Discovery engineering using prototypes can be reversed engineered into system models. These models can then be forward engineered using same CASE tools into robust databases that might serve enterprise-level needs. Normally software development nowadays is a blend of accelerated analysis and then model-driven approaches.

19. 19 Requirements Discovery Methods Requirements Discovery includes those techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community. Fact-finding (or information gathering) is a classical set of techniques used to collect information about system problems, opportunities, solution requirements, and priorities. Sampling - Reading quarterly reports Research - Studying a corporation�s web page Observation - Questionnaires and surveys Interviews

20. 20 Joint Application Development We are separating joint application development (JAD) into its component parts, joint requirements planning (JRP) and joint application design (also JAD). Only JRP is applicable to this chapter. Joint requirements planning (JRP) techniques use facilitated workshops to bring together all of the system owners, system users, systems analysts, and some systems designer and builders to jointly perform systems analysis.

21. 21 Business Process Redesign Methods Business Process Redesign (or business process reengineering) is the application of systems analysis methods to the goal of dramatically changing and improving the fundamental business processes of an organization, independent of information technology. Reality: most systems nowadays are horribly inefficient and wasteful. This industry-wide effort is triggered by Total Quality Management (TQM) and Continuous Process Improvement (CPI) No additional notesNo additional notes

22. 22 Business Process Redesign Some BPR focus on all business processes. After redesigning the business processes, most BPR projects then conclude by examining how information technology might best be applied to the improved business processes. This may create new information systems and application development projects to implement or support the new business processes. Sometimes BPR is needed to accompany purchase and integration of COTS. Generally, the business will have to adapt its processes to fit the software. So, an analysis of existing business processes during systems analysis is usual part of such projects.

23. 23 Systems Analysis Phases Preliminary Analysis (my term) Preliminary Investigation Phase Really a survey phases; learning� Interviewing, questionnaires, face-to-face Gap analyses, research� Problem Analysis Phase Really a �study phase� (Enter: First Deliverable) ? Requirements Analysis Phase Really, a definition / modeling phase Data Analysis and Modeling � Phase II Process Modeling � Phase III Interface Modeling - Phase IV

24. 24 Preliminary Investigation Phase Context

25. 25 Preliminary Analysis Preliminary Analysis (my preference) (lots of other terms� initial feasibility, initial study phase, problem statements and analysis, others; gathering of information; needs� My definition of Preliminary Analysis includes all the items due for your first deliverable: 1. Project Description Domain Modeling; Glossary 2. Use Case Collection Brief Description of Actions/Use Cases 3. Project Scope - preliminary 4. Project Plan - preliminary

26. 26 Preliminary Investigation activity in Preliminary Analysis Deliverable from Preliminary Investigation is the Project Charter : the four components of the Preliminary Analyses your team undertook. First, we need a formal (written) Request for Services!!! key user(s) (maybe), owners, key analyst(s) (those who REALLY know the business) I have provided this� ? Can arise in many many ways. Secondly, we need to identify the functionality that the application will solve (problem solving again�) this may consist of documented problems from existing systems (or new problems that have arisen functionally in the discipline), opportunities, directives, perceived constraints that precipitated the Request for Software Services. So, create your (Problem Statements) Use Cases.

27. 27 Sample Request for System Services

28. 28 Problem Statements

29. 29 Documenting Requirements with Use Cases A use case is a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task. An actor represents anything that needs to interact with the system to exchange information. An actor is a user, a role, which could be an external system as well as a person. Use Cases describe system functions from the perspective of external users and in the manner and terminology in which they understand. result of decomposing the scope of system functionality into many smaller statements of system functionality.

30. 30 Benefits of Using Use Cases Facilitates user involvement. A view of the desired system�s functionality from an external person�s viewpoint. An effective tool for validating requirements. An effective communication tool. Supports MANY follow on activities needed in systems analysis and design

31. 31 Example of a High-Level Use Case Author: S. Shepard Date: 03/01/2002 Use Case Name: New Member Order Actors: Member Description: This use case describes the process of a member submitting an order for Sound Stage products. On completion, the member will be sent a notification that the order was accepted. No additional notes.No additional notes.

32. 32 Author: S. Shepard Date: 10/05/2002 Use Case Name: Submit New Member Order Actor(s): Member Description: This use case describes the process of a member submitting an order for Sound Stage products. On completion, the member will be sent a notification thatthe order was accepted. References: MSS-1.0 Typical Courseof Events: Example of a Requirements Use Case

33. 33 Alternate Step 2: If the club member has indicated an address or telephone number change on theCourses: promotion order, update the club member�s record with the new information. Step 3: If Accounts Receivable returns a credit status that the customer is in arrears, send an order rejection notice to the member. Step 4: If the product number is not valid, send a notification to the member requesting them to submit a valid product number. If the product being ordered is not available, record the ordered product information and mark as �back-ordered.� Pre-condition: Orders can only be submitted by members. Post-condition: Member order has been recorded and the picking ticket has been routed to the warehouse. Assumptions: None at this time. Example of a Requirements Use Case (concluded)

34. 34 More� Domain Model / Glossary. Use Cases should be accompanied by (sometimes prior to their creation; sometimes accompanying them�) a domain model (Can be class diagram if going into OOSE) - perhaps a complete Use Case context diagram � with actors�the business model restricted to the application domain. Glossary � essential. Common definitions all agree upon. Actor Description. Every identified actor should have a brief description of the actor and his/her/its connection to the system. Actors trigger the system; The system provides the use cases. Supplementary Specifications. Statements of non-functional needs (generally declarative). Constraints (operating environment, language), regulatory issues, standards of development; paradigms, performance, usability, persistence, distribution, security�.provide the remainder (most (not all) of the non-functional requirements individually not appropriate to put into a single Use Case (often global requirements�)

35. 35 Preliminary Investigation activity in Preliminary Analysis Thirdly, Create a Preliminary Project Scope Sometimes called Statement of Work, and other name This (guaranteed!) will change later. Essential that we have a baseline starting position. Defined in terms of: (Most significant parts follow? Data that describe the system (like, Products, Orders, Customers � entities�.) Business Processes (like business processes for management, customer relations, order management, order entry, etc.) Interfaces with Users, Locations, other Systems like (customers, sales reps, sales clerks, managers, regional offices, etc.)

36. 36 Preliminary Investigation activity in Preliminary Analysis Project Scope (continued) Items from project scope can also be inferred from the domain model, from the glossary (part of Deliverable #1), Use Cases, and the supplementary specifications. Entire idea behind scope is to BOUND the system. But you need this common understanding of what the application is to provide and to whom. (Thus the domain model and glossary)

37. 37 Preliminary Investigation activity in Preliminary Analysis Fourth: Create a Project Plan Baseline Plan � update at end of each phase.. Contains schedule, resource assignments, for entire project. Plan for Next Phase � the Requirements Analysis Phase Done by project manager (for us, team leader in total coordination with team members. Team leader (here) is not in charge; rather, a �facilitator.�) OPTIONAL � Create a project website Contains project charter and links to project documentation

38. 38 End of Preliminary Investigation of Preliminary Analysis � Kickoff the System Deliverable from Preliminary Analysis are the deliverables listed earlier These contain: Project Request / Description Transmittal letter Problems Statements / Use Cases - (opportunities, directives, constraints, domain model/glossary, supplementary specification (contains standards and environment; platforms, etc.), � Project Scope � project boundaries Project Plan � for tracking and management Project may create a project website

39. 39 Problem Analysis Phase Context

40. 40 Problem Analysis Phase Goal: Study and understand the problem domain well enough to thoroughly analyze its problems, opportunities, and constraints. Sometimes detailed knowledge of current system is needed and modeled (physical DFDs) (Chapter 8) Main idea: need to be able to refine our understanding of project scope and problem statement to define a common vocabulary for the system. Generally create a Domain Model / Glossary / or Both Final Deliverable � Produce System Improvement Objectives that address problems, opportunities, and directives or alternatively a collection of revised Use Cases. Update Project Plan (in repository) if necessary. Create Domain Model (Physical DFD; Perhaps a set of Use Cases and Actors )

41. 41 Problem Analysis Phase Team Activities (as opposed to owners, �.) Really must study the problem domain in more detail Learn about current system Owners, users, analysts bring different levels of understanding to the system � different detail, vocabulary, perceptions, opinions. This is the domain within which all these improvements, opportunities, etc. exist! Very important that Users be available to the project as full-time business analysts; SMEs� Seek out the experts; get their opinions! Oftentimes, current documentation does not exist.

42. 42 Problem Analysis � Current Systems: If there is a current system: list all reports, transactions, purposes of each; frequency, descriptions business events for which a business response is currently implemented, locations of current system users (e.g. regional offices; office managers) Can be quickly done. Don�t shortchange the business vocabulary � great way for communications between developers and users. Might want short data model (single page); one or two-page functional model w/decomposition; a one-page context model or updated use-case diagrams that show the system�s inputs and outputs locally or with other organizations (interface) Stay away from �We need to�� �We want to..� which are solution-based statements. Concentrate on understanding the problems � their causes and effects in the existing system. Update Project Plan as necessary following Problem Analysis

43. 43 Problem Analysis Phase Context No additional notesNo additional notes

44. 44 Cause-and-Effect Analysis Cause-and-effect analysis is a technique in which problems are studied to determine their causes and effects. In practice, effects can be symptomatic of more deeply rooted or basic problems which, in turn, must be analyzed for causes and effects until such a time as the causes and effects do not yield symptoms of other problems. Discuss! What causes a system to be enhanced / redesigned / replaced?

45. 45 System Improvement Objectives An objective is a measure of success. It is something that you expect to achieve, if given sufficient resources. Reduce the number of uncollectible customer accounts by 50 percent within the next year. Increase by 25 percent the number of loan applications that can be processed during an eight-hour shift. Decrease by 50 percent the time required to reschedule a production lot when a workstation malfunctions. A constraint is something that will limit your flexibility in defining a solution to your objectives. Essentially, constraints cannot be changed.

46. 46 Cause-and-Effect / System Improvement Objectives No additional notesNo additional notes

47. 47 Requirements Analysis Phase Context

48. 48 Requirements Analysis Sometimes called the Definition Phase or Logical Design Phase We must define the business requirements for the solution! � No considerations of technology Sometimes, development teams are created at this time and NOW the work starts�. Some development models start with Requirements Analysis Previous work has been done; maybe backlogged. Sometimes Problem Analysis included here (if current system is a consideration � usually the case) So, we discover the WHATs of the required system. Functional Requirements may be captured in Use Cases Non-functional and other requirements captured in Supplementary Specification Document. Assuming project is approved, this is usually considered the most critical part of a project!

49. 49 Recall our previous drawing: Preliminary Analysis (my term) Preliminary Investigation Phase Problem Analysis Phase � current system; causes/effects; opportunities; constraints; system improvements� (Enter: First Deliverable) Requirements Analysis Phase ?===== Data Analysis and Modeling � Deliverable #2 Process Modeling � Deliverable #3 Interface Modeling � Deliverable #4 All about REQUIREMENTS � at the process, data, interface levels Remember: these are impacted by preferences, constraints, managerial approaches, schedule, �.. That is, �scope� items�.(statement of work�)

50. 50 Identification of Business Requirements A functional requirement is a description of activities and services a system must provide. usually defined in terms of inputs / outputs / processes / stored data needed to support this requirement. May be expressed as a Use Case A nonfunctional requirement is a description of other features, characteristics, and constraints that define a satisfactory system. normally deal with performance, usability, budget, costs, deadlines, constraints, security, etc... No additional notesNo additional notes

51. 51 Requirements Analysis � Continued� While desirable, rarely will all the functional requirements and non-functional requirements be identified. Framework for changes. They WILL happen. Not complete, usually ambiguous, not sufficient, perhaps not all necessary, perhaps not all testable� Use Cases (modern approach) helps a great deal. Much better than �Requirements Lists.� These are draft requirements� Accommodated/documented by systems analysts Critical need: access to system stakeholders (various) for business requirements. Discuss �willingness� of some vis a vis others�. Usually CASE tools used to document process, data, interface, stored data to the dictionary, encyclopedia and repository.

52. 52 Requirements Analysis � Continued� The SYSTEMS ANALYSTS MUST identify and analyze functional (and supplementary) requirements so that they can be communicated both to the users and to the technical people� Business may need to prioritize requirements for many reasons. Verify that analysts understands needs. Technical people need to fully understand all requirements in order to design solutions that are traceable to requirements. We typically capture requirements by: Requirements Lists � old way; difficult to deal with; boring! Ambiguous, Charts/graphs, tables (DLTs), etc� Models, such as Use Case Model w/domain and supplementary descriptions and/or combination of models such as ERDs, DFDs, and prototypes.

53. 53 1..Requirements Analysis � Capturing Requirements via Logical System Models LOGICAL models (Logical Design)� no hint of �how� Logical system models depict what a system is or what a system must do�not how the system will be do it. Because logical models depict the essential requirements of a system, they are sometimes called essential system models. Recall: Physical DFDs were used to model existing systems � these have implementations already. Used in Problem Analysis Phase

54. 54 1..Requirements Analysis � Capturing Requirements via Logical System Models Process models (e.g., data flow diagrams � starting point for program design) Data models (e.g., entity relationship diagrams � starting point for designing a database) Interface models (e.g., context diagrams � starting point for designing user interfaces � shows system as a box plus external �entities� Object models (e.g., Uniform Modeling Language diagrams) Logical modeling (Logical Design) (data, process, interface) express business requirements.(LDFD) Physical modeling (Physical Design) addresses solution (PDFD) Physical system models, introduced in the systems design chapter � later�

55. 55 2. Requirements Analysis � Capturing Requirements via Prototyping Building prototypes � particularly valuable when requirements not fully understood (by user and/or developer or both) and in developing the interfaces. Systems Analysts deal with system end-users a great deal in verifying requirements via the prototypes Sometimes, creation of the prototypes as well as databases might be supported by reverse engineering Depends on the approach and tools used�. Then, a model-driven approach can be continued�

56. 56 Requirements Analysis Modeling techniques generally use DFDs, ERDs, Biggest new trend is to emphasize Use Cases. Fewer advocates of DFDs; but in common use�especially for domain modeling and information flow depicting current and/or desired system. CASE Tools such as Visio, System Architect, Visible Analyst, and several others. some simple CASE ranging to iCASE tools. Prototyping tools often include Microsoft Access or Visual Basic � even those these are used in courses dealing with application development. There are a number of tools to support prototyping

57. 57 After requirements accomplished and captured via modeling or prototyping, the requirements capture ABSOLUTLEY NEED TO BE VERIFIED BY THE USER. How so? Discuss�. Use Cases for verification of proposed functionality?? DFDs and ERDs Prototypes Requirements Tracing refers to verifying the system models / prototypes against the requirements. May require some rework � VERY worth the effort!!!! Also associate the non-functional requirements with the functional requirements so that they will be accommodated in system design

58. 58 �leaving Requirements Analysis General Rule of software development: Provide the maximum functionality in the minimum time on schedule and within budget Oftentimes business requirements may be prioritized. �mandatory requirements � for any increment � �dead without it.� �desirable requirements� (can be ranked) for subsequent versions.

59. 59 Parting Comments If trouble (and OFTEN if not) Timeboxing (Versioning) is a mechanism of developing and implementing a key subset (one that provides immediate functionality and utility) in a small development timeframe. Do this successively with different subsets / increments.� Oftentimes called �incremental development� Naturally, any of these activities require Project Plan updating. �Sign-Off� - get a signature. Realize �changes� in requirements will come�

60. 60 A Simple Interface Model No additional notesNo additional notes

61. 61 Requirements Statement No additional notesNo additional notes

62. 62 Decision Analysis Phase Context