 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

 The goal of analysis is to discover problems, incompleteness and inconsistencies in the elicited requirements
 Input - A draft system requirements document
 Output –A set of problematic requirements
 A problem checklist may be used to support analysis
3

 A checklist is a list of questions which the analyst may used to assess each requirement
 Analysis checklists can be implemented as a spreadsheet
 Row - requirements identifiers
 Column - checklist items
 Cell –comments about potential problems of certain requirements
 Checklist should not include more than 10 items (in general)
4

 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

 Conformance with business goals:
 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

and
 Conflict: negatively affect each other
 Overlap: affect each other but not necessarily a conflict
 Example
R1: The file server shall respond to requests within 0.5 seconds
R2: The file server shall serve up to 200 connection simultaneously
Conflict : 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

 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.
 In the requirement interaction matrix, 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
9

Requirement
R1
R2
R3
R4
R5
R6 1
1
R1
0
R2 R3 R4
0 1000 0 1
R5 R6
1
0 0 0 0 0 0
1000 0 0
0 0 1000
1000
0 1
0
1
1000
0 0
0 1000 1
1 0 0
0 0
Interaction matrices only work when there is a relatively small number of requirements ( not more then 200 requirements)
10

 The 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

 The 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 requirements
 Conflicts are not ‘failures’ but reflect different stakeholder needs and priorities
 Input –a set of conflicting or overlapped requirements
 Output –a compromised set of requirements
12

(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 timeconsuming
13

 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
Necessity
Checking
Consistency and completeness checking
Necessity
Checking
Unnecessary requirements
Conflicting and incomplete requirements
Infeasible requirements
Requirements discussion
Requirements Negotiation
Requirements prioritisation
Requirements agreement
15

 Meetings are an effective way to negotiate requirements and resolve requirements conflicts
 All conflict requirements should be discussed individually
 Participants
 Analysts who have discovered requirement overlaps, omissions and conflicts
 Stakeholders who can help resolve the discovered problems
 An independent chairman
16

1.
2.
Information stage
Nature of the problems associated with a requirement is explained
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

3. Resolution stage
 Actions concerning the requirement are agreed
 Delete the requirement
 Suggest specific modifications
 Elicit further information about the requirement
18

 Limited resources
 Schedule


Budget
Effort
Resources
Requirements
 Customer expectations are high



Too many Reqs
Changing Reqs
Conflicting Reqs
All requirements are mandatory, but some are essential/critical while others are not.
19

 Prioritize 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


Different 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, because
 they suspect that low priority requirements will never be implemented
 Developers 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 scales
 Assign each requirement to a priority classification category
 Example categories: high, medium, low
 Prioritization model - cost-value approach
 Analytic Hierarchy Process (AHP)
 value, cost, and risk estimation model
 Kano method
 Other approaches
 Quality function deployment (QFD)
 Total quality management (TQM)
22

 Two dimensions: Importance & Urgency
 High priority (I & U)
 A mission-critical requirement, required for next release
 e.g. Contractual or legal obligations
 Medium priority (I but not U)
 Supports necessary system operations; required eventually but could wait until a later release if necessary
23

(Cont.)
 Low priority (not (I & U))
 A functional or quality enhancement; would be nice to have someday if resources permit
 The fourth (not I but U)
 They do not add sufficient value to the product –Don’t waste your time
24

 Pros
 Cheap and easy to use
 Suitable for a small project
 Cons
 The results are in many cases just a rough estimate
 Participant dependent method
 Customers 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

 Estimating the relative value and relative cost of each requirement
 The 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 risk
 Depend 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.
2.
3.
4.
List all requirements (features or use cases) needed to prioritize
 All the items must be at the same level of abstraction
Estimate the relative benefit on a scale of 1
(negligible benefit ) to 9 (very valuable)
Estimate the relative penalty the customer or business would suffer on a scale of 1 (essentially no penalty) to 9 (a very serious downside)
Calculate the total value (benefit *weight + penalty * weight) and the percentage of the total value (total value / Σ(total value))
27

(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 value value%
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

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

 Value% = value/ sum of values * 100
 Cost% = Cost/ sum of Costs * 100
 Risk% = risk/ sum of Risks* 100
 Priority for the requirement in row 1


Priority =
2 .
7
5 .
2
* 1

3 * 0 .
5
Priority = 1.2
30

 Use the calculated priority sequence only as a guideline
 The accuracy is limited by people’s ability to estimate the benefit, penalty, cost and risk
 Customer 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 project
 Adjust the weighting factors until the calculated priority sequence correlates well with the after -the-fact evaluation
31

1.
2.
3.
4.
5.
Identify the customer requirements
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 ……
Perform a survey
Analyse and interprete the collected data
Select the product features
32

 Quality 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

 Must involve all stakeholders
 All requirements cannot be essential
 Try to get agreement on prioritization informally
 As analysis and design evolving, review and adjust priorities
34

 Prototypes 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

(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