1 Introduction

This paper will, in particular, focus on the claims made in [1]. It suggests that: “the traditional RE research paradigm, in common with most engineering research and practice is founded on the philosophical tradition of positivism.” It goes on to justify this by suggesting that: “requirements engineers being members of the culture of science, often fall back on and operate from a tacit positivism”. It is a stance that has a certain intuitive appeal; the role of abstractions, the status of science, and the lack of formal philosophical reflection, makes its suggestion that positivism may exist as a dogma of requirements engineering seem quite plausible.

Requirements engineering is of course a practical endeavour, and there is hence reason to be sceptical toward philosophical discourse, which may not at first seem to contribute directly to this. Nevertheless, as Popper puts it: “we all have our philosophies, whether or not we are aware of this fact, and our philosophies are not worth very much. But the impact of our philosophies upon our actions and our lives is often devastating.” ([2], p. 33) Philosophical arguments need to be taken seriously, but equally well their presence needs to be carefully justified. In this instance accepting the claim that positivism is fundamental to requirements, could have significant methodological consequences for the field as a whole.

Potts and Newstetter [1] asserts that positivism is a fundamental, and hence unavoidable part of both research and practice in requirements engineering (although they point out that these views may be only tacitly held). The assertion is made clear by the paper’s central sections, in which they discuss the status of naturalistic enquiry (in which they include ethnomethodological fieldwork) as a requirements method. A comparison is made between the principles of naturalistic enquiry, and those of positivism. This highlights a significant philosophical tension between the two, which is proposed as significant because: “accepting that the two approaches are irreconcilable would mean that they could not coexist effectively and that the RE community must repudiate one or the other” ([1], p. 125). The implication of this is clear: positivism is foundational, and any technique one might wish to use in the engineering of requirements must first be reconciled with its commitments. If positivism is foundational to requirements engineering, then this would certainly be a major difficulty for the application of ethnomethodological fieldwork.

Part of the justification given in [1] is that positivism, whether tacit or otherwise, is believed to be fundamental by requirements engineers. This proposition may be difficult to substantiate. The fact that requirements researchers do not perhaps understand requirements practice as well as they ought, has already been noted [3] (indeed some have even gone so far as to accuse researchers of “armchair engineering” [4]). Nevertheless, irrespective of its actual credibility, the very fact that such a claim is being made by researchers motivates an interest in its philosophical plausibility.

This paper will therefore argue to the contrary. Based on a more careful examination it will show that positivism does not in fact turn out to form an acceptable philosophical foundation for requirements engineering. The first consequence of this will be that the implications for using fieldwork presented in [1] may be safely disregarded. The second will be to clear the philosophical ground for future attempts to engage with the foundations of the field.

The paper is structured as follows. Of necessity, it begins with a clear and thorough overview of positivism as a form of philosophy. From this four particular stances are identified and their relevance to requirements engineering explained. Sections 3–10 then present the case against positivism. One of the justifications that [1] gives for positivism, is that the perspective has been inherited from engineering as a whole. Section 3 shows that, although engineering has traditionally been seen as an applied science, more modern understandings reveal science to be only one of many different kinds of essential engineering knowledge. As a consequence, it would be wrong to see engineering as fundamentally positivistic. Sections 4 and 5 both examine potential similarities between the philosophy of positivism and some superficial characteristics of requirements engineering. Section 4 shows that, although the demands of software engineering may appear to suggest a positivistic view, in reality the practices of modern software engineering fail to correspond, either ontologically or epistemologically, with this stance. Section 5 contrasts formal methods for software engineering, against those for requirements engineering. It shows that while formal methods for requirements engineering might initially seem to be one of the easiest techniques to associate with positivism, under scrutiny this association also turns out to be misplaced. Sections 6 and 7 both consider how positivism relates to the activities and opinions of requirements researchers. Section 6 suggests that the orientation of naïve positivism fails to allow engagement with, what leading requirements researchers see as one of the most fundamental challenges in requirements engineering today. Both Sects. 7 and 8 consider scientism. The former examines scientific approaches to requirements research and shows that while the status of science is sometimes unnecessarily privilege, in general, “scientific” and “non-scientific” forms of research are taken to be equally valid. The latter looks at the role of science in requirements practice and concludes that, at best, it would be premature to privilege “scientific” over “non-scientific” approaches. Section 9 considers how arguments from the field of Science and Technology Studies might be used to refute a positivist stance in requirements engineering. Finally, Sect. 10 examines a critical weakness in the positivist position: its inability to fully engage with claims of value, something that is an essential part of engineering requirements.

2 The philosophy of positivism

Halfpenny identifies no less than 12 separate but related forms of positivism ([5], p. 114). Thus, in order to arrive at a proper understanding of this philosophy, it will be necessary to locate it within a broader historical context before identifying those aspects of relevance to RE. The term has its origins in the writings of Comte (1789–1857). He rejected the negative critiques of the enlightenment and instead sought a constructive, scientific era where all phenomena could be understood in terms of invariable natural laws. It became a philosophy of wide-ranging influence, not least in the philosophy of science.

Links with science and mathematics makes it unsurprising that some have associated positivism with software engineering [6–8], requirements engineering [1], and related forms of research [9]. So, in order to be more precise about the ways in which a movement as broad as positivism relates to requirements engineering, and to better understand what Potts and Newstetter might mean by the term, four specific views associated with positivism are outlined below.

2.1 Logical positivism

Logical positivism is one positivist stance, which has been associated by some with the activities of software engineering [6–8]. Philosophically, it characterizes the standpoint of a group of philosophers, scientists and mathematicians, who in the early 1920s became known as the Vienna Circle [10]. In broad terms the group’s position was allied to the work of Hume (1711–1776), Mach (1838–1916), Frege (1848–1925), Whitehead and Russell’s Principia Mathematica (1910–1913), and Wittgenstein’s Tractatus (1922). Logical positivism is perhaps best described as an epistemological movement ([11], p. 29), which sought a new foundation for a variety of fields. Of these, Carnap’s (1891–1970) attempts to find a new foundation for physics were particularly influential. Central to logical positivism is the notion that statements are only meaningful if they are capable of verification. Statements may be either “analytic” or “empirical”; the former, when expressed in a logical calculus, can be verified by inspection; the latter by experiment, measurement and evidence.

Popper’s (1902–1994) view of scientific theories owes much to the work of the Vienna Circle, although Popper counted himself as one of logical positivism’s greatest critics. The hypothetico-deductive method of scientific enquiry which he helped to popularise became perhaps the most well known of all those in the positivist project. Rather than verifying laws Popper’s view of scientific enquiry was one of attempting to falsify hypotheses [12]. However, the origin of these hypotheses is sidestepped as an irrelevancy: “Their source is a psychological or sociological matter, beyond the bounds of the philosophy of logic of science, which restricts itself to analysing the justification for rejecting or retaining whatever hypotheses scientists entertain, regardless of how they come to entertain them” ([5], p. 101).

The philosophy of science was, of course, not the only field of interest to the Vienna Circle. It was felt, for example, that philosophy itself should: “be replaced by the logic of science” ([10], p. 24); economics, sociology, historical analysis, and even poetry, all came to be the subject of similar foundational re-specifications. Carnap used the term “scientific empiricism” to refer to this wider positivist movement with sympathies for the empiricism of Hume, an admiration for the scientific method of 19th century physics, and a willingness, like Russell’s and Wittgenstein’s, to apply logical analysis such as that pioneered by Frege [13].

Within the philosophy of science from the 1920s until around 1950, it would be difficult to understate the influence of logical positivism. However, during the 1950s alternative views began to surface from prominent figures including Toulmin, Kuhn and Feyerabend [14–16]. Logical positivism is also regarded to have failed as a wider philosophical movement. One of its difficulties rested with the principle of verification. This suggested that only verifiable statements are meaningful, yet since the verification principle is not itself verifiable, it is by its own standards meaningless. Similarly, while Wittgenstein’s Tractatus had initially been seen as a shining example of the ideals of logical positivism, close reading by the Vienna Circle revealed significant differences, and his later work famously repudiated even this position.

2.2 Scientism

Logical positivism is perhaps best regarded as an historical movement. Nevertheless, many of the themes it raised are of relevance in contemporary academic debates. For example, the logical positivists gave great value to scientific knowledge, intending to “lift” other fields like economics, sociology, philosophy, and so on, up to the same level. The relationship between art and science is still very much a matter of discussion, and as a consequence the neologism “scientism” has been used to describe: “the belief that science, especially natural science, is the most valuable part of human learning”, or “the belief that science is the only valuable part of human learning, or the view that it is always good for subjects that do not belong to science to be placed on a scientific footing” ([13], p. 1).

Science is undoubtedly afforded an important status in requirements research. Certainly much of the literature seems to draw on science in some way; [17] is a good example, having been awarded best paper at RE’05. It introduces a case study where requirements are gathered for software that is to be personalised for cognitively disabled users; the users are consequently: “assessed by psychology-based questionnaires and tests to measure cognitive, physical and perceptual abilities” (p. 21). Furthermore, there is also a sense in which scientific evidence is preferred in the validation of requirements research. For example, the RE’06 call for papers specifically requests: “scientific evaluation papers”, which should: “evaluate existing problem situations or validate proposed solutions with scientific means.” A scientistic account would suggest that requirements engineering ought to be a scientific activity; it would privilege science over non-science; it would urge researchers to go further in finding applications for science, and developing new science to capture the phenomena of relevance to the field; it would suggest that it is simply the immaturity of the current state-of-the-art that prevents requirements from being a science.

2.3 Naïve positivism

While science may be considered important, many requirements activities seem to occur without it, and yet still appear positivist in nature. One term, which may help to describe this is “naïve positivism”, which is perhaps best understood as a label for the tacit positivist standpoints that still remain in a number of fields. For example, in the social sciences it is often used to refer to a belief in the objectivity of theories: “in the social sciences today there is no longer a God’s-eye view that guarantees absolute methodological certainty. All inquiry reflects the standpoint of the inquirer. All observation is theory-laden. There is no possibility of theory- or value-free knowledge. The days of naive realism and naive positivism are over” ([18], p. 3; for examples of its use in other fields see: [19], p. 6; [20], p. 57; [21], p. 9).

In requirements, the term ‘naïve positivism’ might be most relevant to the activity of modelling. For example, it is often the case that a model is made of the problem, which is to be solved. This usually involves the use of typical engineering skills like abstraction and decomposition. Naturally, the fidelity of these diagrams will be dependent on the skill of the analyst—what is particular to naïve positivism is a belief that this activity is unproblematic. The identification of abstractions within the world is neither one that is worthy of special methodological support, nor of investigation as a topic of research in its own right. Naïve positivism in this context holds that formal structures and theories can be unproblematically identified within the world, by the analyst. Scientific justification of such structures is thus unnecessary.

2.4 Realism

Realism is an ontological position, which takes things in the world to exist, and allow those things to have properties, independent of the observer and irrespective of their beliefs, conceptual schemes, or linguistic practices. It is a stance that is relevant to any number of areas. For example, science is concerned with investigating the properties of the natural world; a realist stance would take the objects under study within the world to exist independently of the individual doing the investigation. Similarly, ethics is concerned with the study of value or quality; a realist stance on ethics would take moral facts to actually exist, and be objectively true independently of the beliefs of any particular person. Realism remains the subject of much debate within philosophy, and it is accepted that one may adopt a more-or-less realist stance toward individual issues; for example, it would be regarded as philosophically consistent to be a realist for the purposes of scientific investigation, yet anti-realist with respect to moral values [22].

The relationship between positivism and realism is not simple, as the terms are sometimes conflated, or used together (as the citation from the previous section does). Moreover, logical positivism, one of the best-developed forms of positivism, is generally anti-realist ([23] provides an explanation of this tension). Despite huge differences, Popper and Durkheim are both though of as positivists [5], and both adopt aspects of realism. Popper argued for a realist view of both the objects of scientific study, and the scientific facts that such study produces. Scientific facts exist in the world, ready to be discovered, independent of the enquirer, through a process of conjecture and refutation. Knowledge is therefore really “out there” in the sense that: “we can make theoretical discoveries in a similar way to that in which we can make geographical discoveries” (p. 74) [2]. Similarly, for Durkheim (1858–1917) one of sociology’s founding fathers, social facts were objectively and ontologically real, and able to exert their influence on the behaviour of a society. It is relevant to consider realism as part of this discussion on positivism because it represents an important strand in the general positivist attitude, and especially the naïve positivism considered above.

For requirements engineering the realist stance may be relevant in predominantly two respects. Firstly, one may choose to be a realist with respect to domains. For example, a requirements domain model might be taken to be a reflection of an ontologically real set of objects, which exist independently of the author; thus any model of that domain will for all practical purposes be the same, irrespective of the author. Secondly, one may choose to take a realist stance toward requirements themselves. Under this view, interviews and conversations with a stakeholder are to be considered as clues as to the true nature of the requirements, which are really “out there” independently of the particular stakeholder or requirements engineer ([24], p. 1).

3 Modern understandings of engineering

As Rogers suggests, engineering is an overwhelmingly practical field, traditionally much more concerned with worldly outcomes than philosophical reflection ([25], p. 3). In this respect it is difficult to assign its activities a philosophical orientation. However, traditional views of engineering often give it a scientistic rendering. Such views take engineering to be a derivative field, where the production of new knowledge is the preserve of science, and engineering is hence concerned with realizing the “implications” of such discoveries ([26], p. 148; but also pp. 177–185, and by definition in [27]). Commentators too highlight a relationship with science. Petroski, for example, describes how: “Engineers hypothesise about assemblages of concrete and steel that they arrange in the world of their own making. Thus each new building or bridge may be considered to be a hypothesis in its own right” [28]; his descriptions have clear parallels with the positivism of Popper’s falsificationism.

This simplistic characterization is challenged by more recent academic work such as [29–31]. Through historical case studies, they present a more realistic picture of technological development. Vincenti in particular begins to describe an independent epistemology for engineering; he shows engineering to be a distinct field of knowledge, neither solely dependent on science to provide it with theories, nor on the scientific method as a means of generating its own. This research shatters the scientistic view of engineering.

For example, research methods like destructive testing provide vital information to engineers, yet would have little standing within the scientific community (p. 232). Another source of knowledge is to be found in the analogies of engineering design; by way of illustration, he describes how engineers think about the “directional stability” of an aircraft by analogy with a weathercock; so called “weathercock stability” is then a concept that can help both engineering design and engineering education (p. 221). To choose one final example, he also highlights the importance of practical knowledge (p. 217): “Theoretical tools and quantitative data are by definition, precise and codifiable; they come mostly from deliberate research. They are not, however, by themselves sufficient. Designers also needed for their work an array of less sharply defined considerations derived from experience in practice, considerations that frequently do not lend themselves to theorizing, tabulation, or programming into a computer... [a] seemingly simple but actually complex example is knowing the clearance that must be allowed for tools and hands in putting together assemblies for which the worker must reach inside. Such knowledge is especially difficult to define, since the requirement depends in part on the spatial relationship of the parts of the assembly and the position required of the worker. Knowledge of this kind defies codification, and a mock-up or prototype must often be built to check the designer’s work.” Vincenti shows that “real” engineering work consists of much more than simply applying science.

A naïve positivist view of engineering, is also challenged by recent research. Bucciarelli’s anthropological study describes how engineers work with “object worlds” [32]. These structured, hierarchical worlds (p. 86), often involve representations that give engineers a view of the world with which they can work (p. 67). The parallels between naïve positivism and “object worlds” are deliberate, enabling him to demonstrate the contrary. Far from being naïve positivists, he describes the care with which engineers construct their abstractions, and the deeply social nature of this work.

Potts and Newstetter [1] takes positivism to have a foundational role in engineering; the kind of accounts presented above give significant reason to doubt this assumption. But more than this, they suggest the tantalizing possibility that similarly sophisticated accounts of requirements engineering may be possible.

4 Software engineering and requirements

Potts and Newstetter [1] claims that requirements engineering is founded in positivism because: “it is compatible with the need to capture and tie down clear-cut features that can be modelled and turned into artefacts.” It is a claim that seems to imply that the philosophy of requirements should be driven by the needs of those who use such requirements; that software engineering should be allowed to exert a coercive influence. In some respects this seems quite reasonable, after all, requirements are only ultimately valuable if they are of utility to software developers. The positivist view of requirements might therefore be justified by reference to two critical properties of software engineering. Development, first of all, is often conducted at a distance from the users or stakeholders of the system under development. This means that requirements models or documents often stand in place of stakeholders themselves. Software engineering is thus deeply dependent on representations of requirements, rather than having those requirements articulated more directly. Second, and fundamental to mainstream software engineering methods, is the idea that these requirements representations must remain stable, for the duration of a development iteration at the very least, and preferably for the duration of the project as a whole. For software engineers, the ideal representation is one that has a stable and objective relationship with a stakeholder requirement. On the surface it may seem as if software engineering is positivistic in its treatment of requirements. However, on closer examination any resemblance can be shown to be entirely superficial. Of course software engineering may see it as desirable to have stable objective requirements, what is at issue is whether they actually view them in this way. To further unpack this concern two specific resemblances will be examined. The first considers whether software engineering is positivist in its epistemic treatment of requirements. The second considers whether software engineering is realist in its ontological treatment of requirements.

Software engineering is often iterative in nature, and so requirements may be revisited repeatedly during the course of a project. Requirements might therefore be seen as parallel to scientific theories, which under a falsificationist paradigm appear to develop in a similar way. The resemblance is hence as follows: software engineering appears to demand stable objective knowledge; the positivist view treats scientific knowledge as objective and stable; and at a practical level, software engineering appears to treat requirements in a similar way to a positivist view of scientific theories. As a consequence one might easily conclude that software engineering is positivist in its epistemic view of requirements. However, a more careful examination reveals this kind of positivist ascription to be misplaced.

In Popper’s conception, scientific knowledge must be falsifiable. The fact that current knowledge has not yet been falsified, and that there exists a community of scientists whose careers would benefit from so doing if it were possible, means that for the moment at least, such knowledge can be trusted; and indeed, for long periods of time, this may be very much the case. On first inspection modern iterative software development, which affords multiple opportunities to revisit requirements activities, may seem similar to Popper’s view of science as a sequence of failed theories. However, the way in which this sequence is envisioned in software engineering, is radically different. Unlike scientific theories, iterative software development explicitly plans at the outset for the revision of the requirements it produces. This expectation, that the revision of requirements is inherently necessary, independent of any attempt to investigate their truth or falsehood, renders claims of epistemic similarity mistaken. Rather than ever seeing them as objectively true, it would seem that software engineering treats its requirements more pragmatically, as perhaps a succession of working approximations. This pragmatic orientation is not at all the same thing as a positivist stance, and the proposed resemblance is therefore illusory.

The second concern, which will be investigated is ontological in nature. Realism is arguably part of the natural scientific attitude, and is also often associated with a naïve positivist position. A realist perspective would assert that scientific theories are representations of phenomena that are really out there in the world. It is essential to its status as “real” that each phenomenon is independent of other phenomena, and of any individual who may attempt to observe it [2]. Once again it is easy to see how parallels between the theories of science and the requirements of software engineering might be drawn. A naïve reading of the software engineering process suggests that: requirements elicitation provides information about a domain, which is then subject to analysis in order to find the requirements expressed within it. The requirements engineer is thus akin to a “butterfly catcher”. This resemblance might lead one to conclude that software engineering adopts a realist view of its requirements. But once again, a closer examination reveals this realist ascription to be misplaced.

Jacobson et al. [33] provides a mainstream view of software engineering. It describes the way in which requirements are produced in iterative software development, suggesting that after inception they become dependent on the system’s emerging architecture (pp. 65–69). So, stakeholders inform requirements, requirements inform architecture, and then architecture and stakeholders both further inform requirements. Jacobson et al. [33] describes how architecture is based on a whole raft of concerns, constraints, enablers, and the experience of the engineers involved. These skilled professional judgements then inform the ongoing evolution of the requirements. It is therefore clear that software engineering does not see requirements as being independent from the individuals who are investigating them, and as a consequence, that a realist stance with respect to requirements cannot uniformly be ascribed to it.

In sum it is wrong to ascribe positivist and realist positions to software engineering. The simple fact that requirements are frozen for a development iteration, seems more likely to be driven by practical necessity, than a belief in their objective truth, or ontologically real character. Moreover, the close examination of software engineering provided above, shows that aspects of it contradict such claims. A positivist view of requirements thus contradicts aspects of that which is considered by many to be best practice within software engineering. The idea that one should take a positivist view of requirements because of supposed constraints imposed by its parent discipline is thus wholly misplaced.

5 Formal methods and requirements

Given their shared emphasis on mathematical deduction, it is perhaps unsurprising that some have associated formal methods for software engineering with logical positivism [7]. Moreover, given the obvious similarity between formal methods for software engineering and formal methods for requirements engineering, it is easy to see how some could assume that the latter might “inherit” this positivist foundation. However, a more careful comparison between the two shows this to be an unwarranted assumption.

Although formal methods sometimes view their craft as being an abstract mathematical one, at a philosophical level they are nevertheless concerned with reasoning about a physical phenomenon—the behaviour of computing hardware.Footnote 1 They are often concerned with proving that one formal model is “equivalent” to another, a task, which therefore aims ultimately to prove that the two models represent two equivalent sets of physical computational behaviours. Each step of such a proof might consist of an application of a calculus rule, each rule might relate to the behaviour of a programming language element, whose behaviour ultimately depends on the behaviour of a physical computer processor. The validity of the proof step, is dependent on the validity of the calculus rule, whose verification therefore ultimately depends on the science of semiconductors. The justification of proofs in formal methods for software engineering are thus epistemically founded in science. This combination of empirical science and logical calculus, makes it easy to see why some have associated formal methods for software engineering with logical positivism.

The story of formal methods for requirements engineering is, however, quite different. The goal-oriented work of van Lamsweerde et al. [36] is particularly interesting as a contemporary approach to developing formal requirements models. Although such techniques have similarities with their counterparts in software engineering, sharing for example the use of predicate calculus, the types of worldly claim that may be made against these models are, however, quite different. For example one might wish to “prove” that a set of goals are sufficient to meet the needs of a group of stakeholders. To do this one might proceed in a structural-induction-like fashion over the goal hierarchy, so that at each step of the proof, a justification is given showing that a set of sub-goals is sufficient to meet its parent. Take the train control system case study [37] (p. 231), and consider the goal:

  • Maintain[worst-case-stopping-distance-between-trains-on-same-track]

  • and its three sub-goals:

  • Maintain[safe-accelerate-command-of-following-train],

  • Maintain[worst-case-response-of-following-train-to-accelerate-command], and

  • Avoid[backward-train].

Evidently the rail network as a whole does much more than these three things to ensure that worst-case-stopping-distances are maintained; closing down the rail network during extreme weather conditions being just one. Of course, what is important here is that these three goals are considered sufficient within the context of this particular rail safety system; justifying the sufficiency of these goals is therefore tantamount to justifying this system’s boundary. A justification of sufficiency is consequently likely to involve: what the project can afford to develop, what the current technologies can provide, what the rail network should reasonably be expected to do to maintain stopping distances, and how this system might relate to the other safety mechanisms that are, or could in the future be, in place within the domain. Justifications of this kind are therefore likely to depend on a complex and interrelated mix of domain, technological and project management expertise.

Of course, it is not proposed that the above style of “proof” reflects real requirements practice; rather, the comparison is intended to highlight the epistemological differences between formal methods in software engineering and requirements engineering. In the former, epistemic claims are justified with reference to a stable, mature branch of science, which is effectively reused time-after-time. In the latter, epistemic claims are justified by drawing on the products of requirements elicitation, which provide a once-off foundation that must be constructed uniquely for each and every project. This distinctive epistemological difference makes the idea that formal methods for requirements might simply “inherit” a positivist foundation from their counterparts in software engineering seem quite inappropriate.Footnote 2

6 Naïve positivism and requirements research

Consider again the goal-oriented example presented above. For the naïve positivist the process of eliciting stakeholders’ needs, which may at first be presented informally, and representing these in terms of a goal hierarchy, which may subsequently lead to the production of a formal specification, would be seen as a relatively unproblematic task. For the naïve positivist formal structures and abstractions can be straightforwardly identified by the requirements analyst, without the need, for example, of scientific justification. However, this unproblematic transition from informal to formal would seem to deny much of the literature in requirements that problematizes the topic.

Reconciling the formal and the informal would seem to be one of the critical challenges in the practical production of formal requirements specifications. Indeed, as many leading figures suggest, reconciling the formal and the informal may also be one of the critical theoretical challenges for requirements engineering as a field. For some it is a matter of when this formalization should occur. As Parnas [38] suggests: “formal descriptions techniques have received considerable attention in RE research, but have not yet been widely adopted into RE practice. Since RE must span the gap between the formal world of software behaviour, the key question over the use of formal methods is not whether to formalize but when to formalize.” A call that is echoed by van Lamsweerde [39]: “constructive techniques are needed to guide requirements engineers in the incremental elaboration and assessment of requirements. In particular, one should clarify when and where to shift from informal, through semi-formal, to formal.”

For others the matter is more fundamental. Goguen for example, in emphasising the balance between formality and informality, describes the very activity of requirements itself as a process of formalization [40]. For Nuseibeh and Easterbrook, bridging the divide between the formal and the informal is in fact one of their six major research challenges for the next 25 years of requirements engineering [38]. To adopt the position of naïve positivism would be to dismiss these challenges as a triviality. Yet, for requirements engineering it would seem that it is this stage of the process that is both most critical and of the greatest interest. Naïve positivism simply fails to account for an engagement with such concerns.

7 Scientism and requirements research

Science has an obvious and important role in requirements engineering. However, scientism is an over-valuing of science, of assigning too high a status to science at the expense of other kinds of knowledge; clearly one may still value science without being scientistic. To investigate this form of positivism it will be worth treating the role of science in the activity of engineering requirements, and the role of science in requirements engineering research, separately.

A recent paper [41], discusses the status of science within requirements engineering research. The authors favour a “broad church” view of scientific research, which they define as: “a social practice concerned with the production of claims of knowledge through a process of inquiry in a way that is: 1. relevant…, 2. systematic…, 3. transparent…” It is a view that would certainly allow one to count a wide variety of requirements research as scientific, and would thus give the field a reassuringly scientific aura. However, this “broad church” definition is so broad that it could arguably include research in medieval history or theology, which seems unsatisfactory. This kind of gerrymandering seems indicative of a scientistic sentiment amongst at least some within the requirements engineering research community.

However, this is by no means universal. Many papers in requirements engineering combine “science” and “non-science” in a very unproblematic way. Maiden and Robertson [42] for example present techniques for creativity in requirements and cites models from cognitive and social psychology as the basis of it is approach. These models are then used to inform the organisation of facilitated stakeholder workshop sessions. Science is therefore being used to inform the design of a requirements method. However, the contributions (discussions, ideas, requirements, and so forth) that stakeholders make as a result of such a workshop may be many and varied. Some contributions may take the form of scientific facts, such as safety parameters or physical properties that are specific to the domain; of course, other contributions may not have such a scientific basis. However, even when a scientific fact is produced by a stakeholder, this is not scientific proof that it necessarily forms a system requirement. Rather the relevance of such a contribution is in practice likely to be dependent on that participant’s own understandings of the requirements process. Not that this is cited as a problem, on the contrary, it would naturally be the job of subsequent requirements analysis to verify the results of such a workshop and deal with any resulting inconsistencies. The point is simply that this requirements process, although itself informed by scientific principles, appears to hinge on the facilitation, production, structuring, and management of qualitative material. Science hence informs the method, but following the method is still a pragmatically oriented activity, perhaps not dissimilar to that revealed by the studies of engineering presented in Sect. 3. Given the unproblematic way that science and non-science are used, and the fact that this paper is quite typical of requirements research, it seems difficult to build a case for a universal scientistic movement within requirement research.

Indeed, although the RE’06 conference call for papers requested scientific evaluation papers, there is an increasing recognition both in requirements engineering, and related field, of the value and rigour of both quantitative and qualitative research methodologies. Wieringa et al. [43] provides a classification of the variety of different sorts of research that makes up requirements engineering, and the different orientations, both scientific and non-scientific, that this may entail. Similarly, while [44] calls for a more systematic approach to requirements evaluation, non-scientific approaches like ethnography are proposed as being a part of the solution. More widely, computer science [45], and information systems [46, 47], have both noted a shift during the nineties toward a less dogmatically positivistic view of research method. In sum, although manifest from time-to-time, the rhetoric of scientism seems increasingly irrelevant to requirements engineering research.

8 Scientism and requirements practice

Although Sect. 6 seems to neglect the role of science in requirements engineering, this is not to deny its importance. Clearly the rail safety example in Sect. 5 would have made use of data whose origins might be found in science. However, as was outlined, these take their place amongst the complex array of opinions that justify any statement of requirements. This places science at the periphery of the requirements process, as just another form of justification, rather than as part of the very methods of engineering requirements itself. Literature by expert practitioners, such as [48] for example, give little or no attention to science and the scientific method. Nevertheless, there is requirements research, which places science right at the heart of requirement practice.

Sutcliffe et al. [17] uses psychiatric research to measure the cognitive abilities of disabled users, and hence develop a scientifically based, personalized user profile. Personalized system requirements are selected for each user on the basis of their profile, and this is described as a process of “satisficing” (p. 23). It is a term, which may certainly be given an informal interpretation. In this instance the task of finding an absolutely “optimal” statement of requirements may be hard or impossible to do, however, it may still be possible for the skilful requirements engineer to find a satisfactory and sufficient solution. In this informal sense, the method presented uses scientific measurement to establish certain properties about the current state of world, but then the skill and creativity of an engineer are necessary in order to formulate a statement of requirements, and thus make a step into the future.

However, the original sense of the term “satisficing” is somewhat more formal, and is often used as a reference to design science. This movement, drawing on [49] seeks: “an explicitly organised, rational and wholly systematic approach to design: not just the utilisation of scientific knowledge of artefacts, but design also in some sense as a scientific activity itself” [50]. Simon [49] presents a science of design, which Simon intends to be taught as part of the discipline of engineering. His aim is to remove design’s dependence on experience and judgement (p. 135), and make it a scientific discipline. Critical to this is his reductionist view of the human condition, very much aligned to his pioneering work in the field of AI, that human intelligence is comparable with a physical symbol processing mechanism (p. 23). Reductionism is often associated with positivism, and its unity of science agenda. However, there is also an obvious scientism to Simon’s aims, viewing a scientific formulation of design as inherently superior to a non-scientific one.

It is a movement that has been controversial even within design itself. Grant [51] (quoted in [50]) suggests: “most opinion among design methodologists and among designers holds that the act of designing itself is not and will not ever be a scientific activity; that is, that designing is itself a nonscientific or ascientific activity.” Schon [52] also presents a view of professional design, which is intractable to an applied positivist science. In [49] the claim that design can be a science rests on a stated assumption that the designing human mind can be considered as a computing machine. This assumption is critical to the view of design as science because it means that the process of design can be reduced to a set of logical rules, which may be discovered through scientific research, and then used like scientific theories in the production of further designs. But the idea that the conscious mind can be compared to a system of formal logic is contentious and has been argued against, for example by the thought experiments of [53], using physics and mathematics in [54], and by drawing on later Wittgenstein and Ryle in [55]. The status of Simon’s positivist design science should therefore also be considered at the very least to be contentious. Even if one abandons a reductionist conception of the activity of design, the notion of design as a science still seems problematic. At a practical level some have suggested that the activities of science and design are actually quite dissimilar [56]. Of course it may be possible to see some parallels with science; however, these seem no more compelling than equally plausible parallels with other rigorous professional disciplines (such as law, for example). Thus, without the contentious positivist conception of design, one is forced into adopting an absurdly broad view of science in order that design might be considered a part of it. Of course this is not to suggest that design science is not capable of formulating useful and practical guidelines, merely, to highlight the scientistic aspirations of its programme.

To conclude, the above alludes to three possible formulations of requirements engineering practice as science. The first takes the aforementioned “broad church” interpretation of science, thus ensuring that everything necessary to engineer requirements counted as a science. But this seems unsatisfactory. The second would be to mould requirements practice into a strict view of the scientific method, such as the hypothetico-deductive model, and then deny the importance of any methodological knowledge that fails to fit. However, studies such as [31] suggest that this may ultimately be to the field’s detriment. The third would adopt a reductionist view of the activity of engineering requirements itself, much as design science does toward the activity of design. However, such a move is at best contentious. In sum, it would be decidedly premature to privilege scientific conceptions of requirements engineering practice over “non-scientific” alternatives.

9 Science and technology studies

Though influential at one time, Positivism is no longer taken seriously in the philosophy of science. Particularly influential in the turn away from positivism was [15]. Kuhn argues that, rather than seeing science as engaged in a steady progress toward truth, it may be better conceived of as a sequence of paradigms. Thus, while there are certainly periods of “normal science,” these are interrupted by episodes of revolutionary change. Kuhn’s view is of a science organised around communities of ideas and practices, rather than around an idealised view of the scientific theory.

The differences between Kuhn’s paradigms, and Popper’s falsification, are put forward particularly clearly in Chap. 4 of [57]. However, [57] is concerned with much more than comparing two philosophies of science; it suggests that these epistemological positions cannot be fully understood without looking at the ideological, cultural, and social concerns, in which they are embedded. This so-called “strong programme in the sociology of knowledge” argues that the content of scientific knowledge, far from effortlessly transcending the circumstances of its production, can in fact be legitimately understood in sociological terms. One of the critical arguments within the strong programme relates to the role of logic and reason in science and mathematics (for instance, see [57], Chap. 6–7, or [58]). The following examples (which draw on [59], [60] pp. 45–48, and [61]) illustrate this concern.

Consider the following hypothetical discussion between a mathematician and a theologian. The theologian is asked to accept that: “all men are mortal” and that: “Socrates is a man;” which he does. The mathematician then urges him to accept by deduction that: “Socrates is mortal.” Suppose the theologian doubts this conclusion. The mathematician could use predicate calculus to reformulate the issue, and point to the rules of a logic which necessitate her conclusion (such as those presented in [62]). Further doubt might result in the calling of a third party, to verify her working. If the theologian persists in his scepticism, he is likely to irritate the mathematician; his intelligence or good character may even be brought into question. The point is that although a rule of logic may allow one to draw a particular conclusion, it does not in and of itself necessitate action. Rather, it seems more reasonable to say that it is the social context of the occasion of that logic’s use, which impels a particular conclusion.Footnote 3

Suppose the theologian instead engages in a different kind of scepticism, suggesting not that the rules aren’t sufficiently persuasive in themselves, but that they are not sufficiently complete for him to apply. Before the theologian may conclude that X is mortal, he must be able to discern that X is in fact a man, and since the mathematician has provided no procedure for him to discern this, as far as the theologian is concerned, her rules are incomplete. Indeed, even if the mathematician provides further rules intended to unambiguously establish whether or not X is a man, these too are susceptible to similar scepticism. Whenever a rule is supplied it is always possible to ask for a further rule, which outlines exactly how that rule is to be applied, forming a potentially infinite regress. Once again, the mathematician will have cause for exasperation: the theologian’s claim not to be able to identify a man seems ridiculous, surely any reasonable member of society should be able to do this? While an infinite regress is certainly possible, in practice any chain of rules eventually reaches an end, usually with something that is deemed to be incontrovertibly commonsense to the users of that rule. So, just as in the previous example, the logic is not in itself complete: to fully understand what is meant by a rule, one must also understand what is deemed by the users of that rule to be incontrovertibly commonsense.

Returning to the example for the last time, suppose the theologian does eventually accept that “Socrates is mortal.” The mathematician might then list other men that the theologian ought to accept as mortal. Suppose this list includes Jesus Christ; he was a man, does the logic therefore compel the theologian to accept that he is also mortal?Footnote 4 Evidently the logic compels no such thing, and in retrospect the pair might agree that the rule did not apply in this circumstance, or that the rule itself should be revised to account for this case. Thus, while it may initially seem as if the logic compels a certain conclusion, in fact the reverse seems more reasonable: that given a particular instance, the pair first discern a “correct” conclusion, and then account for how the rule relates to it. In their actual everyday use, rules consequently have a post hoc character and might be more profitably seen as a resource for action, rather like [64]’s understanding of a “plan”.

This kind of scepticism is often taken to be derivative of Wittgenstein’s work on rules and rule following. Informed by these kinds of insight, Kuhn, the strong programme in the sociology of knowledge, and Science and technology Studies more widely, generally take rules, logic, knowledge, and language, as phenomena which may only be understood properly when seen as embedded within a community of use.Footnote 5

Rules are obviously of importance in requirements engineering. Software systems are not only rule-based constructions, but are introduced into communities, which have their own rules and sense of orderliness. The implications for requirements engineering of the insights outlined above, may therefore be significant, and are evidently well beyond the scope of this paper. However, it will be worth emphasising two conclusions. Firstly, these arguments in no sense make formalisation impossible; the fact that they often focus on logic or mathematics should not be interpreted as asserting the impossibility of these activities. Rather, (and secondly) they are provided here in order to refute positivism’s indifference to the context, origin and practical usage of such formalisations.

Science and Technology Studies is a theoretically rich discipline, of which the aforementioned strong programme in the sociology of knowledge forms only one part. For example, social constructivism [66], the Social Construction of Technology [67], and Actor Network Theory [68], may all, in ways that fall well beyond the scope of this paper, be of relevance to requirements engineering. Indeed, some have already explored such possibilities [69]. However, one does not necessarily have to reject foundationalist accounts, such as realism or essentialism, in order to reject positivism. Even without such theoretical contributions, Science and Technology Studies contains a body of empirical studies which may in their own right, be of value to requirements engineering.

The studies of classification in [70] present just one example. Domain modelling is in many respects similar to the way one might build a classification. However, as [70]’s study of the International Disease Classification illustrates, such activities are far from unproblematic. Through detailed study, the history of the International Classification of Diseases is traced from the seventeenth century to the present day where it forms a vital part of medical governance and technology. It would be easy to imagine that advances in modern medicine have brought stability to this classification, however, the authors conclude otherwise: “what we found was not a record of gradually increasing consensus, but a panoply of tangled and crisscrossing classification schemes held together by an increasingly harassed and sprawling international public health bureaucracy” (p. 21). The study illustrates the complex human work that goes into building and sustaining classifications, and the richly textured moral properties they consequently possess. Such studies should be at the very least, an aid to the sluggish imagination.

10 “Value” and requirements

In seeking a philosophical foundation, requirements engineering is often compared with science. This may be due to a perceived relationship between science and engineering, as discussed in Sect. 3; it may be due to a perception that the methods of science hold an epistemic strength which requirements engineers should replicate, discussed in Sect. 4; or, it may be because science already has a rich philosophy on which to draw. This section will, by contrast, present the view that if requirements engineering is to have a philosophy then it may end up looking more like a branch of ethics.

Essential to this view is the notion that requirements engineering is concerned firstly with thinking about and investigating claims of value, and secondly with concluding how the world ought to be on the basis of such claims. For example, suppose a requirements engineer must make a trade-off between two proposed requirements in order to produce a requirements document. Firstly, in order that any trade-off may be made, the requirements engineer must fully understand the “value” possessed by each proposal. Secondly, in proposing a solution in the form of a new set of requirements that requirements engineer implicitly makes a new value claim. In so far as such claims relate to the “rightness” or “wrongness” of various properties of a system, the requirements engineer’s problem is a moral one. In so far as the field of requirements engineering provides approaches to resolving such problems, it is akin to a branch of normative ethics.

The relationship between value, science, and positivism was clearly delineated by the logical positivists. Hume famously highlighted the problematic status of writers who provide statements about what “is”, yet conclude something about what “ought to be” as a result ([71], Book III, Part I, Sect. I). This distinction between “facts” and “values,” also described by G. E. Moore (1873–1958) and the early Wittgenstein, was one that the logical positivists strongly subscribed to. Furthermore, as Ayer describes [72], because matters of value or what “ought to be” could not be given a scientific treatment, they were to be regarded as literally meaningless as their expression was said to add nothing to a statement’s factual claims. Since requirements engineering is concerned with investigating and proposing claims of value, it is an activity that the logical positivists would have discarded as meaningless. In this respect logical positivism is clearly not a natural candidate for a philosophy of requirements engineering.

Despite their scientistic ideals the logical positivists didn’t think that value-based reasoning could be a scientific activity. Of course, the philosophy of ethics has developed substantially since logical positivism. Loobuyck [73], for example, shows how the later work of Wittgenstein was influential in this development. Whether or not it is philosophically appropriate to treat value, or at least the kind of value that requirements engineering is concerned with, as a topic of scientific enquiry is a meta-ethical question, which lies beyond the scope of this paper. However, one particular stance that some [74] have allied to the later Wittgenstein, will be considered.

Ethnomethodology [63] is of course familiar to requirements engineering [75]. Influenced by the phenomenology of [76], ethnomethodology is an orientation for the study of the locally produced, situated, moral order of everyday mundane human conduct. For example, the moral order of the medical domain may include decisions about whether or not to treat a particular patient; in this sense “moral order” may be quite recognisable as a form of applied ethics. But, this need not be the case, “moral order” equally well includes more mundane matters. During a lecture, for example, it is taken as a basic part of the moral duty of the audience to be quiet and allow the lecturer to speak. Should a member of the audience choose to talk in an inappropriate way, this becomes morally sanctionable, perhaps by fellow members of the audience, perhaps by the lecturer, or by those organising the event. Of course, there may be occasions when it is considered appropriate to abandon such a moral order, for example, if the lecturer were to show himself to be grossly incompetent as a speaker. For ethnomethodology, such moral orders may be widely understood, such as how to attend a lecture, or be quite specific to a particular community, such as how to make medically ethical judgements; they may be explicitly taught, as in organised religion, or only tacitly known, as in the organisation of ordinary conversation [77]. Either way, ethnomethodology is concerned with how they may be uncovered, often using careful observation and fieldwork.

The ethnomethodological view of a domain as a moral order, is thus a richer one than that provided by a scientific conception, which might describe in terms of rules, processes and structures. Garfinkel suggests that a rule-based conception of society makes its members into “dopes” ([63], p. 68). By contrast he shows how members quite mundanely work reflexively with any rule, and how society is as a result, better seen as a locally and intrinsically sustained moral order. Ethnomethodology thus represents a strongly practical conception of value, which is capable of identifying issues that may be of practical relevance to requirements engineers.

For example, to understand a claim of value, such as one that a stakeholder might make when asserting (through a requirement) that a system ought to have a particular property, is to appreciate the senseful character of its justification. Certainly it may be necessary to understand the scientific facts that such a justification might use, but this is not in itself a sufficient condition for understanding that justification as a whole. To achieve this one must also understand the local moral order, which makes that claim meaningful. In this regard, ethnomethodology is an analytic orientation capable of producing the sort of rigorous empirical backdrop, which would allow the sense of value-claims made during requirements to be adequately determined. More than merely understanding the value-claims of others, requirements engineers must also make claims of their own. Analysing, synthesising, and writing requirements are all activities where a requirements engineer must assert value in a statement of their own making; they are bound, so to speak, to get their moral hands dirty. Naturally, the acceptability of such value-claims, and any justifications, which might accompany them, will also relate to this moral order. Ethnomethodological studies can therefore act, not just as background for understanding the value-claims of others, but also as a resource for proposing new ones.

The above of course sketches only one view. It suggests a particular understanding of what value is; it suggests methods of empirical enquiry; and, suggests how the requirements engineer ought to use the results. For example, this perspective proposes that observing participants in their natural environment provides a resource that is distinct from merely listening to descriptions provided during interviews. Similarly, it proposes that stakeholders’ moral orders ought to be accounted for in the production of requirements. Other orientations may propose different views or make different assumptions. Requirements engineering is in part concerned with the exploration and advocacy of such perspectives, and ultimately with considering what adequate requirements practice ought to consist in. In so far as a philosophical treatment of this task may be necessary, it is therefore likely to be closer to a branch of normative ethics, than a philosophy of science.

11 Conclusions

This paper has considered various forms of positivism: logical positivism, naive positivism, and more broadly, scientism and elements of realism. It has also considered the different ways in which these forms might be relevant to both research and practice. It has, in particular, considered these in relation to a variety of specific examples, from formal methods for requirements engineering through to the importance of “value”. Taken alone, each argument shows that positivism, in whatever relevant form, is in no sense foundational to that aspect of requirements engineering. When considered together, they more than adequately refute any broad claim that positivism is foundational to requirements engineering as a whole. Furthermore, they suggest that the positivist perspective is at best detrimental, and at worst antithetical to the activity of engineering requirements.

As a consequence, if positivism is not in fact fundamental to requirements engineering, then the problems regarding the use of fieldwork raised by [1] can be safely disregarded. Interestingly, although [1] clearly asserts positivism’s foundational status, it not clear that the authors are themselves positivists. On the contrary, they appear to be quite dissatisfied with the state of requirements engineering as they perceive it. The authors go to some lengths to highlight the value that ethnographic studies might bring to the engineering of requirements. That such methods are irreconcilable with what they take to be the field’s fundamental principles, seems for them to be an unhappy conclusion. Indeed, as a consequence they respond by calling for a complete rethink of requirements engineering. Of course this author might concur, but for very different reasons. In particular, and in light of the work presented here, such a rethink certainly need not be concerned with “liberating” requirements engineering from any supposed positivist hegemony.