Systems Analysis and Design Chapter 4 Requirements Modeling PDF

Chapter 4 Requirements Modeling Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 1  Describe systems analysis phase activities  Explain joint application development (JAD),...

Chapter 4 Requirements Modeling Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 1  Describe systems analysis phase activities  Explain joint application development (JAD), rapid application development (RAD), and agile methods  Use a functional decomposition diagram (FDD) to model business functions and processes  Describe the Unified Modeling Language (UML) and examples of UML diagrams Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2  List and describe system requirements, including outputs, inputs, processes, performance, and controls  Explain the concept of scalability  Use fact-finding techniques, including interviews, documentation review, observation, questionnaires, sampling, and research Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3  Define total cost of ownership (TCO)  Conduct a successful interview  Develop effective documentation methods to use during systems development Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4  Objectives ◦ Understand the proposed project ◦ Ensure that it supports business requirements ◦ Build a solid foundation for system development  Systems Analysis Activities ◦ Requirements modeling  Involves fact-finding to describe the current system and identification of the requirements for new system ◦ Data and process modeling  Graphically represents system data and processes Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5  ◦ Object modeling  Involves creation of objects to represent people, things, transactions, and events ◦ Development strategies  Include software trends, development alternatives, and outsourcing FIGURE 4-2 The systems analysis phase consists of requirements modeling, data and process modeling, object modeling, and consideration of development strategies. Notice that the systems analysis tasks are interactive, even though the waterfall model generally depicts sequential development Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6  Systems Analysis Skills ◦ Strong analytical and interpersonal skills  Team-Based Techniques: JAD, RAD, and Agile Methods ◦ Goal - To deliver the best possible system at the lowest possible cost in the shortest possible time  Joint application development (JAD) brings users into the design process  Rapid application development (RAD) is a condensed version of the system development life cycle  Agile methods stress intense interaction between developers and users Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7  Brings users into the development process as active participants  User Involvement (formal or informal) ◦ Helps create a successful system  JAD Participants and Roles ◦ Project leader and one or more members ◦ Participants should be insulated from distractions of day-to-day operations Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8 FIGURE 4-3 Typical JAD participants and roles Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9 FIGURE 4-4 Typical agenda for a JAD session Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10  JAD Advantages and Disadvantages ◦ Disadvantages  More expensive than traditional methods  Can be cumbersome if the group is too large ◦ Advantages  Allows key users to participate effectively  Users are more likely to feel a sense of ownership  Produces a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11  Uses a group approach like JAD  End product - New information system  Complete methodology ◦ Includes a four-phase life cycle that parallels the traditional SDLC ◦ Reduces cost and development time ◦ Increases the probability of success ◦ Relies on prototyping and user involvement  Prototypes are modified based on user input Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12 FIGURE 4-5 The four phases of the RAD model are requirements planning, user design, construction, and cutover. Notice the continuous interaction between the user design and construction phases. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13  RAD Objectives ◦ Cut development time and expense  Involve users in every phase of systems development  Must have the right IT resources, skills, and management support  RAD Advantages and Disadvantages ◦ Advantage – Helps develop systems quickly with significant cost savings ◦ Disadvantages  Does not emphasize the company’s strategic business needs  Less time to develop quality, consistency, and design standards Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14  Attempt to develop a system incrementally, by building a series of prototypes and adjusting them to user requirements regularly  Developers revise, extend, and merge earlier versions into the final product  Emphasize continuous feedback ◦ Each incremental step is affected by what was learned in the prior steps Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15  Scrum ◦ A rugby term ◦ Pigs include the product owner, the facilitator, and the development team ◦ Chickens include users, other stakeholders, and managers ◦ Scrum sessions  Have specific guidelines that emphasize time blocks, interaction, and team-based activities that result in FIGURE 4-7 In a rugby scrum, team members deliverable software prepare to lunge at each other to achieve their objectives. fotograf.lv / Shutterstock.com Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16  Agile Method Advantages and Disadvantages ◦ Advantages  Very flexible and efficient in dealing with change  Frequent deliverables constantly validate the project and reduce risk ◦ Disadvantages  Team members need a high level of technical and interpersonal skills  Lack of structure and documentation can introduce risk factors  May be subject to significant change in scope Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17  Involve graphical methods and nontechnical language that represent the system at various stages of development  Systems analysts: ◦ Build fact-finding results into models ◦ Study the models to determine whether additional fact-finding is needed  Functional Decomposition Diagrams (FDD) ◦ Top-down representation of a function or process ◦ Help analysts show business functions and how they are organized into lower-level processes Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18 FIGURE 4-8 This Visible Analyst FDD shows a library system with five top-level functions. The Library Operations function includes two additional levels of processes and sub processes. Source: Visible Systems Corporation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19  Business Process Modeling (BPM) ◦ Represents one or more business processes ◦ Business process modeling notation (BPMN)  Models that use a standard language  Includes shapes and symbols to represent events, processes, and workflows FIGURE 4-9 Using the Visible Analyst CASE tool, an analyst can create a business process diagram. The overall diagram is called a pool, and the two separate customer areas are called swim lanes. Source: Visible Systems Corporation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20   Data Flow Diagrams (DFD) ◦ Show how the system stores, processes, and transforms data ◦ Additional levels of information and detail are depicted in other, related DFDs FIGURE 4-10 This Visible Analyst DFD shows how books are added and removed in a library system. Source: Visible Systems Corporation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21  Use Case Diagrams ◦ Represent the interaction between users and the system FIGURE 4-12 This table documents the credit card validation use case shown in Figure 4-11. FIGURE 4-11 This Visible Analyst use case diagram shows a sales system, where the actor is a customer and the use case is a credit card validation. Source: Visible Systems Corporation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 22   Sequence Diagrams ◦ Show the timing of interactions between objects as they occur FIGURE 4-14 This Visible Analyst sequence diagram shows a credit card validation process. Source: Visible Systems Corporation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 23  Output Examples ◦ The Web site must report online volume statistics every four hours, and hourly during peak periods ◦ The contact management system must generate a daily reminder list for all sales reps ◦ The purchasing system must provide suppliers with up-to-date specifications Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24  Input Examples ◦ The department head must enter overtime hours on a separate screen ◦ Student grades must be entered on machine- readable forms prepared by the instructor ◦ Each input form must include date, time, product code, customer number, and quantity  Process Examples ◦ The student records system must calculate the GPA at the end of each semester ◦ The human resources system must interface properly with the existing payroll system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25  ◦ The prescription system must automatically generate an insurance claim form  Performance Examples ◦ The system must support 25 users online simultaneously ◦ Response time must not exceed four seconds ◦ The system must be operational seven days a week, 365 days a year Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26  Control Examples ◦ The system must provide logon security at the operating system level and at the application level ◦ The system must maintain separate levels of security for users and the system administrator ◦ All transactions must have audit trails ◦ The system must create an error log file that includes the error type, description, and time Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27  Scalability ◦ A system’s ability to handle increased business volume and transactions in the future  A scalable system offers a better return on the initial investment ◦ Information required to evaluate scalability  Projected future volume for all outputs, inputs, and processes Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28  Total Cost of Ownership ◦ Important if the development team is evaluating several alternatives ◦ Problem - Cost estimates tend to understate indirect costs  Systems analysts should try to identify indirect costs and include them in TCO estimates FIGURE 4-15 Total cost of ownership when migrating to the cloud can be significantly less than current computing platforms. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29  Fact-Finding Overview ◦ Identify the required information - Typical questions to ask  What business functions are supported by the current system?  What are the benefits and TCO of the proposed system?  What transactions will the system process?  Must the new system interface with legacy systems? ◦ Develop a fact-finding plan Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30  Who, What, Where, When, How, and Why? ◦ Systems analyst must first understand the current situation  Will help him/her tackle the question of what should be done FIGURE 4-17 Sample questions during requirements modeling as the focus shifts from the current system to the proposed system. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 31  The Zachman Framework ◦ Helps managers and users understand the model ◦ Ensures that overall business goals translate into successful IT projects FIGURE 4-17 Visible Analyst uses the Zachman Framework for Enterprise Architecture. The Zachman concept presents traditional fact-finding questions in a systems development context. Source: Visible Systems Corporation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32  Steps involved ◦ Step 1 - Determine the people to interview ◦ Step 2 - Establish objectives for the interview ◦ Step 3 - Develop interview questions ◦ Step 4 - Prepare for the interview ◦ Step 5 - Conduct the interview ◦ Step 6 - Document the interview ◦ Step 7 - Evaluate the interview Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33  Step 1 - Determine the People to Interview ◦ Select the right people and ask the right questions  Consider candidates from both formal and informal structures ◦ Decide on group and/or individual interviews  Step 2 - Establish Objectives for the Interview ◦ Determine the areas to be discussed ◦ List the facts that need to be gathered ◦ Objectives depend on the role of the person being interviewed Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34  Step 3 - Develop Interview Questions ◦ Decide what to ask and how to phrase the question  Avoid leading questions  Open ended questions encourage spontaneous and unstructured responses  Close ended questions limit the response  Used to verify facts  Range-of-response questions limit the response  Use a numeric scale Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35  Step 4 - Prepare for the Interview ◦ Careful preparation is essential ◦ Limit the interview to no more than one hour ◦ Verify time, place, length, and topics via e-mail ◦ If there are questions about documents, ask the interviewee to have samples available at the meeting Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36 FIGURE 4-19 Sample message to a department head about interviews. Source: 2015 Apple Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37 FIGURE 4-20 Sample message to confirm an interview. Source: 2015 Apple Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38  Step 5 - Conduct the Interview ◦ Develop a specific plan for the meeting ◦ Begin by introducing yourself, describing the project, and explaining your interview objectives ◦ Practice engaged listening ◦ Allow the person enough time to think about the question and arrive at an answer ◦ After an interview, summarize the session and seek a confirmation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39  Step 6 - Document the Interview ◦ Note taking should be kept to a minimum ◦ After conducting the interview:  Record the information quickly  Send memo to the interviewee expressing your appreciation  Note the date, time, location, purpose of the interview, and the main points you discussed so the interviewee has a written summary and can offer additions or corrections  Step 7 - Evaluate the Interview ◦ In addition to recording the facts obtained in an interview, try to identify any possible biases Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40  Unsuccessful Interviews ◦ No matter how well you prepare for interviews, some are not successful ◦ Misunderstanding or personality conflict could affect the interview negatively, or the interviewee might be afraid that the new system will eliminate or change his or her job Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 41  Document Review ◦ Review of baseline documentation ◦ Helps an analyst understand how the current system is supposed to work  Observation ◦ Provides additional perspective and a better understanding of the system procedures ◦ Should be planned in advance Figure 4-21 The Hawthorne study suggested that worker productivity improves during observation. Always consider the Hawthorne Effect when observing the operation of an existing system. Monkey Business Images/Shutterstock.com Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 42  Questionnaires and Surveys ◦ Make sure that the questions collect the right data in a form that can be used to further the fact finding effort ◦ Can be traditional forms, fill-in forms, or forms from online survey websites  Fill-in form: Template used to collect data on the Internet or a company intranet Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 43 ◦ Suggestions for designing a questionnaire  Keep the questionnaire brief and user-friendly  Provide clear instructions  Arrange the questions in a logical order  Phrase questions to avoid misunderstandings  Try not to lead the response  Limit the use of open-ended questions that are difficult to tabulate  Limit the use of questions that can raise concerns about job security or other negative issues  Include a section for general comments  Test the questionnaire on a small test group before finalizing it and distributing to a large group Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 44 FIGURE 4-22 Online version of a sample questionnaire. Does it follow the suggested guidelines? Created by author using Adobe Online Forms, Adobe Systems Incorporated Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 45  Interviews versus Questionnaires ◦ Interview is more familiar and personal  Costly and time-consuming process ◦ Questionnaire gives people the opportunity to provide input and suggestions  Recipients can answer the questions at their convenience  Brainstorming: Small group discussion of a specific problem, opportunity, or issue ◦ Structured brainstorming ◦ Unstructured brainstorming Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 46  Sampling ◦ Systematic sample: Selection of every tenth customer for review ◦ Stratified sample: Selection of five customers from each of four postal codes ◦ Random sample: Selection of any 20 customers ◦ Objective of a sample - To ensure that it represents the overall population accurately Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 47  Research ◦ The Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments ◦ Attending professional meetings, seminars, and discussions with other IT professionals ◦ Site visits Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 48  The Need for Recording the Facts ◦ Principles for documentation  Record information as soon as it is obtained  Use the simplest recording method  Record findings in a way that they can be understood by someone else  Organize documentation so related material is located easily Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 49  Software Tools ◦ CASE tools ◦ Productivity software  Word processing  Spreadsheets  Database management  Presentation graphics  Collaborative FIGURE 4-24 This histogram displays the results from software programs Question 2 in the questionnaire shown in Figure 4-22. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 50   Graphic Modeling Software ◦ Help create charts and diagrams ◦ Popular software  MS Visio FIGURE 4-25 This Microsoft Visio drawing uses drag-and-drop shapes to represent a business process. Source: Microsoft, LLC Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 51   Personal Data Management Software ◦ Microsoft Outlook  Includes a personal calendar, a to-do list with priorities and the capability to check off completed items, and powerful contact management features  Can manage email and appointments, and supports collaboration and team projects ◦ Novell’s GroupWise Figure 4-27 Evernote offers a free version of its popular information management software for most computing platforms, including smartphones and on the web. Source: www.evernote.com Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 52   Project Data Management ◦ Microsoft OneNote  Handles different types of input, including text, handwritten notes, images, audio and video recordings, and web links ◦ Microsoft Word  Recent versions provide note taking feature FIGURE 4-26 The analyst is using Microsoft Word to store fact-finding results. During the interview with Joy Brooks, the analyst recorded part of the discussion and stored it as a document annotation. Source: Microsoft Corporation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 53  At the conclusion of requirements modeling, systems developers should have a clear understanding of business processes and system requirements  Next step - To construct a logical model of the system  IT professionals have differing views about systems development methodologies, and no universally accepted approach exists Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 54  The systems analysis phase includes requirements modeling, data and process modeling, and consideration of development strategies ◦ Objective is to understand the proposed project, ensure that it will support business requirements, and build a solid foundation for the systems design phase  Popular team-based approaches include JAD, RAD, and agile methods Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 55  The fact-finding process includes interviewing, document review, observation, questionnaires, sampling, and research Systems analysts should carefully record and document factual information as it is collected, and various software tools can help an analyst visualize and describe an information system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 56 Chapter 5 Data and Process Modeling Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 1  Describe data and process modeling concepts and tools, including data flow diagrams, a data dictionary, and process descriptions  Describe the symbols used in data flow diagrams and explain the rules for their use  Draw data flow diagrams in a sequence, from general to specific Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2  Explain how to level and balance a set of data flow diagrams  Describe how a data dictionary is used and what it contains  Use process description tools, including structured English, decision tables, and decision trees  Describe the relationship between logical and physical models Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3  Logical Model: Shows what the system must do, regardless of how it will be implemented physically  Physical Model: Describes how the system will be constructed Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4  Systems analysts use graphical techniques to describe an information system  Data flow diagram (DFD) - Uses various symbols to show how the system transforms input data into useful information Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5  A data flow diagram (DFD) shows how data moves through an information system but does not show program logic or processing steps  A set of DFDs provides a logical model that shows what the system does, not how it does it Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6  DFD Symbols ◦ Four basic symbols represent processes, data flows, data stores, and entities ◦ Gane and Sarson: Used in data flow diagrams  Processes, data flows, data stores, and external entities all have a unique symbol ◦ Yourdon: Used in data flow diagrams FIGURE 5-1 Data flow diagram symbols, symbol names, and examples of the Gane and Sarson and Yourdon symbol sets  Processes, data flows, data stores, and external entities each have a unique symbol Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7  Process Symbol Must have at least one input and at least one output Contains business logic that transforms the data Process name identifies its function (verb) Examples” : “apply rent payment” or “calculate commission In DFDs, a process symbol can be referred to as a black box Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8   Data Flow Symbol ◦ Represents one or more data items ◦ The symbol for a data flow is a line with a single or double arrowhead FIGURE 5-3 Examples of correct combinations of data flow and process symbols Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9  Data Flow Symbol ◦ Following data flow and process combinations must be avoided ◦ Spontaneous generation ◦ Black holes ◦ Gray holes FIGURE 5-4 Examples of incorrect combinations of data flow and process symbols. APPLY INSURANCE PREMIUM has no input and is called a spontaneous generation process. CALCULATE GROSS PAY has no outputs and is called a black hole process. CALCULATE GRADE has an input that is obviously unable to produce the output. This process is called a gray hole Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied 10 or duplicated, or posted to a publicly accessible website, in whole or in part. Data Store symbol Represent data that the system stores A DFD does not show the detailed contents of a data store — the specific structure and data elements are defined in the data dictionary A data store must be connected to a process with a data flow Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11  FIGURE 5-6 Examples of incorrect uses of data store symbols: Two data stores cannot be connected by a data flow without an intervening process, and each data store should have an outgoing and incoming data flow FIGURE 5-5 Examples of correct uses of data store symbols in a data flow diagram Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12  Entity Symbol Shows how the system interfaces with the outside world A DFD shows only external entities that provide data to the system or receive output from the system DFD entities also are called terminators because they are data origins or final destinations Each entity must be connected to a process by a data flow Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13  FIGURE 5-8 Examples of incorrect uses of external entities. An external entity must be connected by a data flow to a process, and not directly to a data store or to another external entity FIGURE 5-7 Examples of correct uses of external entities in a data flow diagram Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14  Keep in mind: ◦ All flow lines must be labeled ◦ Large processes can be broken down into smaller components FIGURE 5-9 Examples of correct and incorrect uses of data flows Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15  Create a graphical model of the information system based on your fact-finding results ◦ First, you will review a set of guidelines for drawing DFDs ◦ Then you will learn how to apply these guidelines and create a set of DFDs using a three-step process Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16  Guidelines for Drawing DFDs ◦ Draw the context diagram so that it fits on one page ◦ Use the name of the information system as the process name in the context diagram ◦ Use unique names within each set of symbols ◦ Do not cross lines ◦ Provide a unique name and reference number for each process ◦ Ensure that the model is accurate, easy to understand, and meets the needs of its users Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17 FIGURE 5-10 Context diagram DFD for grading system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18   Step 1: Draw a Context Diagram FIGURE 5-11 Context diagram DFD for an order system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19  Step 2: Draw a Diagram 0 DFD ◦ If same data flows in both directions, you can use a double-headed arrow ◦ Diagram 0 is an exploded view of process 0 ◦ Parent diagram ◦ Child diagram ◦ Functional primitive FIGURE 5-13 Diagram 0 DFD for the order system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20   Step 3: Draw the Lower Level Diagrams FIGURE 5-14 Diagram 1 DFD shows details of the FILLORDER process in the order system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21  Must use leveling and balancing techniques  Leveling examples ◦ Uses a series of increasingly detailed DFDs to describe an information system ◦ Exploding, FIGURE 5-15 This diagram does partitioning, or not show the symbols that connect to data flows entering or leaving decomposing FILL ORDER on the context diagram Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 22 FIGURE 5-16 The order system diagram 0 is shown at the top of the figure, and exploded diagram 3 DFD (for the APPLY PAYMENT process) is shown at the bottom. The two DFDs are balanced because the child diagram at the bottom has the same input and output flows as the parent process 3 shown at the top Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 23  FIGURE 5-17 Example of a parent DFD diagram, showing process 0 as a black box FIGURE 5-18 In the next level of detail, the process 0 black box reveals three processes, two data stores, and four internal data flows — all of which are shown inside the dashed line Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24  A data dictionary, or data repository, is a central storehouse of information about a system’s data An analyst uses the data dictionary to collect, document, and organize specific facts about a system Defines and describes all data elements and meaningful combinations of data elements Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25  Data element: Smallest piece of data that has meaning within an information system ◦ Called data item or field ◦ Are combined into records, also called data structures  Record: Meaningful combination of related data elements that is included in a data flow or retained in a data store ◦ Called data structures Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26  Using CASE Tools for Documentation ◦ More complex the system, more difficult it is to maintain full and accurate documentation ◦ Modern CASE tools simplify the task ◦ A CASE repository ensures data consistency Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27  Documenting the Data Elements ◦ Every data element in the data dictionary should be documented ◦ Objective - To provide clear, comprehensive information about the data and processes that make up a system Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28  Documenting the Data Elements ◦ Data element name and label ◦ Alias ◦ Type and length ◦ Default value ◦ Acceptable values - Domain and validity rules ◦ Source ◦ Security ◦ Responsible user(s) Source: Visible Systems Corporation. ◦ Description and comments FIGURE 5-20 A Visible Analyst screen describes the data element named SOCIAL SECURITY NUMBER. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29  Documenting the Data Flows ◦ Data flow name or label ◦ Description ◦ Alternate name(s) ◦ Origin ◦ Destination ◦ Record ◦ Volume and frequency Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30   Documenting the Data Stores ◦ Data store name or label ◦ Description ◦ Alternate name(s) ◦ Attributes ◦ Volume and frequency Source: Visible Systems Corporation. FIGURE 5-21 Visible Analyst screen that documents a data store named IN STOCK Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 31  Documenting the Processes ◦ Process name or label ◦ Description ◦ Process number ◦ Process description FIGURE 5-22 Visible Analyst screen that describes a process named VERIFY ORDER Source: Visible Systems Corporation. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32  Documenting the Entities - Data dictionary describes all external entities that interact with the system ◦ Characteristics include  Entity name  Description  Alternate name(s)  Input data flows  Output data flows Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33   Documenting the Records ◦ Record or data structure name ◦ Definition or description ◦ Alternate name(s) ◦ Attributes Source: Visible Systems Corporation. FIGURE 5-23 Visible Analyst screen that documents a record, or data structure named CREDIT STATUS Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34  Data Dictionary Reports - Following can be obtained ◦ Alphabetized list of all data elements by name ◦ Report describing each data element and indicating the user or department that is responsible for data entry, updating, or deletion ◦ Report of all data flows and data stores that use a particular data element ◦ Detailed reports showing all characteristics of data elements, records, data flows, processes, or any other selected item stored in the data Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35  Process description: Documents the details of a functional primitive and represents a specific set of processing steps and business logic  Tools - structured English, decision tables, and decision trees  Used in object-oriented development ◦ O-O analysis - combines data and the processes that act on the data into things called objects, and similar objects can be grouped together into classes ◦ O-O processes are called methods Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36  Modular Design ◦ Based on combinations of FIGURE 5-24 Sequence structure three logical structures, sometimes called control structures, which serve as building blocks for FIGURE 5-25 Selection structure the process  Sequence FIGURE 5-26 Iteration  Selection structure  Iteration - looping Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37  Structured English ◦ Rules  Use only the three building blocks of sequence, selection, and iteration  Use indentation for readability  Use a limited vocabulary  standard terms used in the data dictionary  Specific words that Source: Visible Systems Corporation. describe the processing FIGURE 5-27 The VERIFY ORDER process description rules includes logical rules and a structured English version of the policy. Notice the alignment and indentation of the logic statements Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38  Decision Tables ◦ Show a logical structure, with all possible combinations of conditions and resulting actions  Every possible outcome should be considered to ensure that nothing has been overlooked ◦ Number of rules doubles each time a condition is added ◦ Can have more than two possible outcomes ◦ Are the best way to describe a complex set of conditions Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39 FIGURE 5-28 The Verify Order business process has two conditions. For an order to be accepted, the product must be in stock and the customer must have an acceptable credit status FIGURE 5-29 Example of a simple decision table showing the processing logic of the VERIFY ORDER process Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40 FIGURE 5-30 A third condition has been added to the Verify Order business process. For an order to be accepted, the product must be in stock and the customer must have an acceptable credit status. However, the credit manager now has the authority to waive the credit status requirement FIGURE 5-31This table is based on the Verify Order conditions shown in Figure 5-30. With three conditions, there are eight possible combinations, or rules Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 41 FIGURE 5-32 In the first table, dashes have been added to indicate that a condition is not relevant. In the second version, rules have been combined. Notice that in final version, only four rules remain. These rules document the logic, and will be transformed into program code when the system is developed Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 42 FIGURE 5-33 A sales promotion policy with three conditions. Notice that the first statement contains two separate conditions – one for the 5% discount, and another for the additional discount FIGURE 5-34 This decision table is based on the sales promotion policy in Figure 5-33. This is the initial version of the table, before simplification Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 43 FIGURE 5-35 In this version, dashes have been added to indicate that a condition is not relevant. At this point, it appears that several rules can be combined Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 44   Decision Trees ◦ Graphical representation of the conditions, actions, and rules found in a decision table ◦ Show the logic structure in a horizontal form that resembles a tree ◦ Provide the same results as decision tables, but in different forms FIGURE 5-36 This example is based on the same Sales Promotion Policy shown in the decision tables in Figures 5-34 and 5-35 on the previous page. Like a decision table, a decision tree shows all combinations of conditions and outcomes. The main difference is the graphical format, which many viewers find easier to interpret Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 45  While structured analysis tools are used to develop a logical model for a new information system, such tools also can be used to develop physical models of an information system  A physical model shows how the system’s requirements are implemented Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 46  Sequence of Models ◦ Systems analysts create a physical model of the current system and then develop a logical model of the current system before tackling a logical model of the new system  Performing extra step allows to understand the current system better Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 47  Four-Model Approach ◦ Develop:  A physical model of the current system  A logical model of the current system  A logical model of the new system  A physical model of the new system ◦ Disadvantage - Additional time and cost Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 48  During data and process modeling, a systems analyst develops graphical models to show how the system transforms data into useful information  The end product of data and process modeling is a logical model that will support business operations and meet user needs  Data and process modeling involves three main tools: data flow diagrams, a data dictionary, and process descriptions Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 49  Data flow diagrams (DFDs) graphically show the movement and transformation of data in the information system  DFDs use four symbols  A set of DFDs is like a pyramid with the context diagram at the top  The data dictionary is the central documentation tool for structured analysis Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 50  Each functional primitive process is documented using structured English, decision tables, and decision trees  Structured analysis tools can be used to develop a logical model during one systems analysis phase, and a physical model during the systems design phase Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 51  Chapter 7 Development Strategies Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.  Describe the concept of Software as a Service  Define Web 2.0 and cloud computing  Explain software acquisition alternatives, including traditional and Web-based software development strategies  Describe software outsourcing options, including offshore outsourcing and the role of service providers Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 2  Explain advantages and disadvantages of in- house software development  Discuss cost-benefit analysis and financial analysis tools  Describe a request for proposal (RFP) and a request for quotation (RFQ)  Describe the system requirements document  Explain the transition from systems analysis to systems design Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 3  Earlier, certain work functions in the company required: ◦ Development of software by in-house efforts ◦ Employing the services of external entities  Today, organizations have following choices for software acquisition ◦ Application service providers ◦ Web-hosted software options ◦ Firms that offer enterprise-wide software solutions  Selecting the best development path is an important decision Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 4  Software as a Service (SaaS) ◦ Software deployment model that hosts an application as a service provided to customers over the Internet ◦ Reduces the customer’s need for software maintenance, operation, and support Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 5  Traditional vs. Web-Based Systems Development ◦ Service-oriented architecture (SOA)  A way of engineering systems in which reusable business functionality is provided by services through well-defined interfaces  Technically, not software architecture but an architectural style Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 6  Traditional vs. Web-Based Systems Development ◦ Traditional Development  System design is influenced by compatibility issues  Systems are designed to run on local and wide-area networks  Systems often utilize Internet links and resources  Development typically follows one of three main paths:  In-house development  Purchase of a software package with possible modification  Use of outside consultants  Scalability is affected by network limitations and constraints Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 7  Traditional vs. Web-Based Systems Development (Cont.) ◦ Web-Based Development  Systems are developed and delivered on an Internet- based framework  Treats the Web as the platform rather than just a communication channel  Web-based systems are easily scalable and can run on multiple hardware environments  Used for customer relationship management, order processing, and materials management  Treats software applications as services that are less dependent on desktop computing power and resources Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 8  Traditional vs. Web-Based Systems Development (Cont.) ◦ Web-Based Development  Requires additional layers, called middleware, to communicate with existing software and legacy systems  Middleware: Connects dissimilar applications and enables them to communicate and exchange data  Open more complex security issues that should be addressed Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 9  Evolving Trends - Web 2.0, Cloud Computing, and Mobile Devices ◦ Web 2.0: second generation of the web that enables people to collaborate, interact, and share information much more effectively  Enhances interactive experiences ◦ Cloud computing: Online software in which applications and services are accessed and used through an Internet connection ◦ Mobile devices: Smartphones, tablets, and other computing devices that are not permanently tethered to a desk Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 10  Transfer of information systems development, operation, or maintenance to an outside firm  The Growth of Outsourcing ◦ Service provider: Offers outsourcing solutions Application service provider (ASP)  Delivers a software application or access to an application by charging a usage or subscription fee ◦ Internet business services (IBS)  Also called managed hosting  Provide web-based support for transactions Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 11  Outsourcing Fees ◦ Fixed fee model: Uses a set fee based on a specified level of service and user support ◦ Subscription model: Has a variable fee based on the number of users or workstations that have access to the application ◦ Usage model or transaction model: Charges a variable fee based on the volume of transactions or operations performed by the application Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 12  Outsourcing Issues and Concerns ◦ Mission-critical IT systems are outsourced if the result is a cost-attractive and reliable business solution ◦ Overseas outsourcing can raise issues with control, culture communication, and security ◦ Reviewing the outsourcing firm’s history and financial condition is vital ◦ Outsourcing clients can be affected by mergers and acquisitions ◦ Employee job security is a major concern Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 13  Offshore Outsourcing ◦ Called global outsourcing ◦ Shifting IT development, support, and operations to other countries ◦ Reason - Lower bottom-line costs ◦ Risks and concerns  Impact on the economy  Project control  Security issues Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 14  Software development options ◦ Develop own systems ◦ Purchase, possibly customize, and implement a software package  Most important consideration is the total cost of ownership (TCO)  Companies can develop user applications based on commercial software packages Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 15  Make or Buy Decision ◦ Refers to the choice between developing and purchasing ◦ A company’s IT department makes, builds, and develops in-house software ◦ A software package is obtained from a vendor or application service provider FIGURE 7-8 Instead of outsourcing, a company can choose to develop a system in-house, or purchase and possibly customize a commercial package. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 16  Make or Buy Decision (cont.) ◦ Software package: Obtained from a vendor or application service provider ◦ Software vendors: Develop software for sale ◦ Value-added reseller (VAR): Enhances a commercial package by adding custom features and configuring it for a particular industry ◦ Horizontal application: Can be used by many different types of organizations ◦ Vertical application: Developed to handle information requirements for a specific type of business Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 17 FIGURE 7-10 Companies consider various factors when comparing in- house development with the purchase of a software package. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 18  Developing Software In-House ◦ Satisfies unique business requirements  Not possible with standard commercial software packages  Minimizes changes in business procedures and policies  Installing a new software package almost always requires some degree of change in how a company does business ◦ Meets constraints of existing systems  Any new software installed must work with existing systems Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 19  Developing Software In-House (Cont.) ◦ Meets constraints of existing technology  The new system must work with existing hardware and legacy systems ◦ Develops internal resources and capabilities  Companies can develop and train IT staff who understand the organization’s business functions and information support needs Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 20  Purchasing a Software Package ◦ Lower costs  A software package is less expensive than the one developed in-house ◦ Requires less time to implement  Packages have already been designed, programmed, tested, and documented ◦ Proven reliability and performance benchmarks  Major problems would have been detected and corrected by the vendor Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 21  Purchasing a Software Package (Cont.) ◦ Requires less technical development staff  Companies can reduce the number of programmers and systems analysts on the IT staff ◦ Future upgrades provided by the vendor  Improvements and enhancements are included in regular updates ◦ Input from other companies  Users in other companies can be contacted to obtain their input and opinions Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 22  Customizing a Software Package ◦ Purchase a basic package that vendors will customize to suit project requirements ◦ Negotiate directly with the software vendor to make enhancements to meet project needs by paying for the changes ◦ Purchase the package and make project-specific modifications  Ensure modifications are permissible under the terms of the software license Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 23  Creating User Applications ◦ User application: Utilizes standard business software ◦ User interface: Enables effective interaction with the application ◦ Service desk or information center (IC): Provides user support ◦ Screen generators and report generators: Allow users to design their own data entry forms and reports ◦ Appropriate controls must be provided to ensure data security and integrity Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 24 Figure 7-11 Microsoft Access includes Form Wizard and a Report Wizard tools that ask a series of questions and then create the form or report. Source: Screenshots used with permission from Microsoft Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 25  Based on decisions taken by the organization in the systems development process ◦ Current and future needs are considered  Evaluation and selection of alternatives is a complicated process ◦ Forecasting actual costs is difficult  Evaluation and selection team: Selects hardware and software, includes systems analysts and users ◦ Ensures that critical factors are not overlooked and that a sound choice is made Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 26  Financial Analysis Tools ◦ Payback analysis  Determines the time taken for an information system to pay for itself through reduced costs and increased benefits ◦ Return on investment (ROI)  Percentage rate that compares the total net benefits (the return) received from a project to the total costs (the investment) of the project ◦ Net present value (NPV)  Total value of the benefits minus the total value of the costs Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 27 Figure 7-12 In this example, the HP interactive TCO calculator is used to determine the ROI of migrating to an Infrastructure-as-a-Service (IaaS) environment in the cloud from a traditional server environment Source: Hewlett-Packard Development Company, L.P. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 28  Cost-Benefit Analysis Checklist ◦ List each development strategy being considered ◦ Identify all costs and benefits for each alternative ◦ Consider future growth and the need for scalability ◦ Include support costs for hardware and software ◦ Analyze various software licensing options ◦ Apply the financial analysis tools to each alternative ◦ Study the results and prepare a report Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 29  Step 1 - Evaluate the Information System Requirements ◦ Identify key features ◦ Consider network and Web-related issues ◦ Estimate volume and future growth ◦ Specify hardware, software, or personnel constraints ◦ Prepare a request for proposal or quotation  Request for proposal (RFP): Describes the company, lists the IT services or products needed, and specifies the features required  Request for quotation (RFQ): more specific than an RFP Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 30 FIGURE 7-13 Volume estimates for an order processing system showing current activity levels and two forecasts: one based on the existing order processing procedures and another that assumes a new Web site is operational. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 31 FIGURE 7-15 The three vendors have the same initial ratings, but the two evaluation models produce different results. In the unweighted model at the top of the figure, vendor A has the highest total points. However, after applying weight factors, vendor C is the winner, as shown in the model at the bottom of the figure. Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 32  Step 2 - Identify Potential Vendors or Outsourcing Options ◦ The Internet contains information on all major products and acquisition services ◦ The organization can avail the services of a consulting firm that help companies select software packages ◦ Online forums or newsgroups provide opinions and ideas  Google Groups  Yahoo Groups Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 33  Step 3 - Evaluate the Alternatives ◦ Existing users  Provide feedback about their experiences ◦ Application testing  Users in the organization may be able to test the product ◦ Benchmarking  Benchmark: Measures the time a package takes to process a certain number of transactions  Each package is matched against RFP features and the choices are ranked Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 34  Step 4 - Perform Cost-Benefit Analysis ◦ Identify and calculate total cost of ownership (TCO) for each option being considered ◦ Study the conditions of use that come along with the software license ◦ If a software package is purchased, consider a supplemental maintenance agreement Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 35  Step 5 - Prepare a Recommendation ◦ Evaluate and describe alternatives along with:  Costs  Benefits  Advantages  Disadvantages ◦ Submit a formal system requirements document and deliver a presentation Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 36  Step 6 - Implement the Solution ◦ Implementation tasks will depend on the solution selected ◦ Before the new software becomes operational, complete all implementation steps  Loading  Configuring and testing the software  Training users  Converting data files to the new system’s format Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 37  System Requirements Document ◦ Called software requirements specification ◦ Contains the requirements for the new system ◦ Describes the alternatives considered ◦ Makes a specific recommendation to management ◦ Similar to a contract  Identifies items that system developers must deliver to users ◦ Format and organize the systems document  Easy to read and use Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 38  Presentation to Management ◦ Helps take key decisions that affect the future development of the system ◦ Suggestions for effective presentations  Start with a brief overview  Summarize the primary viable alternatives  Explain why the evaluation and selection team chose the recommended alternative  Allow time for discussion  Obtain a final decision from management or agree on a timetable for the next step in the process Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 39  Presentation to Management (Cont.) ◦ Depending on management’s decision, a systems analyst will do one of the following  Implement an outsourcing alternative  Develop an in-house system  Purchase or customize a software package  Perform additional systems analysis work  Stop all further work ◦ Post presentation and management decision, the project begins a transition to the systems phase of the SDLC Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 40  Preparing for Systems Design ◦ Systems design requires accurate documentation  Provide detailed specifications for output, input, data, processes, and other requirements  Logical and Physical Design o Logical design: Defines what must take place o Physical design: Describes the actual process of entering, verifying, and storing data o Logical and physical designs are closely related Accurate systems analysis is required Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 41  A new trend views Software as a Service (SaaS), rather than a product  Traditional systems must: ◦ Function in various hardware and software environments ◦ Be compatible with legacy systems ◦ Operate within the constraints of company networks and desktop computing capability  Companies that choose to handle their own software development needs can: ◦ Create in-house systems ◦ Commercially purchase software packages Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 42  The systems analyst’s role in the software development process depends on the specific development strategy  The most important factor in choosing a development strategy is total cost of ownership (TCO)  Financial analysis tools include: ◦ Payback analysis ◦ Return on investment (ROI) ◦ Net present value (NPV) Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 43  Acquiring software involves a series of specific steps  The system requirements document is the deliverable, or end product, of the systems analysis phase Copyright ©2017 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part. 44