re-tutorial1-120123134807-phpapp01
-
Upload
rishikarthick -
Category
Documents
-
view
214 -
download
0
Transcript of re-tutorial1-120123134807-phpapp01
-
7/27/2019 re-tutorial1-120123134807-phpapp01
1/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
3/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 3
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
4/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 4
Requirements Engineering
Processes and Problems
-
7/27/2019 re-tutorial1-120123134807-phpapp01
5/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 5
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.
-
7/27/2019 re-tutorial1-120123134807-phpapp01
6/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
7/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
8/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 8
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
9/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 9
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?
-
7/27/2019 re-tutorial1-120123134807-phpapp01
10/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 10
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.
-
7/27/2019 re-tutorial1-120123134807-phpapp01
11/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 11
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
12/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 12
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
13/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
14/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 14
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.
-
7/27/2019 re-tutorial1-120123134807-phpapp01
15/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 15
RE process interactions
Requirements engineering
System design
System acquisition
-
7/27/2019 re-tutorial1-120123134807-phpapp01
16/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
17/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 17
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
18/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 18
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
19/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
20/25
-
7/27/2019 re-tutorial1-120123134807-phpapp01
21/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 21
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))
-
7/27/2019 re-tutorial1-120123134807-phpapp01
22/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 22
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
23/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 23
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
-
7/27/2019 re-tutorial1-120123134807-phpapp01
24/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 24
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.
-
7/27/2019 re-tutorial1-120123134807-phpapp01
25/25
I. Sommerville 2000 Requirements Engineering SI-SE 2000 Slide 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