ISYS 3293 Exam 2 Summer ch 6-14 UARK

Process of Determining System Requirements

- Gather info on what the system should do from as many sources as possible

Steps to Process Modeling

- Take information from requirements determination phase -Organize info into meaningful representation of the info system that currently exists - model processing logic

Requirements Determination using Agile Methodologies: The Planning Game

-Based on eXtreme programming -Exploration, steering, commitment

Joint Application Design (JAD)

-Brings together key users, managers, and systems analysts -Purpose: collect system requirements simultaneously from key people -Conducted off-site

Drawbacks to individual interviews

-Contradictions and inconsistencies between interviewees -Follow-up discussions are time consuming -New interviews may reveal new questions that require additional interviews with those interviewed earlier

Guidelines for Drawing DFDs: DFD Completeness

-DFD must include all components necessary for system. -Each component must be fully described in the project dictionary or CASE repository.

Purpose of Activity Diagrams

-Depict the flow of control from activity to activity. -Help in use case analysis to understand what actions need to take place. -Help in identifying extensions in a use case. -Model work flow and business processes. -Model the sequential and concurrent steps in a computation process.

Written Use Cases

-Document containing detailed specifications for a use case -Contents can be written as simple text or in a specified format -Step-by-step description of what must occur in a successful use case

End Result of JAD

-Documentation detailing existing system -Features of proposed system

Useful document: Written work procedure

-For an individual or work group -Describes how a particular job or task is performed -Includes data and information used and created in the process

Process Modeling

-Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment and among system components. -Utilize information gathered during requirements determination. -Model processes and data structures

Good Systems Analyst Characteristics

-Impertinence—question everything -Impartiality—consider all issues to find the best organizational solution -Relax constraints—assume anything is possible -Attention to details—every fact must fit -Reframing—challenge yourself to new ways

Traditional Methods for Determining Requirements

-Interviewing individuals -Interviewing groups -Observing workers -Studying business documents

System prototypes

-Iterative development process -Rudimentary working version of system is built -Refine understanding of system requirements in concrete terms

Deliverables for Requirements Determination: From computerized sources

-Joint Application Design session results -CASE repositories reports from existing systems -displays and reports from system prototype

Guidelines for Drawing DFDs: Primitive DFD

-Lowest logical level of decomposition -Decision has to be made when to stop decomposition

NGT Process

-Members come together as a group, but initially work separately. -Each person writes ideas. -Facilitator reads ideas out loud, and they are written on a blackboard or flipchart. -Group openly discusses the ideas for clarification. -Ideas are prioritized, combined, selected, reduced. Used to complement group meetings or as part of JAD effort

Procedure for Creating Decision Tables

-Name the condition and the values that each condition can assume. -Name all possible actions that can occur. -List all possible rules. -Define the actions for each rule. -Simplify the table.

Balanced DFD means

-Number of inputs to lower level DFD equals number of inputs to associated process of higher-level DFD -Number of outputs to lower level DFD equals number of outputs to associated process of higher-level DFD

Guidelines for Interviewing

-Plan the interview. +Prepare interviewee: appointment, priming questions. +Prepare agenda, checklist, questions. -Listen carefully and take notes (tape record if permitted). -Review notes within 48 hours. -Be neutral. -Seek diverse views.

Useful document: Report

-Primary output of current system -Enables you to work backwards from the report to the data needed to generate it

Goals of BPR

-Reorganize complete flow of data in major sections of an organization. -Eliminate unnecessary steps. -Combine steps. -Become more responsive to future change.

Document Analysis

-Review of existing business documents -Can give a historical and "formal" view of system requirements

JAD Participants

-Session Leader: facilitates group process -Users: active, speaking participants -Managers: active, speaking participants -Sponsor: high-level champion, limited participation -Systems Analysts: should mostly listen -Scribe: record session activities -IS Staff: should mostly listen

Activity Diagrams

-Show the conditional logic for the sequence of system activities needed to accomplish a business process. -Clearly show parallel and alternative behaviors. -Can be used to show the logic of a use case

Key business processes

-Structured, measured set of activities designed to produce specific output for a particular customer or market -Focused on customers and outcome -Same techniques as requirements determination are used

Data Flow Diagramming Guidelines

-The inputs to a process are different from the outputs of that process. +Processes purpose is to transform inputs into outputs. -Objects on a DFD have unique names. +Every process has a unique name.

Guidelines for Drawing DFDs: Timing

-Time is not represented well on DFDs. -Best to draw DFDs as if the system has never started and will never stop.

Template for Writing Use Case

-Use Case Title -Primary Actor -Level -Stakeholders -Precondition -Minimal Guarantee -Success Guarantee -Trigger -Main Success Guarantee -Extensions

Useful document: Business form

-Used for all types of business functions -Explicitly indicates what data flow in and out of a system and data necessary for the system to function -Gives crucial information about the nature of the organization

Direct Observation

-Watching users do their jobs -Used to obtain more firsthand and objective measures of employee interaction with information systems -Can cause people to change their normal operating behavior -Time-consuming and limited time to observe

Guidelines for Drawing DFDs: Rules for stopping decomposition

-When each process has been reduced to a single decision, calculation or database operation -When each data store represents data about a single entity -When the system user does not care to see any more detail -When every data flow does not need to be split further to show that data are handled in various ways -When you believe that you have shown each business form or transaction, online display and report as a single data flow -When you believe that there is a separate process for each choice on all lowest-level menu options

use case

-a depiction of a system's behavior or functionality under various conditions as the system responds to requests from users. -represents a single system function. +Represented as an eclipse

Modeling Logic: Decision table

-a matrix representation of the logic of a decision which specifies the possible conditions for the decision and the resulting actions -Best used for complicated decision logic

Deliverables for Requirements Determination: From interviews and observations

-interview transcripts, -observation notes, -meeting minutes

Deliverables for Requirements Determination: From existing written documents

-mission and strategy statements -business forms -procedure manuals - job descriptions -training manuals -system documentation -flowcharts

Process Modeling Deliverables

1. Context DFD 2. DFD's of the system(decomposed) 3. Thorough descriptions of each DFD component.

How to create Use Case Diagram

1. Create Boundary Rectangle 2. Decide on main functionalities (use cases) 3. Pick actors (users of the system) 4. Evaluate Relationships +Include (always used) +Extend (only used when criteria met) +Connection

How to create basic activity diagram

1. Have your start 2. go into activities which 3. go into Decision points or condition checks 4. after all decisions or condition checks, flow into termination able to be more complex with forks, joins, and swim lanes

Five suggested levels of Use Cases (cockburn)

1. White - as seen from clouds 2. Kite - "birds-eye view" 3. Blue - sea-level view 4. Fish - below sea-level 5. Black - bottom of the sea From summary to detail

Sequence diagram

A UML diagram that shows the interaction between objects to perform critical pieces of use case behavior in a time-ordered manner

Nominal Group Technique (NGT)

A facilitated process that supports idea generation by groups

Data flow diagram (DFD)

A picture of the movement of data between external entities and the processes and data stores within the system

Guidelines for Drawing DFDs: Iterative Development

Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled

Deliverables and Outcomes

Context data flow diagram (DFD) -Scope of system DFDs of current physical system -Adequate detail only DFDs of current logical system -Enables analysts to understand current system DFDs of new logical system -Technology independent -Show data flows, structure, and functional requirements of new system

DFD rules Data Flow

Data Flow - data flow has only one direction of flow. - A fork in data flow means same info goes to two different locations. - A join in a data flow means that same data comes from two different places - Data flow cannot go directly back to same process it leaves - Data flow to a data store means update - A data flow from a data store means retrieve or use - A data flow has a noun label

DFD Rules for Data Store

Data Store - Data cannot be moved from Data Store to another, must have process - Data cannot move from outside source to data source. must have process to receive. - Data cannot move directly to outside sink. - Data store has noun label

Requirements Determination using Agile Methodologies: Agile usage-centered design

Focuses on user goals, roles, and tasks

Interviewing Groups

Interviewing several key people together Advantages -More effective use of time -Can hear agreements and disagreements at once -Opportunity for synergies Disadvantages -More difficult to schedule than individual interviews

DFD Rules for Process

Process: - No Process can have only outputs. Source -No process can have only inputs. Sink -A process has a verb phrase label

JAD Participant: Scribe

Records Session activities

Level of Use Case

Refers to degree of detail in the use case description

Requirements Determination using Agile Methodologies: Continual user involvement

Replace traditional SDLC waterfall with iterative analyze-design-code-test cycle

DFD rules Source/Sink

Source/Sink - Data cannot move directly from source to sink. Needs Process. - A source/sink has noun label

Guidelines for Drawing DFDs: DFD Consistency

The extent to which information contained on one level of a set of nested DFDs is also included on other levels

Level-n diagram

a DFD diagram that is the result of n nested decompositions from a process on a level-0 diagram.

Elements of Activity Diagrams: Activity

a behavior that an object carries out while in a particular state

Elements of Activity Diagrams: Merge

a circular symbol where different paths converge

Elements of Activity Diagrams: Branch

a diamond symbol containing a condition whose results provide transitions to different paths of activities

Asynchronous message

a message in which the sender does not have to wait for the recipient to handle the message

Simple message

a message that transfers control from the sender to the recipient without describing the details of the communication

Use case diagram

a picture showing system behavior along with the key actors that interact with the system

Business Process

a standard method for accomplishing a particular task necessary for an organization to function

Basic Notation: Event

a trigger that initiates the start of a process

Synchronous message

a type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself

Trigger

an event or action that initiates the use case

Disruptive technologies

are technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes.

Swimlanes

columns representing different organizational units of the system

Precondition

conditions that must be satisfied in order to execute the use case

Balancing

conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level

Data store

data at rest (inside the system)

Main success scenario

description of sequence of interactions between actor and use case during the use case execution

Extensions

detailed description of how errors are handled

Source/sink

external entity that is the origin or destination of data (outside the system)

JAD session leader

facilitates group process

Indifferent condition

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

System boundary

includes all the relevant use cases. -A boundary is the dividing line between the system and its environment. -Use cases are within the boundary. -Actors are outside of the boundary. -Represented as a box

Level-0 diagram

is a data flow diagram that represents a system's major processes, data flows, and data stores at a high level of detail

actor

is a role, not an individual. -Involved with the functioning of the system at some basic level -Represented by stick figures -an external entity that interacts with the system

Connection

is an association between an actor and a use case. -Depicts a usage relationship -Connection does not indicate data flow -Actors are connected to use cases with lines. -Use cases are connected to each other with arrows.

Extend relationship

is an association between two use cases where one adds new behaviors or actions to the other. -Extends a use case by adding new behavior or actions -Specialized use case extends the general use case.

Include relationship

is an association between two use cases where one use case uses the functionality contained in the other. -Indicates a use case that is used (invoked) by another use case -Links to general purpose functions, used by many other use cases

Functional decomposition

is an iterative process of breaking a system description down into finer and finer detail. -Creates a set of charts in which one process on a given chart is explained in greater detail on another chart. -Continues until no subprocess can logically be broken down any further.

Context diagram

is an overview of an organizational system that shows: -the system boundaries. -external entities that interact with the system. -major information flows between the entities and the system. Note: only one process symbol, and no data stores shown

Gap Analysis

is the process of discovering discrepancies between two or more sets of data flow diagrams or discrepancies within a single DFD.

Minimal guarantee

outputs that can be expected if the service attempt failed

Success guarantee

outputs that can be expected if the service succeeds

Closed-ended questions

questions that ask those responding to choose from among a set of specified responses

Open-ended questions

questions that have no prespecified answers

Radical Method: Business Process Reengineering (BPR):

search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services

Action stubs

that part of a decision table that lists the actions that result for a given set of conditions

Condition stubs

that part of a decision table that lists the conditions relevant to the decision

Rules

that part of a decision table that specifies which actions are to be followed for a given set of conditions

Formal Systems

the official way a system works as described in organizational documentation (i.e. work procedure)

Sequence diagram: Activation

the time period during which an object performs an operation

Informal Systems

the way a system actually works (i.e. interviews, observations)

Process

work or actions performed on data (inside the system)