Lecture Requirement engineering Chapter 8 Risks in requirements engineering

Lecture Requirement engineering Chapter 8 Risks in requirements engineering. This chapter presents the following content Element risks management, risk assessment, risk avoidance, risk control, product vision and scope,...

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 edge technologies, or by excluding features that

cutting-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:

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

Unimplemented requirements

The requirements traceability matrix helps to avoid overlooking any requirements during design,

construction or testing

It also helps ensure that a requirement is not

implemented by multiple developers because of inadequate communication within the project

Expanding project scope

 If requirements are poorly defined initially, further

definition can expand the scope of the project

 The project resources that were allocated according to the initial requirements might not be adjusted as the true scope of user needs becomes known

 To mitigate this risk, plan on a phased or incremental delivery process

 Implement the core functionality in the early releases, and iteratively elaborate the requirements for the later phases