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)