Reading...
Play button
Play button
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;
79 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
Requirements Discovery
|
The process and techniques used by systems analysts to identify or extract system problems and solution requirements from the user community
|
The process of determining what exactly the problem is
|
|
|
System Requirement
|
Something that the information must do or a property it must have.
|
Also called a “business requirement”
|
|
|
Functional Requirement
|
Something the information system must do
|
Mandatory part of the system
|
|
|
Nonfunctional Requirement
|
A property or quality the system must have.
|
Examples: security, ease of use, performance, etc.
|
|
|
PIECES Framework
|
Performance, Information, Economy, Control/Security, Efficiency, Service
|
Introduced in Chapter 2, is a good framework for classifying system requirements
|
|
|
Relative Cost Ratio of an Erroneous Requirement If Discovered in the Requirements Phase
|
1
|
Least expensive error to repair
|
|
|
Relative Cost Ratio of an Erroneous Requirement If Discovered in the Design Phase
|
3-6
|
Slightly more expensive error than if it was discovered in the requirements phase
|
|
|
Relative Cost Ratio of an Erroneous Requirement If Discovered in the Coding Phase
|
10
|
More expensive error to repair than if discovered in the requirements phase
|
|
|
Relative Cost Ratio of an Erroneous Requirement If Discovered in the Development Testing Phase
|
15-40
|
Significantly more expensive to repair than if it was discovered in the requirements phase
|
|
|
Relative Cost Ratio of an Erroneous Requirement If Discovered in the Acceptance Testing Phase
|
30-70
|
Incredibly more expensive to repair than if it was discovered in the requirements phase
|
|
|
Relative Cost Ratio of an Erroneous Requirement If Discovered in the Operation Phase
|
40-1000
|
Most expensive error to repair; up to 1000x more expensive than if the error was discovered in the requirements phase
|
|
|
Process of Requirements Discovery
|
Problem Discovery and Analysis, Requirements Discovery, Documenting and Analyzing Requirements, Requirements Management
|
Four steps to complete requirements discovery
|
|
|
Ishikawa Diagram
|
A graphical tool used to identify, explore, and depict problems and the causes and effects of those problems.
|
Also called a “fishbone” diagram; a useful tool for problem discovery
|
|
|
Anatomy of Fishbone Diagram
|
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
|
The more general the problem, the closer to the backbone
|
|
|
Fact-Finding
|
The formal process of using research, meetings, interviews, questionnaires, sampling, and other techniques to collect information about system problems, requirements, and preferences.
|
Also called “information gathering” or “data collection”
|
|
|
Tools for Documenting Draft Requirements
|
Use Cases, Decision Tables, Requirements Tables
|
Methods of documenting data findings in a useful way
|
|
|
Requirements Definition Document
|
A formal document that communicates the requirements of a proposed system to key stakeholders and serves as a contract for the systems project.
|
Other names include “Requirements Statement,” “Requirements Specification,” and “Functional Specification.”
|
|
|
Requirements Management
|
The process of managing change to the requirements
|
|
|
|
Fact-Finding Techniques
|
Sampling of Existing Documentation, Research and Site Visits, Observation of the Work Environment, Questionnaires, Interviews, Prototyping, JRP
|
Ways to collect data
|
|
|
Recommended Document to Check First
|
Organization Chart
|
Document which serves to identify key owners and users for a project and their reporting relationships
|
|
|
Types of Documents Analyst Should Collect
|
Those that (1) describe the problem, (2) describe the business functions being studied/designed, and (3) describe studies done by previous analysts
|
Documents should be relevant to the problem/system in some way
|
|
|
Sampling
|
The process of collecting a representative sample of documents, forms, and records
|
There is no need to look at every single relevant document
|
|
|
Pitfall of Studying Blank Forms
|
They tell little about how the form is actually used, when it is not used, or how often it is misused
|
Blank forms actually tell very little about the problem
|
|
|
How Many Samples?
|
As many as it takes to identify all the possible processing conditions and exceptions
|
Depends on the sample size and type
|
|
|
Reliable Sample Size Formula
|
SS = 0.25 (Certainty Factor / Acceptable Error) ^ 2
|
Includes ratio which is not affected by population size itself
|
|
|
Acceptable Error
|
100 – Desirable Certainty
|
The remaining percentage after the Desirable Certainty is accounted for
|
|
|
Randomization
|
A sampling technique characterized by having no predetermined pattern or plan for selecting sample data
|
A pattern of having no predefined pattern
|
|
|
Stratification
|
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
|
Can be done by choosing records by formula instead of at random
|
|
|
Research and Site Visits
|
If another company has had the same problem, they may be “willing to share” their information on how it was resolved
|
Most problems are not completely unique. Other people have solved them before us.
|
|
|
Observation
|
A fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system
|
The analyst becomes the user for a short time
|
|
|
Advantages of Observation as a Fact-Finding Technique
|
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
|
|
|
|
Disadvantages of Observation as a Fact-Finding Technique
|
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
|
|
|
|
Work Sampling
|
A fact-finding technique that involves a large number of observations taken at random intervals
|
Less threatening technique to people being observed
|
|
|
Questionnaires
|
A document that allows the analyst to collect information and opinions from respondents. Most efficient technique for large audiences
|
|
|
|
Advantages of Questionnaires as a Fact-Finding Technique
|
Can be completed quickly; Relatively inexpensive; Allows anonymity; Can be tabulated and analyzed quickly
|
|
|
|
Disadvantages of Questionnaires as a Fact-Finding Technique
|
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
|
|
|
|
Free-Format Questionnaires
|
Questionnaire designed to offer the respondent greater latitude in the answer “Short Answer” question
|
|
|
|
Fixed-Format Questionnaires
|
Questionnaire containing questions that require selecting an answer from predefined available responses
|
“Multiple Choice” question
|
|
|
Types of Fixed-Format Questions
|
Multiple Choice, Rating, Ranking
|
Different variations of “Multiple Choice”
|
|
|
Interview
|
A fact-finding technique whereby the systems analyst collects information from individuals through face-to-face interaction
|
Talking to someone in person
|
|
|
Advantages of Interviewing as a Fact-Finding Technique
|
Questions can be answered more freely; Ability to probe for more feedback; Questions can be adaptable; Nonverbal communication can be observed
|
|
|
|
Disadvantages of Interviewing as a Fact-Finding Technique
|
Time-consuming and costly; Highly dependent on human relations skills; May be impractical due to location
|
|
|
|
Unstructured Interview
|
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
|
|
|
|
Structured Interview
|
An interview in which the interviewer has a specific set of questions to ask the interviewee. More of a traditional interview
|
|
|
|
Open-Ended Question
|
A question that allows the interviewee to respond in any way that seems appropriate. Tend to be longer answers
|
|
|
|
Closed-Ended Question
|
A question that restricts answers to either specific choices or short, direct responses. Tend to be shorter answers
|
|
|
|
Interview Guide
|
A checklist of specific questions the interviewer will ask the interviewee; may also contain follow-up questions and time allotted to each question
|
A useful tool for structuring interviews
|
|
|
Types of Questions that Should Be Avoided
|
Loaded Questions, Leading Questions, Biased Questions
|
The purpose of an interview is to investigate, not to evaluate or criticize
|
|
|
An Interviewer Should:
|
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
|
Rules for an interviewer to follow during the interview
|
|
|
An Interviewer Should Not:
|
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
|
Rules for an interviewer to follow during the interview
|
|
|
Body Language
|
The nonverbal information we communicate. We are usually unaware of this kind of communication
|
|
|
|
Types of Body Language
|
Facial Disclosure, Eye Contact, and Posture
|
In order from most controlled to least controlled
|
|
|
Proxemics
|
The relationship between people and the space around themA. factor in communications that can be controlled by the knowledgeable analyst
|
|
|
|
Discovery Prototyping
|
The act of building a small-scale representative or working model of the users' requirements in order to discover or verify the requirements
|
The users will recognize their requirements when they see them.
|
|
|
Advantages of Prototyping as a Fact-Finding Technique
|
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
|
|
|
|
Disadvantages of Prototyping as a Fact-Finding Technique
|
Developers may need to be trained in this approach; Users may develop unrealistic expectations; May extend development schedule and increase costs.
|
|
|
|
Joint Requirements Planning (JRP)
|
A process whereby highly structured group meetings are conducted for the purpose of analyzing problems and defining requirements
|
An example of the “group work session” approach
|
|
|
JRP Participants
|
Sponsor, Facilitator, Users/Managers, Scribe, IT Staf Everyone has their own distinct role in JRP
|
|
|
|
Brainstorming
|
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
|
|
|
|
Benefits of JRP as a Fact-Finding Technique
|
Actively involves users and managers; Reduces amount of time to develop system; Realizes benefits of prototyping when it is used
|
|
|
|
Common Fact-Finding Temptation for Inexperienced Analysts
|
To start with interviews instead of collecting data through other means first. This temptation often creates an unnecessary waste of users' time
|
|
|
|
User-centered development
|
a process of systems development based on understanding the needs of the stakeholders and the reasons why the system should be developed.
|
|
|
|
Use-case modeling
|
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.
|
|
|
|
Use-case diagram
|
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.
|
|
|
|
Functional decomposition
|
the act of breaking a system into sub-components
|
|
|
|
Use-case narrative
|
a textual description of the business event and how the user will interact with the system to accomplish the task
|
|
|
|
Use case
|
a behaviorally related sequence of steps (a scenario), both automated and manual, for the purpose of completing a single task.
|
|
|
|
Actor
|
anything that needs to interact with the system to exchange information.
|
|
|
|
Primary business actor
|
the stakeholder that primarily benefits from the execution from the use-case by receiving something of measurable or observable value.
|
|
|
|
Primary system actor
|
the stakeholder that directly interfaces with the system to initiate or trigger the business or system event.
|
Examples: Grocery store clerk, telephone operator, bank teller
|
|
|
External server actor
|
the stakeholder that responds to a request from the use case.
|
Example: a credit bureau authorizing the charging by a credit card.
|
|
|
External receiver actor
|
The stakeholder that is not the primary actor, but receives something of measurable, or observable value (output).
|
Example: a warehouse receiving a packing order to prepare a shipment after a customer has placed an order.
|
|
|
Temporal event
|
a system event that is triggered by time.
|
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.
|
|
|
Association
|
a relationship between an actor and a use case in which an interaction occurs between them.
|
|
|
|
Extension use case
|
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.
|
|
|
|
Abstract use case
|
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.
|
|
|
|
depends on
|
a relationship between use cases indicating that one use case cannot be performed until another use case has been performed.
|
|
|
|
Inheritance
|
in use cases, a relationship between actors created to simplify the drawing when an abstract actor inherits the role of multiple real actors.
|
|
|
|
Business requirements use case
|
a use case created during the requirements analysis to capture the interactions between a user and the system – free of technology and implementation details.
|
AKA essential use case.
|
