A Formal Framework
for Requirements Evolution
Consiglio Nazionale delle Ricerche
Bando n. 203.01.72 Codice n. 03.01.04
Massimo Felici
LFCS, School of Informatics, The University of Edinburgh
JCMB, The Kings Buildings, Mayfield Road
Edinburgh EH9 3JZ, United Kingdom
tel. +44-131-6505899
fax. +44-131-6677209
[email protected]
February 2003
Abstract
This report investigates Requirements Evolution for computer-based systems.
Although practitioners and researchers recognise the problem, there has been
little research effort in investigating models of Requirements Evolution. This is
due to lack of long term evolutionary data and models to analyse them.
This report takes into account Requirements Evolution for computer-based
systems and investigates models that may enhance our understanding about
Requirements Evolution. The collection of identified models provides a basis
for a Formal Framework for Requirements Evolution.
This report and the work it describes were partially funded by a grant of
the Italian National Research Council (CNR), Bando n. 203.01.72, Codice n.
03.01.04, Research Program: A Formal Framework for Requirements Evolution.
1
Acknowledgements
I would like to thank Stuart Anderson for his supervision on my work. Moreover
I would like to thank the industrial partner that provided the case study. Due to
the confidentiality agreement with the industrial partners I can not provide any
further information about the case study. Despite this the work still remains
valuable and the results are clearly expressed.
This work has been conducted within the UK EPSRC (Engineering and
Physical Sciences Research Council) DIRC project1 , Interdisciplinary Research
Collaboration in Dependabiliy of Computer-based Systems, grant GR/N13999.
Finally I would like to thank all the DIRC people and colleagues, who collaborated and provided valuable input in related discussions.
This report and the work it describes were partially funded by a grant of
the Italian National Research Council (CNR), Bando n. 203.01.72, Codice n.
03.01.04, Research Program: A Formal Framework for Requirements Evolution.
Related Publications
Parts of this work have been published in the following papers:
[22] Massimo Felici, “Taxonomy of Evolution and Dependability”. To appear
in Proceedings of the Second International Workshop on Unanticipated
Software Evolution, USE 2003, April, 2003, Warsaw, Poland.
[4] Stuart Anderson, Massimo Felici, “Quantitative Aspects of Requirements
Evolution”. In Proceedings of the 26th Annual International Computer
Software and Application Conference, COMPSAC 2002, Oxford, England,
IEEE Computer Society, 2002, pp. 27-32.
1 http://www.dirc.org.uk/
c Massimo Felici, 2003
2
[3] Stuart Anderson, Massimo Felici, “Requirements Evolution: From Process to Product Oriented Management”. In Proceedings of the 3rd International Conference on Product Focused Software Profess Improvement,
Profes 2001, Kaiserslautern, Germany, September 10-13, 2001, LNCS 2188,
c
Springer-Verlag
2001, pp. 27-41.
[1] Stuart Anderson, Massimo Felici, “Controlling Requirements Evolution:
An Avionics Case Study”. In F. Koornneef, M. van der Meulen (Eds.),
Computer Safety, Reliability and Security, 19th International Conference,
SAFECOMP 2000, Rotterdam, The Netherlands, October 2000, Proceedc
ings, LNCS 1943, Springer-Verlag
2000, pp. 361-370.
c Massimo Felici, 2003
Contents
1 Introduction
1.1
8
Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Related Work
2.1
11
Literature Rationale . . . . . . . . . . . . . . . . . . . . . . . . .
3 An Avionics Case Study
3.1
3.2
3.3
10
13
16
Description of the Case Study . . . . . . . . . . . . . . . . . . . .
16
3.1.1
System Requirements . . . . . . . . . . . . . . . . . . . .
17
3.1.2
Development Process . . . . . . . . . . . . . . . . . . . . .
18
Empirical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.1
Requirements Evolution . . . . . . . . . . . . . . . . . . .
22
3.2.2
A Taxonomy of Requirements Evolution . . . . . . . . . .
24
3.2.3
Requirements Maturity Index . . . . . . . . . . . . . . . .
25
3.2.4
Ageing Requirements Maturity . . . . . . . . . . . . . . .
27
3.2.5
Ageing Requirements Evolution: Empirical Evidence . . .
28
3.2.6
Functional Requirements Evolution. . . . . . . . . . . . .
32
3.2.7
Requirements Dependencies . . . . . . . . . . . . . . . . .
37
3.2.8
Visualizing Requirements Evolution . . . . . . . . . . . .
39
Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3
CONTENTS
4
3.3.1
Requirements Evolution in Practice . . . . . . . . . . . .
43
3.3.2
Requirements Evolution Features . . . . . . . . . . . . . .
44
4 Modelling Requirements Evolution
48
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2
Modelling Requirements Evolution . . . . . . . . . . . . . . . . .
50
4.2.1
Data Model . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.2.2
Evolutionary Relationships . . . . . . . . . . . . . . . . .
53
4.2.3
Requirements Process . . . . . . . . . . . . . . . . . . . .
56
4.3
Scenarios of Use . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.4
Conclusions and Further Work . . . . . . . . . . . . . . . . . . .
61
5 Taxonomy of Evolution and Dependability
62
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.2
Taxonomy of Evolution . . . . . . . . . . . . . . . . . . . . . . .
64
5.2.1
Software Evolution . . . . . . . . . . . . . . . . . . . . . .
65
5.2.2
Architecture (Design) Evolution . . . . . . . . . . . . . .
68
5.2.3
Requirements Evolution . . . . . . . . . . . . . . . . . . .
69
5.2.4
Computer-based System Evolution . . . . . . . . . . . . .
71
5.2.5
Organization Evolution . . . . . . . . . . . . . . . . . . .
73
5.3
On the Dependability of Evolution . . . . . . . . . . . . . . . . .
73
5.4
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6 Conclusions and Future Work
6.1
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
c Massimo Felici, 2003
78
79
List of Tables
3.1
Types of changes identified by inspection of the history of changes. 25
3.2
Requirements dependencies matrix. . . . . . . . . . . . . . . . . .
38
5.1
Dependability perspectives of Evolution. . . . . . . . . . . . . . .
76
5
List of Figures
3.1
The safety-critical software development life cycle of the case study. 19
3.2
Development activities and deliverables. . . . . . . . . . . . . . .
21
3.3
Number of requirements changes per software release. . . . . . .
23
3.4
Total number of requirements per software release. . . . . . . . .
24
3.5
Requirements Maturity Index for each software release. . . . . .
26
3.6
Simulation of the requirements evolution metrics on a sample
scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.7
Average number of requirements changes. . . . . . . . . . . . . .
30
3.8
Requirements Stability Index for each function at the 22nd release
of the requirements specification. . . . . . . . . . . . . . . . . . .
3.9
31
Historical Requirements Maturity Index for the entire set of requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.10 Requirements evolution from a functional viewpoint. Distribution of requirements changes over software releases for each function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.11 Cumulative number of requirements changes for each function . .
34
3.12 Cumulative number of requirements changes against the number
of requirements for each function. . . . . . . . . . . . . . . . . . .
35
3.13 Classified requirements evolution. . . . . . . . . . . . . . . . . . .
36
6
LIST OF FIGURES
7
3.14 Scatter plot of number of requirements versus number of changes
for each software function. . . . . . . . . . . . . . . . . . . . . . .
37
3.15 Histograms of the size of the sets of requirements changes allocated to a single software release. . . . . . . . . . . . . . . . . . .
38
3.16 Graphical work flow representation of the basic operations to
changes requirements. . . . . . . . . . . . . . . . . . . . . . . . .
41
3.17 Graphical work flow representation of requirement evolution for
F1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.1
Entity Relationship model for Requirements. . . . . . . . . . . .
51
4.2
Different types of relations between entities. . . . . . . . . . . . .
53
4.3
An ideal requirement process. . . . . . . . . . . . . . . . . . . . .
56
4.4
Evolutionary Classification. . . . . . . . . . . . . . . . . . . . . .
58
4.5
Process Calibration. . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.6
Requirements Featuring. . . . . . . . . . . . . . . . . . . . . . . .
59
5.1
Evolutionary space. . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.2
The SHEL model. . . . . . . . . . . . . . . . . . . . . . . . . . .
72
c Massimo Felici, 2003
Chapter 1
Introduction
This report considers software requirements evolution within industrial production environments. Any production environment consists of diverse stakeholders
interacting through processes focused on particular aspects of software production (e.g., management, designing, testing, etc.). Thus, software is the result of
cooperating processes in which human beings are the main actors [42, 87]. Effective cooperation requires stakeholders to understand their different viewpoints
on the processes [44, 52, 65, 84, 86, 91]. Stakeholder interactions, cooperations
and negotiations result in shifts in the grounds for agreement. These shifts
drive requirements evolution. This work takes Requirements Evolution as an
unavoidable feature of software production. Classically, Requirements Evolution
is seen as an error in the engineering process. By contrast, this report considers
Requirements Evolution as an essential feature of good design processes.
Stakeholders interact as participants in the processes of a software development environment. These interactions result in changes in stakeholder knowledge. These changes are captured and disseminated over the project as Requirements Evolution [33, 69]. Requirements Evolution triggers a sequence of
8
9
events, which allows changes to propagate throughout the development process.
In any development process the definition of requirements is the first phase and
it is always crucial for the success of the project (e.g., in terms of cost, timing,
customer satisfaction, etc.).
As a software project progresses requirements changes become increasingly
expensive and risky [9, 10, 11]. Each requirements change affects the success
of the project as well as system characteristics (e.g., dependability, safety, reliability, usability, etc.) that are crucial for the system functionalities (e.g.,
Air Traffic Control, Electronic Engine Control, Medical Systems, Smart Card
Systems, etc.). These issues motivate an increasing interest in requirements engineering [8, 18, 83]. The deeper the understanding of stakeholder interaction,
the better the control of Requirements Evolution. The problem is how to match
business processes, development processes and product features in order to enhance our ability in understanding and controlling Requirements Evolution by
monitoring stakeholder interactions through requirements.
This work aims to enhance our ability to understand and to control the evolving nature of requirements. In contrast to the process-centred approach taken in
current requirements engineering practice [85, 77, 94], we take a product-centred
approach. Process issues are captured in the product as it is developed. Our
approach originates in the empirical investigation of industrial case studies of
evolving products and their requirements [1, 2, 24, 25]. These case studies aim
to develop a detailed account of the cooperative processes adopted by stakeholders. The underlying hypothesis of this report is that stakeholder interaction in
cooperative processes is a powerful driver of Requirements Evolution.
c Massimo Felici, 2003
1.1. REPORT OUTLINE
1.1
10
Report Outline
This report is structured as follows. Chapter 2 reviews related work in requirements engineering. The review points out a rationale for a framework that
supports the analysis, control, and monitor of Requirements Evolution. Related
research and the existence of few empirical studies motivated the investigation
of the case study in Chapter 3. The literature rationale has been furthermore
taken into account in order to devise the framework outlined in Chapter 4.
Chapter 3 shows an empirical investigation of an avionics safety-critical case
study drew from industry. The empirical analysis points out evolutionary aspects of requirements as well as practical issues. The case study furthermore
stresses the need to enhance our understanding about requirements evolution.
Chapter 4 introduces a framework for modelling Requirements Evolution. The
framework emphasises three main evolutionary aspects: Data Model, Evolutionary Relationships and Requirements Process. Scenarios of uses show how the
modelling framework may be used in practice. Chapter 5 provides a detailed
account of evolution of computer-based systems. A taxonomy of evolution emphasises the different evolutionary aspects and their influence on dependability
of computer-based systems. Finally chapter 6 draws the conclusions of this
work.
c Massimo Felici, 2003
Chapter 2
Related Work
Current practice in requirements engineering [77, 80, 85, 94] identifies a set of
methodologies, tools, processes that aim to specify software (system) requirements. Two big research and practice areas can be identified within requirements engineering, namely, specification and verification1. The former aims to
improve our ability in specifying requirements. The latter aims to improve our
ability in verifying requirements characteristics (e.g., correctness, completeness,
etc.). Everything concerning requirements evolution is usually covered under
another area, namely, requirements management. The name itself emphasises
process oriented approaches. There has been little attention from the product
point of view to devise approaches supporting Requirements Evolution. Most
of the work in requirements management focuses on process aspects. Recent research [32, 33, 69, 88] in requirements engineering points out the evolving nature
of requirements. The PROTEUS project [33, 69] takes into account requirements evolution from a business viewpoint identifying the origins of changing
requirements into stakeholders and business environment. Any specific environ1 Other research areas in requirements engineering are elicitation and analysis, but here we
are not referring to these areas.
11
12
ment producing software is characterised by changing requirements, therefore
any attempt of stopping changes [32], hence requirements evolution, will fail
triggering process and software degradations. The understanding of requirements evolution may be improved by empirical investigations [1, 2, 32, 88] of
industrial case studies, which analyse how requirements evolve in practice. Evolution should be considered differently than reuse. Requirements reuse should
take into account a trade off between process and product viewpoint [47, 48].
Even the solution of reusing requirements has to be carefully adapted to specific
software contexts [47, 48].
The COHERENCE [87] and REAIMS [86, 91] projects encourage the application of hybrid approaches early in the development process even before the
specification of requirements. In particular, the integration of different viewpoints seems an effective way of merging different perspectives related to different stakeholders and engineering processes [84, 86, 87]. It comes out that
even with hybrid approaches focusing on the process, requirements evolution
still remains one of the critical point throughout the software life cycle.
The evolving behaviour is not bounded at the requirements level. The
FEAST project [53] has empirically identified a set of laws for software evolution. But the relation between requirements evolution and software evolution
[6, 53, 43] needs further clarification. Further investigations of this relationship
will improve our ability to assess the impact of requirements changes. Moreover, the widely held view that traceability [19, 20, 41, 70] resolves requirements
evolution turns out to be insufficient. Requirements traceability [41] has been
recognised to be an important aspect to deal with evolution. Traceability represents not only an additional information to be collected (and maintained),
but also a strategic policy involving an entire software organisation [70]. Traceability maintenance relies on strict processes and tools, which allow to identify
c Massimo Felici, 2003
2.1. LITERATURE RATIONALE
13
relationships between the software organisation and the software product [41].
The combination of traceability with other relationships is needed to enhance
our ability in specifying and maintaining requirements. Requirements and Software Evolution has also been considered from a theoretical point of view in
[61, 96], but there has been little attention to integrate theoretical work with
product-line features.
Many recent research projects [16, 17, 63, 73, 74, 75] have progressed the
state of the art in Requirements Engineering and the understanding of evolutionary behaviours in the software life cycle. But the current practice in industry
requires additional research actions. Past projects point out the need to shift to
hybrid process-product oriented methodologies, which shall be defined according the needs identified according to massive empirical investigations of real case
studies.
2.1
Literature Rationale
This section reviews related literature in requirements engineering providing a
rationale for the proposed framework for modelling requirements evolution. The
literature review points out issues or practical challenges that may be supported
by modelling and analysing requirements evolution. The review in this section
does not pretend to be an exhaustive account of research and current practice
in requirements engineering. The review focuses on those aspects related to
requirements evolution.
Hooks and Farry [36] emphasise the need of measuring Requirements Quality. Their initial point is that measuring is the foundation for improvement.
They point out that most of the time this view is not recognised by managers, who belive that measuring requirements is costly (in terms of resources)
and time consuming. Other managers believe that they can not measure rec Massimo Felici, 2003
2.1. LITERATURE RATIONALE
14
quirements until the project is finished. The main motivation of measuring
requirements is to identify opportunity for improvement. They suggest to measure the quality of requirements on data drawn from Change Requests (CRs)
and Discrepancy Reports (DRs). These are mainly different names for stimulus
for changes into requirements. They emphasise the need of adopting simple
measures of requirements statistics derived from the analysis of requirements
counting, trends, percentages, as well as classifications. These metrics represent
a basis for Changes Analysis. Moreover, they represent a means for comparing
projects. A systematic account of measures of requirements provides input to
making changes in an Organisation’s Requirements Definition Process. Many
issues in driving changes into a requirements definition process are related to the
lack in requirements culture within the organisation, lack of empirical evidences,
as well as difficulties in converging on a stable set of requirements. A shift into
the requirements definition process needs to be supported by engineering tools
and analysis models.
Wiegers [94] emphases the importance of measuring and classifying requirements changes in order to achieve process improvements. He stresses the role
of Requirements Management within process related models (e.g., CMM [66]).
Weinberg [92] stresses how the Assumption of Fixed Requirements is a weak
point in most of the work in Software Engineering. This mainly invalidates
many work based on the implied position, that is, “This is how we would design
and build software (if we had unchanging requirements)”. Weinberg’s point is
supported by previous studies pointing out that the majority of serious quality
problems were related to Requirements. This point has been also recognised
by Boehm [9] and has driven the definition of iterative development processes
(e.g., The Spiral Model). Weinberg’s process view stresses the existence of Twin
Processes. That is, the underlying idea is that there exist two processes: one
c Massimo Felici, 2003
2.1. LITERATURE RATIONALE
15
to develop a requirements product; one to develop a software product. The two
processes need to be mutually controlled. The basis for mutually controlling the
two processes should be driven by empirical evidence. Moreover, the empirical
information drawn from mutually controlling two processes should provide a
basis for changing the requirements process.
Sommerville and Sawyer [85] identify guidelines for Requirements Management. Among the main guidelines for requirements management there are three
related activities: Define Change Management Policies; Identify Global System
Requirements; Identify Volatile Requirements. The definition of change management policies is really important in order to have a formal mechanism to
deal with changes into requirements. Change management policies need to be
supported by empirical analyses. The volume of information related to requirements evolution represent a major issues in any change management policy. A
systematic methodology to analyse requirements evolution helps to keep track
of changes within the process and to assess their impact. Moreover, the analysis
of requirements should be addressed to “Identify Global System Requirements”
and to “Identify Volatile Requirements”. The former are very expensive to
change (e.g., architecture changes) and may involve different stakeholders. The
latter may help to design the system so that volatile requirements are isolated
from the rest of the system. Having these information may help to plan for
changes into requirements and to manage requirements evolution as well.
Other Requirements Engineering literature (e.g., [51, 77]) stresses the need
to deal with Requirements Evolution. But they also emphasise how even simple
instruments like maintaining history of changes may become easily impractical.
After a while, the list of change is so huge that it is difficult to realise what is
going on without a systematic method to shape angles for analysing evolutionary
information.
c Massimo Felici, 2003
Chapter 3
An Avionics Case Study
This chapter describes the investigation of an avionics safety-critical industrial
case study with respect to requirements evolution. The investigation of an
industrial case study aims to acquire input from practice in requirements engineering. This should provide a more realist account of requirements evolution.
A case study furthermore provides different viewpoints related to the specific
domain. This is useful in order to identify domain sensitive information with
respect to requirements evolution.
3.1
Description of the Case Study
The case study consists of software that satisfies the most stringent level of
the standard DO178B [78]. Two main business stakeholders cooperate in the
definition of the system requirements. The customer, who provides the general system requirements, and the supplier, who produces the software. The
following paragraphs describe features of the case study that are relevant to
requirements evolution.
16
3.1. DESCRIPTION OF THE CASE STUDY
3.1.1
17
System Requirements
The investigation of the case study takes into account the system software requirements. They have been drawn from the general system requirements provided by the customer. The definition of the software requirements involves
both the customer and the supplier in elicitation, specification and negotiation.
The supplier is responsible for producing the system software and its compliance
with the specified software requirements. The system software requirements fall
down in two main categories: Safety Requirements; Functional and Operational
Requirements.
Safety Requirements. A system safety assessment analyses the system architecture to identify and classify the failure conditions. Safety related requirements are then identified and flowed down to the software and hardware requirements. The allocation of requirements to software or hardware can be unclear at
some stage of the development. Thus there are cases in which the allocation is
delayed until further information is available correctly to allocate requirements.
Functional and Operational Requirements. The customer provides the
system requirements that contain information needed to describe the functional
and operational software requirements. These include timing and memory constraints and accuracy requirements where applicable. Requirements also contain
details of inputs and outputs the software has to handle with special emphasis
to those using non-standard data formats. As for the safety requirements if the
allocation of requirements to software and hardware is unclear any decision is
delayed until further notice.
c Massimo Felici, 2003
3.1. DESCRIPTION OF THE CASE STUDY
3.1.2
18
Development Process
The software development process of the case study is an instance of the V-model
that emphasises relations between the design and coding phases with that of (integration as well as system) testing, verification and validation. The V-mode
implies that if problems arise during verification and validation, they are reported and eventually fixed by refinements and corrections in the requirements
and design as well as in the implementation. Then the verification and validation
phases are repeated again to reassess the software system. The software development process points out the iterative nature of designing and implementing
the system.
Software Development Process. Figure 3.1 shows the development life
cycle of the case study. The bulk of the software development task can be
split into two broad areas, that of software design and code and the other of
verification.
Issues and modifications identified during subsequents development phases
(e.g., design, coding and verification) give rise to feedback loops in the life
cycle. Reported issues fall down in two main chategories, depending on whether
or not they affect the requirments or just the design and implementation of the
system. Figure 3.1 shows them as two different error busses, namely, Software
Error Bus and Requirements Error Bus. Notice that as software development
progresses from requirements to design and code, problems require items further
back in the chain to be modified. The size and scope of these changes will be
different for each modification and for each project, thus only general guidelines
have been defined by the supplier. For example, while coding a part of the
software detailed design a problem may be found with the design or an easier
implementation may be constructed which requires the original design to be
modified. Also modifications, which are due to problems, hardware changes or
c Massimo Felici, 2003
3.1. DESCRIPTION OF THE CASE STUDY
19
Software Error Bus
Requirements
Elicitation
System
Process
Software
Design
Coding
Testing
Review
Requirements Error Bus
Figure 3.1: The safety-critical software development life cycle of the case study.
even stakeholders, may be introduced from the requirements at any stage of the
software project.
As design progresses the partition of software requirements causes an expansion of information through subsequent activities (e.g., testing) and deliverables
(e.g., code) that reflect the resulting fragmentation. For example, the coding
phase consists of a collection of interrelated implementing phases. The boundaries between these phases may overlap due to unclear process definitions or
implementation’s dependencies. Thus, as the code consists of many items it
may be possible to begin the integration of some of them before the code for
the rest is completed. This is often the case, even on small simple projects.
Then it is very difficult to determine the end point of a process and to fix the
point in which a project transition occurs from one phase to another. Thus,
elements within each phase may be in different progress stages. There is a strict
c Massimo Felici, 2003
3.1. DESCRIPTION OF THE CASE STUDY
20
policy for configuration management, which also requires to maintain traceability on the project to ensure that the final code is complete and consistent with
its higher level requirements, and the verification has been performed on the
correct standard of the final code.
Software verification consists of two main elements testing and review analysis. Specific documents produced at the beginning of the project detail the
verification activities by identifying the level of verification required at each
phase of the software development. Changes affecting certified software require
to repeat the entire software verification and the entire software development
life cycle in case of modified requirements. The extent to which all the phases
comply with the required changes depend on the time elapsed since certification.
During the period between flight trials and certification, project documents are
consistent with the implemented software and reviews need to comply with occurring changes depending on the size of the modifications.
Requirements Documentation. Figure 3.2 shows a representation of the
phases of the development process and its deliverables (i.e., system requirements, software functional requirements, etc.). The System Requirements consist of the requirements identified for the whole systems without distinguishing
between software and hardware requirements. The System Process translates
the System Requirements in the Software Functional Requirements. The Software Functional Requirements consist of a set of documents specifying the requirements for each software function identified for the system. These software
functions will then be designed,implemented and integrated by further activities
in the development process.
Anomalies (e.g., faults, failures, misbehaviours, etc.) encountered during
the development are reported by a Fault Report. A Fault report consists of
a document reporting all the information useful to the development team in
c Massimo Felici, 2003
3.1. DESCRIPTION OF THE CASE STUDY
21
Figure 3.2: Development activities and deliverables.
order to assess the possible faults. When a fault has been recognised actions
are taken to fix it and the needed changes are allocated to a specific software
release. The scope of these actions ranges from requirements to software code.
Thus continuous feedback is provided by fault reports. Notice that certification
requires that all the changes are traced.
Product Line Aspects and Standards.
Hardware dependent software re-
quirements arise not directly from the system requirements, but from the implementation of those system requirements. This is normally due to the way that
the hardware has been designed to meet its requirements as well as an indirect
result of safety related requirements. The hardware dependent software requirements characterise the specific product-line in terms of hardware constraints and
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
22
safety requirements. A certification plan for software is the primary means used
by the designed authorities to assess whether the software development process
proposed is commensurate with the software level proposed. The plan of the
case study complies with the specific guidelines in the standard DO-178B [78].
3.2
Empirical Analysis
The case study consists of software for an avionics system. There are 22 successive releases of the software requirements specification each corresponding to a
software release. The empirical investigation of the avionics case study consists
of analyses of data repositories of requirements evolution. The aim is to identify
requirements properties that may enhance our understanding of requirements
evolution [1, 2]. The investigation moves from a general viewpoint towards a
product-oriented viewpoint. The lack of previous analyses about requirements
evolution requires an incremental approach in order to effectively investigate the
case study. The step-by-step approach furthermore allows to refine the analysis
into subsequent investigations.
3.2.1
Requirements Evolution
The initial empirical investigation of the avionics case study consists of analyses
of data repositories of requirements evolution [1, 2, 3]. The aim is to identify
requirements properties that may enhance our ability in understanding Requirements Evolution. Figure 3.3 shows the total number of requirements changes,
i.e., added, deleted and modified requirements, over the 22 software releases1 .
1 There is a correspondence one-to-one between the versions of the requirements specification and the software releases
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
23
Figure 3.3: Number of requirements changes per software release.
The trend of requirements changes does not give enough information about
evolutionary features, but it emphasises Requirements Evolution. The analysis
of requirements evolution points out that requirements changes are not uniformly spread out over the three basic changes (i.e., added, deleted and modified requirements), in fact the total number of requirements constantly increases
over the software releases. Figure 3.4 shows the increasing number of requirements forming the specification of the avionics system. The increasing trend is
due to the fact that requirements become clearer to the stakeholders, who split
complex requirements into smaller and more precisely stated requirements. Another reason is that new requirements arise during the progress of the project,
because there are requirements that can not be defined at the beginning due to
lack of information and requirements dependencies. Finally, design, implementation and testing activities provide additional feedback to the requirements.
Thus there is a predominace of added requirements.
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
24
Figure 3.4: Total number of requirements per software release.
3.2.2
A Taxonomy of Requirements Evolution
The inspection of the history of changes points out the specific changes occurring
into requirements. Table 3.1 shows a taxonomy of Requirements Evolution in
the case study. Changes affect requirements attributes like variables, functionality, explanation, traceability and dependency. These attributes can be collected
and represented by requirements templates (e.g., [77]). These attributes are usually embedded within paragraphs specifying requirements. A structured way of
representing, collecting and organising requirements attributes may be useful to
identify information for controlling and monitoring requirements evolution. The
taxonomy of Requirements Evolution may help to identify requirements issues.
For instance, if changes overlap two categories, the affected requirements may
need to be refined in order to fit in one category. This may identify different
evolving paths, e.g., splitting requirements in smaller and more detailed requirements or clarify (i.e., modify) their specifications. This is the case when there
are requirements that overlap software and hardware. The decision whether
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
25
to allocate requirements to software or hardware may be delayed till there is a
clear understanding of the system. Hence a taxonomy of Requirements Evolution may classify not only an industrial context, but it can be used as a tool
during design to identify requirements issues.
Table 3.1: Types of changes identified by inspection of the history of changes.
Type of Change
Add, Delete and
Modify requirements
Explanation
Rewording
Traceability
Non-compliance
Partial compliance
Hardware modification
Range modification
Add, Delete, Rename
parameters/variables
3.2.3
Description
Requirements are changed due to the specification process maturity and knowledge.
The paragraphs that refer to a specific requirement are
changed for clarity.
The requirements itself does not change, but it is
rephrased for clarity.
The traceability links to other deliverables are
changed.
A requirement that is not applicable for a new software package. This is the case when the requirements
specification is based on that one of a previous project.
A requirement that is applicable partially for a new
software package. This is the case when the requirements specification is based on that one of a previous
project.
Several changes are due to hardware modifications.
This type of change applies usually to hardware dependent software requirements.
The range of the variables within the scope of a specific
requirements is modified.
The variables/parameters to which a specific requirement refers can change.
Requirements Maturity Index
Metrics [26] may be used to quantify some properties monitoring requirements
evolution. The standard IEEE 982 [37, 38] suggests a Software Maturity Index
to quantify the readiness of a software product. The Software Maturity Index
can be used for software requirements, hence a Requirements Maturity Index
(RM I) to quantify the readiness of requirements. Equation 3.1 defines the
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
26
RMI2 .
RM I =
RT − R C
.
RT
(3.1)
Figure 3.5 shows the RM I calculated for each software release with respect to
the total number of requirements (RT ) and the total number of changes (RC ).
The RM I results to be sensitive to the requirements changes occuring release
after release, but it does not take into account historical information about
changes. Thus whenever there is a substantial number of changes (this may be
the case of a new release) the RM I reflects the introduction of changes without
capturing information related to the number of releases and the average number of changes introduced over previous releases. The RM I therefore captures
stepwise (release after release) changes, hence it is too sensitive to changes introduced into a single release overdegradating its assessment about the readeness
of requirements.
R equirem ents M aturity Index (R M I)
1,00
RMI
0,95
0,90
0,85
0,80
0
5
10
15
20
S oftw are R eleases
Figure 3.5: Requirements Maturity Index for each software release.
2 R is the total number of software requirements in the current release; R
T
C is the number
of software requirements in the current release that are added, deleted or modified from the
previous one.
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
3.2.4
27
Ageing Requirements Maturity
The empirical analysis of the case study points out that requirements changes
are not uniformally distributed over the software releases. There is moreover a
different distribution for each function. The behavioural analysis of the RM I on
the dataset points out that the RM I is not sensitive to the history of changes.
This is because the RM I is defined for two subsequent releases, that is, the
RM I does not take into account historical information. For instance, information like how long some changes have been introduced, how many releases
there were without changes, etcetera. We propose to refine the RM I by taking
into account historical evolutionary information and not just the requirements
changes occurred in the next subsequent release. The simplest historical information consists of the Cumulative Number of Requirements Changes (CRC )
and the Average Number of Requirements Changes (ARC ), Eq. 3.2, over the
software releases.
ARC =
CRC
.
n
(3.2)
Based on the above information we propose two refinements of the RM I. The
first refinement is named Requirements Stability Index (RSI) , Eq. 3.3. Differently from the RM I the RSI takes into account the cumulative number of
requirements changes, CRC . Hence RSI is sensitive not just to the total number of requirements, RT , but also to the cumulative number of changes, CRC .
The RSI can be also negative in cases where there have been more changes
than the total number of requirements, RT . The maximum value of SRI is 1 in
the case when there have not been changes since the initial release (this is quite
unlikely in practice).
RSI =
c Massimo Felici, 2003
RT − CRC
.
RT
(3.3)
3.2. EMPIRICAL ANALYSIS
28
The second refinement is named Historical Requirements Maturity Index (HRM I),
Eq. 3.4. It is defined on the total number of requirements and the average distribution of requirements changes over the software releases (ARC ). This allows
to take into account the age of changes.
HRM I =
RT − ARC
.
RT
(3.4)
The intuition behind the two refinements is that if some changes are introduced
into requirements, these changes affect the stability of the requirements. The
maturity of the requirements depends on how long some changes have been
introduced. That is, if there are not further changes the maturity gradually
increases with the delivery of subsequent releases. Figure 3.6 shows the simulation of the above metrics on a sample case. The top, middle and bottom picture
of Fig. 3.6 respectively show the requirements changes, the total number of requirements and the comparison of the RM I, RSI and HRM I. The comparison
of the three indexes, i.e., RM I, RSI and HRM I, shows clearly the different
behaviour with respect to the sample scenario. The HRM I is less sensitive and
more stable than the RM I, which is more sensitive to the number of changes
occurring release after release.
3.2.5
Ageing Requirements Evolution: Empirical Evidence
This section assesses on the case study the proposed quantitative models of
Requirements Evolution. Figure 3.7 shows the average number of changes over
the software releases. The picture shows clearly an increasing trend. This is
particular for the analysed case study, but there could be different distribution
according to the specific system, the adopted design process and the system life
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
29
70
60
50
40
30
0
2
6
4
8
10
12
14
16
18
20
x
Legend
Requirements Changes
900
800
700
600
500
0
2
6
4
8
10
12
14
16
18
20
x
Legend
Total Number of Requirements
1
0.95
0.9
y 0.85
0.8
0.75
0.7 0
2
4
6
8
10
x
Legend
12
14
16
18
20
Requirements Maturity Index (RMI)
Requirements Stability Index (RSI)
Historical Requirements Maturity Index (HRMI)
Figure 3.6: Simulation of the requirements evolution metrics on a sample scenario.
cycle.
As we would expect the RSI has a decreasing trend. Whereas it is more
interesting to analyse the RSI at the last release (i.e., the 22nd release) of the
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
30
Figure 3.7: Average number of requirements changes.
case study. Figure 3.8 shows that the RSI captures the stability of each function.
Those functions with negative RSI are the most unstable in the system. The
RSI can be easily applied to any dataset, because it takes into account not just
the number of changes but also the dimension of the dataset considered. Hence
the RSI estimates how stable is a set of requirements.
Figure 3.9 shows the HRM I for the entire set of requirements. The HRM I
smoothly follows the iterations of the development life cycle. That is,decreasing
trends are associated to the introduction of major changes (establishing a new
major release), which trigger a stabilisation process into subsequent releases
during which the HRM I increases again. HRM I is less sensitive that RM I to
changes over single releases, but it smoothly captures the requirements process
and its stabilization.
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
31
Figure 3.8: Requirements Stability Index for each function at the 22nd release
of the requirements specification.
Figure 3.9: Historical Requirements Maturity Index for the entire set of requirements.
In conclusion this section assesses the proposed metrics, RSI and HRM I.
The analysis supports the intuition behind the two metrics. That is, RSI evaluates the overall stability of a set of requirements and HRM I evaluates the
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
32
requirements maturity with respect to the requirements evolution process. This
points out that the distribution of the requirements changes is an importan
driver for the RSI and the HRM I. This final result relates the Requirements
Evolution process to the development process and provides an attribute to control the maturity of requirements. Different distributions imply different trends
of RSI and HRM I.
3.2.6
Functional Requirements Evolution.
Evolutionary Analysis Viewpoint. Simple trends of requirements evolution provide little information. Previous experience points out that the analysis
of requirements evolution from a functional viewpoint can point out further
information [4]. For instance, it can identify the stable or changeable parts of
requirements. Figure 3.10 shows an example of different functional requirements
(i.e., F1-F8) forming the requirements specification of a system3 . The different trends point out how the stability of functional requirements may change
over the software life cycle. In other words, stable requirements may become
changeable and vice versa. This kind of information can be useful for future
similar projects. This can be the case for software product-lines characterised
by similar related projects differing in specific variability aspects [12]. Moreover, the analysis of requirements from a functional viewpoint can be useful to
identify dependencies between requirements [3]. Dependencies may be used to
effectively assess the impact of changes into requirements and to plan evolution.
To provide a more detailed analysis our focus moves from the total number
of requirements changes to the number of requirements changes in each function that forms the software functional requirements. The software functional
3 The picture in the top-left corner of Fig. 3.10 shows the total number of changes for the
whole requirements specification.
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
33
Figure 3.10: Requirements evolution from a functional viewpoint. Distribution
of requirements changes over software releases for each function.
requirements fall into 8 functions for which separate documents are maintained.
Figure 3.11 shows the trend of the cumulative number of requirements changes
for each function. Figure 3.11 points out that the likelihood that changes can
occur into specific functions is not constant over the software releases. An outcome of this functional analysis is that the function F1 is not likely to change,
therefore it could be considered a stable part of the system. This aspect becomes
interesting, because the specific function describes the hardware architecture of
the system onto which the software architecture is mapped. It seems furthermore that functions that are likely to change during early software releases
change less during later releases, and vice versa. This aspect helps to relate
requirements changes with the software life cycle. The different occurrences
of requirements changes throughout the life cycle points out some dependencies among functional requirements. Understanding these dependencies may
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
34
improve the requirements process.
Figure 3.11: Cumulative number of requirements changes for each function
Figure 3.12 shows the scatter plot of number of cumulative requirements
changes against the size of each fucntion (at the 22nd release) in terms of number
of requirements. Figure 3.12 sows that there exist a linear relationship between
the number of changes occuring into a requirements specification and its size.
But there exist outliers such as, e.g., F2, F5 and F8.Figure 3.12 moreover points
out the intuitive interpretation that the functions above the diagonal dividing
the plan are more unstable (in terms of requirements changes) than that ones
under the diagonal. In particular F1 turns to be a stable part of the system. This
is interesting, because the specific function describes the hardware architecture
of the system onto which the software architecture is mapped.
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
35
Figure 3.12: Cumulative number of requirements changes against the number
of requirements for each function.
The analysis then investigates whether there are differencies among fanctions according to the distribution of changes over the software releases. Figure
3.10 shows the different distribution of requirements changes4 for all functions.
This representation of requirements changes points out how different can be the
distrubution for each function. The different distributions point out some interesting intuitive properties. Firstly the likelihood that changes can occur into
specific functions is not constant over the software releases. Finally it seems
that functions that are likely to change during early software releases change
less during later releases, and vice versa. This aspect helps to relate requirements changes to the software life cycle. The different occurrences of requirements changes throughout the life cycle points out some dependencies among
functional requirements. Understanding these dependencies may improve the
requirements process by effective changes allocation and impact analysis.
4 Requirements changes are expressed in percetage of the total number of changes occured
in the corresponding release
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
36
Product Perspectives into Requirements Evolution. Empirical results
point out that requirements evolution may be further understood if analysed
from a combination of a product viewpoint together with a process viewpoint.
Figure 3.13, for instance, shows a requirements evolution into which changes
fall down into two major categories: changes that have the authority to modify
delivered software; changes that are unauthorised to modify delivered software.
The latter consists of changes that affect associated functionalities, but only
documentation, traceability or non delivered code. Implementation may trigger
this type of change that usually adapts the documentation to the delivered code.
Figure 3.13: Classified requirements evolution.
The proportion between the number of requirements and the number of
changes occurring into requirements specifications provides an intuitive notion
of stability. Figure 3.14 shows a scatter plot of requirements size (in terms
of number of requirements) versus requirements evolution (in terms of number
of requirements changes). Intuitively, the functions below the mid line (i.e.,
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
37
number of requirements equalise number of changes) are more stable than the
functions above the line.
Figure 3.14: Scatter plot of number of requirements versus number of changes
for each software function.
It is furthermore interesting to look at the size of the sets of requirements
changes allocated for each software releases. Figure 3.15 shows the histograms
respectively for the set of changes affecting and non affecting delivered code.
The histograms provide information about the probability of the number of
changes occurring (or allocated) to a single release.
3.2.7
Requirements Dependencies
The analysis of requirements evolution per software function points out some
dependencies between functions. We have evaluated the dependencies between
software functions by the number of common fault reports arose during the software life cycle. The dependencies between two functions have been quantified
by the number of fault reports overlapping requirements changes. The underlying hypothesis implies that if two functions are modified due to the same fault
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
38
b. Changes not having permission
to change delivered code.
a. Changes having permission to
change delivered code.
Figure 3.15: Histograms of the size of the sets of requirements changes allocated
to a single software release.
report, then there are some dependencies between them. Table 3.2 shows the
dependencies matrix that has been obtained according the above assumption.
Table 3.2: Requirements dependencies matrix.
F1 F1
F2 2
F3
F4 3
F5 1
F6
F7
F8 1
F2
3
1
4
4
F3
1
2
3
F4
6
1
1
5
F5
1
1
9
F6
1
2
F7
F8
We take the number of fault reports in common between two functions as
Dependency Index between the corresponding requirements. For example, the
Dependency Index between the functions F4 and F8 is 5, which means that
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
39
there have been 5 fault reports in common between F4 and F8. The blank
entries in Tab. 3.2 mean that there are not common fault reports between
the corresponding crossing functions. The requirements dependencies matrix,
Tab. 3.2, gives a practical tool to assess to which extent software functional
requirements depend each other. Moreover it identifies those particular fault
reports that trigger changes into different functions. Thus an analysis of such
identified fault reports may give important information about requirements. In
order to provide feedback into the software organisation the matrix may be analysed to assess the ability of the organisation in identifying software functional
requirements for a system or a series of systems for a particular product-line.
A tool as the dependencies matrix supports software product-line engineering
[93]. Future refinements over product-line projects may identify an effective set
of modular system functions such that to reduce disturbing dependencies (e.g.,
Dependency Index equals to 1). Moreover the Dependency Index may be used
to refine impact changes estimates based on traceability.
3.2.8
Visualizing Requirements Evolution
The initial investigation provides input to model Requirements Evolution. This
section introduces our empirical model of Requirements Evolution and its process. Requirements Evolution is modelled according to three different aspects
aiming to classify, structure and quantify evolutionary features.
The backward reconstruction of the history of changes identify a structured
work flow of Requirements Evolution. This structure introduces a graphical
model that has been identified by reasoning on data repository of the case
study and by inspecting the requirements documents and their respective history of changes. The inspections of the requirements documents and history of
changes aimed to reconstruct how the documents have been modified through
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
40
the software life cycle by requirements changes. The graphical model shows a
representation of Requirements Evolution in terms of requirements changes (i.e.,
added, deleted and modified requirements) together with a software life cycle
perspective. Using a graphical representation is effective at presenting the overall picture of Requirements Evolution. The diagrammatic representation has
furthermore a more intuitive structure than any text-based representation and
this structure can be used to reflect how requirements are engineered through
the entire life cycle. Finally the graphical representation may allow to easily
identify similarities over functions and product lines. Requirements Evolution
can be expressed in terms of changes allocated to requirements releases. Before
representing Requirements Evolution in terms of changes, we need to define how
requirements are represented. They are organised in a document or a collection
of documents (one per each function) in which all requirements are uniquely
identified by a numeric id. Thus a requirements document can be considered
as a collection of sets of uniquely identified requirements. Among the set of
requirements there is a partial order defined by the numeric id. There are three
basic operations to change requirements. Figure 3.16 shows a graphical work
flow representation of the three operations, which are define in what follows.
Add: Add[n] introduces a subset of n new contiguous requirements ordered
according to their index into the current requirements document.
Delete: Del[n] deletes a subset of n contiguous requirements from the current
requirements document.
Modify: M od[n] modifies a subset of n contiguous requirements into the current requirements document.
Here n represents the size of the subset changed, whereas the specific changed
requirements are identified by the pointed subset in the middle of the three. The
c Massimo Felici, 2003
3.2. EMPIRICAL ANALYSIS
41
subset of m modified requirements is not identified by the graphical representation because the Mod operation does not actually change the structure of the
requirements document. Notice that even if the graphical representation in Fig.
3.16 is not formal, it implies some syntax and semantic, which are expressed by
the different shapes of the trees, the different edges and the order of the leafs
(i.e., subsets of requirements).
Figure 3.16: Graphical work flow representation of the basic operations to
changes requirements.
At this stage the graphical model aims just to intuitively capture the Requirements Evolution Process and its complexity. Figure 3.17 shows the representation of the work flow evolution for the function F1. The shape (even
without detailed information) of the requirement evolution captures the complexity of the Requirements Evolution process. The order of the operations is
c Massimo Felici, 2003
3.3. LESSONS LEARNED
42
left to right, hence the most left node is the initial set of requirements. The initial set of requirements is then modified by a sequence of basic operations (i.e.,
Add, Del, Mod). Requirements changes are allocated over different software
releases. The graphical representation of requirement evolution for the other
functions in the case study is more complex that that one, emphasising how the
structured work flow can easily capture the Requirements Evolution process. It
captures how requirements are changed throughout the software life cycle.
Figure 3.17: Graphical work flow representation of requirement evolution for
F1.
3.3
Lessons Learned
The case study provides us with an experience in investigating requirements
evolution in industrial contexts. On the one hand we faced the practical problem
of collecting evolutionary information. On the other hand we analysed the
evolutionary features of requirements. These two main points re discussed in
c Massimo Felici, 2003
3.3. LESSONS LEARNED
43
what follows.
3.3.1
Requirements Evolution in Practice
We faced some practical issues in the investigation of the case study. The issues
are not specific to the case study. Similar issues may arise in other case studies
and in different industrial contexts. The investigation relies on the case study’s
activities related to the management of requirements changes. The main issues
are discussed as follows.
Data Collection. Building a data repository of evolutionary data is a difficult
task. There are three main critical aspects that affect evolutionary data collections. From the process viewpoint, the collection of data should be an activity
well integrated into the development process. otherwise it will just increase
the workload throughout the development process. A non-well integrated data
collection will result not just in increased workload, but it will frustrate people
who are supposed to provide information. Moreover, a non-well-integrated data
collection will be dropped under the pressure of forthcoming deadlines. This
will result in a non-updated data repository, which will be reconstructed late
in the development process. Thus the feedback that evolutionary information
may have provided was unavailable when needed.
Data Organization. The organization of evolutionary data is another aspect
concerning an effective collection of evolutionary data. That is, the way data
are organised affects our ability to effectivelly analyse and identify evolutionary
features. Moreover, it will require further effort in order to understand any
emergent information.
c Massimo Felici, 2003
3.3. LESSONS LEARNED
44
Data Goals. Data collection should be organised having specific goals. Before
collecting any data we should answer few questions: Why are data collected?
Is any data analysis foreseen? What are the expected outcomes? Who will
review/read/use any (emergent) information? Answering these questions will
help in order to organise an effective data repository. For instance, if your
intention is to collect requirements changes by a simple history of changes in
order to show certification authorities that you have been keeping tracks of
requirements changes, you should expect any feedback into the development
process in order to improve your changes management activities. This is because
a simple history of changes may be suitable to show evidence of your data
collection activities, but it is not effective in order to provide feedback in the
development process by identifying evolutionary relationships.
Enhanced Visibility. The above issues related to requirements evolution affect project visibility. Little coordination between different organizational layers
may reduce the overall visibility within the project. Furthermore this will reduce
our ability to assess the impact of changes (or to perform any sensitivity analysis). We need to tackle the above issues in order to enhance our evolutionary
visibility and to identify a trade-off between process and product managements.
The former is useful to standardise computer-based systems development, but it
may reduce product visibility. The latter aims to enhance product features into
development processes, but it may reduce process repeatability across different
computer-based systems.
3.3.2
Requirements Evolution Features
This section summarises the outcomes of the empirical analysis of the case
study with respect to requirements evolution. The featured of requirements
evolution are strictly related to the specific case study. On the other hand
c Massimo Felici, 2003
3.3. LESSONS LEARNED
45
it is possible to identify similar features in other case studies across different
industrial contexts. The generality of the empirical investigation allows easily
to replicate the analysis. The main requirements evolution features are discussed
as follows.
Quantitative Requirements Evolution. The quantification of requirements
evolution requires a well-defined standard policy to classifying requirements
changes. The simplest types classify requirements changes according to the performed operations in the requirements specification documents. For instance,
add, delete and modify requirements are tree simple types of changes, which
respectively identify the activities of adding new requirements into the requirements specification, deleting requirements from the requirements specification
and modifying requirements in the requirements specification. The classification
of type of change should be supported by traceability information, which link
requests of changes with the requirements changes. The combination of type of
changes together with traceability information allow to quantify the evolution of
requirements specification. The combination of traceability and type of change
may easily quantify the impact of changes. Although this assessment is quite
important, it lacks information about the criticality of changes and history of
changes. Further refinements of the impact of changes should take into account
historical evolutionary information and requirements criticality.
Taxonomy of Requirements Evolution. The analysis of the history of
changes points out a taxonomy of requirements changes. It is possible to classify requirements changes. The resulting taxonomy may characterise not only
the specific case study, but also the specific industrial context. From the process viewpoint, a taxonomy may support the introduction of standard practice
across development environments. One of the main practical issues in keeping
c Massimo Felici, 2003
3.3. LESSONS LEARNED
46
tracks of changes is to uniformly identify them. Thus a taxonomy will help to
reduce the biases between different persons with different level of experiences
and different expertise. Hence the construction of taxonomy of requirements
evolution supports the process of monitoring requirements evolution towards
the standardisation of the work practice.
(Ageing) Requirements Maturity.
Any simple account of the maturity of
requirements may be misleading. Our experience shows that any estimation
(e.g., by the Requirements Maturity Index) of the requirements maturity shold
be carefully evaluated case by case. Any quantitative mesure of the requirements
maturity should be interpreted against the requirements management process
(e.g., priorization of requirements changes, certification constraints) and decision policy (e.g., allocation of requirements changes) in the specific case. On the
other hand the concept of “maturity” can be misleading and misunderstanding
for requirements. Future research should further investigate how to distinguish
berween different interpretations of requirements maturities. Further investifagions shuld address the link bitween stability, volatility and maturity. This
is because requirements volatility may be prefered than requirements stability
some times.
Another aspect is that Requirements Maturity should take into account is the
age of requirements. The elapsed time since requirements were introduced (or
modified) may be an important factor to refine any assessment of the maturity
of requirements. This kind of refinement allows better to link requirements with
the management process and more in general with the system life cycle.
Functional Requirements Evolution. The empirical investigation of the
case study points out that it is possible to identify change-prone requirents from
a functional viewpoint. The analysis emphasises the distribution of requirements
c Massimo Felici, 2003
3.3. LESSONS LEARNED
47
changes over the different function requirements and and over the entire life
cycle. Changes differently occur into functional requirements. A fanctional
viewpoint then identifies the stable and the volatile parts of the requirements.
This kind of information may be useful in order to identify reusable requirements
(e.g., stable requirements of the system architecture) as well as to devise product
lines ranging around variability points.
The functional viewpoint of requirements points out dependencies among
functional requirements. The analysis of functional dependencies may be useful in order to refine the assessment of the impact of changes. On the other
hand requirements dependencies may be further refined throughout subsequent
releases or similar projects.
Visualising Requirements Evolution. The case study points out our limited ability to visualise evolutionary requirements as well as requirements evolution. Our preliminary attempt of visualising requirements evolution stresses
that any visual representation should take into account evolutionary process
features (e.g., releases, life cycle perspectives, etc.) as well as product features
(e.g., type of requirements changes). Any visual representation of requirements
evolution should furthermore capture process complexity and similarity. That
is, a requirement is that a visual representation should enhance our ability
to assess the complexity of any evolutionary process and to compare different
evolutionary processes. These features may allow to identify new insights in
requirements evolution.
c Massimo Felici, 2003
Chapter 4
Modelling Requirements
Evolution
Requirements evolution of computer-based system has been little investigated
and still remains challenging for research and practice in requirements engineering. This is mainly due to the lack of methodologies and tools supporting
the analysis of requirements evolution. On the other hand the analysis and
collection of evolutionary data covering (short as well as long) life cycles of
computer-based systems are difficult tasks within evolving industrial settings.
This chapter introduces a framework for modelling evolutionary information
about requirements. The framework has been drawn from previous industrial
collaborations. Scenarios of use describe how the framework may be used in
practice to further understand and support requirements evolution.
48
4.1. INTRODUCTION
4.1
49
Introduction
Requirements evolution is an inevitable aspect of computer-based systems. Requirements evolve due to stakeholders as well as technical feedback (e.g., feedback from testing). Despite the recognised phenomenon requirements evolution
has been little investigated. This is partially due to the lack of methodologies and tools to acquire further understanding about requirements evolution.
Thus understanding requirements evolution becomes an expensive process that
most of the times industry can not afford due to lack of resources (in terms of
man-power). In spite of lack of methodologies and tools, previous investigations
[1, 2, 3, 4, 33, 69, 88] of requirements evolution have been successfully conducted.
Hence the provision of methodologies and tools for requirements evolution may
identify new insights in requirements engineering.
This chapter introduces a framework for modelling evolutionary information
about requirements. The framework is three-fold:
• a data model for requirements
• a classification scheme to identify evolutionary relationships about requirements
• a general requirements process.
The framework combines a product view of requirements together with a process
view. This paper explains the devised framework, which has been drawn and
motivated by previous industrial collaborations. The review of related literature
and the description of scenarios of use identify how the framework may help in
practice.
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
4.2
50
Modelling Requirements Evolution
This section introduces requirements related models motivated by the empirical
rationale of the previous section. The models take into account three main
viewpoints. The first one provides a data model for requirements. The second
one emphasises relationships related to the evolution of requirements. The third
one points out a process related model providing live cycle perspectives to the
other two models.
4.2.1
Data Model
Figure 4.1 shows a data model for requirements. The data model aims to clarify
some features that may characterise requirements evolution. Moreover, it is
useful to organise data collection. The data model is not so different from other
data models that can be drawn from Requirements Management Tools (e.g.,
Telelogic DOORS and Rational RequisitePro). But differently, it stresses the
classification of requirements evolution in terms of changes and taxonomy. This
section describes the main entities and relationships into the data model.
Requirements Change (RC). Requirements Change consists of the requests
of changes that have arisen in the project. The requests of changes will usually
be assessed and approved for implementation. Thus the entire set of request of
change can be refined into three subsets:
• the subset of request of changes, rc, approved for implementation into
further releases
• the subset of request of changes, rr, rejected
• the subset of request of changes, rv, that are still pending and that may
be eventually allocated to further releases (or rejected).
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
51
Figure 4.1: Entity Relationship model for Requirements.
Requirements changes can be classified according the operations (i.e., Type of
Change: Added, Deleted or Modified) that change the requirements document
and the classification of changes (i.e., Taxonomy of Change).
Type of Change represents the type of operation that a requirements change
implements. The three basic types are: Add, Delete and Modify.
Taxonomy of Change classifies the requests of changes according to context
oriented type of change. The previous section gives an example of Taxonomy of Change.
Changes Rationale. The rationale for changes represents the justification of
requests of changes. That is, changes rationale gives rise to requests of changes.
In mature environment, where there is a specified process managing changes, a
changes rationale may consist of a structured document reporting anomalies or
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
52
requests drawn from stakeholders.
History of Change. The History of Change consists of all changes approved
for implementation in subsequent releases of the Requirements Specification.
Requirements Specification. The specification consists of all active requirements.
Requirements. Requirements consist of all requirements identified for the
ongoing system. These requirements then may be allocated (activated) into a
Requirements Specification. Some requirements may be withdrawn by deleting
them from a Requirements specification. Requirements become active when
they are added to a Requirements Specification. Other requirements identified
for the system may stay dormant until they are approved for inclusion into a
Requirements Specification.
Requirements Attributes identify specific items that can be specified for
each requirement (e.g., variables, functionality, explanation, traceability
and dependency).
Requirements Viewpoints specify angles from which to analyse requirements
and their evolution (e.g. [69, 85].
Type of Requirement classifies requirements according to specific features
(e.g., stable or changeable [69]).
Figure 4.2 shows the different types of relations between data entities [51].
For instance, in Fig. 4.1, the History of Change has one or more Requirements Specification. Each Requirements Specification has zero or one History
of Change. The most general relationship is that one many-to-many that exists between Changes Rationale and Requirements Changes as well as between
Requirements Specification and Requirements.
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
53
Figure 4.2: Different types of relations between entities.
4.2.2
Evolutionary Relationships
The data model, Fig. 4.1, identifies the direct binary relationships between the
different entities into the model. The model provides a framework to identify
further relationships. This section introduces a scheme to identify further relationships across the data model. The aim is to classify relationships in order
to define a framework for the analysis of evolutionary features of requirements.
The framework supports a systematic analysis of requirements evolution. That
is, the framework provides a way to monitor and understand evolutionary features of requirements. The relationships are classified according to their arity
and type of involved items.
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
54
Binary Relationship. The binary relationships aim to understand how different items into the data model relate to each other. There are three main
types of relationships.
Size - Type. The classification of measurable features according to types can
provide further information to understand requirements and requirements
processes. For instance, Fig. 3.13 gives an example of this type of relationship. The number of requirements changes (i.e., Size) are classified
according to the type of change (i.e., Type). In the specific example, requirements changes are classified in two major types: changes that have
permission to modify delivered code; and changes that do not have permission to modify delivered code. The latter are changes that usually modify
documentations, traceability information and non delivered code. Figure
3.13 points out that this second type of requirements change may be triggered by implementation feedback. That is, after the code is delivered the
documentation is updated to comply with the actual implementation.
Size - Size. This type of analysis aims to identify relationships between different measures (of size) for the same entity. For instance, Fig. 3.14 analyses
the relationship between the number of requirements (i.e., Size) forming
a functional specification and the number of requirements changes (i.e.,
Size) occurred into the same functional specification. Figure 3.14 points
out that in general there is a linear relationship between the number of
requirements and the number of requirements changes occurring. Moreover, it points out outliers that may represent specific cases or “issues”.
The specific relationship also identifies an intuitive notion of Requirements
Stability, that is, functional specifications below the midline are stable and
the ones above the midline are unstable or changeable. The continuous
monitoring of this relationship during the entire life cycle may identify the
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
55
progress for each functional specification. This will help to see patterns
for functional specifications evolving from a stable status to an unstable
one and how quickly release after release a functional specification may
become unstable.
Type - Type. This kind of relationship may be seen as a combination of two
Size-Type relationships. For instance, the classification of requirements
changes according to a Taxonomy of change may give further information
if combined with a classification of changes occurring into delivered code.
That is, types of requirements changes mat be related to types of software changes. This information may be useful to filter particular types of
requirements changes in order to reduce corresponding types of changes
into software.
3-arity Relationship. The analysis of three different related items may point
out 3-arity Relationships. For instance, Fig. 3.15 show the histograms of the
size of sets of changes allocated to a single release and classified according to the
types of requirements highlighted in Fig. 3.13. The histograms allow to derive
the distributions (or probability) of the size of set of requirements changes. This
information may be used for future prediction assuming the observed distribution (e.g., Gaussian). Figure 3.15 provides an example of how 3-arity relationship obtained analysing evolutionary features drawn from the analysis of items
into the data model, Fig. 4.1.
4-arity Relationship. The need for 4-arity relationships is questionable. The
systematic analysis of simple relationships may point out how to combine them
in order to obtain the most complex ones. The underlying idea is to devise
a constructive framework of relationships. This may enhance our ability to
analyse requirements evolution.
c Massimo Felici, 2003
4.2. MODELLING REQUIREMENTS EVOLUTION
4.2.3
56
Requirements Process
This section stresses a life cycle perspective. The emphasis is on the continuous monitoring of the information drawn from the modelling introduced in the
previous sections. Figure 4.3 shows an ideal requirements process. A sequence
of processes, P0 , P1 , . . ., (representing iterations of phases of any development
process, e.g., [45]) modifies the Requirements Specification, RSi , by injecting
set of changes rci selected from the set of proposed changes RCi−1 .
...
?
P2
6
...
RSn
-
?
P1
6
P0
RS1
rc
2
rc
1
-
RS1
rv
rv
2
1
-
-
RC1
RC2
...
RCn
Figure 4.3: An ideal requirement process.
It is easy to represent Requirements Specification and Requirements Change
as sets. Hence, the following definitions apply.
Definition 1 The size of set of requirements changes is monotonically increasing, that is,
RC1 ⊆ RC2 ⊆ . . . ⊆ RCn =
[
rv i .
i
Definition 2 The changes allocated to subsequent requirements specifications
is a subset of the proposed requirements changes, that is,
[
i
c Massimo Felici, 2003
rci ⊆
[
i
rv i
4.3. SCENARIOS OF USE
57
Definition 3 The set of stable requirements is the intersection of the subsequent
requirements specifications, that is,
Stable Requirements =
\
RS i
i
The above definitions and the ideal requirements process aim to identify
specific milestones during the requirements process in which to assess the relationships identified in the previous sections. The underlying idea is to provide
a description of the requirements process that may allow reasoning on specific
properties (e.g., identifying stable requirements). The specification of the requirements process is really simple at this stage. Future work aims to devise a
richer description of the requirements process than that one this section introduces.
4.3
Scenarios of Use
This section describes scenarios of use for the modelling introduced in the previous section. The scenarios are drawn from industrial collaborations and experience. The framework can be used in three different ways: Evolutionary
Classification, Process Calibration and Requirements Featuring.
Evolutionary Classification. Figure 4.4 shows the information flow that combines the knowledge acquired by collecting evolutionary information about
requirements together with the process information in order to identify
evolutionary features of requirements.
Process Calibration. Figure 4.5 shows the information flow that combines
the knowledge acquired collecting evolutionary information about requirements together with the characterisation of requirements evolution in order to calibrate the requirements process.
c Massimo Felici, 2003
4.3. SCENARIOS OF USE
58
Figure 4.4: Evolutionary Classification.
Figure 4.5: Process Calibration.
Requirements Featuring. Figure 4.6 shows the information flow that combines the characterisation of requirements evolution together with the
process information in order to analyse and characterise evolving requirements.
The remaining of this section explains the three scenarios by means of examples drew from industry.
Subsequent Releases. The first scenario, Fig. 4.4, applies to those cases in
which a product is developed over subsequent releases. Practice shows that this
is always the case. The evolutionary information collected in previous projects
c Massimo Felici, 2003
4.3. SCENARIOS OF USE
59
Figure 4.6: Requirements Featuring.
together with a selected requirements process (distributing changes over subsequent releases) may provide a prediction of the expected evolutionary relationships in ongoing similar projects. That is, previous experience may be useful
for future projects developing a similar system (e.g., for the same customer).
The evolutionary prediction may allow to effectively improve the requirements
process in order to reduce rework and the risk of faults introduction. Moreover, having information like “Requirements Dependencies” will allow to better
plan subsequent development phases, e.g., coding and testing. Evolutionary information will furthermore be useful to meet stringent certification constraints
requiring changes management.
Product Line Establishment. Evolutionary information may be useful in
establishing a new product line. For instance, let us assume that there is a
company producing similar systems (e.g., smart card systems) having to some
extent different functionalities. In order to reduce the production cost of each
system it may be useful to establish a product line. The new product line will
cover a set of similar systems having a common core set of requirements (e.g.,
architecture requirements) and differencing each other by other requirements
(e.g., interface requirements). In order to establish the requirements for the new
c Massimo Felici, 2003
4.3. SCENARIOS OF USE
60
product line it is necessary to know some information about the nature of the
requirements themselves. Information about the stability of the requirements
may help to identify the core set of requirements characterising the new product
line. Whereas the changeable requirements will identify variability requirements
of the new product line. Hence, requirements for a specific system of the product
line will be derived by merging the core requirements of the product line together
with requirements specifying the variability ones. Furthermore, evolutionary
information together with requirements classifications may help to identify (or
calibrate) a requirements process for the new product line (Fig. 4.5).
Functional Portfolio. Companies producing related (or similar) systems may
want to improve their requirements process by reusing requirements in order to
reduce the effort needed in specifying them. Moreover, system requirements often represent the knowledge acquired by many years of experience in producing
system within specific industrial contexts (e.g., avionics, automotive, telecommunication, etc). Classifying requirements according to evolutionary information (and the requirements process), Fig. 4.6, may be a corporate strategy to
systematically reuse this knowledge into future projects. The knowledge acquired by classifying requirements and monitoring the classification itself may
help to maximise requirements reuse. For instance, evolutionary information
about requirements may help to clarify and/or identify situation in which, e.g.,
a new customer has new requirements (i.e., new for the organisation); a new
customer has old requirements (i.e., already implemented in previous projects);
an old customer has old requirements; or and old customer has new requirements. Being able to identify these cases is important to improve requirement
reuse. Moreover, this information may be used to refine feasibility estimation
at the beginning of new projects.
c Massimo Felici, 2003
4.4. CONCLUSIONS AND FURTHER WORK
4.4
61
Conclusions and Further Work
This chapter introduces a framework for modelling evolutionary information
about requirements. The framework supports the understanding of requirements evolution for computer-based systems. Scenarios drew from industry
help to understand how it may be used in practice. The empirical rationale for
the framework and the description of the framework can be already beneficial
to conduct related investigations within industrial contexts.
Further work aims to: refine the framework by selecting specific metrics to
estimate evolutionary features of requirements [4]; enrich the process specification for the framework in order to allow reasoning on evolutionary features
of requirements; devise a tool implementing the framework; conduct validation
experiments within industrial case studies; build a repository of examples for
the framework.
c Massimo Felici, 2003
Chapter 5
Taxonomy of Evolution and
Dependability
Evolution is one of the major issues affecting system dependability as well as
engineering activities and environments. The most common understanding considers evolution as a phenomenon that needs to be avoided. By contrast this
report takes into account evolution as a necessary feature of computer-based
systems. This chapter reviews a taxonomy of evolution identifying a conceptual framework to analyse evolutionary phenomena of computer-based systems
as well as models of evolutions and their limits. The taxonomy of evolution
points out different dependability aspects of computer-based systems. In conclusion, this chapter provides a conceptual framework to analyse evolution and
its influence on the dependability of computer-based systems.
62
5.1. INTRODUCTION
5.1
63
Introduction
Computer-based systems are evolving citizens of the modern electronic mediated
society. They are continuously (re)designed and (re)deployed in order to capture
environmental evolution. Development life cycles in software system engineering
recognise the need to capture evolution by iterative processes. Evolution of
computer-based systems is a twofold concept. On the one hand evolution is an
inevitable and a needed aspect of computer-based systems. On the other hand
the degradation of the dependability of computer-based systems may be due to
evolution and it may cause, in the worst case, catastrophic failures [56, 67, 89].
The relationship between Evolution and Dependability is still vaguely understood. This is because evolution and dependability are both complex concepts.
There could be many different definitions of evolution that apply to computerbased systems. Evolution can occur from the early stages of a system (e.g.,
requirements evolution) to its deployment, use and decommission (e.g., corrective or perfective maintenance). The existence of different (definitions of)
evolutions is often misunderstanding and it gives rise to practical issues as well.
Dependability is defined as that property of a computer system such that reliance can justifiably be placed on the service it delivers [49, 50]. With respect
to the dependability of computer-based systems evolution may be a means to increase it. On the other hand evolution is also a major source of undependability
for computer-based systems.
This chapter takes account of the evolution of computer-based systems. Section 2 reviews a taxonomy of evolution identifying a conceptual framework to
analyse different evolutionary phenomena of computer-based systems. Section
3 points out how the evolutionary phenomena differently relate to the dependability of computer-based systems. In conclusion, this chapter provides a conceptual framework to analyse evolution and its influence on the dependability
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
64
of computer-based systems.
5.2
Taxonomy of Evolution
This section reviews a taxonomy of evolution of computer-based systems. Figure
5.1 shows the evolutionary space drew by the taxonomy.
Figure 5.1: Evolutionary space.
The two dimensions of the evolutionary space are:
from Evolution in Design to Evolution in Use - stressing the life cycle perspective (or, temporal dimension), i.e., evolution can occur during different
phases of a system life cycle, since design until deployment, use and further on.
from Hard Evolution to Soft Evolution - stressing where in the system evolution
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
65
takes place (or, physical dimension).
A point within the evolutionary space represents a tradeoff among different
evolutionary phenomena. The main evolutionary phenomena forming the evolutionary space are:
Software Evolution takes account of evolution from a product viewpoint.
Architecture (Design) Evolution describes how evolution is perceived at the
design level.
Requirements Evolution represents an intermediate viewpoint. Requirements
are used as a means of interaction between stakeholders, thus requirements
represent a natural place where to capture information about the evolution
of computer-based systems.
Computer-based System Evolution takes into account a systemic viewpoint that
emphasises human factors with respect to evolution.
Organization Evolution emphasises the interaction between the computer-based
system and the surrounding environment.
Notice that the evolutionary phenomena may overlap one another. Thus they
need to be instantiated case by case. These five different evolutionary phenomena have some similarities with other reference models (e.g., [31, 68]) that
categorise and structure engineering aspects of computer-based systems. The
remains of this section describe the different phenomena forming the taxonomy
of evolution.
5.2.1
Software Evolution
The problem of software evolution has been extensively investigated by Lehman
et al [54, 55]. The investigation of software evolution as a natural phenomenon
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
66
has lead to the identification of the E-type programs (i.e., software systems).
According to the Lehman’s laws of software evolution, E-type programs continuously evolve in order to be satisfactory (for users) and (need) to accommodate
environmental changes. E-type programs have an increasing complexity if maintenance is not performed. They represent multi-level, multi-loop, multi-agent
feedback systems. In spite of the progress in software engineering managing
evolution is still challenging [53]. Software evolution (and in general evolution)
is often considered just a management issue [92] having little emphasis on software evolutionary features. Recent research in Object-Oriented software [28]
stresses that a product viewpoint may enhance our understanding of software
evolution. Three main patterns of evolutions have been identified:
Software Tectonics emphasises that software systems need to accommodate
arising changes. It will involve not just fixing bugs, but also fixing flaws
introduced early in the design. Hence software has to be implemented in
order to support evolution, otherwise software changes will just increase
software complexity and destroy fundamental software structures. Moreover, software systems should be adaptable to requirements changes by a
series of small and controlled steps in order to avoid software degradation.
Flexible Foundations catalogues the need to construct systems out of stuff that
can evolve along with them. That is, the basics (e.g., tools, languages,
frameworks, etc.) of each system should be able to evolve themselves in
order to support the software system evolution as a whole. Notice that
the Flexible Foundations pattern focuses on the system’s infrastructure
(or architecture) and not on the specific implementation code.
Metamorphosis shows how equipping systems with mechanisms that allow
them to dynamically manipulate their environments can help them better
to integrate in these environments in order to fulfil evolving requirements.
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
67
There exist different mechanisms supporting the Metamorphosis pattern.
For instance, extendible systems allow users to add new features. Differently mutable systems allow users to change their existing features.
Software Metrics may capture evolutionary properties of software and relate
them to software quality [26, 37, 38, 40, 79]. Metrics quantify how software has
been modified, e.g., in terms of Lines Of Code (LOC). Specific metrics assess
software reliability and probabilistic models, namely Reliability Growth Models,
predict the evolution of software reliability [60]. With respect to evolution Software Reliability Growth Models present some applicability limits [23, 59]. The
basic assumptions (e.g., features of the models inadequately fit real conditions
in software development processes.
In spite of the limits of quantitative approaches recent research [5, 15, 30, 43]
in empirical Software Engineering has emphasised how the use of specific quantitative models may estimate evolutionary software features. Antoniol at al. in
[5] propose a quantitative model in order to estimate the size of changes for
evolving Object-Oriented systems. The model has been assessed and evaluated
on a case study. Coleman et al. in [15] use software metrics to evaluate the
maintainability of 11 industrial software systems. Their experience points out
that even simple models may support the decision making process at different
stages of the software life cycle. Graves et al. in [30] devise different statistical
models to evaluate the likelihood of faults introduced into modules based on
the history of changes. The results emphasise the relationship between software
changes and faults. Moreover, they evaluate the proposed models in order to
assess their performance and accuracy. Kemerer and Slaughter in [43] propose
an empirical approach to studying software evolution. They furthermore emphasise how it is difficult to conduct empirical analyses on software evolution
due to the lack of evolutionary data.
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
5.2.2
68
Architecture (Design) Evolution
At the design level, the role of the system architecture may be unclear with
respect to evolution. Architecture evolution is risky if it is not controlled around
specific variation points that may characterise product lines [12], even if the
evolutionary process and the architecture are well defined and understood [46,
82]. The architectures of product lines [12, 93] represent the extent to which
system families can capture future needs. Our ability to predict evolution is
therefore crucial in the definition of product lines. The architecture should
implement the most suitable trade off between generality and specificity.
Although the architecture is so important, its evolution may be misleading.
There exist in general two (three) types of evolutions: the architecture evolves
or its components evolve (everything evolves). Despite what people may think
about the architecture’s evolution, empirical results [1] show that the architecture is a stable part of those systems that have stringent safety and security
requirements (constraints). Related research in requirements engineering [69]
supports these empirical results by emphasising that stable requirements have
origin in the business core. The more constrained is the business, the more evident is the relation between the architecture’s stability and the business core.
Further progress [62] on the evolution of Object-Oriented architectures supports
these results by stating that: “...A software architecture is a collection of elements that share the same likelihood of change. Each category contains software
elements that exhibit shared stability characteristics. ...A software architecture
always contains a core layer that represents the hardest layer of change. It Identifies those features that cannot be changed without rebuilding the entire software
system.”
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
5.2.3
69
Requirements Evolution
Requirements evolution has been mainly considered a management problem,
rather than a feature of computer-based systems. Requirements Engineering
literature has little emphasis on software evolutionary features [36, 77, 85, 94].
Despite this empirical analyses of industrial case studies point out that it is
impossible to frozen requirements, but it is possible to analyse the extent to
which requirements evolve in order to identify the stable ones and the most
likely to change [1, 2, 3, 35, 36, 69, 88]. Since its recognition Requirements
Engineering has received an increasing interest within Software Engineering and
has acquired a multiperspective role towards model-based software engineering
[90]. There exist structures that support the construction of models towards
Requirements Evolution.
Types of Requirements allow to classify the origins of stable and changing
requirements and to identify a conceptual framework for changing requirements [69]. The Proteus Project [69] suggests three main strategies
dealing with requirements changes. The proposed strategies are reducing
changes, facilitating incorporation of changes and identifying needs for
changes as early as possible. These strategies make use of enabling technologies like predictive analysis of changes, traceability of requirements,
formal framework for representing and reasoning about changes, and prototyping. Guidelines and checklists support the strategies dealing with
requirements changes.
Dependencies between Requirements [3] may be redefined across subsequent
releases in order to minimise them and effectively to assess the impact of
changes.
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
70
Types of Changes,e.g., adding, deleting and modifying requirements, define
how changes alter requirements specifications. It is possible to quantify
requirements evolution by counting occurring (types of) changes. Requirements specification templates (e.g., [39, 76, 77]) may identify other (types
of) attributes that are worthwhile monitoring in order to understand requirements evolution.
further refinements of documents as well as analyses.
Requirements Traceability [19, 20, 41, 70] provides further information to analyse requirements evolution, but it is insufficient. Requirements traceability
is an important aspect to deal with evolution [7, 41]. Traceability represents not only an additional information to be collected (and maintained),
but also a strategic policy involving an entire software organisation [70].
Traceability maintenance consists of strict processes and tools, which allow to identify relationships between the software organisation and the
software product [41]. We can then enhance our ability to specify and
to represent requirements evolution by combining traceability with other
evolutionary information.
We can then represent requirements evolution in terms of the above structures.
The combination of structured requirements evolution together with formal requirements specifications [69, 29, 96] may be useful in order to support formal
as well as quantitative reasoning on requirements evolution. The integration of
formal requirements specifications with empirical information is still challenging
in requirements engineering. There are still few quantitative approaches that
successfully capture requirements evolution [1, 4, 37, 38, 81]. The lack of practical experience in monitoring long term information and the lack of evolutionary
data often limit our ability in monitoring and understanding evolution as well
as to estimate the cost of changes [9, 10, 11].
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
5.2.4
71
Computer-based System Evolution
The term “computer-based system” emphasises the human aspects within sociotechnical systems. Computer systems (consisting of hardware and software) do
not exist in isolation. They are part of the information society. On the other
hand, an holistic view of computer-based systems may identify and better understand the drivers for evolution. For instance, figure 5.2 shows the SHEL model
[21], which defines any productive process as performed by a combination of
Hardware (e.g., any material tool used in the process execution), Software (e.g.,
procedures, rules, practices, etc.) and Liveware (e.g., end-users, managers, etc.)
resources embedded in a given Environment (e.g., socio-cultural, political, etc.).
Thus, any process requires some knowledge that is distributed among the system resources. Hence a productive process may be regarded as an instantiation
of the SHEL model for a specific process execution. An holistic view, like that
of the SHEL model, emphasises how drivers for software evolution may reside
outside software artefacts. On the other hand evolution across resources may
allow new artefacts to emerge as resulting behaviour of the evolved systems.
The link between technical evolution and socio evolution of computer-based
systems has not yet been fully registered. It still remains vaguely understood
and challenging for research and practice [14]. There is not any model that
fully specifies the evolution of socio-technical systems. To some extent we can
represent the evolution of socio-technical systems by collections of models, which
do not complement each other in most of the cases.
Few models arose in order better to understand human factors with respect
to computer-based system evolution. For instance, Social Learning [95] explains
how human beings perceive machines in order to acquire computational artefacts
and accomplish specific tasks. Social Learning consists of two main processes:
Innofusion is a practical activity of learning by trying [27] that allows to cus-
c Massimo Felici, 2003
5.2. TAXONOMY OF EVOLUTION
72
Figure 5.2: The SHEL model.
tomise the computational artefacts (behind a computer-based systems) to
meet social needs. The underlying hypothesis is that workers, individually
as well as collectively, develop more efficient ways of employing machinery
through their experience from usage. This kind of learning curve effect
is well-known. Though often taken to be limited to the initial introduction of new equipment, it is now recognised that learning by doing may
improve the efficiency of production over a very long period of time.
Domestication addresses the creative role of the user in integrating new artefacts within their everyday activities and meanings. Domestication, where
people learn by situated activity, is a practical activity of learning by interacting. This activity stresses the complex interaction between technology
supply and use by applying evolutionary metaphors of the generation of
variation and selection of artefacts.
Distributed Cognition [64] recognises the complex settings of socio-technical
c Massimo Felici, 2003
5.3. ON THE DEPENDABILITY OF EVOLUTION
73
systems and analyses how humans work, operate and create external and internal artefacts. This approach re-elaborates the long lasting thesis that human
cognition is mediated by artefacts (e.g., rules, tools, representations, etc.) that
are both internal and external to the mind. The central tenet of the Distributed
Cognition approach is that knowledge is distributed across people and artefacts;
cognition is not a property of individuals but rather a property of a system of
individuals and artefacts carrying out some activity. According to these theoretical assumptions, human activities and artefacts are the two inseparable sides
of the same phenomenon: human cognition.
The above models are quite useful in order holistically to analyse the evolution of computer-based systems. But they still need to be fully integrated
with classical engineering methodologies (e.g., those reviewed in the previous
subsections).
5.2.5
Organization Evolution
The previous sections point out the strong connection between technical and
social aspects of computer-based systems (or socio-technical systems). The evolution of socio-technical systems influences the organizational context as well.
Thus system evolution implies an organization co-evolution, and vice versa.
The mechanisms driving organization evolution characterise the new electronic
mediated society [13, 14, 57]. The link between socio-technical evolution and
organization evolution has not been yet fully registered. It is still challenging
for future research and practice.
5.3
On the Dependability of Evolution
Dependability models capture evolution in different ways. For instance, fault
tolerance models [50, 71] rely on failure distributions (e.g., Mean Time Between
c Massimo Felici, 2003
5.3. ON THE DEPENDABILITY OF EVOLUTION
74
Failures) for computer-based systems. Monitoring this type of measure allows
to characterise the evolution of system properties (e.g., Reliability, Availability, etc.). Probabilistic models [60] may predict how dependability measures
evolve according to the estimations of attributes and the assumptions about the
operational profile of the system.
By contrast other models link dependability features with system structures
and development processes (e.g., [58, 59]). This allows us to link failure profiles
with design attributes (e.g., diversity) and system structures (e.g., redundancy).
Structured models (e.g., FMEA, HAZOP, FTA) assess the hazard related to system failures and their risk [89]. These models extend the Domino model, which
assumes that an accident is the final result of a chain of events in a particular
context [34]. Similarly the Cheese model consists of different safety layers having evolving undependability holes. Hence system failures completely arise and
become catastrophically unrecoverable when they propagate throughout all the
safety layers in place [72]. Despite of these models capture a dynamic view of
system failures, they do not capture evolution.
The evolutionary phenomena presented in the previous section differently
contribute to dependability. Table 5.1 summarises the different dependability
evolutionary perspectives. The taxonomy of evolution points out that each
methodology has different assumptions about the evolution of computer-based
systems. This may trigger practical issues related to evolution:
Inconsistency: The basic assumptions of all adopted models (in order to
characterise system dependability) may be inconsistent all together.
Coverage: The entire spectrum of models may be insufficient to cover all
evolutionary aspects of system dependability.
Relational: The different evolutionary phenomena relate to each other. It is
difficult to understand the different relationships between the evolutionary
c Massimo Felici, 2003
5.4. CONCLUSIONS
75
phenomena.
Emergent: New (or unexpected) system features may emerge from the different evolutionary phenomena.
The relationships between the evolutionary phenomena may identify a framework for analysing the evolution of computer-based systems. If the coordination
between evolutionary phenomena is too weak, dependability may deteriorate.
On the other hand evolutionary phenomena introduce diversity and may prevent
system failures. Table 5.1 proposes some engineering hints in order to construct
an evolutionary framework. The resulting framework may classify evolution for
computer-based systems. The framework may furthermore provide evidence of
the relationships between the different evolutionary phenomena and relate them
to dependability. Notice that it is difficult to capture and analyse evolutionary
data, because they are usually incomplete, distributed, unrelated and vaguely
understood. The resulting evolutionary framework may support the empirical
process as well. A taxonomy of evolution is then a starting point to understand
how computer-based systems evolve.
5.4
Conclusions
Software evolution represents just one aspect of the evolution of computer-based
systems. This paper describes a taxonomy of evolution: Software Evolution, Architecture (Design) Evolution, Requirements Evolution, Computer-based System
Evolution, Organization Evolution. It provides a holistic viewpoint in order to
analyse and to understand the evolution of computer-based systems. The taxonomy points out the different aspects and drivers for the evolution of computerbased systems. The review of different models and methodologies that take into
account the evolution of computer-based systems is useful to further under-
c Massimo Felici, 2003
5.4. CONCLUSIONS
76
Table 5.1: Dependability perspectives of Evolution.
Evolution
Software
Evolution
Architecture
(Design)
Evolution
Requirements
Evolution
Computerbased
System
Evolution
Organization
Evolution
Dependability Perspective
Software evolution can affect dependability attributes (e.g., Reliability). Nevertheless software evolution can improve dependability attributes by faults removal
and maintenance to satisfy new arising requirements.
Architecture evolution is usually an expensive phenomenon. It does not affect
directly dependability, but there is high
risk if the evolution process is unclear and
little understood. Architecture evolution
may be needed to support specific system
properties (e.g., redundancy, performance,
etc.).
Requirements evolution does not directly
affect dependability, but non-effective
management of the requirement process
may allow undesired changes to fall down
into the product affecting its dependability. On the other hand requirements evolution may enhance system dependability
across subsequent releases.
System evolution may give rise to undependability. This is due to incomplete evolution of system resources. Evolution of
some resources (e.g., software) should be
taken into account by the other resources
(e.g., liveware and hardware) in order to
register a new configuration for the system. Hence the interactions among resources serve to effectively deploy a new
system configuration.
On the other hand human can react and
learn how to deal with undependable situations, but continuous changes in the system configuration may give rise to little
understanding about the system. Hence
the human-computer interaction may become quite undependable as well.
Organization evolution should reflect system evolution. Little coordination between system evolution and organization
evolution may give rise to undependability.
Engineering Hint
Monitor software complexity; Identify the changeprone parts of the software;
Carefully manage basic software structures; Monitor
dependability metrics.
Assess the stability of the
software architecture; Understand the relationship
between the architecture
and the business core;
Analyse any (proposed or
implemented) architecture
change.
Classify
requirements
according to their stability/volatility;
Classify
requirements changes; Monitor requirements evolution.
Acquire a systemic view
(i.e., Hardware, Software,
Liveware
and
Environment); Monitor the interactions between resources;
Understand
evolutionary
dependencies;
Monitor
and analyse the (human)
activities supported by the
system.
Understand environmental
constraints; Understand the
business culture; Identify
obstacles to changes.
stand and stress the relationship between system evolution and dependability.
The different assumptions about the evolution of computer-based systems may
c Massimo Felici, 2003
5.4. CONCLUSIONS
77
trigger practical issues affecting system dependability:
Inconsistency: The basic assumptions of all adopted models (in order to
characterise system dependability) may be inconsistent all together.
Coverage: The entire spectrum of models may be insufficient to cover all
evolutionary aspects of system dependability.
Relational: The different evolutionary phenomena relate to each other. It is
difficult to understand the different relationships between the evolutionary
phenomena.
Emergent: New (or unexpected) system features may emerge from the different evolutionary phenomena.
The dependability analysis with respect to evolution identifies a framework. The
engineering hints related to each evolutionary phenomenon may serve as basics
in order empirically to acquire a taxonomy of evolution. The idea of the taxonomy of evolution has originated from previous experiences and collaborations.
Future work aims to acquire practical experiences by using the the framework
in industrial case studies. In conclusion, the taxonomy of evolution represents
a starting point to analyse evolving computer-based systems. It draws a framework in order to further understand how computer-based systems evolve. It
provides a holistic viewpoint that suggests future directions for research and
practice on computer-based system evolution.
c Massimo Felici, 2003
Chapter 6
Conclusions and Future
Work
This report enhance our understanding about requirements evolution for computerbased systems. The results drew by this work are three-fold.
Empirical Results. The work shows the empirical investigation of requirements evolution. The empirical results enhance our understanding of requirements evolution. They support our basic hypothesis that requirements evolution
may be considered a feature of computer-based systems. This encourages further empirical studies in order to acquire experiences within different industrial
contexts.
Modelling Basics. The different ways of representing and modelling requirements evolution identify a framework for modelling requirements evolution. The
framework is still in a pre-mature stage, but it identifies different milestones towards enhanced requirements evolution.
78
6.1. FUTURE WORK
Requirements Evolution Practice.
79
Although the outcomes of this work
have been little validated by industrial use, they stress how it is important to
take into account requirements evolution in practice. This should encourage
practitioners in establishing pilot projects in order to investigate requirements
evolution within specific industrial contexts. The empirical results clearly show
that the work is worthwhile.
6.1
Future Work
Each chapter of this report identifies research and practical issues related to
requirements evolution. There is still a lot of work that needs to be done towards requirements evolution. We encourage to undertake future work that
may be inspired by this report. Among many potential research and practice
directions we would like to emphasise two of them. Firstly, Modelling requirements evolution will support the entire system life cycle. It shall furthermore
help to acquire new insights that may further enhance our understanding of requirements evolution and completely change the way we design computer-based
systems. Secondly, tools support is a means (probably the only one) in order to
transfer knowledge into practice. Tools supporting the requirements phases still
lack of functionalities enhancing our ability to analyse evolutionary features.
The provision of tool supported evolutionary analysis will help practitioners
to adopt requirements evolution concepts. Furthermore, usage of requirements
evolution tools/models will drive future research in requirements evolution.
c Massimo Felici, 2003
Bibliography
[1] Stuart Anderson and Massimo Felici. Controlling requirements evolution:
An avionics case study. In Proceedings of SAFECOMP 2000, 19th International Conference on Computer Safety, Reliability and Security, LNCS
1943, pages 361–370, Rotterdam, The Netherlands, October 2000. SpringerVerlag.
[2] Stuart Anderson and Massimo Felici. Requirements changes risk/cost analyses: An avionics case study. In M.P. Cottam, D.W. Harvey, R.P. Pape,
and J. Tait, editors, Foresight and Precaution, Proceedings of ESREL 2000,
SARS and SRA-EUROPE Annual Conference, volume 2, pages 921–925,
Edinburgh, Scotland, United Kingdom, May 2000.
[3] Stuart Anderson and Massimo Felici. Requirements evolution: From process to product oriented management. In Proceedings of Profes 2001, 3rd
International Conference on Product Focused Software Process Improvement, LNCS 2188, pages 27–41, Kaiserslautern, Germany, September 2001.
Springer-Verlag.
[4] Stuart Anderson and Massimo Felici. Quantitative aspects of requirements
evolution. In Proceedings of the 26th Annual International Computer Software and Application Conference, COMPSAC 2002, pages 27–32, Oxford,
England, 2002. IEEE Computer Society.
80
BIBLIOGRAPHY
81
[5] G. Antoniol, G. Canfora, and A. De Lucia. Estimating the size of changes
for evolving object oriented systems: A case study. In Proccedings of the
Sixth International Symposium on Software Metrics, METRICS ’99, pages
250–259, Boca Raton, Florida, November 1999. IEEE COmputer Society.
[6] Lowell Jay Arthur. Rapid Evolutionary Development: Requirements, Prototyping & Software Creation. John Wiley & Sons, 1992.
[7] K. Suzanne Barber et al. Requirements evolution and reuse using the
systems engineering process activities (sepa). Australian Journal of Information Systems (AJIS), 7:75–97, 1999. Special Issue on Requirements
Engineering.
[8] Daniel M. Berry and Brian Lawrence. Requirements engineering. IEEE
Software, pages 26–29, March 1998.
[9] Barry W. Boehm. Software Engineering Economics. Prentice-Hall, 1981.
[10] Barry W. Boehm. Software engineering economics. IEEE Transaction on
Software Engineering, 10(1):4–21, January 1984.
[11] Barry W. Boehm et al. Software Cost Estimation with COCOMO II.
Prentice-Hall, 2000.
[12] Jan Bosch. Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach. Addison-Wesley, 2000.
[13] David Bustard, Peter Kawalek, and Mark Norris, editors. Systems Modeling
for Business Process Improvement. Artech House, 2000.
[14] Elayne Coakes, Dianne Willis, and Raymond Lloyd-Jones, editors. The
New SocioTech: Graffiti on the Long Wall. CSCW. Springer, 2000.
c Massimo Felici, 2003
BIBLIOGRAPHY
82
[15] Don Coleman, Dan Ash, Bruce Lowther, and Paul Oman. Using metrics
to evaluate software system maintainability. IEEE Computer, 27(8):44–49,
August 1994.
[16] CREWS Project. Cooperative Requirements Engineering With Scenarios.
http://sunsite.informatik.rwth-aachen.de/CREWS/.
[17] CSEG.
Computing
Cooperative
Systems
Department,
Engineering
Lancaster
Group,
University,
http://www.comp.lancs.ac.uk/computing/research/cseg/.
[18] Alan M. Davis and Pei Hsia. Giving voice to requirements engineering.
IEEE Software, pages 12–16, March 1994.
[19] Giorgio De Michelis et al. A three-faceted view of information systems.
Communications of the ACM, 41(12):64–70, December 1998.
[20] Ralf Dömges and Klaus Pohl.
Adapting traceability environments to
project-specific needs. Communications of the ACM, 41(12):54–62, December 1998.
[21] E. Edwards. Man and machine: Systems for safety. In Proceedings of British
Airline Pilots Associations Technical Symposium, pages 21–36, London,
1972. British Airline Pilots Associations.
[22] Massimo Felici. Taxonomy of evolution and dependability. In Proceedings of
the Second International Workshop on Unanticipated Software Evolution,
USE 2003, page to appear, Warsaw, Poland, April 2003.
[23] Massimo Felici, Alberto Pasquini, and Mark-Alexander Sujan. Applicability limits of software reliability growth models. In MMR’2000, Deuxième
Conférence Internationale sur les Méthodes Mathématiques en Fiabilité:
c Massimo Felici, 2003
BIBLIOGRAPHY
83
Méthodologie, Pratique et Inférence, volume 1, pages 397–400, Bordeaux,
France, July 2000.
[24] Massimo Felici, Mark-Alexander Sujan, and Maria Wimmer.
Integra-
tion of functional congnitive and quality requirements: A railways case
study. In Katrina Maxwell, Rob Kusters, Erik van Veenendaal, and Adrian
Cowderoy, editors, Project Control: The Human Factor. Proceedings of
ESCOM-SCOPE 2000, pages 395–403, Munich, Germany, April 2000.
[25] Massimo Felici, Mark-Alexander Sujan, and Maria Wimmer. Integration
of functional congnitive and quality requirements. A railways case study.
Information and Software Technology, 42(14):993–1000, November 2000.
[26] Norman E. Fenton and Shari Lawrence Pfleeger. Software Metrics: A
Rigorous and Practical Approach. International Thomson Computer Press,
second edition, 1996.
[27] James Fleck. Learning by trying: the implementation of configurational
technology. Research Policy, 23:637–652, 1994.
[28] Brian Foote and Joseph Yoder. Evolution, architecture, and metamorphosis. In John M. Vlissides, James O. Coplien, and Norman L. Kerth, editors,
Pattern Languages of Program Design 2, chapter 13. Addison-Wesley, 1996.
[29] Aditya K. Ghose. Managing requirements evolution: Formal support for
functional and non-functional requirements.
In Proceedings of the In-
ternational Workshop on Principles of Software Evolution, pages 77–84,
Fukuoka, Japan, 1999.
[30] Todd. L. Graves, Alan F. Karr, J. S. Marron, and Harvey Siy. Predicting fault incident using software change history. IEEE Transactions on
Software Engineering, 26(7):653–661, July 2000.
c Massimo Felici, 2003
BIBLIOGRAPHY
84
[31] Carl A. Gunter, Elsa L. Gunter, Michael Jackson, and Pamela Zave. A
reference model for requirements and specifications. IEEE Software, pages
37–43, May/June 2000.
[32] Theodore F. Hammer, Leonore L. Huffman, and Linda H. Rosenberg. Doing
requirements right the first time. CROSSTALK The Journal of Defense
Software Engineering, pages 20–25, December 1998.
[33] S.D.P. Harker, K.D. Eason, and J.E. Dobson. The change and evolution
of requirements as a challenge to the practice of software engineering. In
Proceedings of the IEEE International Symposium on Requirements Engineering, pages 266–272, San Diego, California, USA, January 1993. IEEE
Computer Society Press.
[34] Herbert William Heinrich. Industrial accident prevention: a scientific approach. McGraw-Hill, 3rd edition, 1950.
[35] Hubert F. Hofmann and Franz Lehner. Requirements engineering as a success factor in software projects. IEEE Software, pages 58–66, July/August
2001.
[36] Ivy F. Hooks and Kristin A. Farry. Customer-Centered Products: Creating
Successful Products Through Smart Requirements Management. Amacom,
2001.
[37] IEEE. IEEE Std 982.1 - IEEE Standard Dictionary of Measures to Produce
Reliable Software, 1988.
[38] IEEE. IEEE Std 982.2 - IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software, 1988.
[39] IEEE. IEEE Std 830 - IEEE Recommended Practice for Software Requirements Specifications, 1993.
c Massimo Felici, 2003
BIBLIOGRAPHY
85
[40] ISO/IEC. ISO/IEC 9126 - Information Technology - Software quality characteristics and metrics.
[41] Matthias Jarke. Requirements tracing. Communications of the ACM,
41(12):32–36, December 1998.
[42] Matthias Jarke et al. Theories underlying requirements engineering: An
overview of nature at genesis. In Proceedings of the IEEE International
Symposium on Requirements Engineering, pages 19–31, San Diego, California, USA, January 1993. IEEE Computer Society Press.
[43] Chris F. Kemerer and Sandra Slaughter. An empirical approach to studying
software evolution. IEEE Transactions on Software Engineering, 25(4):493–
509, July/August 1999.
[44] Gerald Kotonya and Ian Sommerville. Requirements engineering with viewpoints. Software Engineering Journal, 11:5–18, January 1996.
[45] Philippe Kruchten.
The Rational Unified Process:
An Introduction.
Addison-Wesley, second edition, 2000.
[46] Juha Kuusela. Architectural evolution. In Patrick Donohoe, editor, Software Architecture, TC2 First Working IFIP Conference on Software Architecture (WICSA1), pages 471–478, San Antonio, Texas, USA, 1999. IFIP,
Kluwer Academic Publishers.
[47] W. Lam. Achieving requirements reuse: A domain-specific approach from
avionics. The Journal of Systems and Software, 38(3):197–209, September
1997.
[48] W. Lam, J.A. McDermid, and A.J. Vickers. Ten steps towards systematic
requirements reuse. In Proceedings of the Third IEEE International Sym-
c Massimo Felici, 2003
BIBLIOGRAPHY
86
posium on Requirements Engineering, pages 6–15, Annapolis, Maryland,
USA, January 1997. IEEE Computer Society Press.
[49] Jean-Claude Laprie. Dependable computing: Concepts, limits, challenges.
In FTCS-25, the 25th IEEE International Symposium on Fault-Tolerant
Computing - Special Issue, pages 42–54, Pasadena, California, USA, June
1995.
[50] Jean-Claude Laprie et al. Dependability handbook. Technical Report
LAAS Report no 98-346, LIS LAAS-CNRS, August 1998.
[51] Soren Lauesen. Software Requirements: Styles and Techniques. AddisonWesley, 2002.
[52] Mingjune Lee and Barry W. Boehm. The winwin requirements negotiation
system: A model-driven approach. Technical Report USC-CSE-96-502,
University of Southern California, 1996.
[53] M.M. Lehman. Software’s future: Managing evolution. IEEE Software,
pages 40–44, Jan-Feb 1998.
[54] M.M. Lehman and L.A. Belady. Program Evolution: Processes of Software
Change, volume 27 of A.P.I.C. Studies in Data Processing. Academic Press,
1985.
[55] M.M. Lehman, D.E. Perry, and J.F. Ramil. On evidence supporting the
feast hypothesis and the laws of software evolution. In Proceedings of Metrics ‘98, Bethesda, Maryland, November 1998.
[56] Nancy G. Leveson. SAFEWARE: System Safety and Computers. AddisonWesley, 1995.
[57] Frederick Levine, Christopher Locke, David Searls, and David Weinberger.
The Cluetrain Manifesto: The end of business as usual. ft.com, 2000.
c Massimo Felici, 2003
BIBLIOGRAPHY
87
[58] Bev Littlewood, Peter Popov, and Lorenzo Strigini. Modelling software
design diversity: a review. ACM Computing Surveys, 33(2):177–208, 2001.
[59] Bev Littlewood and Lorenzo Strigini. Software reliability and dependability: a roadmap. In A. Finkelstein, editor, The Future of Software Engineering, pages 177–188. ACM Press, Limerick, June 2000.
[60] Michael R. Lyu, editor. Handbook of Sofwtare Reliability Engineering. IEEE
Computer Society Press, 1996.
[61] Saeko Matsuura, Hironobu Kuruma, and Shinichi Honiden. Eva: A flexible
programming method for evolving systems. IEEE Transactions on Software
Engineering, 23(5):296–313, May 1997.
[62] Tom Mens and Galan Hassan Galan. 4th workshop on object-oriented
architectural evolution. In A. Frohner, editor, Proceedings of the ECOOP
2001 Workshops, LNCS 2323, pages 150–164. Springer-Verlag, 2002.
[63] NATURE
ing
Project.
Requirements
Novel
Approaches
Engineering.
to
Theories
Underly-
http://www-i5.informatik.rwth-
aachen.de/PROJEKTE/NATURE/nature.html.
[64] Donal A. Norman. The Invisible Computer. The MIT Press Cambridge,
Massachusetts, 1998.
[65] Bashar Nuseibeh, Jeff Kramer, and Anthony Finkelstein. A framework
for expressing the relationships between multiple views in requirements
specification. IEEE Transactions on Software Engineering, 20(10):760–773,
October 1994.
[66] Mark C. Paulk et al. Key practices of the capability maturity model, version
1.1. Technical Report CMU/SEI-93-025, Software Engineering Institute,
Carnegie Mellon University, February 1993.
c Massimo Felici, 2003
BIBLIOGRAPHY
88
[67] Charles Perrow. Normal Accidents: Living with High-Risk Technologies.
Princeton University Press, 1999.
[68] Dewayne E. Perry. Dimensions of software evolution. In Proceedings of the
IEEE International Conference on Software Maintenance. IEEE Computer
Society Press, 1994.
[69] PROTEUS Project. Meeting the challenge of changing requirements. Deliverable 1.3, Centre for Software Reliability, University of Newcastle upon
Tyne, June 1996.
[70] Balasubramaniam Ramesh. Factors influencing requirements traceability
practice. Communications of the ACM, 41(12):37–44, December 1998.
[71] Brian Randel. Facing up to faults. Computer Journal, 43(2):95–106, 2000.
[72] James Reason. Managing the Risks of Organizational Accidents. Ashgate
Publishing Limited, 1997.
[73] RENOIR
national
Project.
Requirements
cooperating
Research
Engineering
groups
a
Network
network
of
Of
Inter-
excellence.
http://www.cs.ucl.ac.uk/research/renoir/.
[74] REVERE Project. REVerse Engineering of REquirements to support business process change, Computing Department, Lancaster University, UK.
http://www.comp.lancs.ac.uk/computing/research/cseg/projects/revere/.
[75] RISE. Research Institute in Software Evolution, Computer Science, University of Durham, UK. http://www.dur.ac.uk/CSM/.
[76] James Robertson and Suzanne Robertson. Volere: Requirements specification template. Technical Report Edition 6.1, Atlantic Systems Guild,
2000.
c Massimo Felici, 2003
BIBLIOGRAPHY
89
[77] Suzanne Robertson and James Robertson. Mastering the Requirements
Process. Addison-Wesley, 1999.
[78] RTCA. DO-178B Software Considerations in Airborne Systems and Equipment Certification, 1992.
[79] W. J. Salamon and D. R. Wallace. Quality characteristics and metrics for
reusable software. Technical Report NISTIR 5459, NIST, 1994.
[80] Pete Sawyer, Ian Sommerville, and Stephen Viller. Capturing the benefits
of requirements engineering. IEEE Software, pages 78–85, March/April
1999.
[81] Norman F. Schneidewind. Measuring and evaluating maintenance process
using reliability, risk, and test metrics. IEEE Transactions on Software
Engineering, 25(6):769–781, November/December 1999.
[82] Lui Sha, Ragunathan Rajkumar, and Michael Gagliardi. A software architecture for dependable and evolvable industrial computing systems. Technical Report CMU/SEI-95-TR-005, CMU/SEI, July 1995.
[83] J. Siddiqi and M.C. Shekaran. Requirements engineering: The emerging
wisdom. IEEE Software, pages 15–19, March 1996.
[84] Ian Sommerville, Gerald Kotonya, Steve Viller, and Pete Sawyer. Process
viewpoints. Technical Report CSEG/1/1995, Lancaster University, 1995.
[85] Ian Sommerville and Pete Sawyer. Requirements Engineering: A Good
Practice Guide. John Wiley & Sons, 1997.
[86] Ian Sommerville and Pete Sawyer. Viewpoints: principles, problems and
a practical approach to requirments engineering. Annals of Software Engineering, pages 101–130, 1997.
c Massimo Felici, 2003
BIBLIOGRAPHY
90
[87] Ian Sommerville, Pete Sawyer, and Stephen Viller. Viewpoints for requirements elicitation: a practical approach. In Proceedings of the IEEE International Conference on Requirements Engineering, Colorado Springs,
Colorado, April 1998.
[88] George Stark, Al Skillicorn, and Ryan Ameele. An examination of the
effects of requirements changes on software releases. CROSSTALK The
Journal of Defence Software Engineering, pages 11–16, December 1998.
[89] Neil Storey. Safety-Critical Computer Systems. Addison-Wesley, 1996.
[90] Axel van Lamsweerde. Requirements engineering in the year 00: A research perspective. In Proceedings of the 2000 International Conference
on Software Engineering (ICSE’2000), pages 5–19, Limerick, Ireland, June
2000.
[91] Stephen Viller and Ian Sommerville. Social analysis in the requirements
engineering process: from ethnography to method.
Technical Report
CSEG/14/1998, Lancaster University, 1998.
[92] Gerald M. Weinberg. Quality Software Management. Volume 4: Anticipating Change. Dorset House, 1997.
[93] David M. Weiss and Chi Tau Robert Lai. Software Product-Line Engineering: A Family-Based Software Development Process. Addison-Wesley,
1999.
[94] Karl Eugene Wiegers. Software Requirements. Microsoft Press, 1999.
[95] Robin Williams, Roger Slack, and James Stewart. Social learning in multimedia. Final report, EC targeted socio-economic research, project: 4141 PL
951003, Research Centre for Social Sciences, The University of Edinburgh,
January 2000.
c Massimo Felici, 2003
BIBLIOGRAPHY
91
[96] Didar Zowghi and Ray Offen. A logical framework for modeling and reasoning about the evolution of requirements. In Proceedings of the Third
IEEE International Symposium on Requirements Engineering, pages 247–
257, Annapolis, Maryland, USA, January 1997. IEEE Computer Society
Press.
c Massimo Felici, 2003