SYSTEMS PRESENTATION to help you in design
- 1. College of Information Technology United Arab Emirates University
- 2. 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 2 Chapter Objectives
- 3. 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 Define total cost of ownership (TCO) Conduct a successful interview Develop effective documentation methods to use during systems development 3 Chapter Objectives (Cont.)
- 4. 4 Systems Analysis Phase Overview Systems Analysis Phase Overview Understand the proposed project Ensure that it supports business requirements Build a solid foundation for system development Systems Analysis Activities Requirements Modeling (chapter 4) Data and Process Modeling (chapter 5) Object Modeling (chapter 6) Development Strategies (chapter 7)
- 5. 5 Systems Analysis Phase Overview (Cont.) 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 Requirements Modeling Fact-finding to describe the current system Requirements for new system Data and Process Modeling Graphically represent system data and processes Object Modeling Create objects to represent things, transactions and events Development Strategies Software trends, development alternatives, outsourcing, etc.
- 6. Systems Analysis Phase Overview (Cont.) A requirement is a software capability needed by the user to solve a problem to achieve an objective Examples: The user shall be able to search either all of the initial set of databases or select a subset from it The system shall provide appropriate viewers for the user to read documents in the document store The system shall respond to search query within 0.03 ms The language of development shall be Java 6
- 7. 7 Systems Analysis Phase Overview (Cont.) System Analysis Skills Strong analytical skills Interpersonal skills Team-Based Techniques: JAD, RAD, and Agile Methods The Objective is to deliver the best possible system at the lowest possible cost in the shortest possible time Joint application development brings users into the design process Rapid application development uses a condensed version of the system development life cycle Agile methods stress intense interaction between developers and users
- 8. Requirements Management A systematic approach to elicitation, organizing, and documenting the requirements of a system and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system
- 9. Requirement Management Road Map 9 Needs Features Software requirements Problem domain Solution domain
- 10. Problem Domain (the home of the system users) and Stakeholder needs (what the users need from the system) System Features: a system service that fulfill one or more user needs the car will have power windows. the system has to be web-based. Software Requirements (more specific ) 10 RequirementManagementroad map (2)
- 11. System feature Vs. SW Requirement A feature tends to be a “higher-level” objective than a requirement – and is usually more focused on business needs rather than implementation. Example: Let’s say you’re designing an online bookstore to compete with Amazon Feature-1: click ordering Related requirements to this feature: User shall be able to activate 1-click ordering within his account User shall be able to deactivate 1-click ordering within his account User shall be able to order books with just 1 click User shall be able to “Undo” his 1-click order for a period of 30 minutes from the time he placed such an order
- 12. System Analysis Overview SA is part of the SDLC or Development Process Many Processes have been introduced Waterfall model V-Model Rapid Prototype Spiral model Agile methods 12
- 13. The Waterfall Model Requirements/ Specifications Verify Integration Test Retirement Design Verify Software Requirements Specifications Implementation Test Design Document Software Units Operation Software Systems and manuals 13 A return in the development process was only possible to an immediate previous phase
- 14. V-Model
- 15. Rapid Prototype
- 17. Iterative and Incremental Approach Iteration: Sequence of activities with an established plan and evaluation criteria resulting in executable of some type In iterative mode: Activities are organized as workflows Workflow is a logically related set of activities Time
- 18. 18 Joint Application Development Brings users into the development process as active participants User Involvement (formally or informally) creates a successful system JAD is used whenever group input and interaction are desired JAD Participants and Roles Project leader and one or more members Participants insulated from distractions of day-to-day operations
- 19. 19 Joint Application Development (Cont.) FIGURE 4-3 Typical JAD participants and roles
- 20. 20 Joint Application Development (Cont.) FIGURE 4-4 Typical agenda for a JAD session
- 21. 21 Joint Application Development (Cont.) JAD Disadvantages JAD is more expensive than traditional methods Can be cumbersome if group is too large JAD Advantages JAD allows key users to participate effectively Users more likely to feel a sense of ownership Produces a more accurate statement of system requirements
- 22. 22 Rapid Application Development Uses a group approach like JAD JAD produces a requirements model, RAD produces a new system Complete methodology 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 modified based on user input
- 23. 23 Rapid Application Development (Cont.) RAD Phases and Activities 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
- 24. 24 Rapid Application Development (Cont.) Requirements Planning Team agrees on business needs, project scope, constraints, and system requirements Management authorization to continue is obtained User Design Users interact with analysts to develop models and prototypes A combination of JAD and CASE tools are used Users understand, modify, and approve a working model
- 25. 25 Rapid Application Development (Cont.) Construction Program and application development Users can suggest changes as screens or reports are developed Cutover Includes data conversion, testing, changeover to the new system, and user training
- 26. 26 Rapid Application Development (Cont.) RAD Objectives Cut development time and expenses by involving users in every phase of systems development Allow the development team to make necessary modifications quickly, as the design evolves RAD Advantages Systems developed more quickly with significant cost savings RAD Disadvantages Does not emphasize strategic business needs (system might work well in short term but miss long-term objectives) Less time to develop quality, consistency, and design standards
- 27. 27 Agile Methods Agile methods attempt to develop a system incrementally, by building a series of prototypes and constantly adjusting them to user requirements Developers revise, extend, and merge earlier versions into the final product Emphasizes continuous feedback, and each incremental step is affected by what was learned in the prior steps
- 28. 28 Agile Methods (Cont.) FIGURE 4-6 Agilian supports various modeling tools, such as the Unified Modeling Language, use cases, and business process modeling, among others
- 29. 29 Agile Methods (Cont.) Agile Method Advantages and Disadvantages Very flexible and efficient in dealing with change Frequent deliverables constantly validate the project and reduce risk Team members need a high level of technical and interpersonal skills May be subject to significant change in scope
- 30. 30 Modeling Tools and Techniques Involves graphical methods and nontechnical language that represent the system at various stages of development Can use various tools Functional Decomposition Diagrams Functional decomposition diagram (FDD) Model business functions and show how they are organized into lower-level processes
- 31. 31 Modeling Tools and Techniques (Cont.) 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 Top-down representation of a function or process Similar to an organization chart
- 32. 32 Modeling Tools and Techniques (Cont.) Business Process Modeling Business process model (BPM) Business process modeling notation (BPMN) 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
- 33. 33 Modeling Tools and Techniques (Cont.) Data Flow Diagrams ◦ Data flow diagram (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
- 34. 34 Modeling Tools and Techniques (Cont.) Use Case Diagrams 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
- 35. 35 Modeling Tools and Techniques (Cont.) Sequence Diagrams Shows the timing of interactions between objects as they occur FIGURE 4-14 This Visible Analyst sequence diagram shows a credit card validation process
- 36. 36 What Are Requirements? System Requirements = Functional requirements Non-functional requirements Functional Requirements– the activities, functions, services,.. the system must perform Business uses, functions the users carry out Non-Functional Requirements- judges the operation of the system Constraints and performance goals
- 37. 37 FURPS+ Requirements Acronym Functional requirements Usability requirements Reliability requirements Performance requirements Security requirements + even more categories…
- 38. 38 FURPS+ Requirements Acronym (2)
- 39. 39 System Requirements Checklist Output Examples The Web site must report online volume statistics every four hours, and hourly during peak periods The inventory system must produce a daily report showing the part number, description, quantity on hand, quantity allocated, quantity available, and unit cost of all sorted by part number 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
- 40. Input Examples Manufacturing employees must swipe their ID cards into online data collection terminals that record labor costs and calculate production efficiency The department head must enter overtime hours on a separate screen Student grades must be entered on machine-scannable forms prepared by the instructor Each input form must include date, time, product code, customer number, and quantity Data entry screens must be uniform, except for background color, which can be changed by the user A data entry person at the medical group must input patient services into the billing system 40 System Requirements Checklist (Cont.)
- 41. Process Examples The student records system must calculate the GPA at the end of each semester As the final step in year-end processing, the payroll system must update employee salaries, bonuses, and benefits and produce tax data required by the IRS The warehouse distribution system must analyze daily orders and create a routing pattern for delivery trucks that maximizes efficiency and reduces unnecessary mileage The human resources system must interface properly with the existing payroll system The equipment rental system must not execute new rental transactions for customers who have overdue accounts The prescription system must automatically generate an insurance claim form 41 System Requirements Checklist (Cont.)
- 42. 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 The accounts receivable system must prepare customer statements by the third business day of the following month The student records system must produce class lists within five hours after the end of registration The online inventory control system must flag all low- stock items within one hour after the quantity falls below a predetermined minimum 42 System Requirements Checklist (Cont.)
- 43. Control Examples The system must provide logon security at the operating system level and at the application level An employee record must be added, changed, or deleted only by a member of the human resources department The system must maintain separate levels of security for users and the system administrator All transactions must have audit trails The manager of the sales department must approve orders that exceed a customer’s credit limit The system must create an error log file that includes the error type, description, and time 43 System Requirements Checklist (Cont.)
- 44. 44 Future Growth, Costs, and Benefits In addition to the system requirements, systems analysts must consider Scalability To determine how a system will handle future growth and demands Total cost of ownership includes all future operational and support costs. Important when evaluating several alternatives Problem: indirect costs tends to be underestimated
- 45. 45 Fact Finding Fact-Finding: collecting information ◦ First, you must identify the information you need ◦ Develop a fact-finding plan How to ask questions? What kind of questions? Traditional Techniques: • Research • Workshops • Brainstorming • Storyboarding • role playing • prototyping, • Interviews • document review • Observation • surveys and questionnaires • Sampling
- 46. Typical questions to ask What business functions are supported by the current system? What strategic objectives and business requirements must be supported by the new system? What are the benefits and TCO of the proposed system? What transactions will the system process? What information do users and managers need from the system? Must the new system interface with legacy systems? What procedures could be eliminated by business process reengineering? What security issues exist? What risks are acceptable? What budget and timetable constraints will affect system development? 46 Fact Finding (Cont.)
- 47. Who, What, Where, When, How, and Why? Who performs each of the procedures within the system? Why? Are the correct people performing the activity? Could other people perform the tasks more effectively? What is being done? What procedures are being followed? Why is that process necessary? Often, procedures are followed for many years and no one knows why. You should question why a procedure is being followed at all Where are operations being performed? Why? Where could they be performed? Could they be performed more efficiently elsewhere? When is a procedure performed? Why is it being performed at this time? Is this the best time? How is a procedure performed? Why is it performed in that manner? Could it be performed better, more efficiently, or less expensively in some other manner? 47 Fact Finding (Cont.)
- 48. 48 Fact Finding (Cont.) FIGURE 4-17 Sample questions during requirements modeling as the focus shifts from the current system to the proposed system
- 49. 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 49 Interviews
- 50. 50 Interviews (Cont.) Step 1: Determine the people to interview Select the right people and ask the right questions Don’t rely on just an organization chart Decide on group and/or individual interviews Step 2: Establish objectives for the interview Determine the areas to be discussed List the facts you need to gather Upper management provides the big picture Users can give you specific details
- 51. 51 Interviews (Cont.) Step 3: Develop interview questions Decide what to ask and how to phrase the question The same question to different people - for comparison Open ended questions encourage spontaneous and unstructured responses How is this task performed? Close ended questions limit the response - used to verify facts Do you review the reports before they are sent out? Range of response questions limit the response – uses a scale On a scale of 1 to 10, with 1 the lowest and 10 the highest, how effective was your training?
- 52. 52 Interviews (Cont.) Step 4: Prepare for the interview Duration: no more than one hour Confirm: time, place, length, and topics via e-mail Ask the interviewee to have samples available Step 5: Conduct the interview Distribute Agenda Begin by introducing yourself, describing the project, and explaining your interview objectives Engaged listening Allow the person enough time At the end, Summarize the session and seek a confirmation
- 53. 53 Interviews (Cont.) Step 6: Document the interview – Note taking should be kept to a minimum – After conducting the interview, you must record the information quickly – After the interview, send memo to the interviewee expressing your appreciation – Note 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
- 54. 54 Interviews (Cont.) 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 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
- 55. • Document Review • Review old and current forms and documentation • Observation – Seeing the system in action gives you additional perspective and a better understanding of the system procedures – Plan your observations in advance – Consider the Hawthorne Effect Study Productivity seemed to improve whenever workers knew they were being observed 55 Other Fact-Finding Techniques
- 56. Other Fact-Finding Techniques (Cont.) 56 Questionnaires and Surveys When designing a questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding Fill-in form FIGURE 4-23 Online version of a sample questionnaire. Does it follow the suggested guidelines?
- 57. Other Fact-Finding Techniques (Cont.) 57 Sampling Systematic sample Select every tenth customer for review Stratified sample Select five customers from each of four postal codes Random sample Any 20 customers Main objective of a sample is to ensure that it represents the overall population accurately
- 58. Other Fact-Finding Techniques (Cont.) 58 Research Can include the Internet, IT magazines, and books to obtain background information, technical material, and news about industry trends and developments Site visit
- 59. Need for Recording the Facts Record information as soon as you obtain it Use the simplest recording method Record your findings in such a way that they can be understood by someone else Organize your documentation so related material is located easily 59 Documentation
- 60. At the conclusion of requirements modeling, systems developers should have a clear understanding of business processes and system requirements The next step is to construct a logical model of the system IT professionals have differing views about systems development methodologies, and no universally accepted approach exists 60 Preview of Logical Modeling
- 61. 61 Chapter Summary The systems analysis phase includes three activities: requirements modeling, data and process modeling, and consideration of development strategies The main 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
- 62. • 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 62 Chapter Summary (Cont.)