IS 421 Information Systems Analysis

IS 421Information Systems Analysis James Nowotarski 7 October 2002

Today’s Objectives • Understand basics of data modeling: • Defining entities • Defining attributes • Defining relationships • Drawing entity-relationship diagrams (ERDs)

Course Map Contents 1. Introduction Planning Phase 2. Project Initiation 3. Project Management Analysis Phase 4. Systems Analysis 5. Gathering Information 6. Process Modeling 7. Data Modeling 1 2 3 4 5 6 7 8 9 10 11 Week Core Exam Review Assignments Quizzes Final

Today’s agenda Topic Duration • Recap Last Week 20 minutes • Recap Assignments 1-2 10 minutes • Quiz 45 minutes *** Break 15 minutes • Data Modeling: Lecture/Discussion 45 minutes • Data Modeling: Group Exercises 45 minutes • Assignment 3 Intro 10 minutes

Today’s agenda Topic Duration • Recap Last Week 20 minutes • Recap Assignments 1-2 10 minutes • Quiz 45 minutes *** Break 15 minutes • Data Modeling: Lecture/Discussion 45 minutes *** Bears vs. Packers begins • Data Modeling: Group Exercises 45 minutes • Assignment 3 Intro 10 minutes

Planning Analysis Design SDLC The systems development life cycle (SDLC) is a description of the phases of an information system Implementation

Key Definitions • The As-Is system is the current system and may or may not be computerized • The To-Be system is the new system that is based on updated requirements

Analysis Phase

Develop ProcessModel Prepare Proposal Develop Data Model Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Analysis Phase From Planning Phase: Develop Concept for To-Be System System request Feasibility analysis Workplan . . . To Design Phase: Deliverables: Analysis Plan Functional Requirements Quality Requirements Data Model Process Model System Proposal System Concept

Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Develop Data Model Develop ProcessModel Prepare Proposal Analysis Phase From Planning Phase: Develop Concept for To-Be System System request Feasibility analysis Workplan . . . To Design Phase: Specify Gather Analyze

Three Fundamental Analysis Strategies • Business process Automation (BPA) • Business Process Improvement (BPI) • Business Process Reengineering (BPR)

High-Level Work Plan for Analysis

Table of contents Executive summary System request Work plan Analysis strategy Recommended system Feasibility analysis Process model Data model Appendices Begin with the End in Mind System Proposal Outline

Information Gathering Techniques • Interviewing • Joint application design • Questionnaires • Document Analysis • Observation

Interviews -- Five Basic Steps • Selecting Interviewees • Designing Interview Questions • Preparing for the Interview • Conducting the Interview • Post-Interview Follow-up

Types of Questions Examples Closed-Ended Questions * How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions * What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions * Why? * Can you give me an example? * Can you explain that in a bit more detail? Types of Questions

Interview Report INTERVIEW REPORT Interview notes approved by: ____________ Person interviewed ______________ Interviewer _______________ Date _______________ Primary Purpose: Summary of Interview: Open Items: Detailed Notes:

JAD Key Ideas • Allows project managers, users, and developers to work together • May reduce scope creep by 50% • Avoids requirements being too specific or too vague

Joint Application Design (JAD) Important Roles • Facilitator • Scribe

JAD Meeting Room JPEG Figure 5-5 Goes Here

Questionnaire Steps • Selecting participants • Using samples of the population • Designing the questionnaire • Careful question selection • Administering the questionnaire • Working to get good response rate • Questionnaire follow-up • Send results to participants

Document Analysis • Provides clues about existing “as-is” system • Typical documents • Forms • Reports • Policy manuals • Look for user additions to forms • Look for unused form elements

Observation • Users/managers often don’t remember everything they do • Checks validity of information gathered other ways • Behaviors change when people are watched • Careful not to ignore periodic activities • Weekly … Monthly … Annual

Interviews JAD Questionnaires Document Observation Analysis Type of As-Is As-Is As-Is As-Is As-Is Information Improve. Improve. Improve. To-Be To-Be Depth of High High Medium Low Low Information Breadth of Low Medium High High Low Information Integration Low High Low Low Low of Info. User Medium High Low Low Low Involvement Cost Medium Low- Low Low Low- Medium Medium Selecting the Appropriate Techniques

Summary • There are five major information gathering techniques that all systems analysts must be able to use: Interviews, JAD, Questionnaires, Document Analysis, and Observation. • Systems analysts must also know how and when to use each as well as how to combine methods.

Develop ProcessModel Prepare Proposal Develop Data Model Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Data Modeling in the Analysis Phase From Planning Phase: Develop Concept for To-Be System System request Feasibility analysis Workplan . . . To Design Phase: Deliverables: Analysis Plan Functional Requirements Quality Requirements Data Model Process Model System Proposal System Concept

Key Definitions • A data model is a • Formal representation of the data to be used for a business system. • A data model should illustrate: • The people, places and things about which data is collected, • And how they are related to each other

Key Definitions • A logical data model shows the logical organization of data • Without regard for how data gets stored, created or manipulated • A physical data model shows how the data will physically be stored in the database (secondary memory). • E.g. Oracle may store a customer table in several files (cust1.dbf, cust2.dbf…) that span several hard drives.

Key Definitions The collective output from logical data modeling is called various names • Logical data model (Wixom and Dennis) • Data model • Conceptual data model • Entity model • Entity-relationship model • Entity-attribute-relationship model • Information model • Semantic data model

Data Modeling A logical data model deliverable includes an ERD and descriptions of entities, attributes, and relationships • Entity-relationship diagram (ERD) • Entity descriptions • Attribute descriptions • Relationship descriptions • Domain descriptions (not covered here) Components of a Logical Data Model

An ERD Example

What Is an Entity? • Entities generally represent people, places, and things of interest to the organization (about which we would like to collect data). • Represented as rectangle on the ERD • Named with a singular noun (e.g., Patient)

Entities and Instances Instances are occurrences of an entity

What is an Attribute? • An attribute is a characteristic or property of an entity. • Attributes contain information that describes an entity. • Attribute names are nouns (e.g, “name”). • Sometimes entity name is added at the beginning of the attribute name (e.g., “vendor_name”).

Examples of Attributes • Entity: Person • Attributes: • first_name • last_name • eye_color • date_of_birth • address • Entity: Classroom • Attributes: • room_no • max_capacity

An ERD Example

Identifiers • An identifier uniquely identifies each instance of the entity. It may consist of one or more attributes. • Identifiers are also known generically as keys • Candidate keys = all identifiers for an entity • Primary key = candidate key designated as “official” identifier

Examples of Identifiers • What attribute uniquely identifies every instance of these entities? • Student • Classroom • Vehicle

Depicting Entities, Attributes and Identifiers Entity name Identifier Or, use cd_id (PK) Attributes

An ERD Example

Relationshipsrepresent connections, links, or associations between entities e.g., Patient-Appointment Relationships have some important properties: Names, that should be active verbs (A patient schedules appointments) Cardinality Modality. Relationships

Cardinality refers to the number of times instances in one entity can be related to instances in another entity One instance in an entity refers to one and only one instance in the related entity (1:1) One instance in an entity refers to one or more instances in the related entity (1:M) One or more instances in an entity refer to one or more instances in the related entity (M:M) Cardinality

Modality refers to the minimum number of times that an instance in one entity can be related to an instance in another entity One means that an instance in the related entity must exist for an instance in another entity to be valid Zero means that no instance in the related entity is necessary for an instance in another entity to be valid Modality

Some Ways to Depict Relationships Patient Appointment 1 M Patient Appointment Same schedules Patient Appointment e.g., A patient may have zero to many appointments schedules Patient Appointment Is scheduled by

Meanings of the Crow’s Feet Cardinality MinMax 0 1 1 1 0 M[any] 1 M[any]

The Entity-Relationship Diagram (ERD)

IS 421 Information Systems Analysis