Towards A System Dynamics Theory of Requirements
Engineering Process
Ddembe Williams
School of Computing, Information Systems and Mathematics
South Bank University, 103 Borough Road,
LONDON SE1 OAA, UK
Tel: +44 (020) 7815 7460 Fax: +44 (020) 7815 7499
E-mail: d.williams@ sbu.ac.uk
Key words: Requirements engineering process, process modelling and analysis, process effectiveness,
model-based theory, system dynamics,
Abstract:
This paper presents initial results of the research towards the development of a system dynamics
theory of requirements engineering (RE) process. Poorly defined requirements cause projects to fall
behind schedule, go over budget and result in poor quality system specification. Many systems
(software) development organisations are attempting to increase the effectiveness of the RE process by
incorporating improvements aimed at better understanding, improved communication and more
effective process modelling and analysis. The need for developing such a theory as a basis for
understanding and a fulcrum for debate have highlighted a strong case for integrating research
approaches. In developing such a theory the paper fills an important gap in the Systems (software)
requirements engineering process modelling and analysis literature. Research in systems (software) on
requirements engineering process modelling and analysis is vital if requirements managers,
researchers and software development organisations are to cope with the pace of software evolution,
retain competitive advantages and reap the benefits of an effective RE process. The paper concludes
that current management and decision-making models fail to make sufficient allowance for the
complexity of requirements engineering stakeholders’ business goals and aspirations in a dynamic
software development environment. The paper suggests that the model-based theory provides both a
foundation for theory building requirements engineering process and a basis for improving
requirements engineering process modelling and analysis.
1. Introduction
Requirements Engineering (RE) process modelling and improvement has become an important field of
research in requirements engineering, a subset of systems (software) engineering. From the early 1970s
RE was established as a distinct field of investigation and practice. In 1977 and 1991, special issues of
IEEE Transactions on Software Engineering were devoted to RE and in 1993 a bi-annual conference
on RE was instituted (Ficas and Finkelstein, 1993). In 1996, the RE Journal published its first volume
(Loucopoulos and Potts, 1996). By the term “engineering” we mean managing, costing, planning,
modelling, analysis, implementing, testing and maintaining the systems requirements. As an
engineering discipline, the RE process needs paradigms, which are underpinned by models and
theories.
Although substantial progress has been made in terms of analysis methods, techniques and tools used
within the RE phase of systems development, little attention has been paid to understanding of the RE
process and its effectiveness. The designers of information systems (IS) and programmers often begin
designing and programming the incumbent system too early, before they actually understand the users’
or stakeholders’ requirements. Since designing and programming systems is very expensive (Boehm,
1981), ill-defined requirements (Bubenko, 1994) cause projects to fail behind schedule (Abdel-Hamid
and Madnick, 1991; Macualay, 1996) and over budget. For the future system to be effective it has to
have a balance between the technical worldview of designers and programmers, and the social
1
worldview of users and customers (Williams and Kennedy, 1997). Current research efforts have been
heavily criticised as failing, in many cases, to improve user / customer understanding of the RE
problems and offering poor return on investment. Improving the RE process research effectiveness, is
a key issue for the understanding problems that meet the expectations of systems stakeholders, who
expect these systems to be developed on time and within budget (Loucopoulos and Karakostas, 1995;
Boehm, 1981) and with the “right” quality (Davis et al, 1993). There is a time lag between the
developer gaining an understanding of the systems' technical potential and the user understanding it.
Although there is a considerable body of literature on requirements engineering, little research has
been published on the modelling and analysis of the requirements engineering process. Research on the
latter has tended to examine formal specification of requirements, rather than focus specifically on
process modelling and analysis (Williams, Hall and Kennedy, 2000). As RE stakeholders are involved
in making decisions about a resource that has a major impact on organisational survival and
effectiveness, an understanding of the factors that affect their decision-making behaviour is vital if
software development organisations (SDO) are to remain competitive. To place the discussion in
context, the section below defines what is meant by the terms ‘requirements engineering’ and
‘requirements engineering process’ and ‘process effectiveness’ .
1.1 Definition of Terms
The term requirements engineering is used to describe a systematic process of developing
requirements through an iterative co-operative process of analysing the problem, documenting the
resulting observations in a variety of representation formats, and checking the accuracy of the
understanding gained (Pohl, 1993). RE is a transformation of business concerns into information
system requirements (Pohl, (1993), "WHAT" the system needs in order to achieve the organisational
goals.
Requirements engineering process, is the other key term used to describe the decomposition of RE into
interacting non-linear activities. These proceed from informal, fuzzy individual statements of
requirements to a formal specification that is understood and agreed by all stakeholders.
The final term requirements engineering process effectiveness is used as the measure of the accuracy
and completeness with which the RE process goals are achieved. The effectiveness dimension is
captured in such a way that it can be translated into meaningful quantitative statements concerning
quality, cost and time schedule.
This paper attempts to develop such an understanding by proposing a framework that identifies the
factors that influence effective process modelling and analysis. Since there is no empirical research on
decision-making in RE, the rest of the paper is organised in nine sections. In section 2 a review of RE
engineering process modelling literature, is given to provide a context of which process performance
effectiveness is achieved. The background to the requirements engineering process modelling and
analysis is discussed in section 3. In section 4 a problem statement for RE process modelling
effectiveness is presented. Section 5 discusses the advantages of using system dynamics /system
thinking in visualising, (through a model of the RE process. Section 7 presents overall model structure
and the resulting behaviour, while section 8 highlights initial observations and insights from this
research. Section 9 presents an initial system dynamics model-based theory of the RE process, while
section 10 considers some future directions to further improve the RE process and conclusions.
2. The Requirements Engineering Process Modelling
Curtis et al, (1988) in perhaps the most cited study of software engineering in real organisations,
highlight the significant causes of problems in RE process:
= The thin spread of applications domain knowledge;
= Fluctuating and conflicting requirements;
= Communication and co-ordination breakdowns;
. In addition to the above three problem areas, Williams, Hall and Kennedy (2000)
demonstrated recently the need for data collection methods to support the RE process modelling
and analysis.
Various approaches have been proposed for evaluating the success of RE process. Newman and Robey
(1992) found the process modelling approach very appealing, particularly its applicability with respect
to complex dynamic RE process. User/customer satisfaction has also been widely used as a measure of
RE process success (El Emmam and Madhavji, 1995). The perceived utility is obtained by seeking the
opinion of the customer/user during a requirements review meeting about both the requirements and
the whole process. Melone (1990) has discussed the limitations of this approach, which is highly
subjective; requiring users to assign numeric value on entities (such as attitudes), which cannot be
directly measured (Clark and Augustine, 1992). A clear link between user satisfaction and process
effectiveness as a measure of RE process success has been difficult to establish.
In information systems studies some researchers have used a general systems approach to assess the
value of information systems (Swanson, 1971). This approach has been demonstrated by Morecroft
(1979) and later tested by Jones (1983). The general systems approach uses simulation modelling in an
attempt to overcome the limitations of analytical techniques. This approach has also been used in
software development process (Abdel-Hamid and Madnick, 1990) and in product development process
(Ford and Sterman, 1996), but it has not been specifically directed at requirements engineering process
modelling. Wolstenholme et al (1990) have used simulation modelling in evaluating an information
system in the defence sector. They proposed a holistic framework that focused on the effectiveness of
an entire Information Systems process. The approach applied in this paper is similar to the above, but
differs in that we are focusing on patterns of behaviour in RE process, while they focused on
information attributes and decision-making. The use of simulation modelling by Wolstenholme et al
(1990) confirmed the usefulness of the system dynamics methodology in assessing value of complex
information. In order for the modelling methodology to be useful in RE process performance we must
identify relevant entities, variables and attributes, their interaction, relationships, and dimensions, and
test the RE process performance.
RE process modelling and analysis, particularly in large-scale projects, is a complex process. As the
research question become more complex and precise, the activities in each phase of RE must become
correspondingly more demanding, precise and controlled. A great deal of work has been carried out on
static RE process-based approaches to requirements engineering (Pohl, 1993), but very little has been
done utilising dynamic process-model based tools. Neither has any dynamic theory of requirements
engineering process has been proposed to facilitate debate and understanding of the problems in this
important phase of software systems development life cycle. This paper contributes to developing such
an understanding by proposing a system dynamics theory that may facilitate the understanding of the
RE process modelling and improvement amongst RE stakeholders.
Many requirements specification frameworks reported in the literature provide insight into the problem
of specifying requirements. These frameworks cannot be regarded as methods of analysing information
needs and determining their information requirements or shading light on the relationship between
different activities or their entities. Main coverage of this domain tends to pay more attention to
specification language issues or form part of a wider systems development method. The requirements
engineering process as a social aspect have largely been ignored where organisational, strategic and
human “soft” communications issues are being examined (Mumford, 1984; Jirotka and Goguen, 1994).
Many authorities (Wieringa, 1995, Macaulay, 1996; Loucopulus and Karakostas, 1995) have indeed
identified problems with current RE process and, while most observers will acknowledge that there are
deficiencies in the current process modelling practice, there is no consensus on what the deficiencies
are. However, systems failures continue to be blamed on poor requirements engineering process
(Macaulay, 1996; Zahedi, 1995; Fickelstein, 1989). This is mainly due to poor understanding of
domain knowledge and poor use of methods, techniques and tools in the modelling process. Further
more, maybe more important poor understanding of the critical success factors that contribute to the
effectiveness of the RE process. Even Macaulay (1996), reports of inconsistency in positioning of
requirements engineering process within the various software development life cycle models.
3
Both academia and practising managers are concerned with the development of software or systems
that are within cost estimates, and on schedule, with a high quality product that fulfils the customers’
requirements. Boehm (1981) provides the most comprehensive empirical evidence on the importance
of the requirements engineering process. In an analysis of 63 software projects performed at TRW, he
demonstrated that the relative effort cost and effort spent on requirements analysis grows
disproportionately as the size of the project increases. In terms of quality and cost specifications, a
study of 8,380 applications development effort (Standish Group, 1986) found that cost overruns
averaged about 189% of the original estimate and 31.1% of development efforts were cancelled. Of the
developments that were completed:
* — only 16.2% delivered initially specified functions
* — the remaining 53% delivered, on average, about 61% of the initially specified functions.
In large companies, only 9% of projects come in on time and on budget while the average time overrun
is 222 % of the original estimate.
Fickelstein (1989) reports that a disproportionately large proportion of errors in IS development were
due to faults in requirements engineering. Figure 1 (below), shows that errors in information systems
have the following distribution: Incomplete requirements (RE) 56%, Design (DN) 27%, Coding (CG)
7% and Other 10%. The high error percentage due to incomplete requirements confirms the earlier
assertion on the poor methods used to elicite and analyse requirements.
% Effort Distibution
Others CG
4% 1%
Others
CG 10%
7%
ON
27%
Figure2. Distribution of Effort to Error Sources
Figure 1. Distribution of Error Sources (Zahedi, 1995)
(Finklelstein, 1989)
Finklelstein's (1989) analysis in Figure 1 is also confirmed by Zahedi (1995). She reports that
correcting errors in IS from various sources does not take proportionally the same amount of effort.
Figure 2 (above) provides further evidence that errors due to incomplete requirements analysis take a
disproportionate larger effort share: Incomplete requirements (RE) 82%, Design (DN) 13%, Coding
(CG) 1% and Others 4%. The empirical evidence presented confirms the deficiencies with the current
RE process effectiveness. The problems of RE and process management are complex and may need
the use of methodological pluralism as a value-added approach, in order to facilitate communication
among stakeholders and understanding of information needs. There is a lack of agreement on the
definitions of requirements engineering. Macaulay (1996) and Castello and Liu (1995) argue that
requirements engineering and RE process are to an extent situation dependant. For a RE process to
begin a situation trigger is necessary. The RE process trigger may be changes in user information
needs, incremental improvements to the existing system, change in management decision making
tules, or change in legal requirements.
Whatever the reason for the RE process trigger, the complexity inherent in RE leads to the need to
develop an understanding of the nature of the problem. This complex situation makes it very difficult
to define the tasks and the skills needed by the requirements engineer. The different designations used
by organisations for the requirements engineer means that different knowledge and skills were being
applied to the requirements engineering process. This is a major source of the problems (solving a
4
wrong problem) in RE process management. The above analysis provides a basis for the need for new
approaches to RE process effectiveness problem solving. It is critical to appreciate that systems are
complex socio-technical systems, largely influenced by human system and management culture. From
this perspective, it is therefore necessary to use methodological pluralism or new problem solving
approaches that support effective capture and synthesis of cost, schedule and quality in the RE process
(Galliers, 1984; Williams and Kennedy, 1997). Traditional process modelling approaches are flawed in
a number of ways and cannot facilitate an effective decision-making, let alone the understanding of the
RE process. Gaining an understanding of the RE process and the factors that lead to its effective
completion is the prerequisite for improving the RE practice and the decision-making process (El
Emmam and Madhavji, 1995; Newman and Robey, 1992). The next section explores how concepts
developed section two and three can be applied in a process measurement environment
3. Requirements Engineering Process Performance Measurement
Controlled RE process are stable processes, and these in tum should enable Software Development
Organisations (SDO) to predict process performance. Predictable process performance in tum enables
SDO to prepare achievable plans, meet cost and schedule commitments and deliver the RE
specification with acceptable quality and consistency. In cases where of a controlled RE process is not
capable of meeting customer requirements or the SDO’s business objectives, the process is then
improved through a decision-making process or deleted. Fenton and Pfleeger (1996) provide
measurement guidelines into how to improve visibility with which the processes, products, resources,
methods and technologies of software development relate to one another. Performance measurement
allows managers and requirements engineers to monitor the effects of activities and the volatility of
requirements on the whole RE process. Fenton and Pfleeger (1996) contend that measurement is useful
for:
. Understanding,
= Establishing a base line, and
= Assessing and predicting.
Where actual measurement differs significantly from the plans based on business goals, action should
be taken as early as possible to control the final cost, time and quality of the system specification.
Where a process is out of control, use of statistical control methods helps identify process or attribute
variability. Causes of parameter variability can then be identified and decisions taken to correct it so
that stability and predictability can be achieved. RE process controllability often leads to differing
measurement needs and decision-making information requirements.
In the RE process many stakeholders are interested in different aspects of the process, its output
products or its products as demonstrated in Table 1. These aspirations may influence the resulting
product and its quality. Paradoxically, a RE process demand greater understanding of the domain
knowledge, the experience of analysts and training in the use of tools aids greater understanding, this
should lead to fewer errors and improved quality in system specification. Improvements in
technological development has facilitated the automation of the RE tools; however this automation has
focussed on documentation of requirements rather than the whole process including process
management and organisation (Williams, Hall and Kennedy, 1999; Williams and Kennedy, 1999).
This shortcoming has meant that requirements stakeholders do not have a whole picture of the process,
its cost, schedule and quality and therefore understanding is not complete so as to facilitate effective
decision-making and process improvement. The fears and aspirations illustrated in Table 1, shape the
success or failure of the RE process decision-making and process improvements.
Table 1: Aspirations of Stakeholders in a RE Process [Adapted from Gilles and Smith, 1994]
Stakeholder Aspirations and Interests
Requirements Engineer Wants a tool that makes their job easier, more statisfyicing and more
productive.
Customer/User Wants a system specification with minimum errors that will describe
the system they want with lowest price and in the shortest time.
Wants usable system, with fewer errors
Project/ Process Manager Wants to deliver on time with the right specification quality and to
satisfy the customer.
Quality Manager Wants to ensure that the delivered system specification is error-free
and meets the aspirations of the customer.
Senior Management Wants to see a return on investment, increased productivity, increase
In quality of products and services and fears the possible failure of
the project!
Feedback from the processing RE support provides additional data and models that may be useful for
future decision-making. Output feedback (which can include outcomes, cognitive information, task
models. and what-if, goal-seeking, and other types of sensitivity analyses) is used to extend or modify
the original analyses and evaluations (Mallach, 1994; Sengupta and Abdel-Hamid, 1993; Williams,
Hall and Kennedy, 1999). These interactive feedback loops make it relatively easy for management to
support the decision making process in a continuous and dynamic manner. Along with the original
analyses and evaluations, the feedback loops also increase the users' confidence in the
recommendations and enable the decision maker to better explain, justify and communicate the
decisions during implementation (Liang, 1986; Sengupta and Abdel-Hamid, 1993 and Sprangue and
Watson, 1996).
By organizing captured RE process data, generating timely focused reports and projecting process
trends, the RE process mode provides problem-specific information. RE process model-based
simulations, optimisations, and sensitivity analyses transforms the knowledge into satisfyicing
solution. Jani’s (1971) analysis indicates that in the RE process environment stakeholders fall into “the
individual differences approach” paradigm described by Keen and Morton (1978). The RE process
stakeholders behave very much as individuals (or group) as their aspirations and interests tend to be
different (table 1). Simon’s (1961) approach, “the satisfyicing, process-oriented view” describes the
goals of a decision maker as making a good decision, but not necessarily the best decision. This
description closely resembles the approach taken by RE process stakeholders, given their constraints of
time, schedule, cost and uncertainty. Gaining an understanding of the RE process facilitates
stakeholders acquiring the general information needed to address the SDO’s RE process problems and
opportunities for product quality improvement. The model-based RE process support tool developed
can be used to systematically examine the discovered problem or opportunity. This model may consist
of decision alternatives, uncontrollable events, criteria, and the numerical relationships between these
variables. Using the explicit generic SD model of the RE process enables management to logically
evaluate the specified alternatives and to generate recommended actions constitute the ensuing choice
phase. During the subsequent implementation phase, the decision maker ponders the analysis and
recommendations, weighs the consequences, gains sufficient confidence in the decision, and
implements the chosen option.
4. Problem Statement
A Requirements Engineering Prescriptive framework is described as a theory and associated
experimental evidence and field studies concerned with helping RE process stakeholders improve their
performance in problem-finding and problem-solving given the complexity and constraints often
presented in real life RE processes. As started earlier, current approaches to RE process modelling are
too informal or too formal to support useful understanding of the RE process modelling and analysis
(Bubenko, 188; Davis et al 1993) or to provide useful theories to facilitate understanding (Williams
and Kennedy, 1997; Williams, Hall and Kennedy, 2000). Discussions presented in earlier sections
raise important question for this paper:
How does the RE process modelling and analysis impact on process effectiveness? Can modelling
and analysis of the RE process from a feedback control viewpoint and the resulting system
dynamics theory be a useful tool to provide a fulcrum for debate and enhanced
understandability of the RE process?
The above question implies that a good model should show a tendency toward fluctuation in both
customer requirements, quality of specification product, cost of resources and customer satisfaction.
When the productivity per requirements engineer decreases, the observed quality decreases. After
some delay, additional requirements may be acquired, the increase in training, however initially
reduces the productivity of analysts. This increased training effort further reduces quality. However,
after training is completed, the productivity ration per requirements engineer increases and observed
quality increases. In order to answer and operationalise the above problem statement, this section seeks
to develop a dynamic requirements engineering process and improvement model capable of capturing
both formal and informal aspects and to facilitate better understanding of the RE process and its
effectiveness in terms of feedback loops, delays and non-linear relationships between key processes’
products and resource variables.
Process Schedule
+
rover
Cost of Resources
42) Specification Quality
+
Customer Satisfacti
Figure 5. D ynamic H ypothesis of requirements engineering process effectiveness
Process effectiveness as defined the measure of the overall accuracy and completeness of goals
achieved in RE process model. The dynamic hypothesis described in Figure 3, can be used to explain
the cause of the problem. As illustrated in Figure 3, the effectiveness of the RE process must be related
to the quality of the product, the cost of resources and the time the product is developed. For the above
statement approach to be correct we assume to have a valid model that incorporates the RE process
structure, quality assurances, budgets and RE process planning and control procedures. A RE process
system can be used as a decision support system for RE stakeholders to explore the likely impact of
their various polices, before actually implementing them. Systems thinking/systems dynamics offers a
vehicle for conceptualising the dynamic theory of RE engineering process (Senge, 1990; Morecroft,
1988; Sterman, 1994).
5. Use of System Dynamics To Model The RE Process
Systems dynamics (SD) has become an important methodology for understanding and formalising
conceptual process models (Abdel-Hamid and Madnick, 1990). SD supports analysis of the system’s
pattem of behaviour in a way that facilitates understanding and insights into organisational structure
and managerial decision-making. It can be used to provide the basis for a model of a feedback
structure in decision-making, which encapsulates the complexity of decision-making behaviour
generated by the iteration of many non-linear loops over time. SD has been applied to a wide range of
domains, from the management of socio-economic systems to the management of eco-systems
(Roberts, 1978). Recent studies have focused on modelling managerial decision-making (Senge, 1990,
Sterman, 1989; Morecroft, 1987; Clark and Augustine, 1992). Clarke and Augustine have devised
what is perhaps the most comprehensive model of managerial decision-making. They use SD to
measure the value of information in the business organisation and describe in detail the decision-
making processes involved in managing the flow of information and effective resources in pursuit of
organisational objectives.
SD has developed over time as a method for modelling the behaviour of complex socio-economic
systems (Forrester, 1961; Keys, 1988; Coyle, 1986, 1995). It can enhance understanding of the nature
of an organisation’s soft (Checkland and Scholes, 1990) and strategic issues (Senge, 1993) and can be
used to improve corporate decision-making. The Stock/Flow notation used in SD can he applied to
build detailed conceptual models of decision processes (Meadows, 1982; Pidd, 1992) and facilitate
identification of information needs at different levels of managerial activity. The main advantage of
SD, however, in terms of modelling decision-making processes is that it can handle both soft and hard
aspects of decision-making. The problem with the ‘hard’ approach’ it is that too narrowly focused to
be genuinely useful in facilitating understanding of decision-making and cannot tackle adequately
problems that are ill structured (Keys, 1988). Soft systems approaches are much better suited to coping
with complex, ill-defined problems but they are too all-encompassing to capture the fine detail of the
decision-making process The ability of SD to integrate both hard and soft approaches means that it is
uniquely capable of revealing and explaining the decision-making processes (Meadows, 1982;
Wolstenholme, 1992; Kuhn, 1970). I have urged that the advantages of the SD approach outlined
above suggest that it is an appropriate vehicle for examining the decision-making process in IT. As has
been demonstrated earlier in the paper, individual decision-making is influenced by hard and soft
factors. SD integrates both factors but is also good at capturing the dynamics of organisational change
processes. Earlier it was suggested that organisational change has a significant impact on decision-
making in IT. It follows that SD may offer a way of exploring the dynamic impact of change on
8
decision-making behaviour and competency. If SD could be applied in this way it would provide a
basis for modelling decision-making, capturing the impact of change processes and exploring the
potential impact of change on competency. This would be of great value in developing a theoretical
framework for understanding decision-making in IT and for improving competency in a learning
situation. The model provides a systemic and holistic view of the RE engineering process that
influence decision-making effectiveness in RE process. Williams, Hall and Kennedy (2000) have
argued that that such an approach is crucial to understanding the dynamics of requirements engineering
process modelling and improvement.
6. Feedback Structure in RE Process Modelling and Analysis
Morecroft (1977, 1983) provide a reference point for understanding the range of factors that influence
decision-making in requirements engineering process management as the quality of information. At
the centre of the model is the RE stakeholder. The decision(s) made by stakeholders is depicted as
being influenced by the factors discussed in the management literature. Personal factors are shown to
be important as are the influence of peers and the groups to which the manager belongs. Personal and
peer/group factors are subject to the influence of organisational factors - the structure, culture and
political ethos of the organisation, its goals, quality of information available, etc. "Business rules” are
shaped by the organisational context and strategic objectives, while investment policies are influenced
by technological factors and are also shown to have an impact on the RE stakeholder. The model, as
illustrated in figure 5, identifies the importance of organisational learning and suggests that it may have
a direct impact on the individual IT manager’s ability to learn and to make effective decisions. These
concepts of feedback structure, delays and non-linearity have a significant impact on a RE process
depending on assumptions embedded in the system.
6.1 RE Process Modelling Scope and Assumptions
Classification of phases of system (software) development life cycle (SDLC) may vary from one
system (software) development organisation (SDO) to another (Boehm, 1981). To put this research
into perspective, the requirements engineering process is the initial phase of the SLDC (Williams and
Kennedy, 1997). Figures 4 and 5 positions the RE in SDLC, which starts when a SDO receives a
Request for proposal from a customer or request for change from a user and ends with the delivery of a
requirements documents just before preliminary design begins. Main process areas form the basis for
management control of software projects and establish the context in which technical methods are
applied and how work products (models, documents, data, report forms, etc.) are produced (Pressman,
1997). Software engineering methods provide the technical ‘how’ for building products.
Requirements
Engineering
[| Preliminary Design 1
Detailed Design
Implementation
(Coding & Unit Testing)
Integration & System
Test
Operation and
Maintenance
Figure 4: Positioning the RE process in relation to the Classical Waterfall Model of SDLC
9
These methods encompass a broad range of processing including requirements engineering, design,
programming, testing and maintenance. RE tools like in software engineering tools, provide
automated or semi-automated support for the process and the methods. To put this research into
context, figure 4 identifies the position of requirements engineering process in the context of
traditional software development (SDLC) ‘waterfall model' based on Boehm (1981).
The RE process starts with elicitation of customers/users requirements that are informal and
incomplete and ends with a specification document that is formal and complete. For the purpose of this
research, the software development lifecycle has been divided into six phases (Figure 5) that are
consistent with the NASA's IV &V (NASA, 1984), the GPL (1985) on cost effectiveness and Boehm's
(1981) waterfall model. A RE prescriptive theory represents a generic system dynamics model of the
RE process modelling and analysis that focuses on the first phase of the SDLC. A RE process can be
thought of as a Use Case (Jacobson, Booch and Rambaugh, 1999) and as having a start state, a request
of proposal (the leftmost rounded rectangle), intermediary states (the subsequent rounded rectangles),
end states as delivery of specification document (the rightmost rounded rectangle), and transitions
from one state to another as illustrated in Figure 5.
eae ©)
Figure 5: Description of the RE process Transitional State Chart
In Figure 5 straight arrows illustrate the basic path, and curved arrows represents key feedback or feed
forward likely to take place in the Requirements Engineering. Feedbacks are one of the fundamental
features not supported in the Unified Modelling Process provided by Jacobson, Booch and Rumbaugh
(1999) as a de facto standard for software process modelling. This paper adopts the above set of
activities as a generic RE process. Since these activities are flexible, can easily be customised to
different domain application or different SDO providing such services. The problem is to select the
process model that is appropriate for a large-scale system to be engineered by a RE process team.
Metrics defined in this paper provide key process performance measures that can be used in the
management and improvement of the model depending on the assumptions made for the system. The
majority of the structure in the model is endogenous. Schedule, quality and cost are tightly coupled to
one another. The requirements change request (or request of proposal) is exogenous. The use of
exogenous variables serves feedback loops, which may have important policy implications. The
requirements change requests normally arrive at the process manager's desk in a non-steady-state
build-up from different stakeholders. On the other hand active requirements over the RE process life
cycle are in a steady state, after which a review process decides to implement them, freeze them or
reject them completely. In the Draper model, Smith and Lavery (1991) reports that a moderate scenario
of 15 percent requirements change with a group of 50 experienced managers only a few finished the
project on time and within budget. Aranda et al (1993) postulate, "no matter how good your
requirements process is, there are still some requirements for a system you could not have known
about until the system was built". Boehm (1981), in another IBM study estimated that requirements
changes averaged 25 percent for a typical project. In this paper an average Error Rework of errors is
set to vary between 15-25 percent.
The model can be divided into a number of subsystems with relatively sparse interactions with the
remainder of the model. Given the above observations in the software process modelling literature, the
following assumptions have been considered in the development of RE process modelling and analysis
prescriptive model:
= the inter-arrival times for requirements change requests are exponentially distributed,
10
. the review times are exponentially distributed,
= the number of active (implemented) requirements is typical of large scale complex systems
i.e. > 10000, therefore finite change requests queuing formulation must be used,
. minimum quality possible is set at 0.25 (dimensionless),
= the inter-arrival times for change requests are statistically independent of the review and
specification times,
= the review and requirements specification activities are parallel and each is capable to review
or to specify requirements,
. the mean time between reviews (MTBR) and mean time to specify (MTTS) values vary for
each requirements age groups and represent the expected value for those variables for that age
group,
= rework of requirements errors will be distributed between 15 and 25 percent for a typical
project.
The average completion time for a requirements process varies between three months to two years for
business systems and command-and control defence systems respectively. Other assumptions used in
this paper will be stated in the appropriate sections. The above model assumptions have guided this
research to state explicitly the purposes of the model implemented in this paper. The focus of this
research is on resources, processes and product variables in the RE process modelling and analysis.
The success of such a process is determined by the effectiveness of the size of documentation, quality
of specification, cost of resources, and project schedule. (Williams, Hall and Kennedy, 2000).
6.2 Time Horizon
RE process vary in duration depending on domain application and the size of the product specification.
Based on Boehm (1981, 1989) requirements analysis takes 6 to 8 percent of time schedule of the whole
software development life cycle. The whole SDLC varies from 7 to 12 years of systems to critical
business applications respectively. Requirements engineering process takes between 3 and 24 calendar
months for business application and critical defence systems respectively (Smiths et al, 1993). The
mean value is 10 calendar months, however this paper adopts 15 calendar months, as a nominal
simulation time frame used for generic RE process model. There are five working days in a week.
Therefore a calendar month (4*5) will have 20 days. Converting 15 calendar months give us 300 days.
The final simulation time in the model is therefore set at 300 days. While it was not the purpose of this
study to estimate model parameters from the data, the comparative longer simulation time period
provides useful test of reference model behaviour.
This section presents a feedback structure of the RE process modelling and analysis. SD modelling
approach takes a philosophical position that feedback structures are responsible for the changing
pattems of behaviour we experience in complex problems (Richardson and Pugh, 1981). Robert et al,
(1983) suggest that there are three important aspects of the SD approach to developing computer
simulation models: establishing cause-and-effect relationships, determining feedback linkages among
components of the system, and setting appropriate boundaries for defining what is to be included
within a system. Conceptualising system structure and communicating model-based insights about
feedback structure and dynamic behaviour can be achieved through causal-loop diagrams or influence
diagrams (IDs), Stock and Flow Diagrams (SFDs) techniques supported by SD. To improve our
understanding of the RE process dynamics, the paper explores the feedback concepts by explaining the
model structure using influence diagram and the net effect on RE Process Effectiveness. An increase
in Changes in Requirements increases the number of process activities, which in tum increases the
number of requirements to be specified. An increase in the number of requirements increases the total
requirements, which in turn increase the number of requirements processed as a result of the review
process. At the same time an increase in No of Requirements to be specified increases the Error
Generation Rate, which in tum increases Error Detection Rate there by increasing Error Rework. The
feedback structure presented in figure 6 contains some of the validated theories of software
development dynamics published in public domain. This paper makes a contribution by adding
features and variables that only are pertinent to requirements engineering, which have not been
modelled by other researchers before.
11
gl
+ :
Total Engineas>, ~ O
Requirements
Implemented +
Figure 6: Feedback Structure of the Requirements Engineering Processes Performance
12
The model (figure 6) is useful insofar as it depicts the main factors that influence the effectiveness of RE
process and indicates some of the possible interrelationships between them. However, it does not depict
the process, delays, complexity or dynamic nature of RE process. If effectiveness in RE process is to be
improved it is necessary to go beyond merely listing factors and activities that influence process
effectiveness and develop a model-based process support system for the RE modelling and improvement.
6.3 Audiences and Purpose of the Model
The beneficiaries of the model developed in this paper are requirements process stakeholders including
requirements managers and researchers, customers and management of SDO. The stakeholders are
responsible for the management of the RE process and would require some guidance on how to improve
RE process effectiveness through controlling the schedule, cost and quality of the specification product.
The resulting model will be used as a tool that allows requirements stakeholders to experiment with
decision choices for improving Requirements Engineering process modelling In addition to the aims and
objectives of this paper and the model requirements. The RE process prescriptive model implemented in
this paper will be used for the following purposes:
= __ to create a discussion environment for better understanding of RE process management,
= toclarify policy implications and problems of the requirements engineering process management
and improvement;
= to create an efficient way to expand the mental models of stakeholders about the RE process
modelling and analysis.
= to forma basis for data collection in a framework for Requirement Engineering process
= to create a platform for experimentation research tool as part of planning and prediction of RE
process performance evaluation;
= to create an environment for testing the various hypothesis about RE process modelling and
analysis and their implications for RE process stakeholders.
= to provide a platform for Reuse of RE process enactment and technology acquisition in different
application domains.
The assumptions stated and purposes of the model above facilitate the scoping of the boundary.
6.4 System Boundary
The model developed in this paper focuses upon aspects of requirements engineering process dynamics that
may be potentially within control by RE process stakeholders. The components define the boundary of the
system dynamics model for RE process developed in this paper and will be used to generate the behaviour
of interest. The assumptions and the model purposes stated earlier provide a basis for describing a generic
system dynamics RE process model. Each phase is generic in structure and represents a specific stage of
product development. The four project components (described as subsystems) interact within each phase
and impacts project performance. The model also uses the three traditional measures of project
performance (time, cost and quality) and these are reflected as cycle time, defects and cost. The
requirements elicited and to be specified flow through the RE process, as described iterative activities.
To help identify divisions among development activities and specification requirements, it is assumed that
requirements within an activity are uniform in size and tangible, and that they are also small enough to be
defective or correct but not partially defective. The model then describes development process through
elicitation and definition, specification process and review process encompassing all six activities.
The interacting three subsystems and 14 sectors in Table 2 and figure 6, endogenously presents the RE
process modelling problems and also in the problem statement and determine the effectiveness of the RE
process modelling and analysis. Table 2 summarises the major functions of each sector.
13
Table 2: Major Functions of Each RE process modelling and analysis Model Sector
Sub-System |
Sector
Major Functions
Process Organisation
Project Scope Sector
Process Integration Sector
Customer Services Sector
Main function is to ensure that the
Organisation producing requirements
specific action adheres to standard
process and there is business case
in the project.
Project Finance
Product Engineering
Process Technology Sector TE
Development \Process Sector
RE Support Environment
Process Schedule Sector
The main function is to ensure that
customer acceptance and satisfaction
with the product quality.
Project Mana
ement
Quality Assurance
Planning and Control Sector
RE Procurement and Contract Management
The main function is to plan and control
achievable commitments regarding cost,
schedule and resources.
Document Management Sector
Process Performance Sector
Customer/User Sector
External
Table 2 summarises the major functions of each subsystem and their sectors represented in the model. The
next section discusses each of the model sector subsystems in detail. The model consists of about 495 Stella
Research 6 (HPS, 2000) equations with 45 level variables. The full listing of the model equations are in
Appendix A1. In the model, request for proposal and inflation are assumed to be exogenous. There are
eleven endogenous interacting sectors within three subsystems identified (Morecroft, 1979). The three
subsystems and 14 sectors are consistent with figure 6 proposed and developed in this paper. The model
subsystem discusses detailed complex relationship between variables.
7. Overall Model Structure and its Resulting Behaviour
Figure 7 shows the overall structure of the system dynamics model that considers important interacting
variables in the RE process modelling and analysis based on concepts explored.
Simulation results presented in Figure 8 through 13 can help develop an understanding of the system
dynamics model and the behaviour of the RE process management. As emphasised earlier, in a generic
model of the RE process exact variable numeric values are not as important as understanding derived from
the impacts of the model structures on its behaviour illustrated in Figures 8 through 13. The structure of the
model includes some of the previously validated models of software process engineering.
Analysis of graph outputs shows the benefit obtained from using novel environment for exploring complex
problems like RE process. The modes of behaviour, which are exhibited in these graphs, reflect real-world
concems of requirements engineering process stakeholders. These outputs provide the RE stakeholders
with measures of how well the RE Process is being managed and therefore process bottlenecks can be
identified and improved. The dynamic behaviour produced by the model is analysed with respect to the
underlying structure or its influence diagram (Figure 6) upon which the model is founded (Wolsteholme et
al, 1990). Analysis of the results in graphs (Figures 8 to 13) shows the benefits of IS obtained from
modelling the entire Requirements engineering process. As suggested by Forrester and Coyle (1986)
Wolstenholme et al (1997) analysis the change in the dynamics produced or the quantitative results is not
enough. It is crucial that the interpretation takes account of how the underlying structure is changed and
how the output dynamics are produced. The cross-analysis of between Z-S shaped dynamics and the living
dynamics is easy to understand.
14
ENVIRONMENT
ENVIRONMENT
Software Development Organisation
Customer Organisation
Request for proposal
Too! Use Training
‘Customer Understanding
Indicated Completion Dat
Witingness to Make Changes}
Time Remaining
Process Organisation
Compattivendss Demand for
PROJECT SCOPE CosTomin SERVICES)
Forecast Schedule Expected Delivery Time ales:
sravdl pst eroneomctinontioe: Mangement corer ; offact
Deccan Tyo arene crete Performance Measures and Decisions aie
Financial Input Value ove pavehte by Cus Se nee een
" Completion Dat No of Projects Actual Technical Effectiveness
Error Density
‘Allocate Process effectiveness Estimated rue op.
ee ‘Quality Effectiveness: oe
PROCESS INTEGRATION PROJECT FINANCE Esnicamchiicasata aules
Process Scope Prom Improve Quality of Specification atial
seme et Pane ‘Wages Minimise Schechile mets a
Same teers Budget Available ‘Customer Satisfaction
Management Knowledge ‘Cost of Resources Customer Understanding acuat | willihgness =
sate Time auaity | Suppht “cf
—4 Quality of
t specication
i—_——— J Custpmer
Expediations
cor Percfeved
Product Engineering | fies roject Management
|
‘a standards 1
ee f DeveLoPmenT proces QUALITY ASSURANCE) (PROCUREMENT MANAGEM
Process Stucturedness_ pi otc Reerecne Time available lity
Teinocoiony Use "peter Precis Biogress fay Suet “Total Cost ‘otal Funds
Train Requirerments analysle eden mate Process irprovernent Conwitied
Actual Proceze Rigour Thor Generation Recuuterants Process Retirements Approved| ene,
rm citeglewens oeie wall Curmnulative ettor ‘err Dencioy Requested Funcs obea
eporta Errors Discovered idcate Costs oF Projecy
F Proaen i
‘rigour Pressure: Reman vee
: i Doturment erat Re
Applied Rigour phates Corresetion bee Schedule Adjustment ipa erasing
‘Tool Use Pipicteaty Productivity Schedule Indicated Engineers 12 of Documentation
Dorr Complexity sd essuire
Believed % Completed
Estimated Completion Time|
Requirements Engineer
Percent Project Complet
Requirements Elicited
NX
Figure 7: Overall Structure of the Requirements Engineering Process Performance
15
_/
ENVIRONMENT
Graphs shown in Figure 8 through 13 represent some of the inferences about the requirements engineering
process performance. Thinking within reference modes supported by the graphs helps to understand several
effects of decision engineering and helps to improve our understanding of the system we are modelling
(Richardson and Pugh, 1981).
Figure 7 illustrates difference between planned and actual effort expended.
1: Analysis Person Months 2: Elicitation & Definition... 3: Modelling Person Mont... 4: VV Person Days 5; Total Person Manths
309
2 31
3 26
4: 64
#3
L 38
2 31
3 264
4: 6a rs
L 38
2 31
3 2s| |
& 64 ly
0.00 3.00 6.00 9.00 12.00 15.00
Naeeaé Geli Bali af PP ato ia wanes
Figure 8: Effort Expended on Different Requirements Engineering Activities
Figure 8 illustrates the amount of planned time spent on the requirements engineering process as a result in
time due to errors is exhibited in verification and validation (4) and this compounded in the total Person
Month(s). The scenario is reflected through the policies and initial condition in the model (Wolstenholme,
1990). Figure 9 shows interesting dynamics into the effects of estimated schedule on completion time.
Figure 9 shows interesting insights. Notice the Z-shaped dynamics. This shows the rate of technology
transfer (3) starts fairly high, then drops dramatically after five months. While planned reviews size (4)
starts fairly low then increases as the customer identifies more errors in the specification document. These
dynamics correspond to real-life behaviour of requirements engineering process.
2 1.00 | ——_-—-_-—— |
3 0.60 * ——
ran
3.00 6.00 9.00 12.00 15.00
Ngee
Figure 9: Behaviour of Technological Transfer, Confidence by the SDO and Perceived Review Size
Graph 7: p3(Analysts-Customer Behaviour... Months 2118 10 0¢t2000
Figure 10 shows dramatic effect of ‘Lump’ type of behaviour. The actual technical effectiveness (1) starts
fairly slowly and rises sharply after nine months. This is due to the fact that it takes time to learn to use
tools and new methodologies (4). Initially, requirements discovered (3) are high, but progressively reduce
16
over time. This behaviour is correspondingly true to requirements documents size (2), which is initially
large, but reduces, as understanding is refined.
: 1050]
2 400.00 Ler,
; eed i] _ |
i pee :
550
250.00 |
250,00
ae Ae >
“
1 050 ae] >
2 100.00 a _—
5
bossy
co a —_}__.
& 3500.00" : —_
Figure 10: Technical effectiveness, Requirements Document and Requirements Discovered
A more stable behaviour showing slow increase in all variables. It is interesting to note that the behaviour
of understated completion date (5) is similar to that of cumulative costs (1) and project cost effectiveness
(4).
1 200000.007]
2 1.00
3 3030
4 4.00 ral
5: 20.00 fe —_ AZ5
4 3 —— 3
anand a
: x
sos
1 100000.00 a 2
2 053 et E
3 30157 4
4 2.00 a rs
5 10.00
4
3 ot
4
1 0.00 |
2 005 2 z
3 30.00 a
4 0.00
a.
5 0.00
0.00 3.00 6.00 9.00 32.00 15.00
Figure 11: Model Behaviour of Perceived Quality and Expended Effort
Perceived quality (2) increases initially but stabilizes in the 7" months equally total Person-Months (3)
expended on the project increases with time, but drops after 9" months, this is due to fewer errors
discovered and high technical effectiveness exhibited in Figure 12. Figure 12, exhibits ‘lump’ and ‘ground
tush’ and ‘Z’ shaped dynamics. Customer satisfaction (1) starts off fairly high but falls dramatically due to
delayed use of tools and methods.
17
[BRD ecusomersatstacton oye Hvetay Actual Technica Elec. 4: Process Efectneness 5: Requirements Enginees
2: 10.50 a
3 oso «|
ae
4 0.00 LAL ae
it eae —— 2
Figure 12: Changes in Customer Satisfaction, Process Effectiveness and Engineers
This makes communication between analysts and customers difficult initially but improves later in the
project. Shortened and delayed requirements changes have a dramatic effect on completion time. A delayed
requirements change is mainly due to delay in hamessing technical effectiveness (4) in many software
development organisations. Improvements in technical effectiveness reduced the requirements volatility
and the need to increase number of requirements engineers on the project. This is in line with Brooke’s law
(Brookes, 1978) described in Abdel-Hamid and Madick (1990).
Requirements volatility has a major impact on cost, and quality. Due to high levels of errors discovered,
demand for RE services (2) continuously increases due to pressure (4) for process improvement.
4 70.00 r
a1 2°
a la
3 0.63" ot
4: 35.00 bd oe
ene
1: 0.50 Zoe |
2 1.00 a oe
;
2% 0.25 _ r
‘ 000 | ee
& 0.00% a
Figure 13: Effect of Fluctuating Requirements on Technical Effectiveness and Demand for RE Services
However due to non-linearity of activities in the requirements engineering process perceived specification
size (4) behaves differently as initially demonstrated in the literature.
This section has modelled explicitly the effects generated by key variables explored in this paper and
provides a basis for discussing general insights derived from the RE engineering process model. I would
like to concur with Wolstenholme et al (1990), who conclude that it is “the process of interpreting the
results obtained by super-imposing the model which gives rise to an understanding of how the results are
actually generated”. The RE process model relationships are based on the views of requirements
18
engineering process stakeholders, thus their insights captured into the model shed light on fundamental
aspects of the real requirements engineering process.
However, it should be noted that the RE process model-based theory has not studied the performance of a
RE process under a number of different scenarios. Undertaking scenario analysis will undoubtedly unfold
some weaknesses in the model. This process points the model in areas of further work will be directed.
8. Insights Generated by the RE Process Model
The model accurately replicates most of actual process patterns. The model produced typical behaviour of
schedule, quality and cost although it did not replicate the exact figures. In the SD study the focus is on
behaviour rather than on numbers (Coyle, 1996); Forrester and Coyle, (1998); and Wolstenholme et al
(1990). As already articulated, the model aims to provide a platform for debate and enhanced understanding
of problems in the RE process. This paper developed prescriptive and descriptive model by applying
System dynamics modelling concepts. This section identified resource, product, processes and information
feedback between states. This paper explicitly modelled the requirement engineering process dynamics and
simulated the process. The resulting generic model can be used as a tool by which problems in the
requirements engineering process management can be explored and explained and appropriate decisions to
change taken jointly by the owners of the problem. (Wolstenholme 1994, Coyle 1996). The rigour of the
model and the modelling process facilitates the understanding of the RE process and will facilitate process
enactment and technology development.
This section describes some of the initial insights generated by the model, which have arisen through this
research programme. These insights demonstrate how system dynamic modelling approach could be applied
to requirements engineer process. Further insights may be explored in the light of areas of future research
discussed section 9. It is intended that such insights show how using dynamic synthesis methodology based
on system dynamics modelling approach can generate ideas for extended debate in facilitating
understanding of the issues rather than opinions or suggestions concerning model-based tool.
Insight 1
In a system like the model, which supports automated planning and control, problems might occur where
adjusting cost, delays or effects. This aspect of target specification was highlighted through the observations
of an unexpected dynamics in the model outputs. It was found that where the scheduled completion time
was assigned the model-produced value, which is over the maximum allowable scheduled date. This
variable (Scheduled Completion Date) was found not to have any substantial effect on expected delivery
time. This is contrary to the position stated in the literature (Abdel-Hamid and Madnick, 1990; Boehm,
1981).
Insight 2
Technslogy and Critical Success Factors of the Software Development Organisations were found to have
effect delivery times rather than on Scheduled Completion. Date as initially designed. This is very important
and fundamentally very difficult question generated by the model which requirements engineers,
researchers and project managers will have to deal with.
Insight 3
As suggested by Wolstenholme (1990) an interesting aspect of insight generation is that structures that give
Tise to them are often generic. This is illustrated in the fact that the problems of requirements error rework
are associated with the allocation of manpower for rework. Use of generic structures like prescriptive theory
in requirements engineering process provides a way of generating further insights, which are not always
obvious to practising managers or requirements engineers. Key variables that seem to generate behaviour in
the Model are summarised as:
= Project Size
Software Development Organisation’ s seasonal critical factors
= Customer satisfaction
= General impact
= — Technology Use
As illustrated by this case study, this paper seeks to understand problems of RE from a feedback control
point of view. The model developed provides a fulcrum for debate and enhanced understanding of the RE
process. The model should not be viewed as an answer to the problems, but rather as a vehicle for exploring
19
many of the problems reported in the literature. The model offers a useful basis for research on decision-
making process in Requirements engineering. This section identifies a number of propositions (P1, P2, P3)
that can be drawn from it and suggests how they may he tested.
P1: There is a time lag between the requirements engineer gaining understanding of the system’s
technical potential and the customer’s understanding of their own requirements at the time of
requirements volatility.
The model offers a basis for capturing the mental models of RE stakeholders and facilitating understanding
of their decision-making processes during the RE process. There is no theory or research, which relates
directly to the mental models of RE stakeholders, or to the impact of requirements volatility on the SDO
processes or RE stakeholder mental models. The model thus provides a basis for generating new
knowledge about the decision-making processes of RE stakeholders through shared mental models of the
decision making process. It has been stressed throughout the paper that there is little theory or research on
decision-making in requirements engineering process modelling. The model makes a useful starting point
for developing a theory of the of RE process modelling and analysis.
P2: The quality and availability of information has a major impact on the SDO’s capacity to respond to
requirements volatility and customer satisfaction on RE process modelling decision-making.
P3: Requirements Reprocess stakeholders who have access to high quality information, and use those
systems to support decision-making, are likely to make more effective RE process decisions than those
who do not have such systems at the time of requirements volatility.
The model’s most distinctive feature is that it can deal with both hard and soft aspects of decision-making.
As suggested previously, the inadequacies of purely hard or soft approaches make it difficult to capture the
complex relationships and feedback loops that characterise decision-making processes. As a tool the model
can be used by practising managers in a learning situation to reduce the uncertainty about requirements
volatility by highlighting the factors that influence decision-making during the RE process. This “fly by
wire” concept of the leaming process has been used in organisations to facilitate learning but it has not
been used as a basis for developing RE process stakeholders’ decision-making effectiveness. This paper is
a contribution to the literature on requirements engineering process modelling and model-based systems
engineering debate.
This paper seeks to understand RE process problems from a feedback control point of view. The SD model
developed provides a fulcrum for debate and enhanced understanding of the problems. SD has been
acknowledged as an excellent medium for exploring and identifying knowledge gaps (Wolstenhome,
1991), but it has not been utilised in the requirements engineering process domain. The theory developed in
this research applies SD modelling techniques to model and analyse the RE process and to be developed.
The use of both qualitative (casual loop diagrams) and quantitative modelling techniques (Stock and flow
Diagrams) Morecroft, 1987; Forrester, 1961; Richardson, 1990; Wolstenhome, 1991; Coyle, 1996) in SD,
is of beneficial effect in communication between different stakeholders, and understanding through
explanatory insights generated from complex models like those frequently identified in RE process.
The model can be used to investigate the effects of possible changes in customer perception of the progress
or as a result of prioritising requirements and freeing others for future exploration. Due to the flexibility
and customisable capabilities of the generic model developed, can be further improved to represent domain
specific requirements engineering process. Such a domain specific model will allow for examination of
different forces at play in each application domain, also for a more accurate representation of the schedule
of the required complexity and associated quality and costs. Particularly, the model also extends the
existing Abdel-Hamid and Madnicks' (1990) model to allow more holistic study of the software
development dynamics. This extension may be achieved by adding a RE process model which was absent
from the published model (Williams, 1994).
9. Towards a SD Theory of Requirements Engineering Process
Existing Software Engineering process models like CMM, Bootstrap, SPICE and ISO 9000 Standard
identifies several prerequisites and technical practices that enable an organisation to consistently achieve
these goals, BUT they do not prescribe specific requirements process modelling and analysis that SDO
organisations must follow. As discussed in sections three and five, and verified in the feedback-based
20
process behaviour. There are detailed interactions between RE specifications product quality, the SDO’S
resources, Customer satisfaction, the schedule, and cost and activities relating to the nature of the process
itself. These interactions determine the progress and completion time of the RE project. There are several
activities within closed loops of the RE process dynamic theory which are sequential. However, over time
these activities become iterative and continuous as depicted in Figure 14. Figure 14 depicts relationship
between the dynamic theory of the RE process feedback structure and the factors of consequence in the
Requirements Engineering process. The RE process starts with Request for Proposal by the customer to the
SDO, and ends with Delivery of Specification. The representation of these generic activities was
accomplished in the RE process several other activities occur, including:
1. Perception of the need for a new or updated systems software specification by both the
customer and the software development organisation (SDO).
2. Estimation of the desired manpower effort to specify a new or upgraded systems software
specification.
3. Estimation of cost, and schedule of corresponding to the desired effort.
4. Software Development Organisation investment of funds.
5. Acquisition of Project requirements engineers and other supporting resources.
6. Software Development Organisation request for funding.
7. Customer evaluation of the request of funding by SDO with respect to expected project
cost - value resulting to commitment of funds.
8. Specification of the system software and validation and verification of the resulting
product quality.
9. Evaluation of the progress of the project by the SDO and the customer.
10. Reformulation of the process estimates, based on (9) newly acquired experienced and
domain knowledge. The customer and the SDO then present the re-evaluation for
process continued investment.
Request fo for Proposal
Customer < Raieays ny.
+
Perception of the t
Neegige New Evaluation Imprien SS Pou Expected Process
ysiem of Progress Completion time
| ge Customer
Ev:
Estimation of rae ~ ,
Effort
_gutuap bee mel Customer Specific ation an
nganisatigns Fe est for { pectieahon anc
anion
@
Estimation of rd Acaistion of Analysts
‘ost o}
resources Committment of Funds Ang. olen Tesourves
\ Software development
organisation's Investment
of Funds
Figure 14: Dynamic Theory of the Requirements Engineering Process
As depicted in Figure 14, the activities continue to interact until the desired specification has heen achieved
and documented or until the process has been cancelled. Through experimental simulations the key
influences upon requirements engineering process effectiveness have been isolated and studied and
explicitly modelled. The factors of consequence emerging from this research as indicated by the direction
and polarity of influence can be grouped in five categories:
21
Size, data and complexity relating to the system software being specified;
Critical success factors involving the SDO;
Customer's external influences;
Influences resulting from the very process of doing requirements engineering, particular as a
social process.
= — Technology availability and maturity for the SDO.
Analyses of relationships between variables indicate that they are many potentially important feedback
loops. Some of these feedback loops return information about the RE process conditions that may be used
in performance effectiveness.
10. Conclusions and Further Work
The requirements engineering process and other features do not happen instantaneously. Understanding the
nature and the size of delays which constraint these process flows is important in relating RE process
structure to behaviour. Introducing the variability in delays can be potentially effective tool for improving
RE process modelling and analysis performance. Several of the relationships between process, product and
resources are non-linear in nature. In particular the relationship that describes specified requirements
between different activities can be described with non-linear relationships better than the linear
approximation. It is these improved descriptions that expand the range of RE process, product and resource
relationship, which can be modelled. This is true particularly if there is need to acquire new technology
then decreasing training time on the use of new tools and methodology results in rapid process industry and
technological integration. This time delay effect can also be avoided if at the start of the RE process there
are more engineers.
Further work will be directed towards validating the system dynamics theory of the RE process. In order to
test the above propositions it is necessary to establish confidence in the model. Forrester and Senge (1980)
propose three main tests for establishing the validity of SD models. These are: tests for model structure,
tests for model behaviour and tests for policy implications. With regard to model structure, the model
proposed in this paper could be tested by comparing its structure with the descriptive knowledge elicited
from RE case studies in interviews. The second test applied to establish confidence, could be carried out by
comparing the behaviour of the model with the observed real-life decision-making behaviour of RE process
stakeholders who take those parts in a simulation of organisational change. The results of this stage of the
testing process may indicate aspects of the model that need to be refined. The third test - for policy
implications of the impact of process effectiveness can be implemented by empirical observation.
I intend to carry out a programme of research to validate the model and test the propositions that may help
explain the effectiveness of the RE process. I aim to undertake a survey that will identify characteristics of
RE process and decision-making stakeholders relevant to research on RE process performance behaviour.
RE process stakeholders in the survey who indicate that their organisation is undertaking a RE process
would be randomly selected for a series of interviews and group modelling exercises based on case
scenarios of requirements volatility. The aim would be to capture their mental models of the decision-
making processes and ascertain whether the effect of requirements change on the participants corresponds
with that predicted in the model. The data gathered about the individuals and their organisations would be
used to test specific propositions. The paper indicates that a great deal of work has been carried out on the
nature of managerial decision-making but that very little has been undertaken on understanding the RE
process performance effectiveness. While this is useful as a first step, it was argued that a systems
thinking/systems dynamics approach is necessary to understand the process of decision-making in RE
process (Flynn and Williams, 2000). The advantage of SD is not merely that it captures the complexity of
decision-making processes; it also offers a way of exploring the impact of requirements volatility on RE
process performance over time. The paper described the model in outline, identified initial propositions that
can be derived from it and suggested how these may be tested empirically. The value of the model in both
theory building and in learning/training situations was highlighted. It was suggested that it may provide a
framework for building a body of knowledge on RE processes modelling performance. The final part of the
paper explained how the data would be collected for empirical analysis and highlighted the potential value
of the research for both theorists and practising managers.
22
References
Abdel-Hamid T and Madnick S. E, (1990)., Software Project Dynamics - An integrated approach. Prentice-
Hall Inc., New Jersey USA.
Adelman, L. (1 992). Evaluating Decision Support and Expert Systems. New Y ork: Wiley.
Aldag, R.J. and D.J. Power (1986). "An Empirical Assessment of Computer-Assisted Decision Analysis."
Decision Sciences, 17(4), 572-588.
Anthony, R.N., (1965) Planning and Control Systems: A Framework for Analysis. Boston: Harvard Graduate
School of Business A dministration.
Argyris, C. (1966). Interpersonal Barriers to Decision-Making. Harvard Business Review. March -
Boehm B. W., (1981), Software Engineering Economics, Prentice Hall, 1981
Checkland, P. (1981). Systems Thinking, Systems Practice. John Wiley and Sons.
Checkland, P. B and Scholes.J, (1990) Soft Systems Methodology in Action, Wiley, Chichester
Cheyney, P.H., Hale, D.P. and Kasper, G.M. (1989). Information Systems Professionals: Skills for the
1990's. In Strague, R.H. 9ed.). Proceedings of the 22"! Annual Hawaii Conference on Systems Sciences.
Washington DC IEE Computer Society Press. Pp 331-336
Clark, T. D and Augustine, F. F, (1992) Using system dynamics to measure the value of information in a
business firm, System Dynamics Review Vol: 8 No 2 pp: 149-173
Cooke, S. and Slack, N. (1984). Making Management Decisions. Prentice Hall
Costello, R.J. and Liu, D.-B. (1995). Metrics for requirements engineering. The Journal of Systems and
Software, 29(1): 39-63.
Coyle R. G (1986) Comment on System dynamics and operational research: An appraisal, European Journal
of Operational Research Vol.: 23 pp 403-406.
Coyle, R. G., (1996). System Dynamics Modelling--A Practical Approach, London: Chapman & Hall. 413
Pp.
Curtis, B. Krasner, H. and Iscoe, N. (1988). A Field Study of the Software Design Process for Large Systems.
Communications of the ACM, 31(11): 1268-1287.
Davis, A., Overmyer, S., Jordan, K., Caruso, J., Dandashi, F., Dinh, A., Kincaid, G., Ledeboer, G., Reynolds,
P., Sitaram, P., Ta, A. and Theofanos, M. (1993). Identifying and Measuring Quality in a Software
Requirements Specification. I 1st International Symposium on Software Metrics pp. 141-152
Dean, J. W. and M. P. Sharfman (1993). "The Relationship Between Procedural Rationality and Political
Behavior in Strategic Decision Making." Decision Sciences, 24(6), 1069-1083.
Docherty, P. and Nyhan, (eds.). (1997). Human Competence and Business Development. Springer-Verlag
Drummond, H. (1993). Effective Decision-Making: A Guide for Management. Kogan Page.
Eden, C. 1980. Modelling Cognition in Complex Decision Problems. Journal of Interdisciplinary Modelling
and Simulation 3: 119-144.
E] Emam, K. and Madhavji, N.H. (1995). A field study of requirements engineering practices in information
systems development. In Second IEEE International Symposium on Requirements Engineering, pages
68-80. IEEE Computer Society Press.
Finkelstein, L (1982) Theory and Philosophy of Measurement. In Handbook of Measurement Science,
Volume 1: Theoretical Fundamentals: P.H Sydenham (ed.), Wiley
Fenton and Pfleger (1996)*
Flynn, V. and Williams, D.W. (1998). A Framework for Understanding the Factors that Influence the
Decision-Making Behaviour of IT Managers as an Aid to Improved Competence in Decision-Making 4"
Intemational Competence-Based Management Conference, Oslo, Norway,
Ford, D. N., and J. D Sterman (1996) Dynamic Modelling of Product Development Processes. Proc. Of the
1996 International System Dynamics Conference, Cambridge, Mass: Vol. 1
Forrester, J. W. and Senge, P. (1980), Tests for Building Confidence in Systems Dynamics Models. TIMS
Studies in the Management Sciences 14, pp209-228. North-Holland Publishing Company.
Forrester, J. W., (1961) Industrial Dynamics. The MIT Press, Cambridge MA.
Fripp, J. (1985). "How Effective are Models?" OMEGA, The InternationalJ ournal of Management Science,
13 (1), 19-28.
Galliers R.D. (ed) (1984) Information Systems Research: Issues, Methods and Practical Guidelines.
Information Systems Series., Alfred Waller Ltd Henley-on-Thames
Janis, I. L. (1971). Groupthink. Psychology Today. November 1971.
Janis, I. L. (1989). Crucial Decisions: Leadership in Policy Making and Crisis. The Free Press Macmillan.
Jones, P. (1996). The Mystery of the IT Managers. Infomatics. September
Keys. P (1988) System Dynamics: A methodological perspective. Trans. of Institute of Management Control,
Vol. 10, No 4, July - Sept pp: 218-224
23
Liang, T. (1 987). "User Interface Design for Decision Support Systems: A Self-Adaptive Approach."
Information & Management, 12, 181-193.
Loucopoulos. P., and Karakostas.V ., (1995) System Requirements Engineering., McGraw-Hill.
Macaulay, L. A., (1996) Requirements Engineering A pplied Computing., Springer
Mallach, E. G. (1 994). Understanding Decision Support Systems and Expert Systems. Burr Ridge:Irwin.
March, J.G. and Simon, H.A. (1958) Organizations. John Wiley and Sons.
Meadows, D. M,,. (1982), Lessons from Global Modelling and Modellers Features Vol.: 14 pp:111-121
Meadows, D. M,. (1982), Whole Systems: Whole Earth Models and Systems, The CoEvolution Quartely.,
Summer pp: 98-108
Morecroft, J. (1988). Systems Dynamics and Microworlds for policymakers, European Journal of Operational
Research Vol: 35 North-Holland, pp: 301-320.
Morecroft, J. D. W. (1979) An integrated approach to Industrial Dynamics. Working Paper, Sloan School of
Management, MIT Cambridge, MA 02139
Morecroft, J. (1990). Strategy Support Models. In Strategic Planning: Models and Analytical Techniques,
ed. R.G. Dyson. Chichester, U.K.: Wiley.
Newman, M. and D. Robey (1992). A Social Process Model of User-Analyst Relationships. MIS Quarterly/
June pp: 249-266.
Pidd M, (1992)., Computer Simulation in Management Science. John Wiley & Sons Ltd, UK.
Pohl, K. (1993). The three dimensions of requirements engineering. In Rolland, C., Bodart, F., and Cauvet,
C., editors, 5th International Conference on Advanced Information Systems Engineering, pages 275-292.
Springer-Verlag.
Roethlisberger,F.J. and Dickson, WJ. (1939). Management and the Worker. Cambridge MA: Harvard
University Press.
Simon, H. A. (1960). The New Science of Management Decisions. New Y ork: Harper and Row Publishers.
Sprague, R. H. and H. J. Watson (1 996). Decision Supportfor Management. Upper Saddle River: Prentice-
Hall.
Standish Group (1986)*
Sterman, J. D (1989) Modelling Managerial Behaviour: Misperceptions of feedback in a dynamic decision-
making Experiment, Management Science, Vol: 35. No 3. Pp: 312-339
Stoner, J. (1968). Risky and cautious shifts in-group decisions: the influence of widely held values. Journal of
Experimental Social Psychology. 4.4. pp. 442-59.
Tan, J. K. H. and 1. Benbasat (1993). "The Effectiveness of Graphical Presentation for Information
Extraction: A Cumulative Experimental Approach." Decision Sciences, 24(1), 167191.
Taylor, R. N. (1984). Behavioral Decision-Making. Scott Foresman.
Turban, E. (1 995). Decision Support and Expert Systems: Management Support Systems, Fourth Edition.
New Y ork: Maemillan.
Wieringa R.J., (1995) Requirements Engineering: Frameworks for Understanding., John Wiley
Williams, Ddembe.W., and Kennedy M. S (1997). A viewpoints conceptual framework for improving the
organisational information requirements: A System Dynamics perspective. In Y aman Barlas, Vedat G.
Dicker and Seckin Polat Eds.15th International System Dynamics Conference, Istanbul, Turkey, Vol 2,
pp: 475-479. System Dynamics Society.
Williams, D., and Kennedy (1999) A Framework for Improving the Requirements Engineering Process
Effectiveness, International Council on Systems Engineering 1999 Conference, Brighton, UK, 5- 11
June
Williams, D., Hall, T and Kennedy (199 9) A Framework for Improving the Requirements Engineering
Process Management, In Eds: C. Hawkins, G. King, M. Ross and G. Staples Managing Quality : Proc. of
Software Quality Management Conference, Southampton, UK, 29 - 31 March. pp 203-217
Williams, Hall and Kennedy (2000) A Framework for Improving the Requirements Engineering Process
Management, Software Quality Journal Vol: 8 (2) pp 1-15
Wolstenholme E. F, (1990) "System Enquiry-a System Dynamics Approach", Wiley, Chichester
Young, L. F. (1 989). Decision Support and Idea Processing Systems. Dubuque: W. C.
Zahedi, F., (1995) Quality information Systems, Boyd & Frazer Publishing Company Danvers, Mass., USA
24
