Requirement Analysis

& Negotiation

Page 1 of 32
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
 Requirement Negotiation Page 2 of 32
 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?
Page 3 of 32
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? Page 4 of 32
 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

Page 5 of 32
 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
Page 6 of 32
 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.

Page 7 of 32
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.
Page 8 of 32
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. Page 9 of 32
 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
Page 10 of 32
 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 organized requirements must also clearly depict the inherent
relationships between requirements. Page 11 of 32
 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 requirements
Structure
 The output of this task is an organized structure for the requirements
and a documented set of relationships between them.
Page 12 of 32
 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.

Page 13 of 32
 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.
Page 14 of 32
 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.
Page 15 of 32
 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. Page 16 of 32
 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.

Page 17 of 32
 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. Page 18 of 32
 Specify and Model Requirements: Elements…
• Improvement Opportunities :
• Analysts should work to identify opportunities to improve
the operation of the business.
• Some common examples of opportunities that a business
analyst is likely to identify include:
 Automate Or Simplify The Work People Perform
 Improve Access To Information
 Reduce Complexity Of Interfaces
 Increase Consistency Of Behavior
 Eliminate Redundancy

Page 19 of 32
 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 Cases
• Data Flow Diagrams • Sequence Diagrams
• Data Modeling • State Diagrams
• Functional Decomposition • User Stories
• Interface Analysis
• Metrics and Key Performance Indicators
• NFRs Analysis
• Organization Modeling
• Process Modeling
Page 20 of 32
 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.

Page 21 of 32
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 to inform them that
options they would normally be allowed to consider are not
available.

Page 22 of 32
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 proves invalid, or a
constraint is removed. Page 23 of 32
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
Page 24 of 32
 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
Page 25 of 32
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. Page 26 of 32
 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”?
Page 27 of 32
 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.
Page 28 of 32
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 select a printer and a copy
of the article is printed. If the article has been flagged as ‘print-only’ it is
deleted from the user’s system once the user has confirmed that printing is
complete.
Page 29 of 32
 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.
System state on completion: User is logged on. The downloaded article
has been deleted from LIBSYS workspace if it has been flagged as print-only.
Page 30 of 32
 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 Page 31 of 32
 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.
Page 32 of 32