Chapter 3

Requirement Analysis & Negotiation

By Yengusie D.
Contents
Introduction
Analysis Checklists
Requirements Analysis: Input , Tasks &
Output
Tasks in Requirement
Prioritizing Requirement
Organizing Requirements
Specifying & Modeling Requirements
Define Assumptions & Constraints

Requirement Analysis Techniques

Scenarios

 Introduction
The goal of analysis is to discover problems,
incompleteness and inconsistencies in the elicited
requirements.
These are then feedback to the stakeholders to resolve
them through the negotiation process
Analysis is interleaved with elicitation as problems are
discovered when the requirements are elicited
A problem checklist may be used to support analysis.
Each requirement may be assessed against the
checklist.
Check list example
 Premature design
 Does the requirement include premature design or implementation
information?
 Combined requirements
 Does the description of a requirement describe a single requirement or
could it be broken down into several different requirements?
Analysis Checklists
Unnecessary requirements
Is the requirement ‘gold plating’? That is, is the
requirement a cosmetic addition to the system which is
not really necessary.
Use of non-standard hardware
Does the requirement mean that non-standard hardware
or software must be used? To make this decision, you
need to know the computer platform requirements.
Conformance with business goals
Is the requirement consistent with the business goals
defined in the introduction to the requirements
document? Requirements ambiguity
Requirements ambiguity
Is the requirement ambiguous i.e. could it be read in
different ways by different people? What are the
possible interpretations of the requirement?
 Analysis Checklists….
Requirements realism
Is the requirement realistic given the technology
which will be used to implement the system?
Requirements testability
Is the requirement testable, that is, is it stated in such a
way that test engineers can derive a test which can show
if the system meets that requirement?
Requirements interactions
 A very important objective of requirements analysis is to
discover the interactions between requirements and to
highlight requirements conflicts and overlaps
 A requirements interaction matrix shows how requirements
interact with each other. Requirements are listed along the
rows and columns of the matrix
 For requirements which conflict, fill in a 1
 For requirements which overlap, fill in a 1000
 For requirements which are independent, fill in a 0
 Requirements Analysis: Input ,

Tasks & Output
Requirement analysis has the following inputs
Requirements
Business Needs
Stakeholder concerns
Organizational process assets
And the outputs are
Requirements [ prioritized, modeled]
Assumptions & Constraints
Requirement Structure
In order to produced the above outputs from the
inputs mentioned earlier the following activities are
involved
Prioritize Requirements
Organizing Requirements
Specify and Model Requirements
Define Assumptions and Constraints
 Prioritize Requirements
Purpose:
Prioritization of requirements ensures that analysis
and implementation efforts focus on the most critical
requirements.
Description:
Requirement prioritization is a decision process used
to determine the relative importance of requirements.
The importance of requirements may be based on
their relative value, risk, difficulty of implementation,
or on other criteria.
These priorities are used to determine which
requirements should be targets for further analysis
and to determine which requirements should be
implemented first.
Prioritize Requirements: Elements
 Basis for Prioritization: Business Value, Business
or Technical Risk, Implementation Difficulty,
Likelihood of Success, Regulatory or Policy
Compliance, Relationship to Other Requirements,
Stakeholder Agreement, Urgency
 Challenges
 Non-negotiable Demands: Stakeholders attempt to
avoid difficult choices, fail to recognize the necessity
for making tradeoffs, or desire to rank all requirements
as high priority.
 Unrealistic Tradeoffs: The solution development
team may intentionally or unintentionally try to
influence the result of the prioritization process by
overestimating the difficulty or complexity of
implementing certain requirements.
Prioritize Requirements: Techniques
 General Techniques
 Decision Analysis - Decision analysis may be
used to identify high-value requirements.
 Risk Analysis - Requirements that are
considered risky may need to be investigated or
implemented first, so that if risks cause the
project to fail, the organization has invested as
little as possible at that point.
 MoSCoW analysis: Must, Should, Could, Won’t
 Timeboxing /Budgeting: All In, All Out, Selective
 Voting: Allocate a fixed amount of resources
(votes, play money, or other tokens) to each
participant for them to distribute among proposed
features or requirements.
 Prioritize Requirements: Outputs
High priority (“Core requirements”)
Must be addressed during analysis, design, and
implementation.
A high-priority feature must be demonstrated
successfully during client acceptance.
Medium priority (“Optional requirements”)
Must be addressed during analysis and design.
 Usually implemented and demonstrated in the second
iteration of the system development.
Low priority (“Fancy requirements”)
Must be addressed during analysis (“very visionary
scenarios”).
Illustrates how the system is going to be used in the
future if not yet available technology enablers are
available
 Organizing Requirements
Purpose:
The purpose of organizing requirements is to
create a set of views of the requirements for the
new business solution that are comprehensive,
complete, consistent, and understood from all
stakeholder perspectives.
Description: There are two key objectives
when organizing requirements.
Understand which models are appropriate for the
business domain and solution scope.
Identify model interrelationships and
dependencies. Requirements alone are not
complex; it is the relationships and
interdependencies among requirements that adds
the element of complexity. Therefore, the
 Organizing Requirements: Inputs &
Outputs
Organizing requirements have the following
inputs
Organizational Process Assets: Describe the
structures and types of requirements information
that stakeholders expect.
Requirements [Stated]: Requirements are stated
in various forms as an output from elicitation
activities. Stated requirements are the expressed
desires of stakeholders, which must be analyzed
to ensure that they reflect a genuine need.
Solution Scope: The selected requirements
models must be sufficient to fully describe the
solution scope from all needed perspectives.
The output of organizing requirements is
 Organizing Requirements: Elements
• Levels of Abstraction
• You can organize requirements based on levels
of abstraction.
• For instance, the difference in requirements
between “what” needs to be done and “how” to
do it.
• Also, the business analysis can designate
requirements “high” level or “low” level.
• Model Selection
• The business analyst must determine which
types of models will be required to describe the
solution scope and meet the informational
needs of stakeholders.
 Organizing Requirements: Techniques
• Business Rules Analysis
• Business rules may be separated from other
requirements for implementation and management in a
business rules engine or similar.
• Data Flow Diagrams
• Shows how information flows through a system. Each
function that modifies the data should be decomposed
into lower levels until the system is sufficiently described.
• Data Modeling
• Describes the concepts and relationships relevant to the
solution or business domain.
• Functional Decomposition
• Breaks down an organizational unit, product scope, or
similar into its component parts. Each part can have its
own set of requirements.
 Organizing Requirements: Techniques…
• Organization Modeling
• Describes the various organizational units, stakeholders, and
their relationships. Requirements can be structured around
the needs of each stakeholder or group.
• Process Modeling
• Requirements may be organized around relevant processes.
Processes themselves can embed sub-processes, and
describe a hierarchy from the top level, end-to-end
processes to the lowest-level individual activities.
• Scenarios and Use Cases
• Describe the requirements that support the individual goals
of each actor, or the response to the triggering event.
• Scope Modeling
• Requirements may be organized based on the solution
components they are related to.
• User Stories
• Describe the stakeholder objectives that the solution will
support.
Specify and Model Requirements
Purpose:
To analyze expressed stakeholder desires and/or
the current state of the organization using a
combination of textual statements, matrices,
diagrams and formal models.
Description:
Specifications and models are created to analyze
the functioning of an organization and provide
insight into opportunities for improvement.
They also support a number of other objectives,
including development and implementation of
solutions, facilitating communication among
stakeholders, supporting training activities and
knowledge management, and ensuring compliance
with contracts and regulations.
Specify and Model Requirements:
Inputs & Output
Inputs
Requirements [Stated]: Specification or
modeling of requirements is performed to
structure and improve our understanding of
needs as expressed by stakeholders.
Requirements Structure: Defines how the
requirement fits into the general requirements
and which other sets of requirements may
include related information.
Output
Requirements [Analyzed]: Modeled and
specified requirements are produced by this
task.
 Specify and Model Requirements:
Elements
• Text:
• A textual requirement must describe the capabilities of the
solution, any conditions that must exist for the requirement
to operate, and any constraints that may prevent the
solution from fulfilling the requirement.
• Matrix Documentation:
• A table is the simplest form of a matrix. A table is used
when the business analyst is looking to convey a set of
requirements that have a complex but uniform structure
which can be broken down into elements that apply to
every entry in the table.
• Models:
• A model is any simplified representation of a complex
reality that is useful for understanding that reality and
making decisions regarding it. Models may be either textual
or graphical, or some combination of both. Graphical
models are often referred to as diagrams.
• Capture Requirements Attributes:
• As each requirement or set of requirements is specified and
modeled, the relevant attributes must be captured.
 Specify and Model Requirements:
Techniques
• Techniques that can be used to specify or
model requirements include:
• Acceptance and Evaluation Criteria Definition
• Business Rules Analysis • Prototyping
• Data Dictionary and Glossary
• Scenarios and Use
• Data Flow Diagrams Cases
• Data Modeling • Sequence
• Functional Decomposition Diagrams
• Interface Analysis • State Diagrams
• Metrics and Key Performance Indicators
• User Stories
• NFRs Analysis
• Organization Modeling
• Process Modeling
 Define Assumptions and

Constraints
Purpose:
Identify factors other than requirements that
may affect which solutions are viable.

 Description:
Assumptions
 are factors that are believed to be true, but
have not been confirmed.
Assumptions may affect all aspects of the
project and pose a certain degree of risk if
they do not prove to be true.
The business analyst identifies and documents
assumptions, attempts to confirm the
accuracy of the assumptions, and identifies
and manages risks related to the ability of a
solution to meet the business need.
Define Assumptions and
Constraints…
Constraints
are defined as restrictions or limitations on
possible solutions.
The business analyst is responsible for
documenting any restrictions or limitations to
the solution design, construction, testing,
validation and deployment.
Solution constraints describe aspects of the
current state, or planned future state that may
not be changed.
They are not requirements, since they are not
implemented in any form by the project team.
Constraints are provided to the project team
Define Assumptions and
Constraints…
Input
Stakeholder Concerns: Assumptions and
constraints are identified through elicitation from
stakeholders.
Output
Assumptions and Constraints: Assumptions and
constraints will limit potential solution options and will
be monitored for potential changes. While they are
not technically requirements, they can be managed
and communicated by performing the tasks.
Elements: Assumptions, Business Constraints,
Technical Constraints:
Techniques
Problem Tracking - Both assumptions and
constraints are often identified, reviewed and
managed using the ongoing planning, monitoring, and
issue/risk management activities of the project team.
Risk Analysis - Assess the risk if an assumption
Requirement Analysis Technique:
Scenarios
Scenario is a narrative description of what people
do and experience as they try to make use of
computer systems and applications.
They are a concrete, focused, informal description
of a single feature of the system used by a single
actor
Discovering scenarios exposes possible system
interactions and reveals system facilities which
may be required
Scenarios are important to elicit and analyze
requirements because system stakeholder find it
more intuitive to reason about concrete examples
rather than abstract descriptions of the functions
provided by a system
Scenarios…
Scenarios should include:
a description of the system state before entering the
scenario
the normal flow of events in the scenario
exceptions to the normal flow of events
information about concurrent activities
a description of the system state at the end of the
scenario
Different types of scenarios
As-is scenario - Used in describing a current situation
Visionary scenario - Used to describe a future system
Evaluation scenario - User tasks against which the
system is to be evaluated
Training scenario - Step by step instructions that guide
a novice user through a system
How do we find scenarios?
Interviews with stakeholder
Possible questions in an interview
What are the primary tasks that the system needs to
perform?
How do you currently perform your primary task?
Do you know about any kind of system or service that already
fulfills some task?
What data will the (main) actor create, store, change, remove
or add in the system?
Are there other actors in the system (explain the term actor!)
Do the actors need assistance during carrying out their tasks?
What kind of exceptions can you suggest?
Can actors interrupt a sequence of interaction? What
happens, if so?
However, don’t rely on questionnaires alone.
 Scenarios: Example 1 - Accident
Management System
Your Task (Problem Statement): Build a
requirements model for a system that allows to report
fire incidents. It should be able to report incidents for
many types of buildings and things.
The approach: Start with single Scenario, e.g. “Warehouse
in fire”.
Interview Guideline:
What do you need to do if a person reports “Warehouse on
Fire?”
Who is involved in reporting an incident?
What does the system do, if no police cars are available? If the
police car has an accident on the way to the “cat in a tree”
incident?
Can the system cope with a simultaneous incident report
“Warehouse on Fire?”
What do you need to do if the “Warehouse on Fire” turns into a
“Cat in the Tree”?
 Scenarios: Example 1 - Warehouse
on Fire
Bob, driving down main street in his patrol car notices
smoke coming out of a warehouse. His partner, Alice,
reports the emergency from her car by using the SYSTEM.
Alice enters the address of the building, a brief description
of its location (i.e., north west corner), and an emergency
level. In addition to a fire unit, she requests several
paramedic units on the scene given that area appear to
be relatively busy. She confirms her input and waits for an
acknowledgment.
John, the Dispatcher, is alerted to the emergency by a
beep of his workstation. He reviews the information
submitted by Alice and acknowledges the report. He
allocates a fire unit and two paramedic units to the
Incident site and sends their estimated arrival time (ETA)
to Alice.
Alice received the acknowledgment and the ETA.
Example 2 - LIBSYS scenario
Initial assumption: The user has logged on to the
LIBSYS system and has located the journal containing
the copy of the article.
Normal: The user selects the article to be copied. He
or she is then prompted by the system to either
provide subscriber information for the journal or to
indicate how they will pay for the article. Alternative
payment methods are by credit card or by quoting an
organisational account number.
The user is then asked to fill in a copyright form that
maintains details of the transaction and they then
submit this to the LIBSYS system.
The copyright form is checked and, if OK, the PDF
version of the article is downloaded to the LIBSYS
working area on the user’s computer and the user is
informed that it is available. The user is asked to
 Example 2 - LIBSYS scenario …
What can go wrong: The user may fail to fill in the
copyright form correctly. In this case, the form should
be re-presented to the user for correction. If the
resubmitted form is still incorrect then the user’s
request for the article is rejected.
The payment may be rejected by the system. The
user’s request for the article is rejected.
The article download may fail. Retry until successful or
the user terminates the session.
It may not be possible to print the article. If the article
is not flagged as ‘print-only’ then it is held in the
LIBSYS workspace. Otherwise, the article is deleted and
the user’s account credited with the cost of the article.
Other activities: Simultaneous downloads of other
articles.
 Requirement Negotiation
Resolve the problems found during requirements
analysis:
Discuss with the stakeholders on the problems
discovered in the draft requirements
 Unnecessary and unrelated (out of scope)
 Inconsistent, incomplete, conflicting, unclear
 “infeasible” within constraints of budget, time, etc.
Negotiation process is often a compromise governed by
organizational, political, personality, and business
considerations
In planning a requirements engineering process, it is
important to leave enough time for negotiation. Finding
an acceptable compromise can be time-consuming
Disagreements about requirements are inevitable when
a system has many stakeholders. Conflicts are not
‘failures’ but reflect different stakeholder needs and
priorities
 Negotiation Meeting
Negotiations are usually performed in meetings and
headed by someone who has no axe to grind -- also
have the authority to make/force decisions
Meeting should be conducted in three stages
Information stage: explain the nature of the problems
associated with requirements.
 Discussion stage: All stakeholders with an interest in
the requirement should be given the opportunity to
comment. Priorities may be assigned to requirements
at this stage.
Resolution stage: actions concerning the requirement
are agreed.
 These actions might be to delete the requirement, to
suggest specific modifications to the requirement or
to elicit further information about the requirement.