Software required engineering

1. SOFTWARE REQUIREMENTS
ENGINEERING
1
Lecture 8
Requirements Analysis

2. 2
Agenda
• Requirements Analysis
– Necessity Checking
– Consistency Checking
– Completeness Checking
– Feasibility Checking
– Risk Analysis
– Requirements Prioritization

3. Necessity Checking
• The need for the requirement is analyzed.
• contribute to the business goals of the
organization
• contribute to the specific problem to be
addressed
• Analytical power of the Requirement
Engineer matters a lot
3

4. 4
Agenda
• Requirements Analysis
– Necessity Checking
– Consistency Checking
– Completeness Checking
– Feasibility Checking
– Risk Analysis
– Requirements Prioritization

5. Consistency Checking
• The requirements are cross-checked for
consistency.
• No requirements should be contradictory
• N X N operations required
5

6. 6
Types of Inconsistency in RE
• Terminology clash:
– same concept named differently in different
statements
e.g. library management: “borrower” vs. “patron”
• Designation clash:
– same name for different concepts in different
statements
e.g. “user” for “library user” vs. “library software user”

7. Types of Inconsistency in RE
• Structure clash:
– same concept structured differently in different
statements
e.g. “latest return date” as time point (e.g. Fri 5pm)
vs. time interval (e.g. Friday)
7

8. 8
Types of Inconsistency in RE
• Strong conflict:
– statements not satisfiable together i.e.
logically inconsistent: S, not S
e.g. “participant constraints may not be disclosed to
anyone else”
vs. “the meeting initiator should know participant
constraints”

9. Types of Inconsistency in RE
• Weak conflict (divergence):
– statements not satisfiable together under some boundary
condition, i.e. strongly conflicting if B holds: potential
conflict
– MUCH more frequent in RE
e.g. (staff’s viewpoint)
“patrons shall return borrowed copies within X weeks”
vs. (patron’s viewpoint)
“patrons shall keep borrowed copies as long as needed”
B: “a patron needing a borrowed copy more than X weeks”
9

10. 10
Handling Inconsistencies
• Handling clashes in terminology, designation,
structure:
– Agreed glossary of terms /synonyms

11. Handling Inconsistencies
• Weak, strong conflicts: more difficult, deeper
causes...
– Often rooted in underlying personal objectives of
stakeholders
=> to be handled at root level and propagated to
requirements level
– Inherent to some non-functional concerns
(performance vs. safety, confidentiality vs. awareness, ...)
=> exploration of preferred tradeoffs
11

12. 12
Managing Conflicts: A Systematic
Process
• Identify Overlap = common terms or phenomena
• Conflict detection
Identify
overlapping
statements
Detect conflicts
among them,
document these
Generate
conflict
resolutions
Evaluate
resolutions,
select preferred

13. 13
Managing Conflicts: A Systematic
Process
• For optimal resolution, better to ...
– explore multiple candidate resolutions first,
– compare, select/agree on most preferred next
• To generate candidate resolutions, use ...
– elicitation techniques
(interviews, group based techniques)
Identify
overlapping
statements
Detect conflicts
among them,
document these
Generate
conflict
resolutions
Evaluate
resolutions,
select preferred

14. 14
Managing Conflicts: A Systematic
Process
• Evaluation criteria for preferred resolution:
– contribution to critical non-functional requirements
– contribution to resolution of other conflicts & risks
Identify
overlapping
statements
Detect conflicts
among them,
document these
Generate
conflict
resolutions
Evaluate
resolutions,
select preferred

15. 15
Agenda
• Requirements Analysis
– Necessity Checking
– Consistency Checking
– Completeness Checking
– Feasibility Checking
– Risk Analysis
– Requirements Prioritization

16. Completeness Checking
• No services or constraints which are
needed have been missed out
• Use composition to break requirements
into more manageable, less ambiguous
parts
• No silver bullet
16

17. 17
Agenda
• Requirements Analysis
– Necessity Checking
– Consistency Checking
– Completeness Checking
– Feasibility Checking
– Risk Analysis
– Requirements Prioritization

18. Feasibility Checking
• Correct with regards to its role towards
business goals but
• Facing problems in the context of
– budget
– schedule
– technology
18

19. 19
Agenda
• Requirements Analysis
– Necessity Checking
– Consistency Checking
– Completeness Checking
– Feasibility Checking
– Risk Analysis
– Requirements Prioritization

20. Requirements Risks
• Purpose:
– Provide input to project risk management,
which is a lifecycle activity
• Definition:
– Risks directly related to specific requirements
or to requirements process.
20

21. 21
Types of Risks
• Product-related risks: Negative impact on functional or non-
functional objectives of the system-to-be
=> failure to deliver services or quality of service
e.g. security threats, safety hazards, legal issues, regulatory
non-compliance
• Process-related risks: Negative impact on development
process
=> delayed delivery, cost overruns, personnel
shortage...

22. 22
Risk Management in Requirement
Analysis
• Risk management is iterative
– countermeasures may introduce new risks
• Poor risk management is a major cause of software failure
– unrecognized, underestimated risks lead to incomplete,
inadequate requirements
Risk
identification
Risk
assessment
Risk
control
what req-related
risks?
likely?
How severe, likely
consequences?
countermeasures
as new reqs

23. 23
Risk Identification: Risk
Checklists
• Product-related risks: risks in functional or quality
requirement categories
– info inaccuracy, unavailability, unusability, poor response
time, poor peak throughput, ...
• Process-related risks:
– personnel shortfalls, dependencies on external sources,
over-budget

24. 24
Risk Identification: Risk
Trees
• Causal linking of failures, causes, consequences
• Failure node = independent failure event or condition
– decomposable into finer-grained nodes
• AND/OR links: causal links through logical nodes ...
– AND-node: child nodes must all occur for parent node to
occur as consequence
– OR-node: only one child node needs to occur

25. 25
Risk Tree: Example
Door opens while train moving
Train is moving
OR
AND
Passenger forces
doors to open
Door actuator
fails
Speedometer
fails
Software controller fails
Wrong
requirement
Wrong
assumption
Wrong
specification
Wrong
implementation
OR
leaf node
decomposable node

26. 26
Risk Identification:
Using Elicitation Techniques
• Analyzing Scenarios to point out failures from WHAT
IF questions
• Knowledge reuse: typical risks from similar systems
• Group sessions focused on identification of
requirement-specific risks

27. 27
Risk Assessment
• Goal: assess likelihood + severity of risks, to control high-
priority risks
• Qualitative assessment: use qualitative estimates (levels)
– for likelihood: {very likely, likely, possible, unlikely, ...}
– for severity: {catastrophic, severe, high, moderate, ...}
=> risk likelihood-consequence table for each risk
=> risk comparison/prioritization on severity levels
Risk
identification
Risk
assessment
Risk
control

28. 28
Qualitative Risk Assessment
Table: Example
Risk: “Doors open while train moving”
Risk likelihood
Consequences Likely Possible Unlikely
Loss of life Catastrophic Catastrophic Severe
Serious injuries Catastrophic Severe High
Train car damaged High Moderate Low
#passengers decreased High High Low
Bad terminal reputation Moderate Low Low
Easy to use
Limited conclusions: coarse-grained, subjective estimates

29. 29
Risk Control
• Goal: Reduce high-exposure risks through counter-measures
– yields new or adapted requirements
– should be cost-effective
Risk
identification
Risk
assessment
Risk
control
Risk control
Explore
countermeasures
Evaluate
countermeasures,
select preferred

30. 30
Risk Reduction Tactics
• Reduce risk likelihood: new requirements to ensure significant
decrease
e.g. “Prompts for driver reaction regularly generated by software”
• Avoid risk: new requirements to ensure risk may never occur
e.g. “Doors may be opened by software-controlled actuators only”
• Reduce consequence likelihood: new requirements to ensure
significant decrease of consequence likelihood
e.g. “Alarm generated in case of door opening while train moving”

31. Risk Reduction Tactics
• Avoid risk consequence: new requirements to
ensure consequence may never occur
e.g. “No collision in case of inaccurate speed/position
estimates”
• Mitigate risk consequence: new requirements to
reduce severity of consequence(s)
e.g. “Waiting passengers informed of train delays”
31

32. 32
Risks Documentation
• To record/explain why these countermeasure requirements, to support system
evolution
• For each identified risk:
– conditions/events for occurrence
– estimated likelihood
– possible causes & consequences
– estimated likelihood & severity of each consequence
– identified countermeasures + risk-reduction leverages
– selected countermeasures
@ annotated risk tree

33. 33
Agenda
• Requirements Analysis
– Necessity Checking
– Consistency Checking
– Completeness Checking
– Feasibility Checking
– Risk Analysis
– Requirements Prioritization

34. 34
Requirements
Prioritization
• Purpose...
–conflict resolution
–resource limitations (budget, personnel,
schedules)
–incremental development
M

35. 35
Cumulative Voting, the 100-
Dollar Test
• The 100-dollar test is a very
straightforward prioritization technique
where the stakeholders are given 100
imaginary units (money, hours, etc.) to
distribute between the requirements
• The result of the prioritization is presented
on a ratio scale

36. 36
Cumulative Voting, the 100-
Dollar Test
• One should only perform the prioritization
once on the same set of requirements,
since the stakeholders might bias their
evaluation the second time around if they
do not get one of their favorite requirements
as a top priority

37. 37
Numerical Assignment
(Grouping)
• It is the most common prioritization
technique, and is based on grouping
requirements into different priority groups
• The number of groups can vary, but in
practice, three groups are very common

38. 38
Numerical Assignment
(Grouping)
• When using numerical assignment, it is
important that each group represents
something that the stakeholders can relate
to (e.g. critical, standard, optional), for a
reliable classification
• Using relative terms such as high,
medium, and low will confuse the
stakeholders

39. 39
MoScoW Technique
• Instead of numbers, this method uses four priority
groups: MUST have, SHOULD have, COULD have, and
WOULD have. With this technique, stakeholders can
prioritize requirements in a collaborative fashion. The
acronym represents the following:
• MUST (Mandatory)
• SHOULD (Of high priority)
• COULD (Preferred but not necessary)
• WOULD (Can be postponed and suggested for future
execution)

40. 40
MoScoW Technique
• Using a Human Resources System as an example,
here’s an explanation of the MoSCoW Technique:
• MUST (M)
– Defines a requirement that has to be satisfied for the final
solution to be acceptable e.g. The HR system “must” store
employee leave history.
• SHOULD (S)
– This is a high-priority requirement that should be included if
possible, within the delivery time frame. Workarounds may be
available for such requirements and they are not usually
considered as time-critical or must-haves. e.g. The HR system
“should” allow printing of leave letters.
•

41. 41
MoScoW Technique
• COULD (C)
– This is a desirable or nice-to-have requirement (time and
resources permitting) but the solution will still be accepted if the
functionality is not included e.g. The HR system “could” send out
notifications on pending leave dates.
• WON’T or WOULD (W)
– This represents a requirement that stakeholders want to have,
but have agreed will not be implemented in the current version of
the system. That is, they have decided it will be postponed till the
next round of developments e.g. The HR system “won’t” support
remote access but may do so in the next release.

42. 42
MoScoW Process
1.Assemble all stakeholders – Each stakeholder, with help
from the Analyst, is responsible for assigning priorities to the
requirements that fall under their purview
2.All Requirements may be listed on a flip chart and
prioritized by assigning categories to each (M, S, C or W).
3.If there are multiple stakeholders with different opinions on
what category to assign to a requirement, voting can be
used to reach consensus.
4.Present categorized requirements in a readable format
5.The requirements should be reviewed throughout the
project as stakeholder needs may evolve with time.

43. 43
MoScoW Template
This is a template for categorizing requirements using the
MoSCoW Technique
Copy and paste all your requirements under the requirements
column
Mark an X under the appropriate M,S, C or W column depending on stakeholder
preference
Focus on the requirements with the M Mark before proceeding with S, C and W in that order (time and resources
permitting)
REQUIREMENTS MUST (M) SHOULD (S) COULD (C) WON'T (W)
Feature to store employee leave historyX
Feature to allow printing of leave letters X
Feature to send notifications on
pending leave dates X
Support for remote login X
Compatibility with iOS X
Compatibility with Android X
Dual Language Support X

44. 44
Bubble Sort Technique
• To prioritize requirements using bubble sort, you take
two requirements and compare them with each other. If
you find out that one requirement should have greater
priority over the other, you swap them accordingly. You
then continue in this fashion until the very last
requirement is properly sorted. The result is a list of
requirements that are ranked.

45. 45
Ranking
• As in numerical assignment, ranking is
based on an ordinal scale but the
requirements are ranked without ties in
rank
• This means that the most important
requirement is ranked 1 and the least
important is ranked n (for n requirements)

46. 46
Top-Ten Requirements
• In this approach, the stakeholders pick
their top-ten requirements (from a larger
set) without assigning an internal order
between the requirements
• This makes the approach especially
suitable for multiple stakeholders of equal
importance

47. 47
Top-Ten Requirements
• It is not advisable to take average across
all stakeholders since it might lead to
some stakeholders not getting any of their
top requirements

48. 48
Top-Ten Requirements
• The main challenge in this technique is to
balance issues related to the fact that top
priority requirements of all stakeholders
are included in the next development
activity

49. THANK YOU
49