requirements engineering process improvement

© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 1

Requirements Engineering Requirements Engineering Process ImprovementProcess Improvement

Requirements Engineering Requirements Engineering Process ImprovementProcess Improvement

Professor Ian SommervilleLancaster University, UK


Structure of the tutorialStructure 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


The REAIMS projectThe REAIMS projectThe REAIMS projectThe 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; TÜVit; University of Manchester, Lancaster University.

Mature, quality-conscious, critical systems engineering Business Environment:

• Tightly regulated, slow evolution to a product focus


Requirements Engineering Requirements Engineering Processes and ProblemsProcesses and Problems


What is Requirements Engineering?What is Requirements Engineering? Requirements engineering (RE) means different things to

different people• It’s about problem analysis, and

• It’s about solution specification, and

• It’s the baseline for design, and

• It’s 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.


A requirements engineering processA requirements engineering processFeasibilitystudyRequirementselicitation andanalysisRequirementsspecificationRequirementsvalidationFeasibilityreport SystemmodelsUser and systemrequirementsRequirementsdocument


Goals of requirements engineeringGoals 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


Problem understandingProblem 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


Is the product...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?


Is the process...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 developer’s strategic goals and customers’ requirements.


Is the customer…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


Has the developer...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


Is the deployment environment...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?

Flexible and geared to change?• Are the people in the environment used to change or will they

resist the system?

• Is the management tradionally hierarchical?

Disciplined?• Do the people in the environment work according to a process

or do they set their own tasks?


Why is RE hard to get right?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 the

problem.

Resources are scarce• RE is always tightly time- and money-bound;

• Required effort will exceed budget.


RE process interactionsRE process interactions

Requirements engineeringSystem designSystem acquisition


The requirements processThe requirements processThe requirements processThe requirements process

Stakeholderrequirements

Elicitation Analysis andnegotiation

ValidationSystem requirements

Test plans


Typical process problemsTypical 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


Symptoms of RE process problemsSymptoms 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


Why RE process improvement?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


What is process improvement?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


Requirements engineering good practiceRequirements engineering good practiceRequirements engineering good practiceRequirements 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))


The state of RE processesThe 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 there’s 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


Inhibitors to RE process improvementInhibitors 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


Are improvements possible?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 don’t 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.


SummarySummary

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