C H A P T E R. 6. REQUIREMENTSDISCOVERY. Introduction to Requirements Discovery. Requirements discovery includes those techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Requirements discovery includes those techniques to be used by systems analysts to identify or extract system problems and solution requirements from the user community.
Problem analysis is the activity of identifying the problem, understanding the problem (including causes and effects), and understanding any constraints that may limit the solution.
Recent studies have shown that as many as 80% of all system development failures can be traced back to problems with requirements!!!
Book has tables of examples! Look these over…..
Create a means to transport a single
individual from home to place of work.
InterpretationAn Ambiguous Requirements Statement
English-language requirements are full of ambiguities; Thus we use models with few symbols
and the jargon of the user. Diagrams generally accompany the graphical / text-based models.
(missed delivery date)
40-1000Relative Cost to Fix an Error
available resources and constraints
functions / features of the system
The Ishikawa diagram is a graphical tool used to identify, explore, and depict problems and the causes and effects of those problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram.
Main categories: methods
materials, contracts, …
Causes come ‘under’
(point to) a category…
of interest is
at the head.
requirements specification, requirements definition, functional specification.
A requirements definition document(s) should consist of the following.
3.Observation is a fact-finding technique wherein the systems analyst either participates in or watches a person perform activities to learn about the system.
‘can be highly reliable’ (see what is done)
‘reasonably inexpensive (employee time, copying, …)
‘ allows systems analyst to do work measurements.
Disadvantages? people uncomfortable
need to watch at peak times / best times/ representative…
perform jobs correctly when watched…
OK, if really “OK”
Work sampling is a fact-finding technique that involves a large number of observations taken at random intervals.
4. Questionnaires are special-purpose documents that allow the analyst to collect information and opinions from respondents.
Free-format questionnaires offer the respondent greater latitude in the answer. A question is asked, and the respondent records the answer in the space provided after the question.
great for analysis
requires much time
what does “good” mean? Avoid key words…
Fixed-format questionnaires contain questions that require selection of predefined responses from individuals.
easy to tabulate
the science of question formulation…
5.Interviews are a fact-finding technique whereby the systems analysts collect information from individuals through face-to-face interaction.
Unstructured interviews are 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.
. May often get offtrack; analyst may need to redirect
interview back to main goal/subject
. Unstructured interviews usually don’t work too well for
systems analysis and design.
In structured interviews the interviewer has a specific set of questions to ask of the interviewee.
Open-ended questions allow the interviewee to respond in any way that seems appropriate.
How do you feel about ….
What do you think is the most important ….
Closed-ended questions restrict answers to either specific choices or short, direct responses.
Restricted choices – yes or no, ….
Interviewee: Jeff Bentley, Accounts Receivable Manager
Date: Tuesday, March, 23, 2000
Time: 1:30 P.M.
Place: Room 223, Admin. Bldg.
Subject: Current Credit-Checking Policy
Observe mannerisms and nonverbal communication
Keep interviewee at ease
Continuing an interview unnecessarily.
Assuming an answer is finished or leading nowhere.
Revealing verbal and nonverbal clues.
Revealing your personal biases.
Talking instead of listening.
Assuming anything about the topic and the interviewee.
Tape recording -- a sign of poor listening skills.Interviewing Do’s and Don’ts
Body language is all of the nonverbal information being communicated by an individual. Body language is a form of nonverbal communications that we all use and are usually unaware of.
Proxemics is the relationship between people and the space around them. Proxemics is a factor in communications that can be controlled by the knowledgeable analyst.
People tend to be territorial…
Startling fact: of a person’s total feelings, only
6. Discovery prototyping is the act of building a small-scale, representative or working model of the users’ requirements in order to discover or verify those requirements.
Dissatisfaction with interview / questionnaire results – conflicting goals, significant time/effort expended.
Enter a ‘group work’ session as a substitute for interviews.
Joint requirements planning (JRP) is a process whereby highly structured group meetings are conducted for the purpose of analyzing problems and defining requirements.
JRP is a subset of a more comprehensive joint application development or JAD technique that encompasses the entire systems development process.
JRP (and JAD) techniques are becoming increasingly common in systems planning and systems analysis to obtain group consensus on problems, objectives, and requirements.
0. Three to five days – or more; much planning on ‘scope.’
Develop high level requirements/expectations of each session
2. Selecting the participants
3. Preparing the agenda – read this.
41' - discovering requirements.
Food & Refreshments
IT Professionals & Other Observers
(for CASE tool)
(for prototyping tool)
IT Professionals & Other ObserversTypical room layout for JRP session
Brainstorming is a technique for generating ideas during group meetings.
Participants are encouraged to generate as many ideas as possible in a short period of time without any analysis until all the ideas have been exhausted.
Sometimes, one of the goals of a JRP session is to generate possible ideas to solve a problem. Brainstorming is a common approach that is used for that purpose.
A use case is a behaviorally related sequence of steps (a scenario), both automated and manual for the purpose of completing a single business task.
An actor represents anything that needs to interact with the system to exchange information. An actor is a user, a role, which could be an external system as well as a person.
A temporal event is a system event that is triggered by time.
Author: S. Shepard Date: 03/01/200
Use Case Name: Create New Member Order
Description:This use case describes the process of a member submitting an order for SoundStage products. On completion, the member will be sent a notification that the order was accepted.
Be sure you know all the parts (rows) of a Use Case:
Here are a few: be able to identify them from the descriptions below:
1. A reference to the requirement(s) in which it can be traced to.
2 A typical event course describing the use case’s major steps, from beginning to end of
this interaction with the actor.
3. Alternate courses describing exceptions to the typical course of events.
4.Precondition describing the state the system is in before the use case is executed.
5. Postcondition describing the state the system is in after the use case is executed.
6. An assumptions section, which includes any nonbehavioral issues, such as performance
or security, that is associated with the use case, but is difficult to model within the
use case’s course of events.
Requirement discovering requirements.
Indicate a unique number or identifier of the requirement
Assign short phrase indicating nature of the requirement
Provide a textual statement of the requirement
Indicate the requirement type
Requirement details and
Functional characteristics or dimensions
Rev date and rev #:
Indicate the acceptance date and revision number of current
Must, Want, or OptionalTables to Capture Requirements
Requirements traceability is the ability to trace a system function or feature back to the requirement that mandates it.
These are used a lot, but the trend is to capture functional requirements via Use Cases
accompanied with Supplementary Specifications (non-functional; glossary, etc.)
In many cases these can be quite boring and ambiguous; better: the stories in Use Cases….
Process New Member Order
The system should be able to process new member orders. Within this process it
should be able to validate member demographic information, verify credit
worthiness, inquire and modify inventory levels based on quantity of product
ordered, initiate backorder process in the event of insufficient inventory to fulfill
order, and send an order confirmation notice once the order has been placed.
Requirement details and
Member credit status will be obtained from the Account Receivable system. A
picking ticket, containing the available ordered items, must be generated and
routed to the warehouse.
Rev date and rev#:
MSS - 14.0
One Hour Order Confirmation Notice
An E-mail notice must be generated and sent to the member, within one hour
from the time the member placed the order.
Requirement details and
The member’s E-mail address must be stored on the system within the member’s
profile. The one- hour constraint applies only to the sending of the notification
And not when it’s received by the member. Related requirement(s): MSS-1.0
Rev date and rev #: