Requirements

Understand the Business Need

These are exactly the type of considerations, which business stakeholders will have
to work through when they are faced with a business problem or need. The
business analyst (operationally focused enterprise analyst) will be part of the
options analysis performed when processes such as a feasibility studies, business
concept briefs and other pre-project analysis steps are undertaken. The business
analyst will also get involved in assessing whether the proposed initiative will be
in line with the business strategy and be profitable by also assisting in
cost/benefits analysis activities. As you can see there are a myriad of business
analysis activities, which are performed even before requirements come into play.
 Requirement

A requirement in the context of Business Analysis is simply a statement provided by

a stakeholder about what they believe they need in order to solve a particular
business problem or respond to a specific business need.
Once this requirement has been raised by the stakeholder it is the business
analyst’s role to further define, analyze, validate and prioritize the requirement
statement as it is now included within the business analysis context of
requirements management.
In real life, the stakeholder will typically state their business problem or need and
then provide a whole range of individual requirements throughout the
requirements management process managed by the business analyst.
 Scope Statements

• Although we are not discussing the scope statements of a project in great detail
here it is important to take note that each project or initiative must have clear
boundaries of what is included and excluded prior to embarking on requirements
analysis. (This is approached in a slightly more iterative and evolutionary fashion
on Agile based projects (driven by time, budget and change in business priorities)
but is essentially still working within boundaries or scope definitions at a high
level).
 Types of Requirements

1 Business Requirement:
• Build a family home to replace the home that was burnt down including the
addition of a garage.
• The Business Requirement is a high level statement describing what is required
from the business’s perspective. In some contexts or projects there may be
overlap between the Business Requirements statements and that of individual
scope statements. For larger initiatives these will be different levels of expressing
what is required.
 Types of Requirements

2 Stakeholder Requirements
• Stakeholder Requirement Example 1: “We need a family house with four
bedrooms so that each child has their own bedroom”
• Stakeholder Requirement Example 2: “We need the house to have two separate
bathrooms to ensure the parents have their own bathroom separate from the
children”
• Stakeholder Requirement Example 3: “We need the house to be protected
against future bush fires so that we don’t have to fear loosing our house again”
 Types of Requirements

3 Solution Requirements
• Solution Requirement Example 1: “I want my bedroom to be painted pink so that
everyone will know it is my room” – Stakeholder who raised this requirement is
the little girl.
• Solution Requirement Example 2: “I want my bedroom floor space to be at least
30 square meters so that I can practice my skateboard tricks in the bedroom” –
Stakeholder who raised this requirement is the teenage boy in the family.
 Types of Requirements
There are two sub-types of Solution Requirements:
• Functional Requirements: This type of solution requirement describes how the
solution must behave. In the example of the house, it describes how the house
must look (colors, size of bedroom) and perform (have an air-conditioning unit in
each bedroom). In a system related scenario example, the different functions that
you want a system to perform is typically described as functional requirements
(in an Agile Project context, it is referred to as a ‘user story’).
• Non-functional Requirements: The non-functional requirement type of solution
requirement describes the characteristics that you want the system to have. In
the context of the house example, solution requirement 4 is describing a
characteristic that is required of the house walls. It is not a function of the house
but rather a characteristic of the walls.
 Types of Requirements
4 Transition Requirement:
• The floors in the house must be covered with sheets to protect the carpets when
the moving company moves the furniture into the house.
• A transition requirement describes a requirement that must be in place for a
certain phase or period of time. In this example, the requirement to have the
floor protect during the moving of furniture into the house is an example of a
transition requirement.

• Requirements gathering is usually divided into 4 phases: Elicitation, Analysis,

Specification, and Validation.
 Requirement Gathering
Techniques

Elicitation consists of the

activities that are taken to
understand the consumers
and explore their requirements.
 Requirement Gathering
Techniques
• Brainstorming is used in requirement gathering to get as many ideas
as possible from group of
people.

Generally used to identify

possible solutions to problems
, and clarify details of
opportunities
 Requirement Gathering
Techniques
• Focus Group is a gathering of people who are representative of the
users or customers of a product to get feedback. The Focus group
includes subject matter experts. The objective of this group is to
discuss the topic and provide information. A moderator manages this
session. A focus group typically consists of 6 to 12 members

• Interviews of stakeholders and users are critical to creating the great

software.
1. Structured/ Unstructured
2. 5 Why technique
 Requirement Gathering
Techniques
• Interface Analysis is used to review the system, people, and
processes. This analysis is used to identify how the information is
exchanged between the components. An Interface can be described
as a connection between two components.
 Requirement Gathering
Techniques
• Document Analysis gather business information by
reviewing/examining the
available materials that
describe the business environment
 JAD Sessions
• Joint Application Development/Design (JAD) is a process used to
collect business requirements while developing new information
systems for a company.
• JAD sessions are highly structured, facilitated workshops that bring
together customer decision makers and IT staff to produce high
quality deliverables in a short period.
• The JAD approach, in comparison with the more traditional practice,
is thought to lead to faster development times and greater client
satisfaction, because the client is involved throughout the
development process.
 JAD Sessions

- Key users - are generally the business users who are more tightly aligned to the IT
project
- Subject Matter Expert (SMEs) - These are the business users and outside experts who
are required for a successful workshop. The subject matter experts are the backbone of
 Requirement Prioritization
Requirements prioritization is the process of managing the relative importance
and urgency of different requirements to cope with the limited resources of
projects. Adequate prioritization ensures that the most critical requirements
are addressed immediately in case time or budgets run out.

Who Prioritizes?
• Prioritization must be done in collaboration with the stakeholders (customer,
product owner, project sponsor, and users) as early as possible so that
alternatives can be explored.
 Prioritization Guidance
A common trap is to let the stakeholders choose the priorities without any
guidance. In those situations, the stakeholders likely tag most requirements as
being critical with only a few as being important but less than critical. The analyst
must guide the stakeholders through the prioritization process.

The business analyst should challenge the customer:

• What are the consequences to the business objectives if this requirement were
omitted?
• Is there an existing system or manual process that could compensate?
• Why can’t this requirement be deferred to the next release?
• What business risk is being introduced if a particular requirement cannot be
implemented right away?
 Priority Semantics
• Subjective Ranking is a scheduling strategy in which each stakeholder assigns a priority value from a
scale. This strategy can often lead to conflicting priorities as all stakeholders’ priority definitions have
the same weight.

• Objective Alignment is a scope delineation strategy in which each discovered requirement is aligned
with a business requirement or business objective (business goal).

• Five Whys is a scope delineation strategy. For each identified requirement, the analyst asks the
stakeholder at least five times why the requirement is necessary.

• Limited Votes is a scheduling strategy that forces reluctant stakeholders to make decisions. Each
stakeholder gets a limited number of votes that can be assigned to any of the identified requirements.

• Time Boxing approach is particularly suited to iterative development. The development of a system is
divided into relatively short time periods that are of a fixed duration, often two to four weeks.
 Requirement Elicitation

Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really need.
Requirements elicitation Activities:
• Requirements elicitation includes the subsequent activities. Few of them are listed below –
• Knowledge of the overall area where the systems is applied.
• The details of the precise customer problem where the system are going to be applied must
be understood.
• Interaction of system with external requirements.
• Detailed investigation of user needs.
• Define the constraints for system development.
 Requirement Elicitation

Requirements Elicitation Methods:

• There are a number of requirements elicitation methods. Few of them are listed
below –
• Interviews
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Quality Function Deployment (QFD)
• Use Case Approach
 Requirement Lifecycle
Requirement lifecycle involves a number of phases and at times it can be a
complicated process. The nature of the process depends on the methodology you
choose for your software development like Agile, Waterfall, Incremental, etc.
Each phase may involve a lot of paperwork and approval procedure. It also deals
with the project documents like a project proposal, project management plan,
project scope, and the business case.
•
 Requirement Lifecycle
Phase 1: Requirement Definition
• It is one of the primary phases of the requirement gathering process commonly
known as Requirement extraction.
• Once the requirement is gathered, it can be organized in folders logically as per
product release or sprint.
• These requirements are analyzed further to prepare facts and figures for a
business analyst to track possible result based on analysis. This procedure is
referred as Impact Assessment.
 Requirement Lifecycle
• Phase 2: Requirement Validation
• The requirement validation phase includes analyzing the needs or conditions
required to meet a new or altered product considering needs of the various
stakeholders.
• For the success of any project, validating requirements is very important.
Requirement validation includes checking the specification, wireframe, High
Fidelity Simulation, Traceability Analysis, etc.
• There are requirement validation tools that do validation with very less human
intervention.
 Requirement Lifecycle
Phase 3: Requirement Documentation
• Requirement documents should cover following things
• Project stakeholders requirement
• Business analysis plan
• Current state analysis
• Scope statement specification
 Requirement Lifecycle
Phase 4: Requirement Management
• Requirement Management process includes planning, monitoring, analyzing,
communicating and managing of those requirements. If the requirement is not
managed well, the end product will get affected adversely. There are requirement
management tool available online which help you to manage the requirement
with minimum hurdles.
 How to Handle changes to
requirements?
This is a logical question asked in an interview. As a Business Analyst, the
first task will be to get a signature on a document by the user which states
that after a point of time no changes to the requirements are accepted.
In a few cases, if the changes to the requirements are accepted then:
• Firstly, I will note down the changes made to the requirements and will
prioritize them.
• I will also go through those changes and find out the impact of them on
the project.
• I will calculate the cost, timeline, and resources required to cover the
impact of change requirements on the project.
• And will make sure that whether those changes affect or create gaps to
functional design documents, testing or coding.