An initial overview of the requirements, its types, elicitation techniques, difficulties in elicitation and requirements trade offs (prioritisation).

1. The Requirements –
Initial Overview
From Article by Martin Schedlbauer
Prepared by Kumail Raza

2. Business Analyst Responsibility
 Discovery (Surveys, Questionnaires, Brainstorming session, Elicitation
Interviews)
 Analysis (Comparing different solutions, identifying pros and cons, risks and
benefits)
 Documentation and
 Communication
Of Requirements

3. What is a Requirement
Generally Speaking
 A requirement is simply a feature
that a product or service must
have in order to be useful to its
stakeholders.
For example, two requirements for a
customer relationship management
system might be;
 To allow users to update the
payment terms for an account.
 To allow users to add new
customers
More Precise Definition
 Condition or capability needed by
a user to solve a problem or
achieve an objective.
 Condition or capability that must
be met or possessed by a system or
system component to satisfy a
contract, standard, specification,
or other formally imposed
document.
 documented representation of a
condition or capability in (1) or
(2).
More precise definition by IEEE Glossary of Software Engineering Terminology and the Business Analysis Body of Knowledge® (BABOK®)

4. Broad Requirement Types
Business, User and System Requirements
Business Requirements
 For example; Reduce
cost of invoicing
customers.
 These are high level
objective of the
organizations and are
generally expressed by
the business sponsors
User Requirements
 For example; Allow me
to click on a customers
name and then display
customer’s account
history.
 This describes what the
users needed to perform
their tasks and are very
specific to functional
need of the user.
System Requirements
 For example; When user
clicks on customer name,
system shows following
customer specific data
fields.
 This describes how the
business process will be
automated and
 the attributes and
 constraints of the
environment where the
system will operate.

5. 6 levels of Requirements
 Business
“Reduce account payable processing time by 40%”
 User (Stakeholder)
“View order history when click to customer account name.”
 Functional (Solution)
“Display customer account name as a link to customer history.”
 Non-Functional (Quality of Service)
“Require strong password of at least 8 characters in length containing a min. of one
non-alphabet character.”
 Constraint
“Account history is only viewable on Internet Explorer”
 Implementation (Transition)
“Users must pass an online certification before being allowed to use the system.”
Requirement levels by Business Analysis Body of Knowledge® (BABOK)®

6. Overlapping Terms Within Some Organization
 A User Requirement is referred to as a
business requirement in some
organization.
 A Business Requirement is sometimes
called a Business Goal or Project
Objective.
 Functional Requirement are also often
called technical, detailed or system
requirement.
 It is important to understand the
semantics of the terms being used. If
there is any doubt, ask, but don’t
assume.
 Publish a glossary of terms to clarify
the meaning of the term being used by
the project team.

7. Project Scope  Scope creep is a common occurrence. It
describes the propensity of scope to expand as
stakeholders add requirements during the
project without regard to its impact on
budget, schedule, and deliverables.
 The project manager must work with its
stakeholders to get an agreement on the
scope.
Is the agreed upon set of features
that the final product will contain.
Or
The requirements that are
considered to be implementable
within the allocated time and
budget are called the project scope.

8. Stakeholders
 They have specific needs that the analyst
must help them to uncover and identify.
A stakeholder is anyone who has an
interest in the successful outcome
of the project including project
sponsors, users, business
executives, managers, developers,
client, customers, vendors and
government agencies.
They are the main source of
requirements.

9. Eliciting Requirements
Is surprisingly hard and challenging.
Often stakeholders are not quite
sure what they need and they often
don’t know how to express what
they need.
“No Silver Bullet: Essence and
Accidents of Software Engineering”
“The hardest single part of building
a software system is deciding
precisely what to build. No other
part of the conceptual work is as
difficult as establishing the
detailed technical requirement,
including all the interfaces to
people, machines, and to other
software systems. No other part of
the work so cripples the resulting
system if done wrong. No other part
is more difficult to rectify later.”
(Fred Brooks stated in his seminal
essay)

10. Eliciting Requirements Techniques
The analyst applies a variety of techniques to elicit requirements.
 Interviews, either with an individual or with a group of people, offer the
opportunity for rich, detailed communication.
 A workshop is a structured method for interacting with a group of people.
Workshops can generate much information quickly if well facilitated and if
participants are active.
 A focus group is an interactive session with a carefully selected group of people
designed to capitalize on the synergy of a group.
 Brainstorming is a method of quickly generating many creative ideas from a
group of people.
 Observation is watching people as they go about their jobs. Observation can be
an effective way to gain a realistic and detailed understanding of how work is
done in the production environment; however, it is time consuming and may
disrupt work.
 Surveys/Questionnaires allow you to collect information from many people in
a relatively short period.

11. Requirements Management (RM)
 Is the process of defining and
maintaining the requirement
that forms the agreement
between the project team and
stakeholders.
 Requirements management is
generally supported by the use of
requirements tracking or
requirements management tools.

12. Requirements Process
 Discovery (elicitation), analysis, modeling and documentation, communication,
and validation.

13. Requirements Priority
 The requirements are generally implemented in order of priority, starting
with the most important ones.
 The simplest reason being most projects have limited time and budget and
commonly not all requirements can be addressed.
 By the time project run out of time and money the stakeholders would want
the most important requirements taken care of. While this sounds simple,
establishing and negotiating the priorities of requirements can often be very
difficult and politically challenging.
 Stakeholders don't want to prioritize for fear of not getting what they want;
the project team does not want an unlimited scope as they know that they
likely cannot accomplish everything with the allotted resources.

14. Prioritization Matrix