Professional Documents
Culture Documents
I. Sommerville 2000
Slide 1
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
Slide 2
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.
I. Sommerville 2000
Slide 3
I. Sommerville 2000
Slide 4
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
Slide 5
Requirements document
I. Sommerville 2000
Slide 6
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
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
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?
I. Sommerville 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
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
Slide 11
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
Slide 12
Disciplined?
I. Sommerville 2000
Slide 13
I. Sommerville 2000
Slide 14
RE process interactions
System acquisition
Requirements engineering
System design
I. Sommerville 2000
Slide 15
Elicitation
Validation
System requirements Test plans
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 16
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
Slide 17
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
Slide 18
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
Slide 19
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
Slide 20
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
Slide 21
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
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.
I. Sommerville 2000
Slide 23
I. Sommerville 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
Slide 25