FACT FINDING

Tujuan Bab

Effective fact-finding techniques are crucial to the development of systems projects. In this chapter
you will learn about techniques to disoover and analyze information system requirements. You will
learn how, to use various fact-finding techniques to gather infor-mation about the system's
problems, opportunities, and directives. You will know that you understand fact-finding techniques
and requirements discovery when you can

Define system requirements and differentiate between functional and nonfunctional requirements.

Understand the activity of problem analysis and be able to create an Ishikawa lfishbonel diagram to
aid in problem solving.

Understand the concept of requirements management.

Identify seven fact-finding techniques and characterize the advantages and disadvantages of each.

Understand six guidelines for doing effective listening.

Understand what body language and proxemics are and why a systems analyst should care.

Characterize the typical participants in a JRP session and describe their roles.

Complete the planning process for a JRP session, including selecting and equipping the location,
selecting the participants. and poeparing an agenda to guide the JRP session.

Describe several benefits of using JRP as a fact-finding technique.

Describe a fact-finding strategy that will make the most of your time with end users.

An Introduction to requirements Discovery

Bob Mattinez has spent most of the week reading. He started with memos related to the proposed
Member Services System to better understand the problem. He then reviewed SoundStage's
procedures manual for any policies related to member senices and pro-motions. He studled nearly
100 member order forms selected at random, noting the kinds of data recorded in each blank and
whlch blanks were always, sometimes, and never used. He read the documentation for the present
member services system. He re-viewed data and process diagrams from the prior member senice
systems development project, noting things that would probably need to be changed tn the new
system. It was grueling work. But in the end he really felt like he was beginning to understand the
system. He produced a report for Sandra, his boss, of the ke• issues and questions that would need
to be answered at the upcoming joint requirements planning meeting.

What are system requirernents? System requirements specify what the infor-mation system must do
or what property or quality the system must have. System re-qutrements that specify what the
Information system must do are frequendy referred to as functional reqtdrements. System
requirements that specify a property or qual-ity the system must have are frequently referred to as
nonfunctional requIrements.
Essentially, the purpose of requlrements discovery and management is to cor-rectly Identify the
ictvowtsoc, PROCESS, and COMMUMCATION requirements for the users of a new system. Fallure to
correctly identify system requirements may result in one or more of the following:

The system may cost more than projected.

The system may be delivered later than promised.

The system may not meet the users expectations, and that dIssatisfactIon may cause them not to
use it.

Once In producilon, the costs of maintalning and enhancing the system may be excessively high.

The system may be unreliable and prone to errors and downtIme.

The reputatlon of the IT staff on the team is tarnIshed because any fallure, regardless of who ls at
fault, will be perceived as a mistake by the team.

The process of requirements discovery consists of the following activitles

• Problem dlscovery and analysls.

• Requirements discovery.

• Documenting and analyzing requirements.

• Requirements management. Let's now examine each one of these activities in detail.

One of the most common mistakes Inexperienced systems analysts make when trying to analyze
problems Is identifyIng a symptom as a problem. As a result, they may design and implement a
solution that more than likely doesn't solve the real problem or that may cause new problems. A
popular tool used by development teams to Identify, analyze, and solve problems Is an Ishikawa
diagram. The fishbone-shaped dlagram is the bralnchild of Kaoru Ishlkawa, who pioneered quality
manage-ment processes in the Kawasaki shlpyards of Japan and, in the process, became one of the
founding fathers of modern management.

Drawing the fishbone diagram begins with the name of the problem of interest en-tered at the right
of the diagram (or theftsb's bead).The possible causes of the problem are then drawn as bones off
the matn backbone, each on an arrow pointing to the backbone. these "bones" are labeled a s four
basic categorks: materlals, ma-chlnes, manpower, and methods (the four Ms). Other names can be
used to suit the problem at hand. Altemative or additional categories inchide places, procedures,
poli-cies, and people (the four Ps) or surroundings, suppliers, systems, and sidlis (the four Ss).

The key is to have three to six main categories that encompass all possible ar-eas of causes.
Brainstorming techniques (defined later in the chapter) are conunonly performed to add causes to
the maln bones. When the brainstorming is complete, the fishbone depicts a complete picture of all
the possibilities about what could be the root cause for the designated problem.The development
team can then use the diagram to dedde and agree on what the most likely causes of the problem
are and how they should be acted on. Figure 6-1 ls an example of a fishbone diagram

Requirement Discovery

Given an understanding of problems, the systems analyst can start to define require-ments. For
today's systems analysts to be successful in defining system requirements, they must be skllled in
effective methods for gathering information—fact-finding. Fact-finding is a technique that is used
across the entire development cyde, but it is extremely critical the requirements analysis phase.
Once fact finding has been completed, tools such as use cases, data models, process models, and
object models will be used to document facts, and condusions will be drawn from the facts. You will
learn about these tools and how to document requirements derived from fact-finding ln subsequent
chapters of this textbook.

Facts are in the domain of the business applic-ation and its end users. Therefore, the analyst must
collect those facts in order to effectively apply the documentation tools and teclutiques. During
systems analysis phases, the analyst learns about the vocabulary, problems, opportunities,
constraints, requirements, and priorities of a business and a system.

DOCUMENTING AND ANALYZING REQUIREMENT

When the systems analyst 1s performing factanding activities, it is important that the analyst
assemble or document the gathered information (or druft requ Irements) 1n an organized,
understandable, and meaningful way. These initial documents will provide direction for the
modeling techniques the systems analyst will use to analyze the re-quirements and determine the
correct requirernents for the project. Once those have been identilled, the systems analyst
formalizes the requlrements by presenting thern in a document that will be rev1ewed and approved
by the users.

Documenting the Draft Requirements Systems analysts use various tools to doc-ument thelr initial
findings in draft form. They write use cases to describe the system fimctlons from the extemal users'
perspective and in a manner and terminology the users understand. Decislon tables are used to
document an organization's complex business policies and decision-making rules, and requirements
tables are used to doc-ument each specific requirement. Fach of these tools is examined in more
detall later in the chapter.

and desires for the functionality and features of the new system. The goal of the requirements
analysis activity is to discover and resolve the problems with the requitements and reach agreement
on any modiflcations to satlsfy the stakeholders. The process is concerned with the "initial"
requirements gathered from the stake-holders. These requirements are usually incomplete and
documented in an informal wa• in instruments such as use cases, tables, and reports. The focus at
this stage is on reaching agreement on the stakeholder's needs; in other words, the analysls should
answer the question, aDo we have the right system requirements for the project?" Inevitably, the
draft requirements contain many problems, such as:

• Missing requirements

• Conflicting requirements

• Infeaslble requirements

• Overlapping requirements

• Ambiguous requirements

The fact-flnding and requirements analysls activitles are very closely assoclated with each other and
in fact are often interwoven. If requilrements dlscovered during the fact-finding process are found to
be problematic, the analyst may go ahead and perform analysis ac-tivities on the seiect ltems in
order to resolve the problems before continuing to elictt additional system needs and desires.

Formalizing Req uirements

System requirernents are usuaIly documented In a for-mal way to communicate the requirements to
the key stakeholders of the system.This document serves as the contract between the system
owners and the develop-ment team on what is going to be provided ln terms of a new system. Thus,
lt may go through many revisions and reviews before everyone agrees and authorizes its contents.
There is no standard name or format for this document. In fact, many organizations use different
names such as requlrements statement, requlrements specificatlon, requirements definItion,
functional specification, and the Ilke, and the format is usu-ally tailored to the organintlon's needs.
Companles that provide information systems and software to the U.S. government must use the
format and namIng comentlons specifled in the government's published standards document MIL-
STD-498.2 Many or-

The functlons and services the system should pro•ide. Nonfunctional requirements, including the
system's features, characteristics, and attrlbutes. The constraints, which restrict the development of
the system or under which the system must operate. Information about other systems with which
the system must interface.

risk of costly requtrements errors. Performing requirements valldation, therefore, is a necessary step
toward achleving that goal. Requirements validation is performed on a nal draft of the requlrements
definttion document after all input has been solldted frotn the system owners and users. The
purpose of thls activity is for the systems analyst to ensure the requirements are written correcdy.
Examples of errors the systems analyst mlght tind are:

• System models that contain errors.

• Typographical or grammatical errors.

• Conflicting requirements.

• Ambiguous or poorly worded requirements.

• Lack of conformance to quallty standards reqttired for the document.

There is 7 Fact Finding

In this section we present seven common fact-finding techniques:

• Sampling of existing documentation, forms, and databases.

• Research and site visits.

• Observation of the work environment.

• Questionnaires.

• Inteniews.

• Prototyping.

• Joint requirements planning.

M analyst usually applies several of these techniques during a single systems pro-ject. To be able to
select the most sultable technique for use in any given situation, systems analysts need to learn the
advantages and disadvantages of each of the fact-finding techniques.

SAMPLING

When studying an existing systern, systems analysts develop a pretty good feel for the system by
studying existing documentation, forms, and files. A good anal•st always knows to get facts first
from existing documentation rather than from people.

Collecting Facts from Existing Documentation What kind of documents can teach you about a
system? The first document the analyst may wish to seek out is the organization citart. An
organization chart serves to identify key Individual owners and users for a project and their reportlng
relationships. The analyst may also want to tnce the history that led to the project.To accomplish
thls, the analyst should collect and revlew documents that describe the problem. These include: •
InteroffIce memoranda, studies, minutes, suggestion box notes, customer com-plaints, and reports
that document the problem area. • Accounting records, performance reviews, work measurement
reviews, and other scheduled operating reports. • Information systems project requests—past and
present.
In addition to documents that describe the problem, there are usually documents that describe the
business function being studled or designed. These documents may include:

• The company's mission statement and strategic plan.

• Formal obJectives for the organization subunits being studled.

• Policy manuals that may place constraints on any proposed system.

• Standard operating procedures (SOPs), Job outlines, or task instructions for specific day-to-day
operations.

• Completed forms that represent actual transactlons at various points in the processing cycle.

• Samples of manual and computerized databases.

• Samples of manual and computerized screens and reports.

Document and File Sampling Techniques Because it would be impractical to study every occurrence
of every form or record ln a file or database, system analysts normally use sampling techniques to
get a large-enough cross section to determine what can happen tn the system. The systems analyst
should seek to sample enough forms to rep-resent the full nature and complextty of the data.
Experienced analysts avoid the pitfalls of sampling blan• forms—blank forms tell little about how the
form Ls actually used, when lt is not used, or how it is often mIsused. When studying documents or
records from a database table, analysts shoukl study enough samples to ldentify all the posslble
processing c-onditions and exc-eptions. Statlstical sampling techniques can be used to detennine if
the sample SiZe is large enough to be representative of the total poptiation of records or documents.

Research and site visits

A second fact-finding technlque is thoroughly researching the problem domain. Most problems are
not completely unlque. Other people have solved them before us. Many times organizations contact
or perform site vislts with companles they know have previously experienced slmllar problems. lf
these companies are to share," valuable infortnation can be obtained that may save tremendous
tlme and cost in the development process. Computer tnde joumals and reference books are a good
source of information. They can provide information on how others have solved slmllar problems.
With recent advances in cyberspace, analysts rarely have to leave their desks to do research.

OBSERVATION

Observation Ls one of the most effectkve data-collectlon techniques for learnIng about a system.
Observation involves the systems analyst becoming an observer of people and activities in order to
learn about the system. This technique is often used when the validity of data collected through
other methods is in question or when the com-plexity of certain aspects of the s•stem prevents a
clear explanation by the end users.

Coll ecting Facts by Observing People at Work Even with a well-conceived ohservation plan, the
systems analyst is not assured that fact-finding will be successfuL The following story, which appears
in a book by Gerald M. Weinberg called Rethink-ing Systems Analysis and Deslgn, gives us an
entertaining •et excellent example of some of the pitfalls of observation.3

Observation Advantages and Disadvantages

Observation can be a very useful and beneficial factanding technique provided that you have the
abillty to observe all aspects of the work being performed by the users and that the work is being
per-formed in the usual manner. You should become aware of the pros and cons of the technique of
observatlon. Advantages and dlsadvantages indude:

Guidelines for Observation

How does the systems analyst obtaln facts through observationt Does one simply arrive at the
observation site and begin recording

everything that's viewed? No. Much preparatIon should take place in advance. The analyst must
determine how data will actually be captured. Will it be necessary to have spedal forms on which to
qulckly record data? Will the indhiduals being observed be bothered b• ha•ing someone watch and
record their actions? When are the low, normal, and peak periods of operations for the task to be
obsen-ed? The systems analyst must identify the ideal time to observe a particular aspect of the
system.

The following guidelines are key to honing obserration skills:

• Determine the who, what, where, when, why, and how of the observatlon.

• Obtain permission to observe from appropriate supervisors or managers.

• Inform those who will be observed of the purpose of the observation.

• Keep a low profile.

• Take notes during or immediately following the observation.

• Review observation notes with appropriate Individuals.

• Don't interrupt indb•duals at work.

• Don't focus heavily on trivlal activides.

• Don't make assumptlons.

Living the System

In this type of observation the systems analyst actively performs the role of the user for a short
period of time. This is one of the most effective ways to leam about problems and requirements of
the system. By filling the user's•shoes," a systems analyst quiddy gains an appreciation for what the
user experiences and what she or he has to do to perform the job.This type of role playing gives the
sys-tems analyst a firsthand educatlon in the business processes and functions, as well as the
problems and challenges assodated with them.
QUESTIONNARY

Another fact-finding technique is conducting surveys through questionnaires. The document can be
mass-produced and distributed to respondents, who can then com-plete the questiotmaire on thelr
own time. Questionnaires allow the analyst to collect facts from a large number of people while
maintaining uniform responses. When deal-ing with a large audience, no other fact-finding
technique can tabulate the same facts as efficiently.

Collecting Facts by Using Ouestionnaires Systems analysts have often criticized the use of
questionnaires. Many systems analysts daim that the responses lack reliable and useful information.
Nevertheless, ques-tionnaires can be an effective means of fact gathering, and many of these
criticisms can be attributed to the inappropriate or

Types of Questionnaires

There are two formats for questionnaires: free format and fixed format. Free-format questionnaires
are deslgned to allow the users to exer-cise more freedom or latitude in their answers to each
questlon.

Here are two examples of free-format questions:

• What reports do you currently receive and how are they used?

• Are there any problems with these reports (e.g., are they inaccurate, is there insufficient
information, or are they difilcult to read and/or use)? If so, please explain.

There are three types of fixed-forrnat questions:

1. For multiple-choice questions, the respondent is given several answers from which to choose. The
respondent should be told lf more than one answer can be selected. Some multlple-choice questions
allow for very brief free-format responses when none of the standard answers apply.

Examples of muittple-citoice thced-forrnat questions are: Do you feel that badcorders occur too
frequently?

❑ YES ❑ NO

Is the current accounts recetvable report that you receive useful?

❑ YES ❑ NO

If no, please explain.

2. For rating questions, the respondent is given a statement and asked to use supplled responses to
state an opinlon.To prevent built-in bias, there should be an equal number of positive and negatIve
ratings.The following is an example of a rating thed-format question:

The implementatIon of quantIty discounts would CallSe an increase in customer orders.

1:1 Strongly agree

❑ Agree

❑ No opinion

❑ Disagree

❑ Strongly disagree

3. For ranking questionts, the respondent is glven several possible answers, which are to be ranked
in order of preference or experlence. An example of a ranking flxed-forrnat questlon ls:

Rank the following transactions according to the amount of time you spend processing them:

new customer orders

order cancellatlons

order modifications

payments

Developing a Questionnaire Good questionnaires can be difficult to develop.The following procedure

can prove helpful in developing an effective questionnaire:

I. Determine what facts and opinions must be collected and from whom you should get them. If the
number of people is large, consider using a smaller, randomly selected group of respondents.

2. Based on the facts and opinions sought, determine whether free- or fixed-format questions will
produce the best answers. A combination format that permits optional free-format clarification of
fixed-format responses is often used.

3. Write the questions. Examine them for construction errors and possible misin-terpretations. Make
sure that the questions don't reveal your personal bias or opinions. Edit the questions.

4. Test the questions on a small sample of respondents. If your respondents had problems with them
or if the answers were not useful, edlt the questions.

5. Duplicate and distribute the questionnaire.

INTERVIEW

The personal interview is generally recognized as the most important and most often used fact-
finding technique. Personal interviews involve soliciting require-ments through direct, face-to-face
interaction. Interviewing can be used to achieve any or all of the following goals: find facts, verify
facts, clarlfy facts, generate en-thusiasm, get the end user involved, identify requirements, and solidt
ideas and opinions. There are two roles assumed in an interview. The systems analyst is the
interviewer, responsible for organlzing and conducting the interview. The system user or system
owner is the interviewee, who is asked to respond to a series of questions. There may be one or
more interviewers and/or interviewees. In other words, In-terviews may be conducted one-on-one
or many-to-many. Unfortunately, many systems analysts are poor interviewers. In this sectlon you
will learn how to conduct proper interviews.
Collecting Facts by Interviewing Users People are the most important element of an information
system. More than anything else, people want to be In on things. No other fact-finding technique
places as much emphasis on people as inter-views. But people have different values, priorities,
opinions, motivations, and personalities. Therefore, to use the interviewing technique, a systems
analyst must possess good human relatlons skills for dealing effectively with different types of
people. As with other fact-finding techniques, interviewing isn't the best method for all situations.
Interviewlng has its advantages and disadvantages, which should be weighed against those of other
fact-finding techniques for every fact-finding situation:

Interview Types and Techniques There are two types of interviews, unstructured
and structured. Unstructured interviews are characterized as involving general
questions that allow the interviewee to direct the conversation:This type of interview
frequently gets off track, and the analyst must be prepared to redirect the interview
back to the main goal Of subject. For this reason, unstructured interviews don't usu-
ally work well for systems analysis and design. Structured interviews involve the in-
terviewer asking specific questions designed to elicit specific information from the
Interviewee. Depending on the interviewee's responses, the interviewer will direct
additional questions to obtain clarification or amplification. Some of these questions
may be planned and others spontaneous.

> How to Conduct an Interview

A systems analyst’s success ts at least partially dependent on the ability to interview.

A successful interview will involve selecting appropriate individuals to interview,
preparing extensively for the interview, conducting the interview property, and fol
lowing up on the interview. Here we examine each of these steps in more detail. Let's
assume that the analyst has identified the need for an interview and has determined
exactly what kinds of facts and opinions are needed.

Select Interviewees The systems analyst should interview the end users of the in-
formation system being studied. A formal organization chart will help identify these
individuals and their responsibilities. The analyst should attempt to learn as much as
possible about each individual prior to the interview, such as the person’s strengths,
fears, biases, and motivations. The interview can then be geared to take the charac-
teristics of the individual into account.

Prepare for the Interview Preparation is the key to a successful interview. An interviewee can easily
detect when an interviewer is unprepared and may resent the
lack of preparation because it wastes valuable time. When the appointment is made,
the interviewee should be notified about the subject of the interview. To ensure that
all pertinent aspects of the subject are covered, the analyst should prepare an interview
guide. The interview guide is a checklist of specific questions the interviewer
will ask the interviewee. The interview guide may also contain follow-up questions

Conduct the Interview

Respect your interviewee and his or her time. Dress to

match the interviewee. That generally means that you will dress differently to inter-
view managers than you will to interview workers on the loading dock. If the inter-

view will be held in a meeting room other than the interviewee’s office, arrive early

to make sure it ts set up appropriately.

Open the interview by thanking the interviewee in advance. State the purpose

and length of the interview and how the gathered data will be used. Then monitor the

time so you will keep your promise.

Follow Up on the Interview To help maintain good rapport and trust with inter-

viewees, the interviewer should send them a memo that summarizes the interview.

This memo should remind the interviewees of their contributions to the systems proj}-

ect and allow them the opportunity to clarify any misinterpretations that the inter-

viewer may have derived during the interview. In addition, the interviewees should be

given the opportunity to offer additional information they may have failed to bring

out during the interview.

Listening When most people talk about communication skills, they think of speak-

ing and writing. The skill of listening is rarely mentioned, but it may be the most im-

portant skill during the interviewing process. In order to conduct a successful

interview, the interviewer must make a distinction between hearing and listening:“To

hear is to recognize that someone is speaking, to listen is to understand what the

speaker wants to communicate.”"*

Body Language and Proxemics What is body language, and why should a sys-

tems analyst care about it during the interviewing process? Body language is all the

non-verbal information being communicated by an individual. Body language is a form

of nonverbal communication that we all use and of which we are usually unaware.

Studies have determined a startling fact: Of a person's total feelings, only 7 percent
are communicated verbally (in words), whereas 38 percent are communicated by the

tone of voice used and 55 percent are communicated by facial and body expressions.

If you only listen to someone's words, you are missing most of what the person has

to say.

> Discovery Prototyping

Another type of fact-finding technique is prototyping. Prototyping was introduced in

Chapter 3 for use in rapid application development (RAD). As you should recall, the

concept behind prototyping is building a small working model of the users’ require-

ments or a proposed design for an information system. This type of prototyping ts usu-

ally a design technique, but the approach can be applied earlier in the system

development life cycle to perform fact-finding and requirements analysis. The process

of building a prototype for the purpose of identifying requirements is referred to as

discovery prototyping.

> Joint Requirements Planning

Many organizations are using the group work session as a substitute for numerous and

separate interviews. One example of the group work session approach is joint

requirements planning (JRP), wherein highly structured group meetings are con-

ducted for the purpose of identifying and analyzing problems and defining system re-

quirements. This and similar techniques generally require extensive training to work

as intended. However, they can significantly decrease the time spent on fact-finding in

one or more phases of the life cycle. JRP is becoming increasingly common in systems

planning and systems analysts to obtain group consensus on problems, objectives, and

requirements. In this section, you will leam about the participants of a JRP session

JRP Participants Joint requirements planning sessions include a wide variety of

participants and roles. Each participant is expected to attend and actively participate

foe the entire JRP session. Let's examine the different types of individuals involved in
a typical JRP session and their roles:

How to Plan JRP Sessions Most JRP sessions span three to five days and occa-

sionally last up to two weeks. The success of any JRP session depends on properly

planning and effectively carrying out the plan. Some preparation is necessary well be-

fore the JRP session can be performed. Before planning a JRP session, the analyst must

work closely with the executive sponsor to determine the scope of the project that is

to be addressed through JRP sessions. It is also important that the highdevel require-

ments and expectations of each JRP session be determined. This normally involves in-

terviewing selected individuals who are responsible for departments or functions that

are to be addressed by the systems project. Finally, before planning the JRP session,

the analyst must ensure that the executive sponsor is willing to commit people, time,

and other resources to the session.

How to Conduct a JRP Session The JRP sesion begins with opening remarks, in-

troductions, and a beief overview of the agenda and objectives for the session. The

JRP facilitator will direct the session by following the prepared script. To successfully

conduct the session, the facilitator should follow these guidelines:

 Do not unreasonably deviate from the agenda.

 Stay on schedule (agenda topics are allotted specific times).
 Ensure that the scribe is able to take notes (this may mean having the users and
managers restate their points more slowly or clearly).
 Avoid the use of technical jargon.
 Apply conflict resolution skills.
 Allow for ample breaks.
 Encourage group consensus.
 Encourage user and management participation without allowing individuals to
dominate the session.
 Make sure that attendees abide by the established ground rules for the session.

FACT STRATEGY

1. Learn from existing documents, forms, reports, and files. Analysts can learn a
lot without any people contact.
2. If appropriate, observe the system in action.

3. Given all the facts already collected, design and distribute questionnaires to
clear up things that aren't fully understood.

4. Conduct interviews (or group work sessions). Because most of the pertinent
facts have already been collected by low-user-contact methods, interviews can
be used to verify and clarify the most difficult issues and problems. (Alterna-
uvely, consider using JRP techniques to replace or complement interviews.)

5. (Optional). Build discovery prototypes for any functional requirements that are
not understood or for requirements that need to be validated.

6. Follow up. Use appropriate fact-finding techniques to verify facts (usually inter-
views or observation).