Lecture Requirement engineering Chapter 8 Risks in requirements engineering

 Risk

management provides a standard
approach to
Identify and document risk factors
Evaluate their potential severity

Propose strategies for mitigating them



 Risk

assessment: is the process of examining a
project to identify areas of potential risk.
Risk identification: makes lists of common risk

factors for software projects
Risk analysis: Examine the potential consequences
of specific risks to your project.
Risk prioritization: focus on the most severe risks
by assessing the potential risk exposure from each.


 Risk

avoidance :

You can avoid risks by not undertaking

certain
projects, by relying on proven rather than cuttingedge technologies, or by excluding features that
will be especially difficult to implement correctly.
Software development is intrinsically risky, though,
so avoiding risk also means losing an opportunity.


 Risk

control: manage the top-priority risks

Risk management planning: produce

a plan for
dealing with each risk including mitigation
approaches, contingency plans, owners, and
timelines
Risk resolution involves executing the plans for
mitigating each risk.
Risk monitoring: track your progress toward
resolving each risk item through


 Risks

factors are organized by the requirements
engineering sub-disciplines:
Elicitation
Analysis
Specification

Verification
Management

 Techniques are suggested that can reduce:
Either the probability of the risk materializing into a

problems
Or the Impact on the projects if it does.


 Product

Vision and scope:

Team members don’t have a clear, shared

understanding of what the product is supposed to
be or do.
 Early in the project write a vision and scope
document that contains your business
requirements and use it to guide decisions about
new or modified requirements.


 Time

spent on requirements development

Tight projects schedules

often pressure managers
into glossing over the requirements.
 A rough guideline is :
To spend about 15 per cent of your project effort
on requirements development activities.
Keep records of how much efforts you actually
spend on requirements development  you can
judge whether it is sufficient and improve your
planning for future projects.


 Completeness

and correctness of
requirements specification
Apply the use case technique to elicit

requirements by focusing on user tasks. This
ensure that you will capture real customer needs.
Devise specific usage scenarios.
Write test cases from requirements
Create prototypes to make the requirements more
tangible for users and to elicit specific feedback
from them.


 Requirements

for highly innovative products:

Emphasize marked research, build prototypes,
Use customer focus groups to obtain early and

frequent feedback about your innovative product
visions.


 Defining

Non functional requirements

Natural emphasis on product

functionality and
easy neglect of non functional ones.
Query customers about quality characteristics:
performance, reliability, usability….
Document these NF requirements and their
acceptance criteria in the SRS document.


 Customer

agreement on product
requirements:
Determine who

the primary customers are.
Make sure you have adequate customer
representation and involvement

Make sure you are relying on the right people for
decision making authority on requirements.


 Unstated

requirements:

Customers might hold implicit expectations that

are not communicated or documented.
Try to identify and record any assumptions the
customers might be taking.
Use open ended questions to encourage customers
to share more of their thoughts, ideas and
concerns than you might otherwise hear.


 Existing

product used as the requirement
baseline:
Developers are sometimes told to use the existing

product as their source for requirements (fix
specific bugs, add new features).
 Document the requirements that you discover
through reverse engineering, and have customers
review those requirements to ensure that they are
correct and still relevant

 Requirement

prioritization

Ensure that every requirement, feature or use case

is prioritized and allocated to a specific product
release or implementation stage.
Evaluate the priority of every new requirement
against the existing body of work remaining to be
done so you can make clever trade-off decisions.


 Technical

difficult features:

Evaluate the feasibility of each requirement to

identify those that might take longer to implement
than planned.
Use your project status tracking to watch for
requirements that are falling behind their
implementation schedule.
Take corrective action as early as possible,


 Unfamiliar

technologies, methods, tools, or

hardware
Don’t underestimate the learning curve of getting

up to speed with new techniques that are needed
to satisfy certain requirements
Identify those high risks requirements early
Allow sufficient time for false starts, learning,
experimentation and prototyping.


 Requirement

Understanding:

Different understandings

of the requirements by
developers and users may lead to expectation gaps.
Formal inspections of requirements documents by
teams including developers, testers, and customers
can mitigate the risk.
Trained and experimented requirements analysts will
ask the right questions and write better specification.
Models and prototypes that represent the
requirements from multiples perspectives will reveal
fuzzy and ambiguous requirements.

 Time

pressure to proceed despite TBDs

Good idea to mark areas of the SRS document that

need further work with ‘to be determined’ (TBD).
But it is risky to proceed with the construction if
these TBDs have not been resolved.
Record the name of the individual responsible for
resolving each TBD, how it will resolved, and the
target date for resolution.


 Ambiguous

terminology

Create a glossary and data dictionary to define all

business and technical terms that might be
interpreted differently by different readers.
Especially define terms that have both common
and technical or domain-specific meanings
Specific reviews can help participants reach a
common understanding of key terms and concepts.


 Unverified

requirements

Inspecting a lengthy

SRS, writing test cases very
early in the development process may appears
fastidious.
However if you verify the quality and correctness
of the requirements before construction begins,
through inspection, requirements-based test
planning and prototyping you can greatly reduce
expensive rework later in the project.


 Unverified

requirements

Include time and resources for these quality

activities in he project plan.
Gain commitments from your customer
representatives to participate in requirements
inspections.
Perform incremental, informal reviews prior to
formal inspections to find problems as early and
cheaper as possible.

 Inspection

proficiency:

Serious defects might be missed in case inspectors

do not know to properly inspect requirements
documents, and to contribute to effective
inspections.
Train all team members who will participate in
inspections of requirement documents.
Invite an experienced inspector from your
organization or outside consultant to observe and
moderate your early inspections to help make
them effective.


 Requirement change process:
Risks from the way changes to requirements are

managed include not having a defined change process,
using an ineffective change mechanism, and permitting
changes to be made without following the process.

You will need to develop a culture and discipline of

change management at all levels.

A requirements change process that includes impact

analysis of proposed changes, a change control board
to make decisions, and a tool to support the defined
procedure is an important starting point.