A Review of the Impact of Requirements on Software Project Development Using a Control Theoretic Model

Software projects have a low success rate in terms of reliability, meeting due dates and working within assigned budgets with only 16% of projects being considered fully successful while Capers Jones has estimated that such projects only have a success rate of 65%. Many of these failures can be attributed to changes in requirements as the project progresses. This paper reviews several System Dynamics models from the literature and analyses the model of Andersson and Karlsson, showing that this model is uncontrollable and unobservable. This leads to a number of issues that need to be addressed in requirements acquisition.


Introduction
Software projects have a low success rate in terms of reliability, meeting due dates and working within assigned budgets [1][2][3] with only 16% of projects being considered fully successful while Capers Jones has estimated that such projects only have a success rate of 65%.The American "Standish Group" has been involved for 10 years with research into ICT.In their research, they aim to determine and change success and failure factors regarding such projects.Their study, which has been appropriately baptised "Chaos" [4,5], appears every two years.This study also shows that in 2003 only 34% were successful, 51% did not go according to plan but ultimately did lead to some result and 15% of the projects fail completely.
Despite these failures significant progress has been made in the use of System Dynamics methods to describe the development of software projects.The models of operation of the software development process were described by the successful System Dynamics (SD) models based on the work of Abdel-Hamid & Madnick [6], which set up equations relating levels such as the number of perceived errors, or the number of reworked errors and relates them to rates such as the error detection rate or the rework rate, significant features of these models included the decision processes.These models were validated against NASA project data for a medium size project and the agreement is strikingly good.
Many of these failures can be attributed to changes in requirements as the project progresses.Capers-Jones [7] states that as the project gets larger the probability of requirements creep becomes more likely, typically 1-2% per month and as high as 10% in a single month.Lorin May [8] talks about poorly established guidelines that determine when requirements should be added, removed and implemented.Deifel and Salzmann [9] describe a view of "requirements dynamics" relating to the process of changing requirements.They go on to develop a strategy to deal with the regime in which some requirements are invariant and some migrate.
Coulin et al. [10] state that "the elicitation of requirements for software systems is one of the most critical and complex activities within the development cycle" and that "this is preformed after project initiation and preliminary planning but before system conception and design."This would not be strictly true if evolutionary or iterative methods were used.The later the requirements in the cycle of development change, the more costly is that revision (Boehm & Pappacio [11]).It is certainly the case as Hoorn et al. [12] report that owing to many shifts in focus and priorities, stakeholders become inconsistent about what they actually want to accomplish with the system.If we are to improve the requirements process then proper models of a process are needed.Kotanya & Sommerville [13] outlines the requirements engineering process as shown in Figure 1.Although there is feedback between requirements validation and specification and in the elicitation and specification as will be shown this is not represented in the current models.It is not clear in any of the texts on the subject whether the involvement of the use is mandated at these stages.
The whole purpose of this paper is to present simple control system models of the project development process including requirements, as in inventory analysis, and demonstrate rules for stability.

System Dynamics
Wolstenholme [14] describes System Dynamics as: "A rigorous method for qualitative description, exploration and analysis of complex systems in terms of their processes, information, organizational structure and strategies; which facilitates simulation modelling and quantitive analysis for the design of system structure and control".
This definition is expanded in Table 1 taken from Wolstenholme.
The SD model structure is highly non-linear with a number of theoretical assumptions, for example about how the errors in the coding are propagated.
These structural assumptions do not allow for System Dynamics models to enable any general rules to be developed by academics for managers to make sound judgments based on good analysis.The distinction with models of inventory processes, which are related, is the rationale for this research program.Early SD invent-tory models developed by Forrester [15] were also non-linear and contained a number of factors, such as employment rate, that made the problem too complex for simple rules to be developed.
The simplest expression of representation of requirements in SD models is that use by Madachy [16], shown in Figure 2. In this case requirements are added to by a rate of generation, usually constant.The time taken to acquire the whole requirements is dictated by the acquisition rate.Häberlein [17] proposed a different structure for the development of the whole project.In his model (Figure 3) the rate of generation of requirements is split into several phases depending on the comprehension of the supplier and how this is influenced.This model could show considerable promise but no equations are presented.The model of Williams [18] (Figure 4) could not be evaluated further at this time due to incomplete equations.The structure indicated shows dependence on quantities such as customer satisfaction that are not readily measured during the process.The model of Andersson and Karlsson [19] (Figure 5) is the most complete and useful model out in the literature.Not only are all the equations given, with data, but the results are of a project in industry.This model shows that the process of gaining requirements is split into a phase where the level of requirements tasks to be completed is gained via an input pulse function.The required tasks to be completed are fed from the previous state by a constant requirements completion rate.Rework is discovered in these requirements and this is fed back at a constant rate to the first level.Inadequate requirements are discarded at a rate that      is also a constant'.The final finished requirements are fed by a finished requirements rate.A number of non-linear "constants" are embedded into the system.No proper validation is made of this model or any of the models given here (this is normally very difficult).Do any or all of these models match the published material on requirements engineering?In the broadest sense, yes, they do match what is contained in books such as Sommerville.To make further progress let us assume that the Anderson and Karlsson model is correct.This non-linear SD model has been linearised and analysed using control theory to see any general lessons can be learned.

Control Analysis
Part of the simplification of the Project Model is being tackled in the USA by the newer control system models of software testing (Cangussu et al. [20]) and the approach to control of software development by White [21].
In this case the model of Andersson and Karlsson was linearized and the following state equations obtained: The linearized auxiliary SD equations are: (where this is a pulse of height fi, the initial estimate of the number of requirements).
  These equations can be represented by a state-space equation where A, B and B' are given by:   where u = pulse function and v = rprod.In this configuration v acts as a disturbance.
State-space theory can be used to see if this system is either controllable or observable.
We can define two matrices that will allow a measure of these properties if they are both full rank.The control stability is defined by the four eigenvalues two zero and two damped complex conjugates.The system is neutrally stable at best.

Cm = B AB A B A B (17)
The rank of Cm is 1!The observability is given by: The rank of this matrix is also 1.This means that the system described by the linearized state equations is uncontrollable and unobservable!The principle reason for this is that no corrective forces exist to alter the rate of production of requirements and that the rework and inadequate requirements cannot be altered independently of each other.Although a set of parameters will allow the requirements to be produced, once set in train no process exists to vary that process.No variation in workforce for example is set up in this model.No simple solutions allow this model to be put into a controllable form, although it can be made observable.

Conclusions
All the SD models illustrated here would appear to use a constant rate of conversion of requirement wishes from the customer to specifications, depending strictly on staff productivity.The number of staff in the cases cited appears to be fixed at the start of the process and altered only reluctantly, taking no account of project size or complexity.If this is generally true it has severe implications for the later analysis and development of the project.The most comprehensive model cited, due to Andersson and Karlsson has been analysed from a control system viewpoint.This analysis shows that such models are neutrally stable since there are no feedback mechanisms to establish when all the requirements are obtained, and they are neither controllable nor observable.The problem is that only the group of states fr, ir and rtc together are specified, one of them cannot be separately described or made to achieve a particular trajectory If the staff productivity is fixed and the number of staff is decided beforehand then the final outcome is proscribed.They can with some manipulation be made stabilizable.

2 .
To create and examine feedback loop structure 3. To provide a qualitative assessment of the relationship between system process structure, information structure, delays organizational structure and strategy 2. To examine the validity and sensitivity of the model to changes in  Information structure  Strategies  Delays and uncertainties 1.To examine alternative system structures and control strategies based on  Intuitive ideas  Control theory analogies  Control theory algorithms: in terms of non-optimizing robust policy design

Figure 3 .
Figure 3. Requirements as a total process in comparison to Abdel-Hamids' task based mod.