Chapter 3 cont.

…
Requirement Analysis & Negotiation
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
 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
 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/tasks 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 organized requirements must also clearly depict the inherent
relationships between requirements.
 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.
 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: 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
 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 Diagrams
• Functional Decomposition • State Diagrams
• Interface Analysis • User Stories
• Metrics and Key Performance Indicators
• 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 to inform them that options they would normally

be allowed to consider are not available.

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