Module 1 REQUIREMENT GATHERING TECHNIQUES

Unit 1 Fact Finding Techniques

1.0 INTRODUCTION

In this unit you will learn about the various techniques of fact finding and getting appropriate
information about systems which is currently in place.

2.0 OBJECTIVES

After going through this unit, you should be able to:

mention the types of interviews

enumerate the steps to be followed for a successful interview explain group
discussions describe how site visits are conducted

describe how presentations are done explain the two

types of questionnaires.

3.0 MAIN CONTENT

3.1 Fact Finding Techniques

To learn the functions of the existing system, systems analyst needs to collect data
related to the existing system. Usually, the data related to organization, staff,
documents used, formats used in the input and output processes is collected. This
information is obtained through interviews, group discussions, site visits,
presentations, and questionnaires.

Need for Fact Finding

Normally, each and every business house or any organization has its own rules and
procedures to run and manage it. When a system needs to be developed, the systems
analyst needs to know the requirements of the system. Depending on these
requirements, the system has to be developed.

3.2 Interviews

Personal interview is a recognized and most important fact finding technique, where
the systems analyst gathers information from individual through face to face
interaction. Interviews are used to find the facts, verify facts, clarify facts, get the
customer involved, identify the system requirements and know all options. The
interview is usually conducted by the systems analyst. To conduct interview, the
interviewer must have personality which helps him/her to be social with strangers or
 different types of people. Always and for all situations, interviews are not appropriate
fact finding methods. It has both advantages and disadvantages.

Advantages

Interviews permit the systems analyst to get individual’s views and get the specific
problem work wise and operation wise.
Interviews allow the systems analyst to obtain a better clarity of the problem due to
feedback from the interviewees.
In the process of interviews, the interviewer has time and scope to motivate the
interviewee to respond freely and openly.
Interviews allow the systems analyst to understand the user requirements and to
know the problems faced by the user with the current system.
It is an effective technique to gather information about complex existing
systems. Disadvantages

Interviews are very time consuming.

Success of interviews, in most of the cases, depends on the systems analyst’s interpersonal
relationship skills.
Some times, interviews may be impractical due to the location of interviewees.

Types of Interviews

There are two types of interviews:

Structured; and Unstructured.

In structured interviews, there is a specific set of questions to be asked to an interviewee. In the

case of unstructured interviews, there are few specific questions pertaining to an interviewee.
But, you have questions which are common to all interviewees. Unstructured interviews are
conducted with only a general goal or subject in mind.

Conducting Interview is an art. The success in interview depends on selecting the individual,
preparing for the interview, creating situation in which the answers offered are reliable and
creating a situation in which opinion can be given without any fear of being criticized by others.

Arranging Interview

The system analyst should prepare properly for the interview. S/he should select place of
interview, time of interview in such a way so that there will be minimal interruption. Always, it
is important to take appointment with the interviewee. Time to be spent during interview varies
from project to project. The higher the management level of the interviewee, the less the time to
be scheduled for the interview.

Guidelines for Conducting Interviews

For a successful interview, the steps to be followed are given below:

Introduction

During introduction; the analyst should introduce himself by focusing on purpose of the interview
and the confidential nature of interview. Also, this is the phase wherein first impressions are
formed and pave way for the success of the remaining part of the interview.

Asking Questions
Questions should be asked exactly as these are worded in case of structured interview.
Rewording may modify or bias the response. Always, questions have to asked in the
same sequence as prepared.

Recording the Interview

Record of the interview must be kept mentioning the source of the data and its time
of collection. Sometimes, the analyst cannot remember the source of the data which
may attribute to the invalid sources.

Doing a Final Check

After the interview has been completed, the deliberations made during the interview
should be put in the form of a report. The report of the interview has to be sent to the
interviewee for his/her signature, If any discrepancies are found or any modifications
are to be done, these CaJ1 be done at this point of time.

3.3 Group Discussions

In this method, a group of staff members are invited who are expected to be well
versed in their own wings of the organization. The analysts will have a discussion
with the members for their views and responses to various queries posed by them.
 In this process, individuals from different sections gather together and will discuss
tl1e problem at hand. Ultimately, tl1ey come to an optimum solution. In this process,
the problems of all sections are taken care of most of the cases; solutions are found
which are acceptable to everyone. The main disadvantage of this process is that it is
very difficult to get all the concerned people together at a time. But, the major
advantage is that a mutually acceptable solution can be found.

3.4 Site Visits

The engineers of the development organization visit the sites. Usually, the systems
analysts visit sites to get first hand information of the working of the system. In this
technique, systems analyst watches the activities of different staff members to learn
about the system. When there is confusion about the validity of data collected
from other sources, the systems analyst uses the method of site visits. The main
objective of site visit is to examine the existing system closely and record the activities
of the system.

Advantages

1. The process of recording facts site visits is highly reliable.

2. Sometimes, site visits take place to clear doubts and check the validity of the data.
3. Site visit is inexpensive when compared to other fact finding techniques.
4. In this technique, systems analyst will be able to see the processes in the organization at first
hand.
5. The systems analyst can easily understand the complex processes in the organization.

Disadvantages

1. People usually feel uncomfortable when being watched; they may unwillingly perform
their work differently when being observed.
2. Due to interruptions in the task being observed, the information that is collected may be
inaccurate.
3. Site visits are done during a specific period and during that period, complexities
existing in the system may not be experienced.
4. There may be scheduling problems for the systems analysts when the activities take place
during odd hours.
5. Sometimes, people may be more careful to adopt the exact procedure which they do
not typically follow. .

Guidelines for Site Visit

Site visits are to be conducted where the work load is normal. After studying the work and normal
work load, systems analyst can observe the work at peak hours to see the effect caused by
increased volumes. The systems analyst should collect the input/output form, documents at the
time of his/her visit. The following guidelines need to be followed at the time of observation and
site visit:

1. Keep a low profile at the time of site visit.

2. Take necessary permissions from appropriate officials to conduct site visit.
3. Inform the individuals who will be observed at the time of site visit.
4. Take notes of the study of site visit immediately.
5. Do not make any assumptions.

3.5 Presentations
It is another way of finding the facts and collecting data. Presentation is the way by
which the systems analyst gathers first hand knowledge of the project. The customer
makes a presentation of the existing system or about the organization. Participants in
the meeting are representatives from the IT company and key personnel of the client
organization. When a company needs to develop a software project, it may present its
requirements for IOE (interest of expression) from the interested IT Company. In that
case, the client presents his/her requirements. Based on the requirements, tile IT
companies make prototype and show the demo of the prototype. It is very difficult to
obtain information in detail from a presentation. But, information available through
presentation is sufficient to develop a prototype. Presentation is made by the
concerned department in consultation from other departments and senior officials.

3.6 Questionnaires

Questionnaires are special purpose documents that allow the analyst to collect
information and opinion from respondents. By using questionnaires, it is possible to
collect responses or opinion from a large number of people. This is the only way to
get response from a large audience.

Advantages

1. It is an inexpensive means of collecting the data from a large group of

individuals
2. It requires less skill and experience to administer questionnaires.
3. Proper formulation and interaction with respondents leads to unbiased
response from the customers. .
4. Customers can complete it at their convenience.
 5. Responses can be tabulated and analyzed quickly.

Disadvantages

1. Sometimes, the number of respondents is low.

2. There is no guarantee that the respondents will answer all the questions.
3. Sometimes, the individual may misunderstand the question. In that situation,
the analyst may not get correct answer.

Types of Questionnaires

There are two types of questionnaires:

Free formed questionnaires are questionnaires where questions are mentioned along with
blank spaces for response.
Fixed formed questionnaires are questionnaires which consist of multiple choices and the
respondent can select only from the choices
provided.

SELF ASSESSMENT EXERCISE

1. What are the guidelines for conducting interviews?

2. Discuss the two types of questionnaires

4.0 CONCLUSION

In this unit, you have learned about the various techniques of fact finding and how to get
appropriate information about a system currently in place.

5.0 SUMMARY

What you have learned from this unit is based on fact finding techniques.

6.0 TUTOR-MARKED ASSIGNMENT

Explain the two types of interviews.

7.0 REFERENCES/FURTHER READINGS

Advanced System Analysis and Design, 2009. National Open University of Nigeria. 2009.
ISBN:978-058-678-4.

Jeffrey L. Whilten, Lonmie D. Benltey, Kevin C, Diltoman; (2001).

System Analysis and Design Methods, (Fifth Edition).

Jeffrey A. Hofter, Jorey F. George, Joseph S. Valaclch, (2002). Modern Systems Analysis and
Design Pearson Education; (Third Edition).
National Open University of Nigeria. 2009. ISBN:978-058-678-4.

Elias M. Award;( 1994). Systems Analysis and Design; Galgotia Publications; (Second
Edition).

Perry Edwards (1993). Systems Analysis and Design; McGraw-Hill Publication.

Online Resources

http://www.rspa.com http;//www.cbpa.edu/flin/info609/sysplan
UNIT 2. DATA MODELING

1.0 INTRODUCTION

In this unit we will learn about data modeling which is also referred to as information
modeling. We will also consider the entity relationship (ER) diagram as well as
process specification tools.

2.0 OBJECTIVES

At the end of this unit, you should be able to:

understand and explain data modeling describe the entity

relationship diagram describe the three tools for
specifying policies.

3.0 MAIN CONTENT

3.1 Data Modeling

It is a technique for organizing and documenting a system’s data. Data modeling is

sometimes called database modeling because a data model is eventually implemented
as database. It is also some times called information modeling. The tool for data
modeling is entity relationship diagram.
3.2 ER Diagram

It depicts data in terms of entities and relationships described by the data. Martin gives the
following notations for the components of ERD.

1. Entities: An entity is something about which the business needs to store data. An entity
is a class of persons, places, objects, events or concepts about which we need to capture
and store data. An entity instance is a single occurrence of an entity. The notation
is given below:

Student is the Student name of entity

2. Attribute: An attribute is a descriptive property or characteristic of an entity. Synonyms
include element, property and field.

A compound attribute is one that actually consists of other attributes. It is also known as a
composite attribute. An attribute “Address” is the example of compound attribute as shown in
the following illustration.

3. Relationships: A relationship is a natural business association that exists between one or more
entities. The relationship may represent an event that links the entities.

The following are some important terms related to ER diagrams:

Cardinality defines the minimum and maximum number of occurrences of one entity that may
be related to a single occurrence of the other entity. Because all relationships are bidirectional,
cardinality must be defined in both directions for every relationship. Figure 7.4 depicts various
types of cardinality.

Degree: The degree of a relationship is the number of entities that participate in the relationship.

Recursive Relationship: A relationship that exists between different instances of the same entity
is called recursive relationship. Figure 7.3 depicts recursive relationship between the instances
of the Course entity.

Figure 7.3: Example of Recursive relationship

 Figure 7.4: Different types of cardinality

3.3 Process Specification Tools

Processes in Data Flow Diagrams represent required tasks that are performed by the
system. These tasks are performed in accordance with business policies and
procedures.

Policy

A policy is a set of rules that govern some task or function in the business. Policies
consist of rules that can often be translated into computer programs. Systems Analyst
along with representatives from the policy making organization can accurately convey
those rules to the computer programmer for programming purposes.

Procedures

Procedures put the policies into action. Policies are implemented by procedures.
Procedures represent the executable instructions in a computer program.
There are tools with the help of whom specification for policies can be created. They are Decision
Table, Decision Tree and Software Engineering notations.

3.3.1 Decision Tables

Decision Table is very useful for specifying complex policies and decision-making rules. Figure
7.5 depicts a Decision table.
The following are various components of a Decision table:

Condition Stubs: This portion of table describes the conditions or factors that will affect
the decision or policy making of the organisation.

Action Stubs: This portion describes the possible policy actions or decisions in the form of
statements.

Rule: Rules describe which actions are to be taken under a specific combination of conditions.

Decision tables use a standard format and handle combinations of conditions in a very concise
manner. Decision table also provides technique for identifying policy incompleteness and
contradictions.

X – Action (condition is true)

_ - Condition is irrelevant for this rule
? – Unknown rule

Figure 7.5: An example Decision Table

3.3.2 Decision Trees

Decision tree is a diagram that represents conditions and actions sequentially, and thus shows
which conditions to consider first, and so on. It is also a method of showing the relationship each
condition and permissible subsequent actions. The diagram resembles branches on a tree.
The root of the tree is the starting point of the decision sequence. The particular
branch to be followed depends on the conditions that exist and decision that will be
made. Progression from the left to right along a particular branch is the result of
making a series of decisions. Following each decision point is the next set of
decisions to be considered. The nodes of the tree thus represent conditions and
 indicate that a determination must be made about which condition exists before the
next path can be chosen. Figure 7.6 depicts a Decision tree.

Figure 7.6: An Example Decision tree for a Customer Bill Payment System

3.2.3 Structured English Notation

It is a tool for describing process. There are three valid constructs in this notation.

They are:

1. A sequence of single declarative statements.

2. The selection of one or more declarative statements based on a decision, e.g.,
if-then-else, switch, case.
3. The repetition of one or more declarative statements, e.g., looping constructs
such as do-while, for-do

The following are the guidelines usage of Structured English notation:

1. Avoid computer programming language verbs such a move, open or close.

2. The statement used in the Structured English Notation should always specify
the formula to be used.
Structured English notation is based on the principles of structured programming. Process
specification logic consists or a combination of sequences of one or more imperative sentences
with decision and repetition constructs. Consider the following:

1. An imperative sentence usually consists of an imperative verb followed by the contents

of one or more data stores on which the verb operate;
 For example, add PERSONS-SALARY TO TOTAL SALARY
2. In imperative sentences, verbs such as “process”, “handle” or “operate” should not be
used.
3. Verbs should define precise activities such as “add” or compute average etc.
4. Adjectives that have no precise meaning such as “some” or “few” should also not be used
in imperative sentences, because they cannot be used later to develop programs.
5. Boolean and arithmetic operations can be used in imperative statements. Table 7.1 lists
the arithmetic and Boolean operators.

Table 7.1: Arithmetic and Boolean Operators

6. Structured English logic:

Structured English uses certain keywords to group imperative sentences and define
decision branches and iterations. These keywords are:

(BEGIN, END), (REPEAT, UNTIL), (IF, THEN, ELSE), (DO; WHILE), FOR, CASE, etc.

7. Grouping imperative sentences:

1) Sequence Construct

A sequence of imperative statements can be grouped by enclosing them with

BEGIN and END keywords

2) Decision (Selection)

a) A structure, which allows a choice between two groups of imperative

sentences. The key words IF, THEN and ELSE are used in this structure. If a
 condition is ‘true’, then group I sentences are executed. If it is false, then group
2 sentences are executed.

b) A structure which allows a choice between any numbers of groups of

imperative sentences. The keywords CASE and OF are used in this structure.
The value of a variable is first computed. The group of sentences that are
selected for execution depends on that value.

3) Repetition

This structure shows two ways of specifying iterations in structured English.

a) One way is to use the WHILE...DO structure. Here, the condition is tested
before a set of sentences is processed.

Alternative to WHILE….. DO is FOR structure.

b) REPEAT......UNTIL structure. Here, a group of sentences is executed

first then the condition is tested. So, in this structure, the groups of sentences
are executed at least once.

Table 7.2 depicts the criteria to be used for deciding the notation among Structured
English. Decision Tables and Decision Trees. Table 7.3 depicts the criteria to be used
for deciding the notation among Decision Tables and Decision Trees.

Table 7.2: Criteria for deciding the notation to be used

Criteria Structured Decision Decision

English Tables Trees
Determining condition 2 3 1
& actions
Transforming condition 1 2 1
& actions into
sequence
Checking consistency 2 1 1
& completeness

Table 7.3: Criteria for deciding the notation to be used between

Decision tables and Decision trees
 Criteria Decision Tables Decision Trees
Portraying complex Best Worst
logic
Portraying simple Worst Best
problems
Making decisions Worst Best
More compact Best Worst
Easier to manipulate Best Worst

3.4 Data Dictionary

A Data Dictionary consists of data about data. The major elements of data dictionary are data
flows, data stores and processes. The data dictionary stores details and descriptions of these
elements. It does not consist of actual data in the database. But, DBMS cannot access data in
database with out accessing data dictionary.

If analysts want to know tile other names by which a data item is referenced in the system or
where it is used in the system, they should be able to find the answers in properly developed
data dictionary. Data dictionaries are hidden from users so that data in it not tampered.

Analysts use data dictionaries for tile following reasons:

1. To manage the detail in large systems.

2. To communicate a common meaning for all system elements.
3. To document the features of the system.
4. To facilitate analysis of the details in order to evaluate characteristics and determine
changes that should be made to the system.
5. To locate errors and omission~ in the system.

The dictionary contains two types of descriptions for the data flowing through the
system: Data elements and Data structures. Data elements are grouped together to
make up a data structure.

Data-elements are recorded in data dictionary at the fundamental data level. Each item
is identified by a data name, description, alias and length and has specific values that
are permissible for it in the system.

A data structure is a set of data items that are related to one another and then
collectively describe a component in the system. Data is arranged in accordance with
one of the relationships namely sequence, selection, iteration and optional
relationship.
 SELF ASSESSMENT EXERCISE

1. What is the ER Diagram?

2. Describe a recursive relationship with the aid of a diagram.

4.0 CONCLUSION

In this unit, we have learned about data modeling. We have also considered the
entity relationship diagram as well as process specification tools.

5.0 SUMMARY

Data modeling, entity relationship diagram and process specification tools were
considered in this unit.

6.0 TUTOR-MARKED ASSIGNMENT

Define the term “Data modeling”.

7.0 REFERENCES/FURTHER READINGS

Advanced System Analysis and Design, 2009. National Open University of Nigeria. 2009.
ISBN:978-058-678-4.

Jeffrey L. Whilten, Lonmie D. Benltey, Kevin C, Diltoman; (2001). System Analysis

and Design Methods, (Fifth Edition).

Jeffrey A. Hofter, Jorcy F. George, Joseph S. Valaclch, (2002). Modern Systems

Analysis and Design Pearson Education; (Third Edition).

Elias M. Award; (1994.). Systems Analysis and Design; Galgotia Publications;

(Second Edition).

Perry Edwards; (1993). Systems Analysis and Design; McGraw-Hill Publication.

Online Resources

http://www.rspa.com