re-tutorial1-120123134807-phpapp01

7/27/2019 re-tutorial1-120123134807-phpapp01

1/25


2/25

I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 2

Structure of the tutorial

Goal identification

What are YOURproblems and what would YOU like to gain

from this tutorial?

Requirements engineering - Processes and Problems

Questions and Discussion

A Requirements Engineering Process Maturity Model

Requirements Engineering - Good Practice Guidelines

Questions and Discussion


3/25


The REAIMS project

Requirements Engineering Adaptation and Improvement

for Safety and Dependability (1994 - 96)

This was the background for the approach to process

improvement that I will describe here.

Partners: GEC-Alsthom; Aerospatiale; Digilog; TVit;University of Manchester, Lancaster University.

Mature, quality-conscious, critical systems engineering

Business Environment: Tightly regulated, slow evolution to a product focus


4/25


Requirements Engineering

Processes and Problems


5/25


What is Requirements Engineering?

Requirements engineering (RE) means different things to

different people

Its about problem analysis, and

Its about solution specification, and

Its the baseline for design, and

Its what you do at the start of the life-cycle.

RE is all of these things but, more generally, it is the

process of developing an understanding of what a system

should do, how it should do it and the environment wherethe system will be used.


6/25


7/25


8/25


Problem understanding

Understanding the problem when developing

requirements for a system is not a simple technical issue.

Requirements engineers have to understand

The product The process

The customer (s)

The developer (s) of the software

The deployment environment


9/25


Is the product...

An information system?

Understanding the organisational environment is crucial;

The organisation may change radically;

An embedded or hybrid system?

Operational environment needs to be understood;

Solution architecture fixed early and hard to change;

Production problems tend to migrate to the software.

A custom-built system or a software product

Do customers for know what their requirements are?

Who supplies the requirements for a software product?


10/25


Is the process...

Customer-driven?

Customer is principal stakeholder;

Typically a document-driven process.

Market-driven? Time-to-market is the dominant constraint;

Developer is principal stakeholder;

Driven by product vision for first release. Subsequent releases

need to balance developers strategic goals and customers

requirements.


11/25


Is the customer

Homogeneous?

Need to understand their business and strategic objectives.

Heterogeneous?

Need to trade off conflicting requirements, This is the normal

situation.

Merely potential?

Need a proxy to represent the actual customer


12/25


Has the developer...

A document culture?

Documentation may be an overhead for small start-ups - but a

creeping requirement as product and customer base grows.

A quality culture?

RE products perceived to have only an indirect relationship to

software products;

Classical view of quality conflicts with short development

cycles.

A RAD culture? No experience of dealing with requirements documents but

works on the basis of prototyping and rapid evolution


13/25


14/25


Why is RE hard to get right?

The world is complex

The problem is not always tractable to analysis.

The world changes

The problem will change and the solution may change theproblem.

Resources are scarce

RE is always tightly time- and money-bound;

Required effort will exceed budget.


15/25


RE process interactions

Requirements engineering

System design

System acquisition


16/25


17/25


Typical process problems

Requirements elicitation

Failure to consider all important stakeholders and therefore

critical requirements are not included in the system

Requirements analysis

Failure to carry out a detailed analysis of the requirements

System and problem models become inconsistent

Requirements validation

Failure to identify requirements tests

Insufficient validation of requirements

Requirements management

Failure of change control and management of requirements


18/25


Symptoms of RE process problems

Product problems

Customer dissatisfaction

Delays in implementing changes to products

Unused product features

People problems

System stakeholders feel excluded

Meetings failing to reach agreement

Schedule problems

Requirements changes take a long time to negotiate

Extensive rework causes schedule delays


19/25


20/25


21/25


Requirements engineering good practice

Good practice is the basis of an incremental approach to

RE process improvement

Where does it come from?

Experience Internal company experience

External community wisdom

Standards, e.g. IEEE std 830 (SRS standard)

IEEE std 1362 (Concept of Operations) ISO/IEC 12207 (S/W life-cycle standard)

PSS-05 (ESA software engineering standard(s))


22/25


The state of RE processes

Informal studies have shown that few organisations have

thought about their RE processes and that many good

practices are ignored

If theres so much known good practice, why is RE soimmature?

Domain specialists involved in RE are not aware of good practice

because they are not requirements engineers

Generally infeasible to adopt a big-bang approach

Community wisdom lacks consensus

Standards need to be interpreted and tailored

Insufficient guidance on how to prioritise adoption of a standard


23/25


Inhibitors to RE process improvement

The range of stakeholders in the RE process itself and

their different priorities

Process improvement is perceived as

a customer-imposed overhead; aimed at large, bespoke projects;

resource-hungry.

Existing software process improvements models fail to

consider RE in detail


24/25


Are improvements possible?

Definitely YES so long as:

You tailor the improvements to the type of products and

processes that you develop. Informal processes for small

products are as amenable to improvements than larger processes

for large custom systems products You dont expect miracles. Improvements should be

incremental and should respect the sensibilities of the people

involved in the processes

You design improvements based on what you REALLY do not

on a formal, unrealistic model. Professionals interpret thesemodels in their own way.


25/25


Summary

Requirements engineering is a very complex task which

can be thought of as the interface between the real world

and the computer system

Requirements engineering processes are often informal

and process weaknesses can lead to problems in the

delivered product

Requirements engineering process improvement should

improve product quality and shorten delivery times

Process improvement should be incremental and should

respect the sensibilities of the people involved

re-tutorial1-120123134807-phpapp01

Documents

Transcript of re-tutorial1-120123134807-phpapp01