LECTURE IV

REQUIREMENTS
ENGINEERING
1
 Requirements Engineering

Requirem ents Engineering

Requirem ents Elicitation Requirem ents Analysis

Requirem ents Specification Requirem ents Verification

Requirem ents Managem ent

 REQUIREMENTS ELICITATION
In Requirement Engineering, Requirements
Elicitation/Gathering is the practice of obtaining
the requirements of a system from users, customers
and other stakeholders. 

Lack of user input is one of the most common causes

of unsuccessful projects.
 Importance of Requirements Elicitation

 Helps to identify a problem.

 Helps to define the problem.
 Leads to action or decision making.

4
 Challenges of requirements
elicitation
Requirements Elicitation is one of the most difficult
stages of analysis, with numerous communication
barriers existing between the analyst and client that
make eliciting requirements difficult.
 Challenges of Requirements
Elicitation
The “Yes, But” syndrome.
The Undiscovered Ruins
“User and Developer” syndrome.
“The sins of your predecessors” syndrome.
 The “Yes, But” Syndrome
The “Yes, But” syndrome stems from human nature
and the users inability to experience the software as
they might a physical device.
Need to employ techniques that get the “yes, buts”
out early.
Anticipate that there will be “yes, buts” and add time
and resources to plan for feedback.
Tends to be User Interface centric, these tend to be
the touch points of the system by the users.
 The “Undiscovered Ruins”
Syndrome
The more you find, the more you realize there is still
more
Teams struggle with determining when they are done
with requirements elicitation.
First scope the requirements elicitation effort by
defining the problem or problems that are to be
solved with the system.
Employ techniques that help find some of those ruins
and have the stakeholders buy-into the requirements.
 The “User and the Developer”
Syndrome
Reflects the profound differences between the
two, making communication difficult.
Characteristic Response
Users do not know what Recognize and
they want, or they know appreciate the user as
what they want but cannot domain experts; try
articulate it. different techniques.
Users think they know Provide alternative
what they want until elicitation techniques
developers give them earlier; storyboard, role
what they said they playing, prototypes, and
wanted. so on.
 The “User and the Developer”
Syndrome
Characteristic Response
Analysts think they Put the analyst in the
understand user problems users place. Try role
better than users do. playing for an hour or a
day.
Everybody believes Yes, its part of human
everybody else is nature, so lets get on
politically motivated. with the program.
 The “Living with the Sins of your
Predecessors” syndrome
The users and developers do not trust each other
based on previous interactions, so users want
everything and developers commit to nothing
Need to build trust, slowly. Do not over commit to
features, schedule, or budget.
Build success by delivering highest priority features
early in the process.
 Challenges….
The difference in general language in both cases. The
clients use a business language while analysts tend to
be more technical.
Retrieval induced forgetting. There is a problem that
users often do not recall all the relevant information
they have available.
It is also difficult or impossible at times to meet with
the relevant stakeholders.
Assumed requirements which are not necessary.
 Challenges…
Misunderstanding between the client and the analyst.
This is where the clients do not fully understand the
system that analyst’s are proposing to design.
Problems of scope. This is where the System
boundaries are inadequately defined or defined too
soon
 Problems of volatility. This is where Stakeholders
refuse to commit to a set of written requirements.
 Conflicting requirements within the organization.
 Challenges
Lack of motivation and resistance to change from
the Participants which might often lead to hiding of
necessary information from the analysts.
Limited time to meet all stakeholders for discussions
to come up with a common agreement and
understanding.
There is also a problem of unspoken requirements
which might be very crucial during the deployment
of the system.
Unnecessary technical details
 Questions asked
Requirements Requirements analysis
determination questions
questions Who should do it?
Who does it? What should be
What is done? done?
Where is it done? Where should it be
When is it done? done?
How is it done? When should it be
done?
How should it be
done?
 Gathering Information
Need to have a checklist of types of information /
documentation to gather.

Challenges are :
Where to look for information
When to stop looking for information i.e. how much
is enough
 Categories of Information
Information about the Organisation
Information about the People
Information about the Work
Information about the Work Environment
 Categories of information checklist
Information about the organisation
Goals of the company
Organisational structure
Objectives and purposes of functional units
Policies
Information about the people
Authority and responsibility relationships
Job duties
Interpersonal relations
Information needs
Categories of information checklist
Information about the work
Tasks and work flows
Methods and procedures for performing the work
Work schedules and volumes
Performance criteria
Control mechanisms
Information about the work Environment
Physical arrangement of work areas
Resources available
 Sources of Data
Primary sources; collecting raw data and analyzing
it.
Secondary sources; reviewing literature and other
data sources, collected for some other purpose other
than the investigation at hand.
 Methods of Data collection
The main data collection methods for
requirements elicitation can be obtained by the
following techniques;

21
 Method: Requirements Workshop
The requirements workshop is perhaps the most
powerful technique for eliciting requirements.
It gathers all key stakeholders together for a short but
intensely focused period.
The use of an outside facilitator experienced in
requirements management can ensure the success of
the workshop.
Brainstorming is the most important part of the
workshop.
 Workshop Problems and
Suggestions
Challenge
Time Management
It’s difficult to get going
after breaks and lunch.
Key shareholders may
be late returning
Grandstanding,
domineering positions
Remedy
Facilitator keeps a timer
for all breaks and fines
anyone that is late,
everyone gets one free
pass.
Everyone gets one 5
minute position
statement.
 Workshop Problems and
Suggestions
Challenge Remedy
Lack of input from Facilitator encourages
stakeholders everyone to use 5-
minute position and
great idea ticket.
comments, petty Use “Cheap Shot
behaviors, and turf wars
Tickets”, all others cost
money.
Flagging energy after Light lunches,
lunch afternoon breaks,
rearrange seating
 Method: Storyboarding
Storyboards identify the players, explain what
happens to them, and describes how it happens.
The purpose of storyboarding is to elicit early “Yes,
But” reactions.
Storyboards can be positive, active, or inactive.
Make the storyboard sketchy, easy to modify, and
unshippable.
Storyboard early and often on every project with new
or innovative content.
Storyboarding
 Method: Use Cases
Use Cases, like storyboards, identify the who, what,
and how of system behavior.
Use Cases describe the interactions between a user
and a system, focusing on what the system “does” for
the user.
The Use Case model describes the totality of the
system’s functional behavior.
Early stages: After you have an overview of the use
cases, perhaps only by a phrase a piece, expand 10%
of them in detail.
Use case diagram
 Method: Role Playing
Role playing allows stakeholders to experience the
user’s world from the user’s perspective.
A scripted walkthrough may replace role playing in
some situations, with the script becoming a live
storyboard.

(Class-Responsibility-Collaboration (CRC) cards, often

used in object-oriented analysis, are a derivative of
role playing.)
 Method: Prototyping
Prototyping is especially effective in addressing the
“Yes, But” and the “Undiscovered Ruins”
syndromes.
A software requirements prototype is a partial
implementation of a software system, built to help
developers, users, and customers better understand
system requirements.
Prototype the “fuzzy” requirements: those that,
although known or implied, are poorly defined and
poorly understood.
 Method: Observation Method
A method of collecting primary data by human,
mechanical, electrical or electronic means; commonly.
It may include collecting verbal communication as
well as non verbal.

31
 Method: The Experience Survey
The analyst questions knowledgeable individuals usually
done thru an informal, free-flowing conversation.
 
Participants are not selected randomly nor are they
representative of the organization or department within
which they work. Rather, they are knowledgeable,
articulate and thoughtful individuals.

32
 Method: The Case Study
Used when it is necessary to learn from the experience of
others. The emphasis is on an entire organization with
great attention paid to detail under study.
 
In order to obtain the information required, it is usually
necessary to use other methods like an indepth interview,
consulting internal documents and records and
observation.

33
 Method: The In-Person Interview
Survey
Direct communication.
Planning for the interview
Try to answer the following questions
 What do you wish to achieve from the interview?
Who should be interviewed?
How will these interviews be conducted?
What topics are to be covered in the interview?

It can be conducted as a telephone interview 34

 Method: Self-administered Survey

Any survey technique that requires the

respondent to complete the questionnaire
him/herself. Mostly used for other
stakeholders of the system such as customers.

The most common ways of distributing these

surveys are through the use of mail, fax,
newspapers/ magazines, the Internet, etc.
 Questionnaires
The questionnaire is a formal approach to measuring
characteristics, attitudes, motivations, opinions as well
as past, current and future possible behaviours.

The information produced from a questionnaire can be

used to describe, compare or predict these facts.

36
Requirements Elicitation Guidelines
Assess System Feasibility
Be sensitive to organizational and political
considerations
Identify and consult system stakeholders
Record requirements sources
Use Business concerns to drive requirements
elicitation
Look for domain constraints
Record requirements rationale
Requirements Elicitation Guidelines
Collect requirements from multiple viewpoints
Prototype poorly understood requirements
Use scenarios to elicit requirements
Define operational processes
Reuse requirements
 Identify and Consult System
Stakeholders
If lacking consideration of everyone who is likely to
be affected by the introduction of the system, there is
a great likelihood of missing some critical
requirements.

Identifying stakeholders and discussing the system

with them makes people feel like they are part of the
requirements elicitation process.
 Use Business Concerns to Drive
Requirements Elicitation
If a system is to be useful, it must contribute to the
key concerns of the business. If the concerns are
identified and used as drivers of the requirements
elicitation process, there will be higher confidence
that the system will meet real organization needs.

Making the business concerns explicit helps to focus

and clarify these goals.
Collect Requirements from Multiple
Viewpoints
If requirements are collected from a single
viewpoint, they are unlikely to meet other
stakeholders’ requirements.
Collecting requirements from multiple viewpoints is
a useful way to prioritize requirements
Identified viewpoints can be used to help
organize requirements elicitation and
organize the requirements specification, too.
 Reuse Requirements
Saves money and time. Studies have shown that
similar systems can re-use up to 80% of the
requirements.
Reuse reduces risk. Reused requirements have a
better chance of being understood by all the
stakeholders.
Requirements reuse may lead to additional reuse in
other lifecycle activities.
Component design
Tests
Code
 REQUIREMENTS VERIFICATION
Before being presented as information, data should be
put through editing. This process checks for accuracy
and eliminates problems that can produce
disorganized or incorrect information.

Data editing may be performed by clerical staff,

computer software, or a combination of both;
depending on the medium in which the data are
submitted.
 REQUIREMENTS ANALYSIS
Focuses on the actual work of doing requirements
determination/ specification. The “Pieces” model is
used to classify identified requirements into one of six
subject areas.
 The “PIECES” framework

P - Performance
I - Information
E - Economy
C - Control
E - Efficiency
S - Services
 The “PIECES” framework
 Performance
 Is current throughput and response time adequate?
 Information
 Do end users and managers get timely, pertinent, accurate
and usefully formatted information?
 Economy
 Are services provided by the current system cost-
effective?
 Could there be a reduction in costs and/or an increase in
benefits?
 The “PIECES” framework
 Control
 Are there effective controls to protect against fraud and
to guarantee information accuracy and security?
 Efficiency
 Does current system make good use of resources: people,
time, flow of forms?
 Services
 Are current services reliable?
 Are they flexible and expandable?
 REQUIREMENTS MANAGEMENT
The process of documenting, analysing, tracing,
prioritising and agreeing on requirements and then
controlling change and communicating to relevant
stakeholders.
The purpose is to ensure that requirements are
documented, verified, and meet the needs and
expectations of stakeholders
It is a continuous process throughout a project
 Requirements tracing
Requirements traceability is concerned with
documenting the life of a requirement.
It enables tracing back origin of each requirement
and every change made to the requirement
The use of the requirement after the implemented
features have been deployed and used should be
traceable.
 Prioritising and Agreeing
The Scope is the overall view of what a system will
deliver. The impact a system has on an organization’s
ability to meet its goals determines the true value of
that system to the organization.
It defines what is included in, or excluded from, a
project
Care needs to be taken to avoid Scope Creep (the
insidious growth in the scale of a system during the
life of a project).
 Determining Scope…
Define the scope: Often, they are qualitative and/or
focus on general statements. Includes;
Defining Deliverables
Defining Functionality and Data
Defining Technical Structure
Assumptions: In order to define the scope, there will
be assumptions that need to be made.
Define the outcome: The outcome is the change that
will occur when the project is complete.
 Establishing Objectives
The two main categories of objectives are;
Performance objectives (does it improve performance?)
Quality or usefulness of the output
Quality or usefulness of the format of the output
Speed at which output is generated
Cost objectives (Does it reduce costs?)
Development costs
Costs related to the uniqueness of the system application
Fixed investments in hardware and related equipment
Ongoing operating costs of the system
Establishing measurable Objectives

Measuring objectives requires creative and

critical analysis.
Creative analysis
The investigation of new approaches to existing
problems
Critical analysis
Unbiased and careful questioning of whether system
elements are effective and efficient and whether new
relationships should be established
 Feasibility Analysis
A step that assesses viability of a system
Economic feasibility: Does the project make
financial sense? Do the predicted benefits offset the
time and cost needed to acquire them?
Net Present Value
Preferred approach for ranking competing projects and
determining economic feasibility
Represents the net amount by which project savings
exceed project expenses, after allowing for the cost of
capital and the passage of time
 Feasibility Analysis…
Technical feasibility: can the hardware, software and
other systems components be acquired or developed to
solve the problem
Operational feasibility: can the project be put into
operation or action? What are the logistical and
motivational considerations?
Schedule feasibility: Can the project be completed in a
reasonable amount of time?
Legal feasibility – e.g., will the system contravene the
Information Privacy Act?
 Defining Business Needs
A good set of user requirements are needed for
computer system projects to be successful. There is
need to specify correctly what the system should do.
Computer systems developers rarely have as good an
idea of how a business runs and should run,
compared with a business user,
Business users have little idea of what a computer
system could achieve for them.
As a result, focus is on meeting timescales and
budgets, rather than what is going to be delivered.
 Defining Business Needs…
A requirement for a computer system specifies what
you want or desire from a system. For a business it
is, "What you want or desire from a system, which
you believe will deliver you a business advantage".

This advantage need not just be a reduction in costs

There is no need for a great deal of technical
knowledge to specify requirements; it can be a big
disadvantage.
 REQUIREMENTS SPECIFICATION
Business Requirement: what the system must be
able to do in order to achieve business goals and
objectives e.g. to reduce transaction costs by a
certain %age.
User Requirement: what users want of the system
e.g.
 A system that can capture student class attendance
A system that can enable retrieval of student attendance
 Requirements Specification…
Functional requirements - are what you want a
system to do. They are the tasks you want the system
to perform e.g.
To record students’ daily class attendance
To produce weekly student class attendance reports
 Requirements Specification…
Non-Functional Requirements: are restrictions or
constraints on the types of solutions that will meet
the functional requirements. Their purpose is to
restrict the number of solutions that will meet a set of
requirements. It specifies how well the system should
operate e.g. security, operational efficiency, speed,
scalability etc
It can be split into two types:
Performance constraints
Development constraints.
 Requirements Specification…
Performance Constraints
These constraints are how the system should perform
when it is delivered. Examples are;
The response time for information to appear to a user.
The number of hours a system should be available.
The number of records a system should be able to hold.
The capacity for growth of the system.
The length of time a record should be held for auditing
purposes.
Performance Testing is used to prove these have been met.
 Requirements Specification…
Development Constraints
These mainly fall in the field of project management.
The three general types are:
Time - When a system should be delivered.
Resource - How much money is available to develop the
system and the amount of time business staff could spend
in briefing system development staff.
Quality - Any standards which are used to develop the
system including project management, development
methods etc.
 Requirements Specification…
Design Objectives/Systems requirements
Design objectives assist in selecting a solution from
a number that are offered to you. It specifies the
Software and Hardware requirements.
If you do not produce a set of design objectives,
which are in a priority order, the developers will
produce their own, and these might not be what you
want.
 Requirements Specification…
Implementation/Transition requirements: specify
the type of software, hardware, human skills, change
over plan etc that should be in place in order to roll
out the new system.
 Defining Business Needs…
Requirements to Avoid
Many sets of requirements given to developers are
polluted with design and implementation solutions.
Hence the customer has told the developer how to
conduct their business
Requirements must only tell the developer
WHAT the design should deliver and not HOW the
system should be built, unless there are good reasons
for the “HOW” as it may lead to missing out on
better systems solutions.
 Dealing with constraints
Prioritising Requirements
Often large and complex sets of requirements are
produced . Most times the organisation may not
afford the time and financial resources for all the
requirements to be delivered, especially not
immediately.
The customer should prioritise the requirements to
specify what they most want. This is mainly done
using a technique called the MoSCoW technique.
 Dealing with constraints

Prioritising Requirements
MoSCoW technique divides the needs
into must haves, should haves, could
haves and won't (want to) haves.
If the customer does not prioritise then it will be
done by the developers, who may select the parts of
the process which are easiest to produce, or that are
technically challenging, but not taking into account
the needs of the organisation.
 MoSCoW
The "Must" requirements are non-negotiable, if they
are not delivered then the project is a failure.
Nice to have features are classified in the other
categories of "Should" and "Could.
Requirements marked as "Won't" are potentially as
important as the "Must" category but can be left for a
future release. A great deal of time might be spent in
trying to produce a good "Won't" list. (read more)
 Prioritising the Project Objectives
When a set of requirements has been prioritised then
it can be compared against the other planning aspects
of the project: scope, quality, timescale and
resources, and a risk statement produced.
One can prioritise the four main factors of scope,
quality, timescale and resources, and thus prioritise
the key project objectives. Which of them "Must" be
delivered, which has the maximum flexibility and is
defined as "Could", with the other two factors
between these as "Should“ and “wont”.
 Implications of Prioritising the
Project
Any choice that is made has tradeoffs.
If nearly all the requirements are prioritised as
"Must", then there is not much flexibility in the
scope of a project.
However it is better if a project is delivered on time,
even if it has few features, than if a project is
delivered late, but with a full set of features.
Therefore timescale competes to be the most
important factor.
 Implications of Prioritising the
Project
If quality is sacrificed then faults will occur in the
software.
Finally all systems must be produced to a budget,
and a business does not have unlimited resources to
put into a project.
There must be a chance of delivering business value
to avoid the risk going sky high.
A balanced and planned prioritisation of the factors
must take place.
 Dealing with constraints
A good set of user requirements consists of prioritised
sets of:
Functional requirements,
Non-functional requirements, and
Design objectives.
And does NOT have any design or implementation
decisions.
Producing these will enable you to get systems that will
deliver a business advantage.