SENG304: Software

Requirement
Engineering and
Construction
LECTURE SIX: SOFTWARE
REQUIREMENTS RISK MANAGEMENT
Requirements Risk Management
 Requirements risk management involves the proactive analysis,
identification, monitoring, and mitigation of any factors that can threaten the
integrity of the requirements engineering process.
 Requirements risk factors can be divided into two types
 Technical and
 Management.
 Technical risk factors pertain to the elicitation, analysis, agreement, and
representation processes
Requirements Risk Management
 Requirements management risk factors tend toward issues of expectation
management and interpersonal relationships,
 Inadequate requirements engineering practices have led to some spectacular
failures.
 Requirements can be inadequate in many ways including:
 Inaccurate or incomplete stakeholder identification
 Insufficient requirements validation
 Insufficient requirements verification
Requirements Risk Management
 Incomplete requirements
 Incorrect requirements
 Incorrectly ranked requirements
 Inconsistent requirements

 To mitigate requirement risk, we should carry out proper requirement

validation and verification.
Requirements Validation and
Verification
 Requirements validation and verification involves review, analysis, and
testing to ensure a system complies with its requirements.
 Requirements validation: “am I building the right product?”
 Requirements verification: “am I building the product right?”
 In other words, verification involves fully understanding customer intent and
validation involves satisfying the customer's intent.
Requirements Validation and
Verification
 There are great benefits to implementing a requirements verification and
validation program. These include:
 Early detection and correction of system anomalies
 Enhanced management insight into process and product risk
 Support for life cycle processes to ensure conformance to program
performance and budget
 Early assessment of software and system performance
 Ability to obtain objective evidence of software and system conformance to
support process analysis model
Requirements Validation and
Verification
 Improved system development and maintenance processes
 Improved and integrated systems analysis model
 Requirements validation involves checking that the system provides all of the
functions that best support the customer’s needs and it does not provide the
functions that the customer does not need or want.
 Validation should ensure that there are no requirements conflicts and that
satisfaction of the requirements can be demonstrated.
 Requirements verification (testing) involves checking the satisfaction of
several desirable properties of the requirements.
Techniques for Requirements
Validation and Verification
 Walkthroughs
 Walkthroughs or peer/team reviews are an informal methodology to detect
errors and improve requirements quality.
 A typical walkthrough scenario involves requirements engineers, a
supervisor, and peers participating in a semi-structured meeting to review the
requirements before release.
 The goal is to identify ambiguities and inconsistencies and to determine if the
requirements can be tested..
Techniques for Requirements
Validation and Verification
 Inspections
 Inspections are a method of requirement quality control that can be informal
(ad hoc) or highly structured.
 Inspections define the following:
 What can be inspected
 When the code can be inspected
 Who can inspect the code
 What preparation is needed for the inspection
 How the inspection is to be conducted
Techniques for Requirements
Validation and Verification
 The data to be collected
 The follow-up activities
 Inspection can be used in many of requirements engineering settings but is
especially appropriate for safety-critical systems.
Techniques for Requirements
Validation and Verification
 Validating Requirements Use Cases
 When use cases comprise part of the requirements, these can be validated by
asking a simple set of questions:
 Are there any additional actors that are not represented?
 Are there any activities that are not represented?
 Are each actor’s goals being met?
 Are there events in the use case that do not address these goals?
 Can the use case be simplified?
Mandatory qualities for
Requirement
 The mandatory qualities for an individual requirement are that it must be:
 Singular
 Feasible
 Unambiguous
 Complete
 Consistent
 Verifiable
 Traceable
Mandatory qualities for
Requirement
 Then, taken collectively, the set of all requirements in an SRS document
should exhibit the following properties:
 Complete
 Consistent
 Bounded
 Affordable
Mandatory qualities for
Requirement
 Singularity - A requirement should specify a single behavior and have no
conjunctions. For example, consider this requirement for the wet well control
system.
 3.1.1 The pump control unit shall start the submersible pump motors to prevent the
wet well from running over and stop the pump motors before the wet well runs
dry.
 This requirement could be separated into two:
 3.1.1.1 The pump control unit shall start the submersible pump motors to prevent
the wet well from running over.
 3.1.1.2 The pump control unit shall stop the pump motors before the wet well runs
dry.
Mandatory qualities for
Requirement
 Feasibility - A requirement is feasible if it can be satisfied with current
technology and cost constraints, that is, it is not a ridiculous requirement.
Various techniques can be used to assess feasibility including reviews,
inspections, and competitive analysis.
 Ambiguity - A requirement is unambiguous if it has only one interpretation.
 Completeness - Completeness is the sense of whether the specification
contains all requirements and whether all requirements contained in the
specification are completely specified.
Mandatory qualities for
Requirement
 Consistency - Requirements in the document should not conflict. That is,
there should not be contradictory constraints or different descriptions of the
same system function
 Verifiability - To reduce the potential for disputes between customer and
contractor, system requirements should always be written so that they are
verifiable. This means that you should be able to write a set of tests that can
demonstrate that the delivered system meets each specified requirement.
Mandatory qualities for
Requirement
 Traceability - An SRS is traceable if each requirement is identifiable, and all
linkages to other requirements are noted.
 Ranking - A requirements set is ranked if the items are prioritized for
importance and/or stability.