Chapter 3Requirements Analysis,

Negotiation and Modeling

Part 2

Dr. Eman Al-MagharyDr. Eman Al-Maghary

Requirements EngineeringRequirements Engineering

Analysis and Negotiation

Analysis – the process of evaluating value/cost of different requirements, identifying dependencies between requirements, etc.

Negotiation – the process of resolving conflicts between requirements, deciding which to accept, setting priorities.

2

Requirements Analysis

The goal of analysis is to discover problems, incompleteness and inconsistencies in the elicited requirementsInput - A draft system requirements documentOutput –A set of problematic requirements

A problem checklist may be used to support analysis

3

Analysis checklists

A checklist is a list of questions which the analyst may used to assess each requirement

Analysis checklists can be implemented as a spreadsheetRow - requirements identifiersColumn - checklist itemsCell –comments about potential problems of

certain requirementsChecklist should not include more than 10

items (in general)

4

An example Checklist for Individual Requirements

Premature design: Does the requirement include premature design or implementation information

Combined requirements: Does the requirement description describes a single requirement or can be divided into several different requirements.

Unnecessary requirements: Is the requirement a cosmatic addition, which is not really needed by the system

Use of non-standard hardware: Does the requirement mean that non standard hardware or software must be used.* 5

An example Checklist for Individual RequirementsConformance with business goals: Is the

requirement consistent with business goals defined in the introduction of the requirements document.

Requirements ambiguity: What are the possible interpretations of the requirement?*

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, can the system engineers derive a test which can show if the system can meet that requirement?

6

Requiremnts interaction:Conflict and Overlap

Conflict: negatively affect each otherOverlap: affect each other but not necessarily a

conflictExampleR1: The file server shall respond to requests within

0.5 secondsR2: The file server shall serve up to 200 connection

simultaneouslyConflict: The file server HW resources may

prevent requirement from being satisfied simultaneously

7

R3:“the file server shall allow logged in users of storing up to 2GB of data daily(total)”

R4: “the file server shall allow each logged in user to store up to 20MB of data daily”

Overlap no conflict, they affect each other, R5 might be extracted

R5: the file server shall allow up to 100 users to login daily

8

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

In the requirement interaction matrix, requirements are listed along the rows and columns of the matrixFor requirements which conflict, fill in a 1For requirements which overlap, fill in a 1000For requirements which are independent, fill in a 0

9

Example of an interaction matrix

Interaction matrices only work when there is a relatively small number of requirements ( not more then 200 requirements)

Requirement R1 R2 R3 R4 R5 R6

R1 0 0 1000 0 1 1

R2 0 0 0 0 0 0

R3 1000 0 0 1000 0 1000

R4 0 0 1000 0 1 1

R5 1 0 0 1 0 0

R6 1 0 1000 1 0 0

10

The advantage of using numeric values for conflicts and overlapsThe sum of each row and each column give

1. the number of conflicts: the reminder when dividing the total by 1000

2. The number of overlaps the total when dividing by 1000

A large number of conflicts or overlaps means that changing a requirement has a great impact on the rest of the system

11

Requirements negotiationThe goal requirements negotiation is to reach

agreement on changes to satisfy all system stakeholders.

Requirements negotiation stage involves the different stakeholders to solve the conflicts and overlaps and agree on a set of requirementsConflicts are not ‘failures’ but reflect different

stakeholder needs and prioritiesInput –a set of conflicting or overlapped

requirementsOutput –a compromised set of requirements

12

Requirements negotiation (Cont.)

Negotiation is interleaved with elicitation and analysis as problems are discovered and possible solutions are agreed when the requirements are elicited

Finding an acceptable compromise can be time-consuming

13

Negotiation goals

Three basic goals of requirements negotiation:To make the conflicts explicit.To make explicit, for each conflict, the relevant

alternatives, the argumentations, and the underlying rationales.

To facilitate in that “right” decisions are made.“Right” decision here denotes a decision

made rationally, decision made based by evaluating the alternatives and selecting the best one.

14

Requirements analysis and negotiation

15

Requirements Analysis

Requirements Negotiation

Necessity

Checking

Consistency and

completenesschecking

Necessity

Checking

Unnecessaryrequirements

Conflicting and

incompleterequirements

Infeasible requirement

s

Requirements

discussion

Requirementsprioritisation

Requirements

agreement

Negotiation meetingsMeetings are an effective way to negotiate

requirements and resolve requirements conflicts

All conflict requirements should be discussed individually

ParticipantsAnalysts who have discovered requirement

overlaps, omissions and conflictsStakeholders who can help resolve the

discovered problemsAn independent chairman

16

Three stages of the negotiation meeting

1. Information stage Nature of the problems associated with a

requirement is explained

2. Discussion stage Stakeholders are involved discuss how these

problems might be resolved All stakeholders with an interest in the

requirement should be given the opportunity to comment. Priorities may be assigned to requirements at this stage

17

Three stages of the negotiation meeting

3. Resolution stageActions concerning the requirement are agreed

Delete the requirementSuggest specific modificationsElicit further information about the

requirement

18

Why prioritize requirements?

Limited resourcesScheduleBudgetEffort

19

Customer expectations are highToo many ReqsChanging ReqsConflicting

ReqsRequirements

Resources

All requirements are mandatory, but some are essential/critical while others are not.

PrioritizationPrioritize means listing or rating in order of

priority

Requirements prioritization means balancing the business benefit of each requirement against its cost and any implications it has for the architectural foundation and future evolution of the product

Requirements prioritization takes place at the requirements analysis and negotiation stage

20

Challenges of prioritizationDifferent stakeholders have usually different

opinions about requirement’s importance and urgency.People naturally have their own interest and they

aren’t always willing to compromise their needs for someone else’s benefit.

Customers may try to avoid prioritization, becausethey suspect that low priority requirements will

never be implementedDevelopers may try to avoid prioritization, because

they feel bad to admit, that they can’t implement all requirements

Many of the prioritization methods are either too complicated and time consuming or insufficient

21

Prioritization techniquesPrioritization scales

Assign each requirement to a priority classification category

Example categories: high, medium, lowPrioritization model - cost-value approach

Analytic Hierarchy Process (AHP)value, cost, and risk estimation model

Kano methodOther approaches

Quality function deployment (QFD)Total quality management (TQM)

22

Requirements prioritization scales

Two dimensions: Importance & UrgencyHigh priority (I & U)

A mission-critical requirement, required for next release

e.g. Contractual or legal obligationsMedium priority (I but not U)

Supports necessary system operations; required eventually but could wait until a later release if necessary

23

Low priority (not (I & U))A functional or quality enhancement; would be

nice to have someday if resources permitThe fourth (not I but U)

They do not add sufficient value to the product –Don’t waste your time

24

Requirements prioritization scales (Cont.)

Summary of prioritization scalesPros

Cheap and easy to useSuitable for a small project

ConsThe results are in many cases just a rough estimateParticipant dependent methodCustomers estimate 85% of requirements at high

priority, 15% at medium and 5% at low priority No desired flexibility for the project

In the real world low priority requirements have frequently been abandoned

25

Prioritization modelEstimating the relative value and relative cost of

each requirementThe highest priority requirements are those that

provide the largest fraction of the total product value at the smallest fraction of the total cost

The prioritization model prioritizes negotiable requirements based on value, cost, and riskDepend on both the benefit provided to the customer if

a specific product feature is present and the penalty paid if that feature is absent

A requirement’s attractiveness is directly proportional to the value it provides and inversely proportional to its cost and the technical risk associated with implementing it

26

1. List all requirements (features or use cases) needed to prioritize

All the items must be at the same level of abstraction

2. Estimate the relative benefit on a scale of 1 (negligible benefit ) to 9 (very valuable)

3. Estimate the relative penalty the customer or business would suffer on a scale of 1 (essentially no penalty) to 9 (a very serious downside)

4. Calculate the total value (benefit *weight + penalty * weight) and the percentage of the total value (total value / Σ(total value))

27

Steps to use the prioritization model

Steps to use the prioritization model (Cont).

5. Estimate the relative cost of implementing each requirement on a scale of 1 (low) to 9 (high)

6. Estimate the relative degree of technical or other risks associated with each requirement on a scale of 1 (low) to 9 (high)

7. Calculate the priority valuevalue%

Priority = -----------------------------------------------------(cost% * cost weight) + (risk% * risk weight)

8. Sort the list of requirements in descending order by calculate priority. The features at the top of the list have the most favorable balance of value, cost, and risk

28

Example and Template

29

You can download the MS Excel template from the web site.

Value% = value/ sum of values * 100Cost% = Cost/ sum of Costs * 100Risk% = risk/ sum of Risks* 100

Priority for the requirement in row 1Priority = Priority = 1.2

30

5.0*31*7.2

2.5

Summary of the prioritization modelUse the calculated priority sequence only as a

guidelineThe accuracy is limited by people’s ability to

estimate the benefit, penalty, cost and riskCustomer and development representatives should

review the completed spreadsheet to reach agreement on the ratings and the resulting sorted priority sequence

Calibrate the model for your own use with a set of completed requirements from a previous projectAdjust the weighting factors until the calculated

priority sequence correlates well with the after -the-fact evaluation

31

A Five-step procedure by using Kanomethod

1. Identify the customer requirements2. Construct a questionnaire (e.g. roller shutter

control feature)Functional questions

e.g. Suppose that your HAS could open and close roller shutters automatically, what would you think about that?

Dysfunctional questions e.g. … … would not be able to ……

3. Perform a survey4. Analyse and interprete the collected data5. Select the product features

32

Other prioritization techniquesQuality function deployment (QFD)

A Japanese technique developed at the Kobe Shipyard

A comprehensive method for relating customer value to the features for a proposed product

It can be used for large, complex projects in which diverse stakeholders have very different viewpoints and are having trouble agreeing

Total quality management (TQM)It rates each requirement against several weighted

project success criteria and computes a score to rank the priority of the requirements

33

Prioritization considerationsMust involve all stakeholdersAll requirements cannot be essentialTry to get agreement on prioritization

informallyAs analysis and design evolving, review and

adjust priorities

34

Key pointsPrototypes are effective for requirements

elicitation because stakeholders have something which they can experiment with to find their real requirements

Checklists are particularly useful as a way of organizing the requirements validation process. They remind analysts what to look for when reading through the proposed requirements

Requirements negotiation is always necessary to resolve requirements conflicts and remove requirements overlaps. Negotiation involves information interchange, discussion and resolution of disagreements

35

Key points (Cont.)

Requirements prioritization provides options to manage requirement additions and risk, enables delivery of a useful product in spite of changes in schedule and resource allocations, and guides architecting and design tradeoffs

The analyst plays a central role in collecting and disseminating product information. He bridges communication between customer and development stakeholders

36