Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
19 Cards in this Set
- Front
- Back
What is system requirements determination and why do we do this? What are the characteristics for successful requirements determination?
|
Definition: Figuring out what’s really going on: The problems, the needs, the requirements of the new system
Characteristics: Impertinence, Impartiality, Relaxing constraints, Attention to details, Reframing |
|
Be able to discuss the different methods for determining requirements (both traditional and contemporary methods).
|
Traditional: Interviewing individuals, Interviewing groups, Observing workers, Studying business documents
Contemporary: Joint Application Design (JAD) Brings together key users, managers, and systems analysts Purpose: collect system requirements simultaneously from key people Conducted off-site Intensive group-oriented requirements determination technique Team members meet in isolation for an extended period of time Highly focused Resource intensive Started by IBM in 1970s 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 Group Support Systems • Facilitate sharing of ideas and voicing of opinions about system requirements CASE tools Software used to analyze existing systems Help discover requirements to meet changing business conditions System prototypes Iterative development process Rudimentary working version of system is built Refine understanding of system requirements in concrete terms |
|
prototyping
|
Prototyping: (Types: Evolutionary and Throwaway)
Quickly converts requirements to working version of system Once the user sees requirements converted to system, will ask for modifications or will generate additional requests Most useful when: ◦ User requests are not clear ◦ Few users are involved in the system ◦ Designs are complex and require concrete form ◦ History of communication problems between analysts and users Tools are readily available to build prototype Drawbacks of prototyping: Tendency to avoid formal documentation Difficult to adapt to more general user audience Sharing data with other systems is often not considered Systems Development Life Cycle (SDLC) checks are often bypassed Throwaway prototypes are hard to throwaway |
|
Business Process Reengineering (BPR)
|
Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services
Goals ◦ Reorganize complete flow of data in major sections of an organization ◦ Eliminate unnecessary steps Goals (cont.) ◦ Combine steps ◦ Become more responsive to future change Identification of processes to reengineer ◦ Key business processes Set of activities designed to produce specific output for a particular customer or market Focused on customers and outcome Same techniques are used as were used for requirements determination |
|
Agile User Centered Design
|
Gather group of programmers, analysts, users, testers, facilitator
Document complaints of current system Determine important user roles Determine, prioritize, and describe tasks for each user role Group similar tasks into interaction contexts Associate each interaction context with a user interface for the system, and prototype the interaction context Step through and modify the prototype |
|
eXtreme Programming’s Planning Game
|
-see picture on study guide-
|
|
Context Diagram
|
Context Diagram
A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system Does not contain data store |
|
Level 0 diagram
|
Level-0 Diagram
A data flow diagram (DFD) that represents a system’s major processes, data flows and data stores at a high level of detail |
|
Level X diagram
|
Level-X Diagram
Breaks down each process in Level-0 into smaller processes Ex: Process 1.0 in Level-0 gets broken down into smaller processes in the Level-1 diagram |
|
Miracle
|
Process with only outputs
|
|
Black hole
|
Process with only inputs
|
|
Functional Decomposition Diagram
|
Show top-down functional decomposition or structure of a system
Provide outline for drawing DFDs |
|
Balancing
|
The conservation of inputs and outputs to a data flow process when that process is decomposed to a lower level
Balanced 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 |
|
Logical DFDs
|
Logical DFDs state what the new system will do (“Business View”)
The same rules pertaining to balance and decomposition apply |
|
Physical DFDs
|
Physical DFDs show implementation details and explain how the final system will work. (“systems (programmer) view”)
References to actual technology Format of information moving through process Human interaction that is involved |
|
Current Physical
|
Process labels identify technology (people or systems) used to process the data.
Data flows and data stores identify actual name of the physical media. |
|
Current Logical
|
Physical aspects of system are removed as much as possible.
Current system is reduced to data and processes that transform them. |
|
New Logical
|
Includes additional functions
Obsolete functions are removed Inefficient data flows are reorganized |
|
New Physical
|
Represents the physical implementation of the new system
|