Download - 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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 2
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 3
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 4
Requirements Engineering Requirements Engineering Processes and ProblemsProcesses and Problems
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 5
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.
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 6
A requirements engineering processA requirements engineering processFeasibilitystudyRequirementselicitation andanalysisRequirementsspecificationRequirementsvalidationFeasibilityreport SystemmodelsUser and systemrequirementsRequirementsdocument
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 7
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 8
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 9
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?
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 10
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.
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 11
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 12
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 13
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?
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 14
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.
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 15
RE process interactionsRE process interactions
Requirements engineeringSystem designSystem acquisition
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 16
The requirements processThe requirements processThe requirements processThe requirements process
Stakeholderrequirements
Elicitation Analysis andnegotiation
ValidationSystem requirements
Test plans
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 17
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 18
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 19
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 20
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 21
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))
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 22
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 23
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
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 24
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.
© I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 25
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