1 / 57

COSC 2810 Systems Analysis and Design Phase 2 : Systems Analysis (Chapter 3, 4, 5)

COSC 2810 Systems Analysis and Design Phase 2 : Systems Analysis (Chapter 3, 4, 5). Chapter 3: Requirements Modeling Chapter 4: Enterprise Modeling Chapter 5: Development Strategies Chapter 3: Requirements Modeling

Download Presentation

COSC 2810 Systems Analysis and Design Phase 2 : Systems Analysis (Chapter 3, 4, 5)

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

E N D

Presentation Transcript


  1. COSC 2810 Systems Analysis and Design Phase 2 : Systems Analysis (Chapter 3, 4, 5) Chapter 3: Requirements Modeling Chapter 4: Enterprise Modeling Chapter 5: Development Strategies Chapter 3: Requirements Modeling • After system planning (Phrase 1), an sys. analyst needs to use requirements models to describe the new sys. This chapter describes modeling techniques and team-based methods to visualize and document the new sys.

  2. Phase 2 System Analysis: • Systems analysis is the second of five phases in the systems development life cycle (SDLC) • Uses requirements modeling and enterprise modeling to represent the new system • Before proceeding to the next phase -> systems design, a sys. analyst will consider system development strategies

  3. Chapter Objectives • Describe systems analysis phase activities and the end product of the systems analysis phase(A system requirements document) • Understand joint application development (JAD) and rapid application development (RAD) • Explain how systems analysts use a functional decomposition diagram (FDD) • Describe the Unified Modeling Language (UML) and use case diagrams and sequence diagrams

  4. Chapter Objectives • List and describe system requirements, including outputs, inputs, processes, performance, and controls • Explain the importance of scalability in system design • Use fact-finding techniques, including interviews, documentation review, observation, questionnaires, sampling, and research

  5. Chapter Objectives • Define total cost of ownership (TCO) and explain the concept • Conduct a successful interview • Develop effective documentation methods to use during systems development

  6. Introduction • This chapter describes requirements modeling techniques and team-based methods that systems analysts use to visualize and document new systems • The chapter discusses system requirements and fact-finding techniques, which include interviewing, documentation review, observation, surveys and questionnaires, sampling, and research

  7. Systems Analysis Phase Overview • Use models and other documentation tools to visualize and describe the proposed system • The deliverable is a system requirements document • Sys. analysis phase includes 3 main activities: Figure 3-2

  8. Systems Analysis Phase Overview • Requirement modeling involves fact-finding to describe the current sys. and identify the requirements of the new sys. • Systems Analysis Skills • Analytical skills(Id a problem,evaluate key elements of the problem, and develop a solution.) • Interpersonal skills (communicating people at all levels) • Team-Oriented Methods and Techniques • Joint application development (JAD) • Rapid application development (RAD)

  9. Joint Application Development (JAD)- A fact finding technique that brings user into development process as active participants. • User Involvement • Users have a vital stake in an information system and they should participate fully • Successful systems must be user-oriented and users need to be involved

  10. Joint Application Development • JAD Participants and Roles Figure 3-4

  11. Joint Application Development Sys development is a joint effort: Figure 3-5

  12. Joint Application Development • JAD Advantages and Disadvantages • More expensive and can be cumbersome (large team) • Allows key users to participate effectively • When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system.

  13. Rapid Application Development (RAD) • Is a team-based technique that speeds up information systems development and produces a functioning information system • Relies heavily on prototyping and user involvement (allow user to exam a model at early developing stage) • Project team uses CASE tools to build the prototypes and create a continuous stream of documentation

  14. Rapid Application Development • RAD Phases (4) and Activities Requirements planning, User design, Construction, Cutover Figure 3-7

  15. Rapid Application Development • RAD Objectives • To cut development time and expense by involving the users in every phase of systems development (reduce cost of change) • Successful RAD team must have IT resources, skills, and management support

  16. Rapid Application Development • RAD Advantages and Disadvantages • Systems can be developed more quickly with significant cost savings • RAD stresses the mechanics of the system itself and does not emphasize the company’s strategic business needs (meet short term purpose, scarifies long term goals) • Might allow less time to develop quality, consistency, and design standards

  17. Modeling Tools and Techniques • CASE Tools: Popkin’s eg. :business enterprise model, a business process model,an organization model, a location model, an application model, a data model and a technology model. Figure 3-8

  18. Modeling Tools and Techniques • Functional Decomposition Diagrams(FDD) • A top-down representation of business functions and processes, also called structure charts • Start at the top and work way down. During requirement modeling, FDD is used to model business functions and show how they are organized into low-level process. Those processes are used as logical symbols and can be translated into program modules during application development

  19. Modeling Tools and Techniques • Functional Decomposition Diagrams Figure 3-9

  20. Modeling Tools and Techniques • Unified Modeling Language (UML) - uses OOP design concepts • A widely used method of visualizing and documenting software systems design • provides various graphical tools and techniques, such as use case diagrams and sequence diagrams

  21. Modeling Tools and Techniques • Unified Modeling Language: case diagrams: visually represent the interaction between users and info. sys. Figure 3-10

  22. Modeling Tools and Techniques Unified Modeling Language Table documents for F. 3-10 Figure 3-11

  23. Modeling Tools and Techniques Unified Modeling Language Sequence Diagrams: shows timing transactions between objects. Sequence Diagram Figure 3-13, vertical timeline of a successful credit card validation

  24. System Requirements Checklist • During requirement modeling, must describe all sys. requirements, which serve as benchmarks to measure the overall acceptability of finished sys. • Five general categories • Outputs • Inputs • Processes • Performance • Controls

  25. System Requirements Checklistexamples of Outputs: • A purchasing sys must provide suppliers with up-to date specifications. • An inventory sys. Must produce a daily report showing part no. quantity on hand, quantity available and unit cost • A contact management sys. Must generate a daily reminder list for all sales reps.

  26. System Requirements Checklistexamples of Inputs • Input patient services into billing sys. in a hospital • Teachers must enter grades online • Mgr must enter overtime hour sheet for payroll sys.

  27. System Requirements Checklistexamples of Processes • Student records sys. must allow access by entering ID or name • Human resources must interface with payroll sys. • Bank must reject over-limit loans

  28. System Requirements Checklistexamples of Performance • Online retailer must be operational 24 hours, 7 days • Response time to user should be relatively short • Online inventory sys must flag low-stock items.

  29. System Requirements Checklistexamples of Controls • Provide logon security limit access • File access control • Order approval by mgr

  30. Future Growth, Costs, and Benefits • 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 • To evaluate, you need information about projected future volume for all outputs, inputs, and processes. eg 1: to ensure an online hotel reservation sys. to work for years of operation, you should forecast the frequency of online queries and estimate turnaround and response time. eg 2: You need to exam current data storage to predict future needs for upgrading current sys. configuration or HW

  31. Future Growth, Costs, and Benefits • Total Cost of Ownership • In addition to direct costs, systems developers must identify and document indirect expenses (user support, downtime productivity losses) that contribute to the total cost of ownership (TCO) • Microsoft has developed a method for measuring total costs and benefits, called Rapid Economic Justification (REJ), F. 3-14, p. 103

  32. Specific Fact-Finding processes: • Overview • Although software can help you to gather and analyze facts, no program actually performs fact-finding for you • Fact-finding techniques: interviews, document review, observation, surveys, questionnaires, sampling and research • The first step is to identify the information you need, ie. start with a fact-finding plan involving types of who, what, where, when, why and how questions

  33. Fact-Finding • Who, What, Where, When, How, and Why? Figure 3-15

  34. Fact-Finding • The Zachman Framework (1980s) for enterprise architecture • A model that asks the traditional fact-finding questions in a systems development context

  35. Fact-Finding see eg. on p. 105 or refer to government.popkin.com/frameworks/ zachman.htm Figure 3-16

  36. Interviews • Systems analysts spend a great deal of time talking with people • Much of that time is spent conducting interviews • Consists of 7 steps

  37. Interview • Step 1: Determine the People to Interview • Informal structures • Step 2: Establish Objectives • Determine the general areas to be discussed • List the facts you want to gather

  38. Interviews • Step 3: Develop Interview Questions • Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents • Avoid leading questions • Open-ended questions • Closed-ended questions • Range-of-response questions

  39. Interviews • Step 4: Prepare for the Interview • Careful preparation is essential because an important meeting and not just a casual chat • Limit the interview to no more than one hour • Send a list of topics • Ask the interviewee to have samples available

  40. Interviews Memo eg. p. 108 Figure 3-18

  41. Interviews Figure 3-19

  42. Interviews • Step 5: Conduct the Interview • Develop a specific plan for the meeting • Begin with good introduction • Use engaged listening • Allow the person enough time to think about the question • Summarize main points • After interview, summarize the session and seek a confirmation

  43. Interviews • Step 6: Document the Interview • During the interview, note taking should be kept to a minimum • After the interview, record the information quickly • After the interview, send memo expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections

  44. Interviews • Step 7: Evaluate the Interview • In addition to recording the facts obtained in an interview, try to identify any possible biases • Unsuccessful Interviews • No matter how well you prepare for interviews, some are not successful (deliberate info hiding due to poetical job loss, eliminate positions)

  45. Other Fact-Finding Techniques • Document Review Fax, hard copies • Observation • Seeing the system in action gives you additional perspective and a better understanding of the system procedures • Plan you observations in advance • Hawthorne Effect: productivity improved when workers being observed.

  46. Other Fact-Finding Techniques • Questionnaires and Surveys • Keep the questionnaire brief and user-friendly • Provide clear instructions that will answer all anticipated questions • Arrange the questions in a logical order, going from simple to more complex topics Sample questionnaires on p. 113, Fig. 3-21

  47. Other Fact-Finding Techniques • Questionnaires and Surveys • Phrase questions to avoid misunderstandings; use simple terms and wording • Try not to lead the response or use questions that give clues to expected answers • Limit the use of open-ended questions that are difficult to tabulate

  48. Other Fact-Finding Techniques • Questionnaires and Surveys • Limit the use of questions that can raise concerns about job security or other negative issues • Include a section at the end of the questionnaire for general comments • Test the questionnaire whenever possible on a small test group before finalizing it and distributing to a large group

  49. Other Fact-Finding Techniques • Sampling: collect examples of documents Fact: list of 100 complains errors in statement • Systematic sample (select every 20th customer for review) • Stratified sample (select 5 from each of the 4 different zip code areas) • Random sample (select any 20 customers) • Main objective of a sample is to ensure that it represents the overall population accurately

  50. Other Fact-Finding Techniques • Research • Newsgroups • Site visit Figure 3-23

More Related