Download Requirements Evaluation in Software Engineering: A Comprehensive Guide and more Lecture notes Software Engineering in PDF only on Docsity!
CHAPTER 4
Requirements Evaluation
Source of PP slides :
- Lamsweerde, A. V. 2011. Requirements Engineering: From System goals to UML Models to Software Specification. 2 nd **ed.Wiley.
- Weigers, K. And Beatty, J.** 2013. Software Requirements. 3 rd edn. Microsoft Press.
Lesson Objectives
- (^) To understand the concept of
Inconsistency Management
- (^) To explain the activities involved in Risk
Analysis and Risk Management
- (^) Differentiate qualitative and qualitative risk
assessment techniques
- (^) Evaluating alternative options for decision
making
- (^) To understand what is Requirements
Prioritization
Introduction
- (^) Requirement evaluation - Negotiation-based decision making
involved : (as introduced in Chapter 1 ...)
Identification & resolution of inconsistencies Identification, assessment & resolution of system risks Comparison of alternative options, selection of preferred ones Requirements prioritization
Requirements evaluation: outline
- (^) Inconsistency management
- (^) Types of inconsistency
- (^) Handling inconsistencies
- (^) Managing conflicts: a systematic process
- (^) Risk analysis
- (^) Types of risk
- (^) Risk management
- (^) Risk documentation
- (^) DDP: quantitative risk management for RE
- (^) Evaluating alternative options for decision making
- (^) Requirements prioritization
Types of inconsistency in RE
- (^) Terminology clash: same concept named differently in
different statements
e.g. “Participating” & “Attending” meeting
- (^) Designation clash: same name for different concepts in
different statements
e.g. participant in a meeting - participating full meeting till ends
- participating partial meeting
- (^) Structure clash: same concept structured differently in
different statements
e.g. “latest return date” - as time point i.e FRI, 5pm
- as time interval i.e. FRI
Types of inconsistency in RE (2)
- (^) Strong conflict: statements not satisfiable together
- (^) i.e. logically inconsistent: S , not S e.g. “participant constraints may not be disclosed to anyone” vs “the meeting initiator should know participant constraints”
- (^) 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”
Managing conflicts: a systematic process
Step 1 : Identifying Overlapping Statements
- (^) Overlap = reference to common terms or phenomena
- (^) precondition for conflicting statements
- (^) e.g. gathering meeting constraints, determining schedules Identify overlapping statements Detect conflicts among them, document these Generate conflict resolutions Evaluate resolutions, select preferred
Managing conflicts: a systematic process
Step 2 : Detect Conflicts & Document Them
- (^) Conflict detection can be done by...
- (^) informally
- (^) using heuristics on conflicting req categories
- (^) “Check information req & confidentiality req on related objects”
- (^) “Check reqs on decreasing & increasing related quantities”
- (^) using conflict patterns
- (^) formally Identify overlapping statements Detect conflicts among them, document these Generate conflict resolutions Evaluate resolutions, select preferred
Managing conflicts: a systematic process (2)
- (^) Step 3 : Generate Conflicts Resolutions
- (^) 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 sessions) – as discussed in previous chapter
- (^) resolution tactics – let’s discuss in next slide Identify overlapping statements Detect conflicts among them, document these Generate conflict resolutions Evaluate resolutions, select preferred
Conflict resolution tactics
(Refer to the example of library system discussed earlier….)
- (^) Avoid boundary condition
- (^) e.g. “Keep copies of highly needed books unborrowable”
- (^) Restore conflicting statements
- (^) e.g. “Copy returned within X weeks and then borrowed again”
- (^) Weaken conflicting statements
- (^) e.g. “Copy returned within X weeks unless explicit permission”
- (^) Drop lower-priority statements
- (^) Specialize conflict source or target
- (^) e.g. “Book loan status known by staff users only ”
Managing conflicts: Q & A
- (^) Will we stop the managing conflicts process
after completing step 4 (as discussed in
previous slides)???
- (^) Answer…
- (^) It depends… we may need to go through the process due to error, incompleteness, new conflicts caused by new requirements(because of business environment changes), etc… Identify overlapping statements Detect conflicts among them, document these Generate conflict resolutions Evaluate resolutions, select preferred
Requirements evaluation: outline
- (^) Inconsistency management
- (^) Types of inconsistency
- (^) Handling inconsistencies
- (^) Managing conflicts: a systematic process (overview)
- (^) Risk analysis
- (^) Types of risk
- (^) Risk management
- (^) Risk documentation
- (^) DDP: quantitative risk management for RE
- (^) Evaluating alternative options for decision making
- (^) Requirements prioritization
Types of RE risk
- (^) Product-related risks: negative impact on functional or non-
functional objectives of the system
=> failure to deliver services or quality of service
e.g.1: failure to generate monthly sales report
e.g.2: security threats, safety hazards
- (^) Process-related risks: negative impact on development
objectives
=> delayed delivery, cost overruns, ...
e.g. personnel turnover
RE risk management
- (^) Risk management is iterative
- (^) Poor risk management is a major cause of software
failure
what system- specific risks? likely? severe, likely consequences? countermeasur es as new reqs
Risk
identification
Risk
assessment
Risk
control
