Requirement analysis and negotiation

1. Chapter 3
Requirement Analysis & Negotiation

2.  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
Contents

3.  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
Introduction

4.  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

5.  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
Analysis Checklists….

6.  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

7.  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
Requirements Analysis: Input , Tasks & Output

8.  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

9.  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: Elements

10.  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: Techniques

11.  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
Prioritize Requirements: Outputs

12.  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.
Organizing Requirements

13.  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.
Organizing Requirements: Inputs & Outputs

14. • 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: Elements

15. • 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

16. • 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.
Organizing Requirements: Techniques…

17.  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

18.  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: Inputs & Output

19. • 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:
Elements

20. • 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
Specify and Model Requirements: Elements…

21. • Techniques that can be used to specify or model requirements
include:
• Acceptance and Evaluation Criteria Definition
• Business Rules Analysis
• Data Dictionary and Glossary
• Data Flow Diagrams
• Data Modeling
• Functional Decomposition
• Interface Analysis
• Metrics and Key Performance Indicators
• NFRs Analysis
• Organization Modeling
• Process Modeling
Specify and Model Requirements: Techniques
• Prototyping
• Scenarios and Use
Cases
• Sequence Diagrams
• State Diagrams
• User Stories

22.  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

23.  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.
Define Assumptions and Constraints…

24.  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.
Define Assumptions and Constraints…

25.  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
Requirement Analysis Technique: Scenarios

26.  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
Scenarios…

27.  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.
How do we find scenarios?

28.  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 - Accident Management System

29.  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.
Scenarios: Example 1 - Warehouse on
Fire

30. 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.

31. 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.
Example 2 - LIBSYS scenario …

32.  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
Requirement Negotiation

33.  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.
Negotiation Meeting