620 Exam 2

Data Flow Repository Entries Include

-label or name for data flow as entered on dfd -a short description defining the data flow - a list of other repository objects grouped into categories by objects - the composition or list of data elements contained in the data flow -notes supplementing the limited space for the description -a list of locations on which the data flow appears

Direct Observation

-people are not always reliable, especially with infrequent events. -There is an example of how managers work differs from how it is described, the same way with people responding to emails. -These methods are not always possible and observation can cause people to change their ordinary behavior. -This takes a lot of time and doesn't render much data.

Nominal Group Technique

-the individuals working together to solve a problem are a group in name only. -Group members work alone to come up with ideas, and then come together and their ideas are pooled by a moderator. -End result should be a set of problems or features to address with a high level of ownership for this. -Can be added on to a typical JAD session

Major system functions

1. Capture data from different sources 2. Maintain data stores 3. Produce and distribute data to different entities or sinks 4. High level descriptions of data transformation operations

Candidate Key Naming Criteria

1. Choose a key that will not change over the life of the instance or type 2. Attribute is guaranteed not to be null 3. Avoid intelligent identifiers 4. Consider substituting single attribute keys for large composite keys

DFD Considerations

1. Completeness 2. Consistency 3. Timing considerations 4. Iterative nature of drawing dfds 5. Primitive dfd

3 parts of the decision table

1. Condition stubs: part that lists the conditions relevant to the decision 2. Action stubs: list actions that result for a given decision 3. Rules: specifies which actions are to be followed for a given set of conditions

Deliverables of Conceptual Data Modeling

1. ERD 2. Full set of entries about data object that will be stored

Basic ER constructs

1. Entities 2. Relationships 3. Attributes

Business rules 1-4

1. Entity integrity(identifier not null) 2. Referential integrity constraints 3. Domains (constraints on valid values for attributes) 4. Triggering operations (protect validity of attribute values)

Planning Game

1. How planning, analysis, design and construction are all fused to one phase 2. Unique way to capture and present system requirements and design specs. Players are Business and Development, Story Cards. 3 phases 1. Exploration 2. Commitment 3. Steering. This game is followed by the Iteration Game, played by programmers

BPR Steps

1. Identify key business processes 2. Identify specific activities that can be radically improved through reengineering (How important is the activity to delivering outcome? How feasible is changing the activity? How dysfunctional is the activity?) 3. Information technologies applied to improve processes.

Deliverables of Rdetermination

1. Information collected from conversations/observations of users 2. Existing and written information about the business 3. Computer based information: JAD session results Case Repository contents ect

DFD Rules

1. Inputs to a process are different from outputs of that process 2. Objects on a dfd have unique names

Not Considered for external entities

1. Interactions occurring between entities 2. What external entity does with data 3. How to control or redesign an external entity 4. How to provide entities direct access to stored data

Procedures for decision tables

1. Name the conditions and the values that each condition can assume 2. Name all possible actions that can occur 3. List all possible rules 4. Define actions for each rule 5. Simplify the decision table

Guidelines for naming attributes

1. Noun 2. Unique within attributes 3. Follow standard format 4. Similar attributes of different entity types should use similar but distinguishing names

Answers in Documents

1. Problems with existing systems 2. Opportunities to meet new needs if certain information was available 3. Organizational direction 4. Titles and names of key individuals involved 5. Values or the organization who can help determine priorities 6. Special information processing circumstances that occur irregularly 7. The reason current systems are designed why they are and why things were left out 8. Data rules for processing data, and principles that must be enforced by the system

Advantages to keeping business rules in the repository

1. Provide for faster application development with few errors 2. Reduce maintenance effort and expenditures 3. Provides for faster response to business changes 4. Facilitates end user involvement in developing new systems and manipulating data 5. Provides for consistent application of integrity constraints 6. Reduces the time and effort required to train application programmers 7. Promotes ease of use of a database

Guidelines for entity type names

1. Singular noun 2. Descriptive and specific 3. Concise 4. Result of event, not process of it

Guidelines for entity type descriptions

1. Statement of what unique characteristics are for each instance of entity type 2. What entity instances are included and not included in the type 3. When the instance for the type is created and deleted 4. When an instance might change into an instance of another entity type 5. What history is to be kept about the entity instance

Key questions to ask to develop accurate data models

1. What are the subjects of the business? 2.What unique characteristic separates objects 3. What characteristics describe each object? 4. How do you use this data? 5. Over what period of time are you interested in this data? 6. Are all instances of each object the same? 7. What events occur that imply associations among various objects? 8. Is each activity or event always handled the same way or are there special circumstances?

Guidelines for defining attributes

1. What attribute is and why it is important 2. What is included and what is not 3. Any aliases or alternative names 4. Source of values for the attribute 5. If a value for the attribute is required or optional 6. If value of attribute may change 7. Relationships attributes have with eachother

Interview Guidelines

1. don't phrase a question in a way that implies a right or wrong answer 2. Listen carefully to what is being said 3. Type notes on interview within 48 hours 4. Don't set expectations about the new or replacement system 5. Seek a variety of users of the system

Group Interview Advantages

1. more efficient use of time 2. Synergies can occur from hearing the ideas and opinions of other people

Prototyping Drawbacks

1. tendency to avoid creating formal documentation of system reqs, 2. can become idiosyncratic and difficult to diffuse or adapt, 3. often built as standalone systems 4. sharing and scalability problems, 5. checks in SDLC are bypassed so more subtle requirements may be forgotten

Guidelines for naming Relationships

1.verb phrase 2. Avoid vague names 3. What action is being taken and possibly why it is important 4. Give examples to clarify action 5. Explain any optional participation 6. Explain reason for explicit maximum cardinality other than many 7. Explain restrictions on participation in the relationship 8. Explain extent of history that is kept on relationship 9. Explain whether an entity instance can transfer participation to another relationship instance

Joint Application Design

1970 IBM, collect system requirements simultaneously from key people involved. End result is a set of documents depicting the workings of the current system in relation to a new system -analysts may also walk away from JADs with some detailed information about what is desired for another system

Bill of Materials Structure

Common unary relationship.

Agile Requirements Determinations

Continual user development, Agile Usage Centered Design, Planning Game (part of eXtreme Programming)

Iterative Development for DFD

Count on drawing a DFD multiple times to capture all elements of a system

Level N Diagram

DFD that is a result of N nested decompositions from a level 0 process

Timing for DFD

Draw the DFD as if the data movement never started and never stops

Entity Types vs Instances

Entity type: collection of entities that share common properties of characteristics Entity Instance: A single occurance of an entity type.

Key Business Processes

First step in BPR effort. Structed set of measurable activities designed to produce a specific output for a particular customer or market.

Do not need to know

How or when data is processed or used to do data modeling

DFD for Business Process Reengineering

IBM processes looked at as tedious and wasteful. DFDs allowed for easy process break down

RDetermination Characteristics

Imperitance:Question everything, Impartiality:Find the best solution to a business problem not to justify a specific one, relax constraints:assume anything is possible and eliminate the infeasible, Attention to detail: every fact must fit with every other fact-one element out of place means the best system will fail at sometime, Reframing:challenge yourself to look at the organization in a new way

Contemporary methods of System Requirements

JAD session, Case Tools, prototyping

Primitive DFD

Lowest level, no more breaking down can occur

E-R

Most common use for data modeling, primary deliverable of the analysis phase "A detailed logical representation of the entities, associations and data elements of an organization's business area"

Conceptual Modeling Process Matched with SDLC

Planning: Only entities. Analysis: Attributes too. Design: logical data model and physical and database design. Implementation: Database and file definitions, DBMS code. Maintenance: Data model evolution.

Gap Analysis

Process of discovering discrepancies between two or more sets of DFDs or within a single one. Often DFDs are used to discover redundancies. Inefficiencies can also be found. Also, DFDs for old systems can be compared with new DFDs

Evolutionary prototyping

Prototype can serve as the basis for the produced system. Prototype eventually becomes the actual working system. Start with most difficult system parts. Systems will always need to: 1. facilitate database access, 2. database integrity, 3. system security, 4. networking, 5. scalability, 6. multiuser support 7. multiplatform support. 90% of system's functioning is devoted to exceptional cases.

Disruptive technologies

Technologies that enable breaking long held business rules that inhibit organizations from making radical business changes

Lost Soft Drink Sales

The driver did not get enough time for "Shmoozing." All this to say without observation, process understanding may not be complete

Business Process Reengineering

The search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services. 1990s fad. Eliminate unnecessary steps, achieve synergies and become more responsive to the future. Example of a European Golfer Coming to America. Cannot be done by tweaking the old system but instead starting from scratch

Triggering Operations

Trigger. Assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete. Typically include the following components: 1. User rule 2. Event 3. Entity name 4. Condition 5. Action

Supertype

a generic entity type that has a relationship with one or more subtypes

Decision Table

a matrix representation of the logic of a decision. Specifies possible conditions for the decision and resulting actions

Repeating group

a set of two or more multivalued attributes that are logically related

Subtype

a subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings (Graduate Student and Undergrad Student are subtypes are Student)

Candidate key Identifiers

an attribute or combination of attributes that uniquely identify each instance of an entity type

Documents describing the current system

another important document that can be made up of data flows, case tool reports, user manuals ect.

Entities can consist of

another organization, a person outside business, other information system

Report

another useful document that is generated by a current system -work backward from the info on the report to the data necessary to issue them

Business Form

another useful document. Forms are for all business functions. They indicate the data flow in and out of a system. Forms are most useful when they can contain actual org data

Data Model Must include

any data flows that have been captured in a dfd. Each data store in a process model must relate to an ERD entity

Composite attribute

attribute such as an address with meaningful component parts, also could be a name

Derived attribute

attribute that can be derived from other data in the data base. (Employee age based on employee birthdate)

Multivalued attribute

attribute that may take on more that one value for an entity instance (ex. Employees have many skills.

Functional Decomposition

breaking description of a system into finer and finer detail, creating a set of charts in which once process on a given chart in explained in greater detail in another chart

DFD Balancing

conservation of inputs and outputs as DFD are decomposed to lower levels.

Data Store

data at rest

Data flow

data in motion

Conceptual Data Model

detailed model capturing the overall structure of organizational data that is independent of any database management system or other implementation considerations. -typically done in parallel as other requirement analysis and structing steps

Analysis Paralysis

development project bogged down by an abundance of analysis work(this is why JAD and Prototyping were developed)

Group Interview Disadvantages

difficulty in scheduling the interview (videoconferencing can help with this)

Associative Entity

entity type that associates the instances of one or more entity type and contains attributes that are peculiar to the relationship between those entity instances, GERUND

Consistency of DFD

extent to which information contained in one level of a DFD is included on other levels

Source/sink

external entity

Requirements determination

gather information on what the system should do from as many sources as possible, including current users, observing users, reports, forms and prodedures, can be thought of like conducting an investigation

ERD

graphical representation of an ER model

Process Modeling

graphically representing functions or processes in a system. Tells what you've learned during your requirements determination

Indifferent Condition

in a decision table, this is a condition whose value does not affect which actions are taken for two or more rules

Prototyping

iterative process involving analysts and users whereby rudimentary versions of info systems are built and rebuilt according to user feedback. This can REPLACE or AUGMENT it. Quickly make working versions -good chance to capture users requirements

Identifier

key that has been selected as unique and identifies an entity type

Binary Relationship

most common relationship. One to one, one to many, many to many.

CASE Tools

most useful JAD CTs are for diagramming and form and report generation -more interaction between analysts and users the better -give graphic view of ideas and requirements to the users. -The same CTs are valuable when doing requirement determination AND structuring. -CASE tools can capture info more flexibly than a scribe

Attribute

named property or characteristic of an entity that is of interest to the organization

Degree of relationships

number of entity types that participate in a relationship

Data Flow Diagram

one method of process modeling. A picture of the movement of data between external entities/processes/data stores. Primary deliverable. Not as good as flowcharts for depicting details of physical systems. Good for purely logical info flows. No problem of premature system design

Context level diagram

overview of organizational system showing the system boundaries, external entities that interact with a system and major information flows.

Interviewing & Listening

prepare before the interview, prepare an interview guide/checklist,

Close ended questions

provide a range of answers from which the interviewee may choose. Work well when the major answers to questions are well known, work on a smaller time commitment-more topics covered. Can be good to start an interview off this way which will then guide open ended questions. Can be 1. True or false 2. Multiple choice 3. Rating a response or idea on a scale 4.ranking items in order of importance

Open ended questions

questions in interviews with no prespecified answers which are used to probe for information for which you cannot anticipate all possible responses/don't know what to ask advantages: 1. Previously unknown information may surface 2. Often put interviewees at ease/give them more a sense of involvement or control. A disadvantage is the amount of time these take

Unary Relationships

recursive relationships. Relationships between instances of one type. (ex. Person_Id ----is married to---- Person_id.)(EmployeeID manages EmployeeID)

Systems analysis phases

requirements determination & requirements structuring

Bottom Up Approach

review specific business documents and reports. These are the items that appear on data flows of dfds

Domain

set of all data types and values that an attribute can assume Advantages: 1. Verify the values for an attribute are valid 2. Ensure various data manipulation operations are logical 3. Help conserve effort in describing attribute characteristics

Class Diagraming

similar to ERD but used for object oriented development approach.

Agile Usage Centered Design

similar to JAD session, focuses on user roles, goals and processes necessary to achieve those goals. Two most effective aspects are 1. Venting sessions 2. The use of 3x5 cards used as communication tools

Ternary Relationships

simultaneous relationship among instances of three entity types

Business Rules

specifications that preserve the integrity of the logical data model

Primitive DFDs

stop when you have... 1. Reduced each process to a single decision or action 2. Data store represents one entity 3. System user doesn't want more detail 4. What every dataflow does not need to be split further 5. When you believe you have shown each business form or screen 6. When there is a separate process for each choice on lowest level menu options

formal systems

the official way a system works as described in organizational documents

Throwaway prototyping

the prototype is only used as a model and is discarded. Most useful when: 1. user reqs are not clear, 2. one or few users are involved, 3. possible designs are complex and require concrete form to fully evaluate, 4. communication problems have existed in the past, 5. tools and data are readily available

informal system

the way the system actually works -develop because of inadequacies of formal procedures, individual work habits/preferences, resistance to control and other factors

Top Down Approach

typically basis for a purchased data model. Derives business rules from an intimate understanding of the nature of the business.

Continual User Involvement

user is continuously involved, best used in conjunction with the analysis-design-code-test cycle. Used when the Boeing 757 was being created