C H A P T E R

2. Chapter Five Objectives: What are information systems, and who are the stakeholders in the information systems game? Define systems analysis and relate the term to the preliminary investigation, problem analysis, requirements analysis, and decision analysis phases of the systems development methodology. Describe a number of systems analysis approaches for solving business system problems. Describe the preliminary investigation, problem analysis, requirements analysis, and decision analysis phases in terms of your information system building blocks. Describe the preliminary investigation, problem analysis, requirements analysis, and decision analysis phases in terms of purpose, participants, inputs, outputs, techniques, and steps. Understand the importance of never making assumptions!

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

4. Information Systems Analysis Information systems analysis is defined as those development phases in a project that primarily focus on the business problem, independent of any technology that can or will be used to implement a solution to that problem.

5. Repository A repository is a location (or set of locations) where systems analysts, systems designers, and system builders keep all of the documentation associated with one or more systems or projects. A network directory of computer-generated files that contain project correspondence, reports, and data A CASE tool dictionary or encyclopedia Printed documentation (binders and system libraries) An intranet website interface to the above components

6. Never Make Assumptions: Nativity Scene Christmas season - independent of religious beliefs, the most recognized icon of the season is the Nativity scene. Take a moment to review the typical Nativity scene in your head. Try to describe all of the elements of the scene. Have you seen it so much that you can�t properly remember all of the pieces?? What is the correct description? Where do we find it?

7. Model-Driven Analysis Methods Model-driven analysis emphasizes the drawing of pictorial system models to document and validate both existing and/or proposed systems. Ultimately, the system model becomes the blueprint for designing and constructing an improved system. A model is a representation of either reality or vision. Just as �a picture is worth a thousand words,� most models use pictures to represent the reality or vision.

8. Model-Driven Methods Structured analysis is a model-driven, process-centered technique used to either analyze an existing system, define business requirements for a new system, or both. The models are pictures that illustrate the system�s component pieces: processes and their associated inputs, outputs, and files. Information engineering (IE) is a model-driven and data-centered, but process-sensitive technique to plan, analyze, and design information systems. IE models are pictures that illustrate and synchronize the system�s data and processes. Object-oriented analysis (OOA) is a model-driven technique that integrates data and process concerns into constructs called objects. OOA models are pictures that illustrate the system�s objects from various perspectives such as structure and behavior.

9. A Simple Process Model

10. A Simple Data Model

11. A Simple Object Model

12. Accelerated Analysis Methods Accelerated analysis approaches emphasize the construction of prototypes to more rapidly identify business and user requirements for a new system. A prototype is a small-scale, incomplete, but working sample of a desired system. Prototypes cater to the �I�ll know what I want when I see it� way of thinking that is characteristic of many users and managers.

13. Accelerated Analysis Methods Discovery prototyping (sometimes called requirements prototyping) is used to identify the users� business requirements by having them react to a quick-and-dirty implementation of those requirements. Rapid architecture analysis is an approach that attempts to derive system models (as described earlier in this section) from existing systems or discovery prototypes.  Reverse engineering technology reads the program code for a database, application program, and/or user interface and automatically generates the equivalent system model.

14. Requirements Discovery Methods Requirements discovery includes those techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community. Fact-finding (or information gathering) is a classical set of techniques used to collect information about system problems, opportunities, solution requirements, and priorities. Sampling Research Observation Questionnaires and surveys Interviews Joint requirements planning (JRP) techniques use facilitated workshops to bring together all of the system owners, system users, systems analysts, and some systems designer and builders to jointly perform systems analysis.

15. Business Process Redesign Methods Business process redesign is the application of systems analysis methods to the goal of dramatically changing and improving the fundamental business processes of an organization, independent of information technology.

16. Systems Analysis Phases Preliminary Investigation Phase Problem Analysis Phase Requirements Analysis Phase Decision Analysis Phase

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

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

19. Business Requirements A functional requirement is a description of activities and services a system must provide. A nonfunctional requirement is a description of other features, characteristics, and constraints that define a satisfactory system.

20. Logical System Models Logical system models depict what a system is or what a system must do�not how the system will be implemented. Because logical models depict the essential requirements of a system, they are sometimes called essential system models. Process models (e.g., data flow diagrams) Data models (e.g., entity relationship diagrams) Interface models (e.g., context diagrams) Object models (e.g., Uniform Modeling Language diagrams)

21. A Simple Interface Model

22. Requirements Statement

23. Feasibility Analyses Technical feasibility. Is the solution technically practical? Does our staff have the technical expertise to design and build this solution? Operational feasibility. Will the solution fulfill the users� requirements? To what degree? How will the solution change the users� work environment? How do users feel about such a solution? Economic feasibility. Is the solution cost-effective? Schedule feasibility. Can the solution be designed and implemented within an acceptable time period?

24. Automated Tools for Systems Development

25. Learning Objectives Identify the trade-offs when using CASE Describe organizational forces for and against adoption of CASE tools Describe the role of CASE tools and how they are used to support the SDLC List and describe the typical components of a comprehensive CASE environment Describe the general functions of upper CASE tools, lower CASE tools, cross life-cycle CASE tools and the CASE repository

26. Learning Objectives Describe visual and emerging development tools and how they are being used

27. Introduction Computer-aided Software Engineering (CASE) Automated software tool used by systems analysts to develop information systems Used to support or automate activities throughout the systems development life cycle (SDLC) Increase productivity Improve overall quality of systems

28. The Use of CASE in Organizations Purpose of CASE is to facilitate a single design philosophy within an organization

29. The Use of CASE in Organizations Objectives of CASE Improve quality of systems developed Increase speed of development and design Ease and improve testing process through automated checking Improve integration of development activities via common methodologies Improve quality and completeness of documentation Help standardize the development process Improve project management Simply program maintenance Promote reusability Improve software portability

30. CASE and System Quality Majority of organizations adopt CASE to improve speed and quality of systems development projects Widespread deployment has been slower than expected

31. CASE and System Quality Several factors that inhibit widespread deployment Cost Between $5,000 and $15,000 per year to provide CASE tools to one systems analyst Return on Investment Biggest benefits of CASE come in late stages of SDLC Productivity Bottlenecks Inability of some tools to share information Difficulty in providing tools for all stages of SDLC

32. The Outlook for CASE Functionality is increasing Cost is decreasing Reverse Engineering Tools Automated tools that read program source code as input and create graphical and textual representations of program design-level information Reengineering Tools Automated software that reads program source code, analyzes it and automatically or interactively alters an existing system to improve quality and/or performance

33. Components of CASE Upper CASE CASE tools designed to support the information planning and the project identification and selection, project initiation and planning, analysis and design phases of the systems development life cycle Lower CASE CASE tools designed to support the implementation and maintenance phases of the systems development life cycle

34. Components of CASE Cross life-cycle CASE CASE tools designed to support activities that occur across multiple phases of the systems development life cycle Most CASE tools utilize a repository to store all diagrams, forms, models and report definitions

35. Components of CASE Types of CASE tools Diagramming tools Computer display and report generators Analysis tools used to check for incomplete, inconsistent or incorrect specifications A central repository Documentation generators Code generators

36. Components of CASE Security Features Version Control Import/Export Backup and Recovery

37. CASE versus Traditional Systems Development Traditional approach does not offer support for integration of specification documents Often, documentation is done after coding is completed in traditional systems development Traditional approach often leads to out- of-date documentation

38. CASE versus Traditional Systems Development Traditional Systems Development Emphasis on coding and testing Paper-based specifications Manual coding of programs Manual documenting Intensive software testing Maintain code and documentation CASE-Based Systems Development Emphasis on analysis and design Rapid interactive prototyping Automated code generation Automated documentation generation Automated design checking Maintain design specifications

39. CASE Diagramming Tools Enable representation of a system and components visually Effective for representing process flows, data structures and program structures Several types of diagrams Data Flow Diagrams (DFD) Functional Hierarchy Diagrams Entity-Relationship Diagrams

40. CASE Form and Report Generator Tools CASE tools that support the creation of system forms and reports in order to prototype how systems will look and feel to users Two Purposes Create, modify and test prototypes of computer display forms and reports Identify which data items to display or collect for each form or report

41. CASE Analysis Tools Enable automatic checking for incomplete, inconsistent or incorrect specifications in diagrams, forms and reports. Types of analyses vary depending on the organization�s development methodology and features of CASE environment

42. CASE Repository Integrated CASE (I-CASE) Automated systems development environment that provides numerous tools to create diagrams, forms and reports Provides analysis, reporting and code generation facilities Seamlessly shares and integrates data across and between tools Repository is central place to store information to share between tools

43. CASE Repository Holds complete information needed to create, modify and evolve a software system from project initiation and planning to code generation and maintenance Two Primary Segments Information Repository Data Dictionary

44. CASE Repository Information Repository Combines information about an organization�s business information and its application portfolio Provides automated tools to manage and control access to repository Business Information Data stored in corporate databases Application Portfolio Application programs used to manage business

45. CASE Repository Data Dictionary Computer software tool used to manage and control access to the information repository Contains all data definitions for all organizational applications Cross referencing Enables one description of a data item to be stored and accessed by all individuals Single definition for a data item is established and used

46. CASE Repository Data Dictionary Entries have a standard definition Element name and alias Textual description of the element List of related elements Element type and format Range of acceptable values Other information unique to the proper processing of this element

47. CASE Repository CASE Repository and the SDLC During project initiation and planning phase, all information related to the problem being solved is stored in the repository Problem domain, project resources, history and organizational context During analysis and design phases, store graphical diagrams and prototype forms and reports Data stored in repository are used for basis to generate code and documentation

48. CASE Repository Additional Advantages Assistance with project management tasks Aids in software reusability The ability to design software modules in a manner so that they can be used again and again in different systems without significant modification

49. CASE Documentation Generator Tools Enable the easy production of both technical and user documentation Allow creation of master templates used to verify that documentation conforms to all stages of SDLC

50. CASE Code Generation Tools Enable the automatic generation of program and database definition code directly from the design documents, diagrams, forms and reports stored in the repository

51. Visual and Emerging Development Tools Object-Oriented Development Tools Object A chunk of program and data that is built to perform common functions within a system Easily reused Encapsulation Process of grouping data and instructions together Development environment includes pre-defined objects and facilitates reuse of code

52. Visual and Emerging Development Tools Visual Development Tools Enable developers to quickly create user interfaces Popular tools include: Microsoft Visual Studio Delphi Powerbuilder ColdFusion

53. Summary Use of CASE in Organizations Categories of CASE Tools Reverse Engineering Re-engineering Components of CASE Upper CASE Diagramming tools Form and report generators Analysis tools

54. Break

55. INFORMATION GATHERING FOR INFORMATION SYSTEMS DEVELOPMENT

56. Lecture Objectives to be aware of various methods for data gathering in respect of information system development to understand the usefulness and suitability of various data gathering methods for particular problem situations

57. Data gathering in systems development Data gathering is a major task of systems analysis. Systems analysis involves: Understanding and describing how the current system functions Determining what users would like their new system to do (requirements) Need to collect information: current and future situations, problems, opportunities, constraints

58. Data gathering as a foundation for developing information systems What data? Sources of data? What data gathering methods? What strategy for gathering data is needed? How will the data gathered be analysed?

59. Data about the business or organisation Data about the business environment Data about the system�s environment Data about the users of the system Data about the current system Data about the proposed system Constraints: e.g. cost, technical,timeframe What data to gather?

60. What data to gather? The business or organisation: Data about the nature of the business and its market and business environment Data about business goals and objectives that dictate what and how work is done Data about organisational structure: major functions, departments etc Data about major business subsystems and how they interact Data about business policies and guidelines

61. Users of the system: Roles and responsibilities Reporting structures Job specifications and actual tasks performed Information needed to do their jobs Formal and informal communication and workflow channels What data to gather?

62. Users of the system: Data about roles and responsibilities Data about reporting structures Job specifications and data about actual tasks performed Data about information needed to do their jobs Data about formal and informal communication and workflow channels What data to gather?

63. The existing system: Data about tasks and workflow: functions, processes, sequence of processes, methods and procedures, inputs, outputs Data about the data (definition, volumes, size etc.) Data about interactions with other systems Data about work volumes and processing cycles Data about performance standards and criteria Data about control mechanisms: e.g security, accuracy Data about problems: e.g. efficiency, information What data to gather?

64. The new system: Data about system requirement: a need or desire to be met by a proposed system Data about both functional requirements (processes and functionality) and non-functional requirements (security, performance, service etc.) Data about constraints e.g. existing technology Data about interactions with other systems Data about relationship to existing system/s What data to gather?

65. Sources of data Users and other stakeholders Documents about the system Documents about the organisation Documents and data used within the existing system Transactions within existing system External sources

66. Users System sponsor/owner: overall project objectives Managers: high level, broad view of existing system and requirements End-users: detailed, operational level view of existing system and requirements Technical staff: technology capaabilities, limitations etc. External stakeholders: e.g. customers Sources of data

67. Documents about the system and organisation: Organisation charts Policy manuals Business reports: financial, annual etc. Jobs, procedure, operations manuals Training manuals Existing system documentation Internal reports relating to the system Sources of data

68. Documents and data used within the existing system: Files, databases, programs, forms, reports Informal: Memos, bulletin boards, files External sources: Other organisations� systems Hardware & software vendors Business & industry publications Sources of data

69. Interviews Questionnaires Observation Sampling documents and transactions Research and site visits

70. Generally the most important and widely-used method for data gathering May be formal/structured (specific questions) or informal/unstructured (general goal or purpose) Need an interview strategy for the entire interviewing process Need an interview plan or guide for each interview

71. The interview strategy Identify the users to interview: Do this after you have an initial understanding of the organisation and system Establish general objectives and guidelines for the entire interviewing process: e.g. information to be obtained, sources, formats, documenting, analysis Ensure all key people are included

72. Determine the sequence of interviews: E.g. management first: broad overview of system operations gain support and co-operation help to identify who to interview next Then system users: obtain information about detailed operations Co-ordinate the interviewing process: Compare results, select follow ups etc. The interview strategy

73. The interview strategy Need individual interview plans: Initial interviews to meet users Fact gathering interviews Follow up interviews Interview plans: Decide on interview structure Determine content of questions Decide on question types

74. Interviews Need to consider: Who has the information you need? Where to conduct the interview? When is the best time to interview? How should the interview progress?

75. The individual interview Before the interview: Arrange time and place, necessary materials, inform interviewee of interview purpose Conduct the interview After the interview: Write an interview report Review this with the interviewee at a follow up interview

76. The interview structure Preliminaries: Introduction, purpose, environment and procedures e.g. permission to tape �Body�: Define what you already believe to be true and confirm this, explore points & issues further, new areas (questions) Conclusion: Summarise and confirm your findings Schedule a follow up interview

77. Interviews: types of questions Closed: how many transactions per day? Limits available responses Open: tell me about �.. Leaves options open for interviewee Probe: tell me more about the problem with the �. To clarify and expand Mirror: From what you said, I understand that�. To confirm what was said etc.

78. Interviews: types of questions Avoid long, complex, or double-barrelled questions: what decisions are made during this process and how do you make them? Avoid leading questions; you don�t need the customer number on this report, do you? Avoid loaded questions: when did you first discover the mistake? i.e. how long have you known and done nothing?

79. Interviews: advantages obtain extensive, complex detailed information get insights and opinions discover informal procedures flexible e.g. explore issues further or new issues establish rapport with interviewee and understand their attitudes reveal the �politics� of the system environment information is revealed both by the spoken word and by the interviewee�s body language guaranteed response

80. Interviews: Disadvantages Time-consuming Costly Danger of bias More difficult to tabulate and analyse results e.g. to obtain an overall picture Success in interviewing depends on the inter-personal skills of the interviewer

81. A structured method of data gathering in which written questions/comments are provided for the participants to respond to in written form The questionnaire can take many forms - write comments/ select from a list of possible responses/ mark on a scale May permit either quantitative or qualitative data (mark out of 10/grade from good to bad) Usually involves no direct contact between data gatherer and respondents

82. Questionnaires Useful when small amounts of data are required from a large number of people For geographically dispersed respondents Types of questions: Open-ended (free format) Fill-in-the-blank Multiple choice Rating Ranking

83. Designing questionnaires What facts and opinions to be collected Who to sample and sample size Types of questions and wording (precise, accurate, unambiguous) How to administer e.g. paper, online, mail out etc. Format and layout (grouping, crosschecks etc.) Test on small sample of respondents How completed questionnaires will be returned and collated How analysis of the data will be carried out

84. Questionnaires Useful for: Obtaining simple opinions, facts Quantifying what was found in interviews Identifying issues before interviewing Determining extent of problems Not useful for detailed or complex information or exploring issues in depth Can supplement other methods

85. Questionnaires: advantages most economical method for gathering data from large numbers of people quick and easy to administer results can be tabulated rapidly and analysed readily allow respondents to be anonymous gives respondents time to reflect on answers respondents complete in their own time

86. Questionnaires: disadvantages difficult to construct effective questionnaires specific and limited amounts of information possible low return rates possible bias and misinterpretation cannot probe issues further (inflexible) cannot clarify vague or incomplete answers lack non-verbal communication

87. Observation observing the actual processes of a system need to prepare beforehand, and report on data collected gain first hand knowledge of current system�s operations clarify other information collected understand complex procedures inexpensive behaviour distortions may affect reliability unrepresentative samples affect reliability

88. Sampling of documents and transactions Sampling: collecting a representative sample of documents, forms, transactions Useful for specific information e.g. transaction volumes and types, file sizes Useful where large volumes exist Information about existing system operations Representative samples must be selected: determine sample size, appropriate range, avoid bias

89. Research and site visits Most problems not unique: learn from experiences of other organisations Professional societies can provide contacts for site visits Computer trade journals and magazines and the internet can be sources for research into the problem/s e.g. do appropriate software packages exist?

90. Other data gathering methods Other �modern� methods used: Discovery prototyping JAD (Joint Application Development) sessions Focus groups

91. A data gathering strategy Data gathering must be carefully planned in order to make the most of the time and resources available: Information sources Data gathering methods Recording and documentation methods Data analysis methods Procedures for reviewing results with management and users

92. A data gathering strategy E.g. a �top down� approach: Initial interviews with management to determine major system activities and data Document and verify this Expand major system component descriptions into detailed descriptions: Interview operational users, sampling, questionnaires, observation etc Document and verify this Repeat these last two steps as necessary Review findings with management

93. A data gathering strategy Consider costs: allow for time and resources required for initial and ongoing information gathering Use the least expensive methods first Plan how to check the validity of data: Cross checking between groups, methods Evaluate data for inconsistencies Ask further questions Plan documentation of data e.g. records of interviews etc. data dictionary, system models

94. Data gathering in practice Completeness? Accuracy? Objectivity? Biases? Stability? Representative? Finished?