Outline
 Working towards the three C’s:
 Consistency
Requirements evaluation
 Correctness
 Completeness
 Handling risks in the system-to-be
 Prioritising amongst alternatives:
 Requirements
Kristian Sandahl
 Strategies
IDA
 Features
2
Why do we do this?
Types of inconsistency
 There are many people depending on the requirements, use
cases, user stories, win-condition or what ever you call it.
 Terminology clash: one concept – many names
 It is hard to predict the behaviour of a complex system.
 Structure clash: one concept – many structures
 We have always a limited amount of resources.
 Strong conflict: A
 Designation clash: many concepts – one name
B
⊥ (always)
 Weak conflict (divergence): A
Therefore:
B
⊥ (sometimes, under
boundary condition)
We want to avoid future problems.
We don’t want show-stoppers.
We want to spend resources where they make the best value.
3
Linköpings universitet
4
Terminology clash
- dead parrot
Detecting and identifying conflicts
Mr. Praline:
 Reviewing requirements documents and models:
 Peer-review
'E's not pinin'! 'E's passed on! This parrot is no
more! He has ceased to be! 'E's expired
and gone to meet 'is maker! 'E's a stiff!
Bereft of life, 'e rests in peace! If you hadn't
nailed 'im to the perch 'e'd be pushing up
the daisies! 'Is metabolic processes are
now 'istory! 'E's off the twig! 'E's kicked the
bucket, 'e's shuffled off 'is mortal coil, run
down the curtain and joined the bleedin'
choir invisibile!! THIS IS AN EX-PARROT!!
 Structured walk-through
 Inspection
 Cross-referencing requirements relations
 Heuristic detection
 Natural language processing techniques
 Formal techniques
5
Inspection process
6
Cross-referencing
 Group:
 Initial:
 Check criteria
 Detection, or
 Plan
 Collection
 Overview
 Inspection record
R1
R1
 Preparation, or
 Detection
 Change
R6
R6
R7
OK
OK
R5
 Document & data handling
R5
OK
R4
 Follow-up
R4
OK
OK
R3
 Exit:
R3
OK
R2
 Data collection
 Individual:
R2
OK
OK
OK
Conflict
OK
OK
OK
OK
R7
Oops!
7
Linköpings universitet
7
8
Heuristic detection
Natural language processing techniques
 Iteratively obtain a taxonomy of conflict-prone requirement
classes: ex: control algorithms, exception handling
 Uses NLP approach to determine:
 Perform classification during elicitation
 Analyze different classes
 Similarities between specifications, ex: market wishes – product
plans
 Search for keywords, important variables, ex: “decreasing”
 Finding candidates for consistency checking
 Create checklists, ex: investigate initial states, check that all
variables are used,
 Consolidation of requirements
 Similarities within a specification, ex: functional – non functional
 The goodness of approach is measured by
 Recall, % correct classification per known classification
 Precision % correct classification per all system classification

Johan Natt och Dag: Managing Natural Language Requirements in
LargeScale Software Development, PhD dissertation Lund, 2005,
(ISRN LUTEDX/TETS–1070–SE+222P)
9
Case study, similarity between
specifications, preprocessing
Case study, similarity measure
11
Linköpings universitet
10
12
Case study, similarity threshold and recall
Formal notations, Z example
 Book example on white-board
13
Handling inconsistencies
14
The NFR Framework
Good Capacity
for accounts
 Glossary – cheap and effective way of handling terminology
Secure
accounts
 Negotiations:
 Stakeholders’ win-condition
 Conflicting Non-functional requirements (NFRs)
 Use resolution tactics:
Response
time
Space
 Avoid boundary conditions – provide parallel solutions
-
 Restore conflicting statements – find satisfying sequences of use
-
 Weaken conflicting statements – permit exceptions
+
+
 Drop lower-priority statements
 Specialise conflict source or target – fine-grained domain model

Use stakeholders in elicitation for resolution

Use authority
Use uncompressed
format
15
Linköpings universitet
Use indexing
Validity access
against eligibility
rules
16
18
Risk management, some terminology
Hazard, Incident, Accident
 A risk is an uncertain factor whose occurrence may result in a
loss of satisfaction of a corresponding objective.
 Hazard – System state or
condition that may lead to an
incident.
 A risk has a likelihood of occurrence, some authors use
probability
 Incident – Potentially dangerous
system behaviour
 If occurred, a risk has negative consequences
 Accident – Unplanned sequence
of events that lead to human
death, severe injury or big loss of
resources
 Each consequence has a severity, some authors use impact
 Risks are handled with countermeasures
 Focus of the book: Product-related risks
17
Risk management process
18
Risk identification
 Risk checklists
 Missing functions
 Wrong assumptions
Risk identification
Risk assessment
Risk control
 Hazards
 Vulnerabilities....
 Software reviews
 Risk trees
 Scenarious
 Knowledge reuse
 Brainstorming
19
Linköpings universitet
20
Risk assessment
Defect Detection Prevention (DDP)
Impact matrix
 L(c) – likelihood of occurrence for consequence c
 0
 S(c) – severity of consequence c
 Assume risk r has a set of independent consequences
 Risk exposure Exp can be calculated as
Exp(r ) = ! L(c) " S (c)
c
 Some authors use Risk Magnitude Indicator with averaged S(c)
per risk
 Some authors use Risk Criticality explicitly calculating risk as a
weighted sum of different objective consequences
0.7 " (0.4 " 0.3 + 0.3 " 0 + 0.1" 0.3 + 0.2 " 0.1) ! 0.12
21
22
Risk control tactics (strategies)
Finding countermeasures
 Avoid – Require failure-safe mechanisms
 What-if questions in elicitation
 Transfer – Buy components
 Simulate system or process
 Accept
 Prototyping
 Mitigate – Lower the likelihood of occurrence
 Define contingency plan – A “plan B” if the risk occurs
 Risk-Reduction Leverage (RRL) for risk r and countermeasure
cm
RRL(r , cm) = ( Exp(r ) ! Exp(r cm) / cost (cm)
 Exp( r|cm) is the new risk exposure given that cm is taken.
23
Linköpings universitet
24
Evaluating alternatives
Weighted matrices
Decisions are everywhere in requirements:
Criteria
Option1
Option2
Option3
 Alternative combinations of sub-systems
Convenience 0.3
0.5
0.9
...
 Alternative system boundaries
Reliability
0.6
0.9
0.3
...
Price
0.1
0.5
1.0
...
Total
1.0
0.74
0.55
...
 Alternative conflict resolution methods
 Alternative countermeasures
Weight
Values can be based on judgement, statistics or both
 Alternative scheduling
 Alternative software acquisition opportunities
totalScore(opt ) = ! ( Score(opt , crit ) " Weight (crit ))
 Alternative business strategies
crit
25
26
AHP for requirements prioritisation
AHP, calculating the relative priority
 Create hierarchies of comparable requirements that are on
same abstraction level and in the same sub-system
 Let C be the comparison matrix, then w is a non-null so called
eigenvector such that:
 Make pairwise comparisons on a 9 grade-scale and construct
an AHP comparison matrix:
Cw = !w
 λ is the eigenvalue
 Elements of w correspond to the relative priority for the
requirements in the rows of C
Always the inverse values
27
Linköpings universitet
28
AHP, approximating the calculation of the
eigenvector
Result from the book
 Normalise values per column, so
1
1/ 5
1/ 6
1/ 7
0.66
becomes
0.13
0.11
0.10
 Next, sum the rows and divide by number of requirements, so
0.66 0.78 0.39 0.53
becomes 0.59
29
30
32
31
Linköpings universitet
31
32
Wait, a minute...
 What about correctness and completeness?
 What is the crucial prerequisite of the methods?
33
33
www.liu.se
Linköpings universitet
34