Requirements Engineering Process Improvement

Professor Ian Sommerville Lancaster University, UK

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 1

Structure of the tutorial

Goal identification
What are YOUR problems 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

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 2

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

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 3

Requirements Engineering Processes and Problems

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 4

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 where the system will be used.

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 5

A requirements engineering process

Feasibility study Requirements elicitation and analysis

Requir ements specification Requirements validation

Feasibility report System models User and system requirements

Requirements document

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 6

Goals of requirements engineering

Specify a product that satisfies the stakeholders and constraints Specify how that satisfaction is to be verified Enable project planning and cost estimation Manage change Write a description of the requirements in a form that is suitable for the customer for the system and for the system developer

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 7

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

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 8

Is the product...

An information system?
Understanding the organisational environment is crucial; The organisation may change radically; Operational environment needs to be understood; Solution architecture fixed early and hard to change; Production problems tend to migrate to the software. Do customers for know what their requirements are? Who supplies the requirements for a software product?

An embedded or hybrid system?

A custom-built system or a software product

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 9

Is the process...

Customer-driven?
Customer is principal stakeholder; Typically a document-driven process. 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.

Market-driven?

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 10

Is the customer

Homogeneous?
Need to understand their business and strategic objectives.

Heterogeneous?
Need to trade off conflicting requirements, This is the normal situation.
Need a proxy to represent the actual customer

Merely potential?

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 11

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. RE products perceived to have only an indirect relationship to software products; Classical view of quality conflicts with short development cycles. No experience of dealing with requirements documents but works on the basis of prototyping and rapid evolution

A quality culture?

A RAD culture?

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 12

Is the deployment environment...

An existing environment with established processes and equipment?

How should the system integrate with the existing equipment? Will existing processes be resistant to change? Are the people in the environment used to change or will they resist the system? Is the management tradionally hierarchical? Do the people in the environment work according to a process or do they set their own tasks?

Flexible and geared to change?

Disciplined?

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 13

Why is RE hard to get right?

The world is complex

The problem is not always tractable to analysis. The problem will change and the solution may change the problem. RE is always tightly time- and money-bound; Required effort will exceed budget.

The world changes

Resources are scarce

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 14

RE process interactions
System acquisition

Requirements engineering

System design

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 15

The requirements process

Stakeholder requirements

Elicitation

Analysis and negotiation

Validation
System requirements Test plans
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 16

Typical process problems

Requirements elicitation
Failure to consider all important stakeholders and therefore critical requirements are not included in the system Failure to carry out a detailed analysis of the requirements System and problem models become inconsistent Failure to identify requirements tests Insufficient validation of requirements Failure of change control and management of requirements

Requirements analysis

Requirements validation

Requirements management

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 17

Symptoms of RE process problems

Product problems
Customer dissatisfaction Delays in implementing changes to products Unused product features System stakeholders feel excluded Meetings failing to reach agreement Requirements changes take a long time to negotiate Extensive rework causes schedule delays

People problems

Schedule problems

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 18

Why RE process improvement?

To reduce problems with operational software To reduce the costs of requirements engineering To satisfy external customers or regulators To reduce the time to delivery for software systems To adapt to other process changes To make better use of your intellectual assets

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 19

What is process improvement?

Changes to a process that are introduced to make that process more effective in supporting the goals of the business Approaches to improvement
Business process re-engineering. Radical revision of processes often supplemented with new IT support. Rarely effective for knowledge-based processes Incremental improvement. Finding better ways to do what is already being done! Technology support. Introducing new technology to support existing processes with minimal process change

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 20

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))

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 21

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 so immature?

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
Requirements Engineering SI-SE 2000 Slide 22

I. Sommerville 2000

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

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 23

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 these models in their own way.

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 24

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

I. Sommerville 2000

Requirements Engineering SI-SE 2000

Slide 25