Systems Analysis And Design -- Chapters 5 And 6

Front 1

Requirements Discovery

Back 1

The process and techniques used by systems analysts to identify or extract system problems and solution requirements from the user community

Hint 1

The process of determining what exactly the problem is

Front 2

System Requirement

Back 2

Something that the information must do or a property it must have.

Hint 2

Also called a “business requirement”

Front 3

Functional Requirement

Back 3

Something the information system must do

Hint 3

Mandatory part of the system

Front 4

Nonfunctional Requirement

Back 4

A property or quality the system must have.

Hint 4

Examples: security, ease of use, performance, etc.

Front 5

PIECES Framework

Back 5

Performance, Information, Economy, Control/Security, Efficiency, Service

Hint 5

Introduced in Chapter 2, is a good framework for classifying system requirements

Front 6

Relative Cost Ratio of an Erroneous Requirement If Discovered in the Requirements Phase

Back 6

1

Hint 6

Least expensive error to repair

Front 7

Relative Cost Ratio of an Erroneous Requirement If Discovered in the Design Phase

Back 7

3-6

Hint 7

Slightly more expensive error than if it was discovered in the requirements phase

Front 8

Relative Cost Ratio of an Erroneous Requirement If Discovered in the Coding Phase

Back 8

10

Hint 8

More expensive error to repair than if discovered in the requirements phase

Front 9

Relative Cost Ratio of an Erroneous Requirement If Discovered in the Development Testing Phase

Back 9

15-40

Hint 9

Significantly more expensive to repair than if it was discovered in the requirements phase

Front 10

Relative Cost Ratio of an Erroneous Requirement If Discovered in the Acceptance Testing Phase

Back 10

30-70

Hint 10

Incredibly more expensive to repair than if it was discovered in the requirements phase

Front 11

Relative Cost Ratio of an Erroneous Requirement If Discovered in the Operation Phase

Back 11

40-1000

Hint 11

Most expensive error to repair; up to 1000x more expensive than if the error was discovered in the requirements phase

Front 12

Process of Requirements Discovery

Back 12

Problem Discovery and Analysis, Requirements Discovery, Documenting and Analyzing Requirements, Requirements Management

Hint 12

Four steps to complete requirements discovery

Front 13

Ishikawa Diagram

Back 13

A graphical tool used to identify, explore, and depict problems and the causes and effects of those problems.

Hint 13

Also called a “fishbone” diagram; a useful tool for problem discovery

Front 14

Anatomy of Fishbone Diagram

Back 14

Name of the problem to be solved makes up the fish's head; possible causes of the problem are “bones” off the “main backbone”; actual causes of problem are bones off category bones

Hint 14

The more general the problem, the closer to the backbone

Front 15

Fact-Finding

Back 15

The formal process of using research, meetings, interviews, questionnaires, sampling, and other techniques to collect information about system problems, requirements, and preferences.

Hint 15

Also called “information gathering” or “data collection”

Front 16

Tools for Documenting Draft Requirements

Back 16

Use Cases, Decision Tables, Requirements Tables

Hint 16

Methods of documenting data findings in a useful way

Front 17

Requirements Definition Document

Back 17

A formal document that communicates the requirements of a proposed system to key stakeholders and serves as a contract for the systems project.

Hint 17

Other names include “Requirements Statement,” “Requirements Specification,” and “Functional Specification.”

Front 18

Requirements Management

Back 18

The process of managing change to the requirements

Front 19

Fact-Finding Techniques

Back 19

Sampling of Existing Documentation, Research and Site Visits, Observation of the Work Environment, Questionnaires, Interviews, Prototyping, JRP

Hint 19

Ways to collect data

Front 20

Recommended Document to Check First

Back 20

Organization Chart

Hint 20

Document which serves to identify key owners and users for a project and their reporting relationships

Front 21

Types of Documents Analyst Should Collect

Back 21

Those that (1) describe the problem, (2) describe the business functions being studied/designed, and (3) describe studies done by previous analysts

Hint 21

Documents should be relevant to the problem/system in some way

Front 22

Sampling

Back 22

The process of collecting a representative sample of documents, forms, and records

Hint 22

There is no need to look at every single relevant document

Front 23

Pitfall of Studying Blank Forms

Back 23

They tell little about how the form is actually used, when it is not used, or how often it is misused

Hint 23

Blank forms actually tell very little about the problem

Front 24

How Many Samples?

Back 24

As many as it takes to identify all the possible processing conditions and exceptions

Hint 24

Depends on the sample size and type

Front 25

Reliable Sample Size Formula

Back 25

SS = 0.25 (Certainty Factor / Acceptable Error) ^ 2

Hint 25

Includes ratio which is not affected by population size itself

Front 26

Acceptable Error

Back 26

100 – Desirable Certainty

Hint 26

The remaining percentage after the Desirable Certainty is accounted for

Front 27

Randomization

Back 27

A sampling technique characterized by having no predetermined pattern or plan for selecting sample data

Hint 27

A pattern of having no predefined pattern

Front 28

Stratification

Back 28

A systematic sampling technique that attempts to reduce the variance of estimates by spreading out the sampling and avoiding very high or very low estimates

Hint 28

Can be done by choosing records by formula instead of at random

Front 29

Research and Site Visits

Back 29

If another company has had the same problem, they may be “willing to share” their information on how it was resolved

Hint 29

Most problems are not completely unique. Other people have solved them before us.

Front 30

Observation

Back 30

A fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system

Hint 30

The analyst becomes the user for a short time

Front 31

Advantages of Observation as a Fact-Finding Technique

Back 31

Data gathered can be very reliable; The analyst can see exactly what is being done; Is relatively inexpensive; Allows system analyst to do work measurements

Front 32

Disadvantages of Observation as a Fact-Finding Technique

Back 32

Workers may perform differently; Scheduling inconveniences are possible; Situation observed may not be normal/objectionable part of work day; Subject to interruptions; People let you see what they want you to see

Front 33

Work Sampling

Back 33

A fact-finding technique that involves a large number of observations taken at random intervals

Hint 33

Less threatening technique to people being observed

Front 34

Questionnaires

Back 34

A document that allows the analyst to collect information and opinions from respondents. Most efficient technique for large audiences

Front 35

Advantages of Questionnaires as a Fact-Finding Technique

Back 35

Can be completed quickly; Relatively inexpensive; Allows anonymity; Can be tabulated and analyzed quickly

Front 36

Disadvantages of Questionnaires as a Fact-Finding Technique

Back 36

Low number of respondents; No guarantee all questions will be answered; Tend to be inflexible; Nothing can be clarified; Can be difficult to prepare successfully

Front 37

Free-Format Questionnaires

Back 37

Questionnaire designed to offer the respondent greater latitude in the answer “Short Answer” question

Front 38

Fixed-Format Questionnaires

Back 38

Questionnaire containing questions that require selecting an answer from predefined available responses

Hint 38

“Multiple Choice” question

Front 39

Types of Fixed-Format Questions

Back 39

Multiple Choice, Rating, Ranking

Hint 39

Different variations of “Multiple Choice”

Front 40

Interview

Back 40

A fact-finding technique whereby the systems analyst collects information from individuals through face-to-face interaction

Hint 40

Talking to someone in person

Front 41

Advantages of Interviewing as a Fact-Finding Technique

Back 41

Questions can be answered more freely; Ability to probe for more feedback; Questions can be adaptable; Nonverbal communication can be observed

Front 42

Disadvantages of Interviewing as a Fact-Finding Technique

Back 42

Time-consuming and costly; Highly dependent on human relations skills; May be impractical due to location

Front 43

Unstructured Interview

Back 43

An interview that is conducted with only a general goal or subject in mind and with few, if any, specific questions. The interviewer counts on the interviewee to provide a framework and direct the conversation. More of a conversation than an interview

Front 44

Structured Interview

Back 44

An interview in which the interviewer has a specific set of questions to ask the interviewee. More of a traditional interview

Front 45

Open-Ended Question

Back 45

A question that allows the interviewee to respond in any way that seems appropriate. Tend to be longer answers

Front 46

Closed-Ended Question

Back 46

A question that restricts answers to either specific choices or short, direct responses. Tend to be shorter answers

Front 47

Interview Guide

Back 47

A checklist of specific questions the interviewer will ask the interviewee; may also contain follow-up questions and time allotted to each question

Hint 47

A useful tool for structuring interviews

Front 48

Types of Questions that Should Be Avoided

Back 48

Loaded Questions, Leading Questions, Biased Questions

Hint 48

The purpose of an interview is to investigate, not to evaluate or criticize

Front 49

An Interviewer Should:

Back 49

Dress appropriately; Be courteous; Listen carefully; Maintain control of the interview; Probe; Observe mannerisms and nonverbal communication; Be patient; Keep the interviewee at ease; Maintain self-control; Finish on time

Hint 49

Rules for an interviewer to follow during the interview

Front 50

An Interviewer Should Not:

Back 50

Assume an answer is finished or leading nowhere; Reveal verbal and nonverbal clues; Use jargon; Reveal personal biases; Talk instead of listen; Assume anything about the topic or interviewee; Tape record the interview

Hint 50

Rules for an interviewer to follow during the interview

Front 51

Body Language

Back 51

The nonverbal information we communicate. We are usually unaware of this kind of communication

Front 52

Types of Body Language

Back 52

Facial Disclosure, Eye Contact, and Posture

Hint 52

In order from most controlled to least controlled

Front 53

Proxemics

Back 53

The relationship between people and the space around themA. factor in communications that can be controlled by the knowledgeable analyst

Front 54

Discovery Prototyping

Back 54

The act of building a small-scale representative or working model of the users' requirements in order to discover or verify the requirements

Hint 54

The users will recognize their requirements when they see them.

Front 55

Advantages of Prototyping as a Fact-Finding Technique

Back 55

Allows experimentation with the software; Helps determine feasibility before high development costs are incurred; Serves as a training mechanism; Aids in building system test plans; May minimize time spent on fact-finding

Front 56

Disadvantages of Prototyping as a Fact-Finding Technique

Back 56

Developers may need to be trained in this approach; Users may develop unrealistic expectations; May extend development schedule and increase costs.

Front 57

Joint Requirements Planning (JRP)

Back 57

A process whereby highly structured group meetings are conducted for the purpose of analyzing problems and defining requirements

Hint 57

An example of the “group work session” approach

Front 58

JRP Participants

Back 58

Sponsor, Facilitator, Users/Managers, Scribe, IT Staf Everyone has their own distinct role in JRP

Front 59

Brainstorming

Back 59

A technique for generating ideas by encouraging participants to offer as many ideas as possible in a short period of time without any analysis until all the ideas have been exhausted. Let's put our heads together

Front 60

Benefits of JRP as a Fact-Finding Technique

Back 60

Actively involves users and managers; Reduces amount of time to develop system; Realizes benefits of prototyping when it is used

Front 61

Common Fact-Finding Temptation for Inexperienced Analysts

Back 61

To start with interviews instead of collecting data through other means first. This temptation often creates an unnecessary waste of users' time

Front 62

User-centered development

Back 62

a process of systems development based on understanding the needs of the stakeholders and the reasons why the system should be developed.

Front 63

Use-case modeling

Back 63

the process of modeling a system's functions in terms of business events, who initiated the events, and how the system responds to those events.

Front 64

Use-case diagram

Back 64

a diagram that depicts the inter-actions between the system and external systems and users. In other words, it graphically describes who will use the system and in what ways the user expects to interact with the system.

Front 65

Functional decomposition

Back 65

the act of breaking a system into sub-components

Front 66

Use-case narrative

Back 66

a textual description of the business event and how the user will interact with the system to accomplish the task

Front 67

Use case

Back 67

a behaviorally related sequence of steps (a scenario), both automated and manual, for the purpose of completing a single task.

Front 68

Actor

Back 68

anything that needs to interact with the system to exchange information.

Front 69

Primary business actor

Back 69

the stakeholder that primarily benefits from the execution from the use-case by receiving something of measurable or observable value.

Front 70

Primary system actor

Back 70

the stakeholder that directly interfaces with the system to initiate or trigger the business or system event.

Hint 70

Examples: Grocery store clerk, telephone operator, bank teller

Front 71

External server actor

Back 71

the stakeholder that responds to a request from the use case.

Hint 71

Example: a credit bureau authorizing the charging by a credit card.

Front 72

External receiver actor

Back 72

The stakeholder that is not the primary actor, but receives something of measurable, or observable value (output).

Hint 72

Example: a warehouse receiving a packing order to prepare a shipment after a customer has placed an order.

Front 73

Temporal event

Back 73

a system event that is triggered by time.

Hint 73

A billing system automatically generating its bills on the 5th day of the month. A bank reconciling its check transactions every day at 5:00pm/ Nightly reports of closing enrollment for a class.

Front 74

Association

Back 74

a relationship between an actor and a use case in which an interaction occurs between them.

Front 75

Extension use case

Back 75

a use case consisting of steps extracted from a more complex use case in order to simplify te original case and thus extend its functionality. The extension use case extends the functionality of the original use case.

Front 76

Abstract use case

Back 76

a use case that reduces redundancy among two or more other use cases by combining the common steps found in those cases. Another use case uses or includes the abstract use case.

Front 77

depends on

Back 77

a relationship between use cases indicating that one use case cannot be performed until another use case has been performed.

Front 78

Inheritance

Back 78

in use cases, a relationship between actors created to simplify the drawing when an abstract actor inherits the role of multiple real actors.

Front 79

Business requirements use case

Back 79

a use case created during the requirements analysis to capture the interactions between a user and the system – free of technology and implementation details.

Hint 79

AKA essential use case.