3.1 A philosophical perspective

In the late 1980s W. M. Turski (1986) observed that developing software is inherently difficult because it involves descriptions of properties of both formal and non-formal domains. Formal domains are those which pertain to the artificial, i.e., the software itself and its hardware – man-made artefacts which can be described using fully formal notations, such as code or statements of logic. Non-formal domains are those which pertain to the natural, such as people, organisations or natural phenomena; such domains don’t always allow formal description, and even when they do, different linguistic descriptions are used, which raises the further challenge of how to relate them and reason about them. Consequently, Turski sees developing software as compounding the difficulties of mathematics, in its concern with relationships between formal domains, and of natural science, in its concern with descriptions of the properties of non-formal domains. In Turski’s view an effective software development process would have to deal adequately with descriptions across the formal/non-formal divide.

Building upon Turski’s thinking, M. Jackson and others (Jackson, 1995; Gunter et al., 2000; Hall and Rapanotti, 2003) proposed a view of software development encompassing two distinct but related ‘spaces’: the problem space, in which the problem to be addressed is located; and the solution space, in which the software solution resides. In this view, descriptions, whether formal or non-formal, are further categorised into indicative and optative: an indicative description is a statement of fact – that is, an assumption which is believed to be true and on which further reasoning can be constructed; an optative description is a statement of wish – that is, something we would like to become true at some point. To give an example, a requirement is an optative description, as it states something that it is hoped will be true once the system is designed and operational; on the other hand, an existing business rule is an indicative description, as it states how the business works currently; that is, this is something taken for granted in developing the system.

In this view, specifications provide the point of contact between the two spaces: a specification captures optative requirements as to how the software system should behave at its interface with the real world. As such, the specification can be validated against the problem: we can check whether building a software system to that specification will address the problem; and the software can be verified against the specification: i.e., we can check that the software has been built in such a way that it will satisfy the specification. In this view, therefore, an effective software development process would have to deal adequately with building and separating optative and indicative descriptions across the problem/solution divide, and transform optative requirements before development into indicative statements once the software is in operation.

The work of Turski and of Jackson and others provides useful insights into the nature of the descriptions required in software development, and processes can be, and have been, defined which establish when and where such descriptions are required. However, there are further dimensions to software development which are widely recognised as being highly influential, and which should be taken into account. One such dimension in those descriptions is fitness for purpose – and how this can be established. The other dimension is the design rationale, i.e., the explicit articulation and capture of the reasons behind and justifications for decisions made when designing an artefact, including alternatives considered and trade-offs.

Hall and Rapanotti (2009) have proposed a view of software development as spanning two orthogonal spaces: the design space, to which the descriptions of Turski and Jackson and others belong; and the assurance space, where consideration of design rationale and fitness for purpose take place and related descriptions are generated. In this view, contact between the two spaces occurs throughout the development process, both in the problem and solution spaces, at points at which assurance artefacts are shared and checked by different stakeholders – for example, as with a business analyst checking understanding of business processes with the customer, or a software architect reviewing and approving an architectural blueprint for a system. Hence, the fitness for purpose of any description, from problem statement to working code, can only be established by the stakeholders involved in the process, bringing stakeholders to the heart of software development and highlighting their identification and participation in the process as a key success factor. As a consequence, in this view, an effective software development process would have to deal adequately with building and separating descriptions not just across the problem/solution divide, but also across the design/assurance divide, and would also have to identify key representative stakeholders and account for their involvement in the development process.

Historically, software development processes have focused primarily on the design space. However, the importance of the assurance space has long been acknowledged and recognised, and a parallel discipline of project management has developed in a bid to address some of the assurance needs of software development processes highlighted by Hall and Rapanotti (2009). It should be noted that the importance of stakeholders is also explicitly recognised by Agile development, whose manifesto explicitly values individuals and interactions as well as customer collaboration.