CHAPTER THREE AND FOUR

REQUIREMENTS ENGINEERING
This is the process of eliciting, analysing and recording requirements for software
systems. Its goal is to create and maintain a system requirement document. The process
involves assessing whether the system is useful to business, discovering requirements,
converting them into some standard form and checking that the requirements actually
define the system.

The requirements engineering process

These are the activities that are involved in requirements engineering. They include:

1. Requirements elicitation
In requirements engineering, requirements elicitation is the practice of obtaining the
requirements of a system from users, customers and other stakeholders. The practice is
also sometimes referred to as requirements gathering/requirements discovery.
The term elicitation is used in books and research to raise the fact that good requirements
can not just be collected from the customer, as would be indicated by the name
requirements gathering. Requirements elicitation is non-trivial because you can never be
sure you get all requirements from the user and customer by just asking them what the
system should do. Requirements elicitation practices involves fact finding techniques
such as interviews, questionnaires, user observation/ethnography, Documentary review
e.t.c
2. Requirements Analysis and Negotiation
The purpose of this activity is to transform technical requirements into formal
requirements by ensuring that they express the needs of the customer. Analysis is an
iterative activity. The process steps will likely be repeated several times in consultation
with the customers. The goal of analysis is to locate places where requirements are
unclear, incomplete, ambiguous or contradictory. It groups related requirements and
organizes them into coherent clusters. The requirements are then prioritized and any
conflicts that arise are resolved.
3. Requirements Validation
Concerned with demonstrating that the requirements define the system that the customer
really wants. Requirements errors are very costly and so validation is very important.
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error. The requirements are checked against the following factors:
Validity – Does the system provide the functions which best support the customers
needs?
Consistency – Are there any requirements conflicts?
Completeness – Are all functions required by the customer included?
Regular reviews should be held during the whole process both the technical staff and the
customer should be involved in the reviews. Good communication between the technical
staff and the customer can resolve problems at an early stage. Before changing
requirements, check for traceability (origin) and adaptability (impact on other
requirements) of the requirements.

4. Requirements Management
The process of managing changing requirements during the requirements engineering
process. Requirements may change because:
 Technology may change
 User needs may change
 Changing business processes e.t.c
5. Requirements Documentation
Requirements need to be documented and a standard format is used.
Requirements should state what the system should do and the design should describe how
it does this.
N.B: Learn more about the IEEE standard for documentation especially requirement
documents.

Challenges in getting requirements

 Stakeholders don’t know what they really want.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have conflicting requirements.
 Organisational and political factors may influence the system requirements.
 The requirements change during the analysis process. New stakeholders may
emerge and the business environment change.

FACT FINDING
The formal process of using techniques such as interviews and questionnaires to collect facts
about systems, requirements and preferences.

When are fact finding techniques used?

There are many occasions for fact finding during the system development process. However, fact
finding is particularly crucial to the early stages of the life cycle including system planning,
system definition and requirements collection and analysis stages. It is during these early stages
that the developer learns about the terminology, problems, opportunities, constraints,
requirements and priorities of the enterprise and the users of the system.

Interviews
This is the most commonly used and normally most useful, fact-finding technique. Interviews are
a fact finding technique whereby the systems analysts collect information from individuals
(and/or groups) through face-to-face interaction. There can be several objectives to using
interviewing, such as finding out facts, verifying facts, clarifying facts, generating enthusiasm,
getting end-user involved, identifying requirements and gathering ideas and opinions. However,
using the interviewing technique requires good communication skills for dealing effectively with
people who have different values, priorities, opinions, motivations and personalities. As with
other fact finding techniques, interviewing is not always the best method for all situations.
There are two types of interviews: structured and unstructured. Unstructured interviews are
conducted with only a general objective in mind and with few, if any, specific questions. The
interviewer counts on the interviewee to provide a framework and direction to the interview. This
type of interview frequently loses focus and, for this reason, it often does not work well for
systems analysis and design.
In structured interviews, the interviewer has a specific set of questions to ask the interviewee.
Depending on the interviewee’s responses, the interviewer will direct additional questions to
obtain clarification or expansion. Some of the questions may be planned and others spontaneous.
Open-ended questions allow the interviewee to respond in any way he/she seems appropriate. An
example of an open-ended question is: ‘Why are you dissatisfied with the report on client
registration?’ Closed-ended questions restrict answers to either specific choices or short, direct
answers. An example of a closed-ended question might be: ‘Are you receiving the report on client
registration on time?’ or ‘Does the report on client registration contain accurate information?’
Both questions only require a ‘Yes’ or ‘No’ response.
To ensure a successful interview includes selecting appropriate individuals, preparing extensively
for the interview and conducting the interview in an efficient and effective manner.

Advantages
- Interviews give the analyst an opportunity to motivate the interviewee to respond freely
and openly to questions. By establishing rapport, the systems analyst is able to give the
interviewee a feeling of actively contributing to the systems project.
- Interviews allow the systems analyst to probe for more feedback from the interviewee.
- Interviews give the analyst an opportunity to observe the interviewee’s nonverbal
communication. A good analyst may be able to obtain information by observing the
interviewee’s body movements and facial expressions as well as by listening to verbal
replies to questions.
- Interviews permit the systems analyst to adapt or reword questions for each individual.

Disadvantages
- Interviewing is a very time-consuming, and therefore costly, fact-finding approach.
- Success of interviews is highly dependent on the systems analyst’s human relations skills.
- Interviewing may be impractical due to the location of interviews.
- Success can be dependent on the willingness of the interviewees to participate in
interviews.

Observation
Observation is one of the most effective fact-finding techniques for understanding a system. With
this technique, it is possible to either participate in, or watch, a person perform activities to learn
about the system. This technique is particularly useful when the validity of data collected through
other methods is in question or when the complexity of certain aspects of the system prevents a
clear expansion by the end users.
As with the other fact-finding techniques, successful observation requires preparation. To ensure
that the observation is successful, it is important to know as much about the individuals and the
activity to be observed as possible. For example, ‘When are the low, normal and peak periods for
the activity being observed?’ and ‘Will the individuals be upset by having someone watch and
record their actions?’
Advantages
- Data gathered by observation can be highly reliable. Sometimes observations are
conducted to check the validity of data obtained directly from individuals.
- The systems analyst is able to see exactly what is being done. Complex tasks are
sometimes difficult to clearly explain in words. Through observation, the systems analyst
can identify tasks that have been missed or inaccurately described by other fact-finding
techniques. Also, the analyst can obtain data describing the physical environment of the
task (e.g., physical layout, traffic lighting, noise level).
- Observation is relatively inexpensive compared with other fact-finding techniques. Other
techniques usually require substantially more employee release time and copying
expenses.
- Observation allows the systems analyst to do work measurements.

Disadvantages
- Because people usually feel uncomfortable when being watch, they may unwittingly
perform differently when being observed.
- The work being observed may not involve the level of difficulty or volume normally
experienced during that time period.
- Some systems activities may take place at odd times causing a scheduling inconvenience
for the systems analyst.
- The tasks being observed are subject t various types of interruption.
- Some tasks may not always be performed in the manner in which they are observed by the
systems analyst. For example, the systems analyst might have observed how a company
filled several customer orders. However, the procedures observed may have been those
steps used to fill a number of regular customer orders. If any of those orders had been
special orders (e.g. an order for goods not normally kept in stock), the systems analyst
would have observed a different set of procedures being executed.
- If people have been performing tasks in a manner that violates standard operating
procedures, they may temporarily perform their jobs correctly while you are observing
them. In other words, people may let you see what they you want you to see.

Questionnaires
Questionnaires are special–purpose documents that allow facts to be gathered from a large
number of people while maintaining some control over their responses. When dealing with a
large audience, no other fact-finding technique can tabulate the same facts as efficiently.
There are two types of questions that cam be asked in a questionnaire, namely free-format and
fixed-format. Free-format questions offer greater freedom in providing answers. A question is
asked and the respondent records the answer in the space provided after the question. Examples
of free-format questions are: ‘What reports do you currently receive and how are they used?’ and
‘Are there any problems with these reports?’ If so, please explain. The problems with free-format
questions are that the respondent’s answers may prove difficult to tabulate and, in some, may not
match the questions asked.

Fixed-format questions require responses from individuals. Given any question, the respondent
must choose from the available answers. This means the results much easier to tabulate. On the
other hand, the respondent cannot provide additional information. An example of a fixed-format
question is: ‘The current format of the report on property rentals is ideal and should not be
changed?’ The respondent may be given the option to answer ‘Yes’ or ‘No’ to this question or be
given the option to answer from a range of responses including ‘Strongly Agree’, ‘Agree’, ‘No
Opinion’, ‘Disagree’, and ‘Strongly Disagree’.

Advantages
- Most questionnaires can be answered quickly. People can complete and return
questionnaires at their convenience.
- Questionnaires provide a relatively inexpensive means for gathering data from a large
number of individuals.
- Questionnaires allow individuals to maintain anonymity. Therefore, individuals are more
likely to provide the real facts, rather than telling you what they think their boss would
want them to.
- Responses can be tabulated and analyzed quickly.

Disadvantages
- The number of respondents is often low.
- There’s no guarantee that an individual will answer or expand on all the questions.
- Questionnaires tend to be inflexible. There’s no opportunity for the systems analyst to
obtain voluntary information from individuals or to reword questions that may have been
misinterpreted.
- It is not possible for the systems analyst to observe and analyze the respondent’s body
language.
- There is no immediate opportunity to clarify a vague or incomplete answer to any
question.
- Good questionnaires are difficult to prepare.

Documentary Review

It involves perusing through literature to gain a better understanding of the existing

system. The documents to be reviewed will include: job descriptions, procedure
manuals, management reports, and sales report e.t.c.

When to Use Documentary Review

1) When a system analyst wants to have a quick overview of a system.

2) When the information required cannot be obtained using other techniques.

Merits

1) It is comparatively cheaper.
2) It is a faster means of information gathering especially if the documents are few.

Demerits

1) It may be time consuming and requires a lot of patience.

2) The relevant information maybe missing.
 3) The success depends on the experience and skills of the system analyst.
4) Most of the information available may be outdated.
5) The information available may not suit well with the requirements of the system
proposed.

Sampling

This is a process of systematically selecting representative elements of a population when

these elements are examined closely; it is assumed that the analysis will reveal useful
information about the population as a whole.
In the language of sampling:
-a population is the entire collection of people or things you are interested in;
-a census is a measurement of all the units in the population;
-a population parameter is a number that results from measuring all the units in
the population;
-a sampling frame is the specific data from which the sample is drawn, e.g., a
telephone book;
-a unit of analysis is the type of object of interest, e.g., arsons, fire departments,
firefighters;
-a sample is a subset of some of the units in the population;
-a statistic is a number that results from measuring all the units in the sample;
-statistics derived from samples are used to estimate population parameters.

For example, to find out the average age of all motor vehicles in the state in 1997:

Population=all motor vehicles in the state in 1997

Sampling frame=all motor vehicles registered with the DMV on July 1, 1997
Design=probability sampling
Unit of analysis=motor vehicle
Sample=300 motor vehicles
Data gathered=the age of each of the 300 motor vehicles selected in the sample
Statistic=the average age of the 300 motor vehicles in the sample Parameter=the
estimate of the average age of all motor vehicles in the state-1997

Types of Samples:
Non-probability (non-random) samples:
These samples focus on volunteers, easily available units, or those that just happen to be
present when the research is done. Non-probability samples are useful for quick and
cheap studies, for case studies, for qualitative research, for pilot studies, and for
developing hypotheses for future research.

Convenience sample:

also called an "accidental" sample or "man-in-the-street" samples. The researcher

selects units that are convenient, close at hand, easy to reach, etc.
 Purposive sample:

the researcher selects the units with some purpose in mind, for example, students
who live in dorms on campus, or experts on urban development.

Quota sample:

the researcher constructs quotas for different types of units. For example, to
interview a fixed number of shoppers at a mall, half of whom are male and half of
whom are female.

Other samples that are usually constructed with non-probability methods include
library research, participant observation, marketing research, consulting with
experts, and comparing organizations, nations, or governments.

Probability-based (random) samples:

Simple random sample:

Each unit in the population is identified, and each unit has an equal chance of
being in the sample. The selection of each unit is independent of the selection of
every other unit. Selection of one unit does not affect the chances of any other
unit.

Systematic random sampling:

Each unit in the population is identified, and each unit has an equal chance of
being in the sample.

Stratified random sampling:

Each unit in the population is identified, and each unit has a known, non-zero
chance of being in the sample. This is used when the researcher knows that the
population has sub-groups (strata) that are of interest.

Cluster sampling:

cluster sampling views the units in a population as not only being members of the
total population but as members also of naturally-occurring in clusters within the
population. For example, city residents are also residents of neighborhoods,
blocks, and housing structures.

When to Use Sampling

1) When the target population is too large.

2) When the population has similar characteristics.
Merits

1) It is cheaper considering the target population.

2) It speeds up the data gathering process.
3) It is effective since one obtains accurate information, which is assumed to be
representative.

Demerits

1) One requires statistical knowledge to use the method.

2) The sample taken may not be representative of the entire population and may
overlook certain critical issues.

Research and survey/site visit

This involves thorough research of the applications and problems of the old system. The
analyst must review trade journals, periodicals and books containing relevant
information.
He can also attend professional meetings, seminars and visiting others companies which
have similar systems.

Existing computerized system

The user requirement of a new computerized system can also be collected from the
existing computer system. The way work is done is analyzed and improvement
suggested. The areas looked at are:
i. File structures
ii. Transaction volumes
iii. Screen design
iv. User satisfaction
v. Causes of system crash e.t.c.

FEASIBILITY STUDY

Depending on the results of the initial investigations, the survey is expanded to a more detailed
feasibility study.
i) A feasibility study is an activity undertaken to determine the possibility or probability of
either improving the existing system or developing a totally new system.
ii) A feasibility study is a test of system proposal according to its workability, impact on the
organization, ability to meet user needs, and effectively use resources. It focuses on three
major questions:
- What are the end user’s demonstrable needs and how does a candidate system meet
them?
- What resources are available for given candidate systems? Is the problem worth
solving?
 - What are the likely impacts of the candidate system on the organization? How well
does it fit within the organization’s master computerization plan?

Each of these questions must be answered carefully. They revolve around investigation and
evaluation of the problem, identification and description of candidate systems, specification of
performance and the cost of each system and the final selection of the best system.
The objective of feasibility study is not to solve the problem but to acquire a sense of its scope.
During the study, the problem definition is crystallized and aspects of the problem to be included
in the system are determined. Consequently, costs and benefits are estimated with greater
accuracy at this stage. The result of this feasibility study is a formal proposal. This is simply a
report – a formal document detailing the nature and scope of the proposed solution. The proposal
summarizes what is known and what is going to be done. The report is the medium by which you
tell the management what the problem is, what you have found its causes to be and what you have
to offer in the way of recommendations. It consists of:

i) Statement of the problem – a carefully worded statement of the problem that led to
analysis.
ii) Summary of findings and recommendations – a list of major findings and
recommendations of the study. Clearly describe the subject and scope. List the areas
included and excluded. It is ideal for the user who requires quick access to the results of
the analysis of the system under study. Conclusions are stated, followed by a list of the
study recommendations and a justification for them.

iii) Details of findings – an outline of the methods and procedures undertaken by the existing
system, followed by coverage of the objectives and procedures of the candidate system.
Included are also discussions of the output reports, file structures and costs and benefits
of the candidate system.

iv) Recommendations and conclusions – specific recommendations regarding the candidate

system, including personnel assignments, costs, project schedules and target dates.

After the report is reviewed by the management, it becomes a formal agreement that paves the
way for actual design and implementation. This is a crucial decision point in the life cycle. Many
projects die here, whereas the more promising ones continue through implementation. Changes in
the proposal are made in writing, depending on the complexity, size and cost of the project. It is
important to verify changes before committing the project to design.

Types of Feasibility Studies

Technical Feasibility
Technical feasibility assesses whether the current technical resources are sufficient for the new
system. If they are not available, can they be upgraded to provide the level of technology
necessary for the new system?

Economic Feasibility
Economic feasibility determines whether the time and money are available to develop the system.
Includes the purchase of
- New equipment
- Hardware
- Software

Operational Feasibility
Operational feasibility determines if the human resources are available to operate the system once
it has been installed. Users that do not want a new system may prevent it from becoming
operationally feasible.

Social Feasibility
Determines the impact of the system of the people who will work with the system. This may
include work schedule, separation of offices, retraining, redeployment and even laying off
workers.
A well-done feasibility study enables the firm to avoid six common mistakes often made in
project work. These are:
i) Lack of top management support – top management has to understand and support
surbodinate managers in their effort to improve the firm’s operations. Feasibility studies
also get surbodinate managers directly involved in exploring and designing the systems
they will have to live with in the future. Such involvement results in increased
conscientiousness, which in turn enables top management to have more confidence in
surbodinates’ plans. The result will be top management support for such plans.

ii) Failure to clearly specify problems and objectives – the feasibility study can be directed
toward defining the problems and objectives involved in a project, after management has
given the group some understanding of what they would like to accomplish.

iii) Overoptimism – a feasibility study can be conducted in an objective realistic manner to

prevent overoptimistic forecasts. The study should be conservative in its estimates of
improved operations; reduced costs, and so on, to ensure that all the firm’s future
surprises with a new system are happy ones.

iv) Estimation errors – it is easy to underestimate the time and money involved in the
following areas:
a) Impact on the company’s structure
b) Employee’s resistance to change
c) Difficulty of retraining personnel
d) System development and implementation
e) Computer program debugging and running

ii) The crash project – many managers do not realize the magnitude of work involved in
developing new systems. Crash projects usually involve changing too quickly. A
feasibility study might determine that a present system with all its inadequacies is
superior to a crash project – assuming of course that the feasibility study itself is not run
as a crash project.

iii) The hardware approach – firms have been known to get a computer first and then
decide on how to use it. A feasibility study can identify, in advance, the uses to which
the computer will be put and can identify the best computers for the job before any
irreversible commitments are made.