1 Introduction

Developing system requirements in complex situations has proven to be a difficult endeavor. The tools, techniques, procedures, and processes used in traditional requirements elicitation processes (TREPS) have been a subject of criticism for applicability to complex system domains [1]. This is especially the case since the domain of complex systems is characterized [2, 3] as having any combination of the following factors present:

  • Diverse and potentially conflicting perspectives,

  • High levels of ambiguity and uncertainty,

  • Information that may be incomplete, incorrect, or nonexistent,

  • Boundary conditions that are ambiguous and subject to change,

  • Resources that are insufficient or subject to rapid shifts,

  • Limited understanding of the problem or need

  • High impact of nontechnical aspects of the problem (e.g., politics),

  • Indeterminate entry point to address the situation,

  • High levels of contextual influence (e.g., infrastructure, managerial worldviews).

In the face of these characteristics, the notion that requirements can be characterized by traditional attributes such as being unambiguous, consistent, complete, ranked, understandable, verifiable, traceable, and modifiable becomes tenuous for complex situations.

For complex situations, the elicitation of requirements as a process needs to be reexamined and evaluated in the face of increasing complexity. More specifically, the nature of requirements, the role of the observerFootnote 1 in the requirements process, and the environment within which requirements are generated offer important points of contrast. Against this backdrop, this paper examines requirements and provides a framework that can facilitate the assessment of system problem characteristics to aid understanding of the potential limitations of TREPS applicability for requirements elicitation in highly complex situations. TREPS are thriving and have been successfully used in design, development, production, and construction of system solutions, and therefore, their use will remain viable [4–6]. However, authors of this paper identify a need for more robust approaches to address requirements elicitation methods, tools, techniques, and processes for dealing with requirements in complex situations. Such situations arise when dealing with complex systems that are irreducible and can only offer transient knowledge [7]. In effect, the very tenets of TREPS application are defied by these complex situations.

TREPS are useful when implemented for appropriate technical problems where requirements can be elicited, verified, and validated. Such methods are also useful when problems have a linear component of one-problem one-solution with the ability to provide “absolute” traceability. However, these conditions are not the case for complex systems in dynamic environments, characterized by high levels of uncertainty, ambiguity, and emergence. Assuming that requirements are easily traced, modified, and understood in a complex situation is a misconception. Therefore, the dilemma is twofold: (1) to develop approaches that can elicit requirements for complex situations and (2) know when traditional approaches are beyond the limits of their applicability. Forcing TREPS into these environments is not likely to produce desirable results. This paper suggests that the effective elicitation of system requirements involves successful consideration of three primary aspects, including (1) the role of the system observer, (2) the nature of system requirements related to the system under consideration, and (3) the environment which influences the system under consideration. Individually, these aspects have been addressed in the literature. For example, [8] notes that personality types affect human behavior in decision-making. Further, [9] demonstrates that requirements can change over time. In addition, the current literature review reveals that a critical focus of development is on observer influences [10, 11] for the requirements processes. This paper contributes to the understanding of requirements elicitation in two ways: firstly, it argues for a more holistic view of requirements analysis by expounding on the nature of the observer and including considerations for the environment of the system. Secondly, it provides a preliminary framework for engineering practitioners in elicitation of requirements in complex situations.

This paper pursues two primary objectives to enhance the prospects of dealing more effectively with requirements elicitation in complex situations. First, the limitations of the use of TREPS in elicitation of requirements in complex situations are identified. Second, having presented the potential incompatibility of traditional approaches to complex situations, authors provide a first exploration of systems-based foundation requirements elicitation. This recognizes that requirements elicitation processes must continually be challenged with respect to their appropriateness to meet the modern realities of complex environments. Only through the establishment of compatibility between the requirements elicitation process and complexity of the situation (i.e., degree of uncertainty, ambiguity, emergence, etc.) can effectiveness of requirements elicitation be achieved. To accomplish our objectives, this paper is structured into several sections building toward a first articulation of an emerging framework for elicitation of requirements in complex situations. Following our introduction, Section 2 is a review of related literature. The review of literature introduces current research in the subject, points to possible strengths and weakness associated with the use of TREPS in complex situations, and positions this work in the body of knowledge of requirements elicitation. Section 3 examines the role played by the nature of the system observer in relationship to requirements elicitation in complex situations. Section 4 explores the nature of requirements. Using complex system attributes, authors suggest a diverging perspective on limitations of traditional thinking when dealing with requirements in complex situations. Section 5 examines the nature of the requirements environment. In Section 6, the utility for the use of TREPS in complex situations is explored. Specifically, the implications for requirements elicitation is scrutinized based on the degree of complexity present in a situation. In Section 7, the authors present an emerging framework that can be used in requirements elicitation when dealing with complex situations. While this framework is in the embryonic stages of development, authors are confident that it can provide some immediate utility to practitioners who must confront requirements elicitation in complex situations. The paper concludes with Section 8 on the implications of the framework for the practice of requirements engineering. The developmental challenges and examination of the path forward to further refine the practice of requirements elicitation in complex situations are also included.

2 Related literature

This section summarizes various literature used to address requirements elicitation and as such provides an overall view regarding strengths and weaknesses. Corral [12] stresses the need to develop and improve methods and tools for requirements engineering due to increasing complexity. Recognizing complexity associated with stakeholder requirements, Agouridas and McKay [13] proposed a systematic framework for capturing the requirements prior to system design. Their framework deals with the derivation of design requirements that align with observer needs. Furthermore, an “onion level model” to deal with requirements while incorporating the system environment has been developed by Alexander and Robertson [14]. For this model, they demonstrated that for each “level of the onion” the lack of consideration for stakeholder’s input and the environment resulted in missing requirements. They continued to point out that one of the areas of research for their proposed model was the consideration for the dynamic nature of the environment.

Ballejos and Montagna [15] have pointed out the need to identify types of stakeholders via attributes in the interorganizational environment. They note that interorganizational environments are “a set of organizations that have different characteristics and collaborate in order to reach common goals” ([15], p. 282). Having different environmental characteristics has implications for the selection of appropriate tools, techniques, and approaches during the requirements elicitation process.

Widely used in software engineering, the i* modeling framework for early phase requirements engineering presents a different perspective [16, 17]. The framework argues that emergent behavior in system design can be avoided if one can build a considerable amount of knowledge in early phases of requirements analysis. Rather than focusing on the system-to-be, the i* model focusses on the whys. This enables the capture of contextual issues, especially as they relate to agent dependencies.

In summary, the elicitation of requirements is not a new topic or one that will remain static. This short examination of the literature indicates that the field recognizes the shifting landscape of increasing complexity and the need to evolve requirements elicitation approaches in response.

The current dialog of this paper contributes to this evolution of the requirements field by providing an alternative systems thinking grounded perspective on the requirements elicitation process. Holistic in nature, this perspective of requirements elicitation (as proposed in this paper) is established with the consideration of the complex, interrelated nature of the people, the systems involved, and the environment. In addition, Table 1 summarizes the contribution of this research in current literature to move the field forward.

Table 1 Literature positioning in different aspects of requirements elicitation
Full size table

The motivation for the authors stems from dealing with emerging problems of security, healthcare, terrorism, natural events, and their effects in the emerging critical infrastructure paradigm faced in the twenty-first century. The proposed framework developed in this work offers:

  • Holistic view on requirements elicitation process in complex situations by considering the role of the system observer, the nature of system requirements, and the influence of the system environment. This framework does not promote or ignore one aspect over another. Many of the current approaches rely on the role of system observer as the only perspective to guide elicitation of requirements.

  • Contribution to requirements elicitation for complex situations by addressing a need as indicated in the literature. The literature supports the need for frameworks that consider multiple elements of the requirements domain (e.g., dynamic environment, complexity) to effectively address requirements. For example, while the Ballejos and Montagnas’ [15] framework appreciates the dynamic nature of the environment and the concomitant consequences, they also acknowledge that interorganizational environments can operate under conditions of rapid change. However, their framework considers “a static perspective” (p. 295) only.

  • As illustrated by Table 1, there is a need for further development in areas related to the degree of situation complexity and the influence of dynamic environments in requirements elicitation. Less has been written on how to deal with requirements for complex and emerging situations that are a fact of life for requirements engineering professionals in the twenty-first century.

Authors have identified several essential terms (Table 2) critical to ground the development of our emerging framework and ease ambiguities created in the literature. These terms provide a conceptual foundation upon which the following themes of the paper are developed.

Table 2 Related systems terminology
Full size table

The process of obtaining true requirements in a complex situation requires a holistic systems view that can only be provided at the system level. The approach taken by the authors heavily depends on systems thinking as proposed by [39–42] with “wholes” being the focus of problem-solving efforts. This thinking has enabled us to propose a requirements elicitation framework that includes a system observer, nature of requirements, and system environment for contextual reasoning. On context, [41] notes that “[a] problem context can be defined to include the individual or group of individuals who are the would-be problem solvers, the system(s) within which the problem lie[s], and the set of relevant participants.” From this perspective, authors suggest that there are multiple and potentially divergent observer-dependent perspectives at play in complex situations. These perspectives may or may not be accessible and suggest that the nature of the observer in requirements elicitation processes be taken into consideration.

3 Nature of system observer

The elicitation of requirements in complex situations is by no means a simple task. There are implications for framing, performance, and design of system-to-be as discussed in [2, 43]. This section elaborates on the implication for requirements from the nature of system observers. The system observer is defined as an individual or group of individuals involved in defining, collecting, analyzing, decision-making, and interpretation of system requirements. This includes system owners, designers, and analysts. While discussions of the system observer can appear to be abstract to the realm of practice, authors provide specific emphasis of the implications of this element for practitioners faced with requirements in a complex situation context.

It is only fitting that system observer becomes a subject of this discussion since he/she is the one who makes decisions and interprets the appropriateness of methods, tools, approaches, and the way to proceed in requirements elicitation. Additionally, it is the system observer who does the sense making and interpretation regarding the system/requirements. It is from this perspective, within systems thinking, that authors suggest that the way the observer approaches requirements elicitation has much to do with observers’ dispositions [41]. Furthermore, [44] has illustrated that people can have diverging perspectives on the same issue. This has implications for selection of what might be deemed “appropriate” (from the perspective of the observer) methods, tools, techniques, and approaches used during requirements elicitation. For the practitioner, understanding the differences in perspectives and the potential source of those distinctions is critical. These distinctions are not merely those that sound engineering judgment may overcome. On the contrary, the differences emanating from divergent philosophical underpinnings among system observers lies at a much deeper level, not subject to resolution simply by appealing to engineering-based argumentation. For instance, while a sound engineering argument may be easily conceded by an observer, differences that cut against deeply held values, beliefs, and worldviews will find consensus a much more difficult path. In essence, this would be asking someone to surrender his or her deeply held belief system. Failure of practitioners to appreciate these divergent dispositions may exacerbate the already difficult task of requirements elicitation in complex situations.

In this section, authors do not attempt to discuss who is in the best position to elicit good requirements. However, authors do contend that system observers have dispositions that affect their judgment regarding system requirements elicitation. Such inclinations and tendencies affect the approach taken when dealing with problematic situations. Readers who desire a deeper treatment on how different viewpoints can aid in elicitation of requirements (primarily in software) are directed to the works of [45], [46], [47], and [48]. Choosing to see a complex situation in a particular manner, “will obviously affect the approach adopted to studying it or seeking to change it” [41]. Concerning observer dispositions, [49] notes that there are four main areas of consideration: ontology (view of the nature of reality), epistemology (view of the nature of knowledge), nature of human beings (view of the nature of human choice), and methodology (view of the nature of appropriate approach). Challenges associated with these views are consistent with systems thinking [40, 50], soft systems thinking [41], and system of systems thinking [3] approaches that all recognize the inherent impact of the range of perspectives held by individuals engaging in systems processes. Again, authors are primarily not focused on distinctions and differences in viewpoints or perspectives that might be resolved through rational logical engineering argumentation or judgment. Instead, this treatment of observers lies at a much deeper level of distinction (e.g., philosophical orientation) that calls into question both the ability to make the basis for distinctions explicit as well as deal with their inherently higher degree of intransigence. In effect, they exist at a much more fundamental and tacit level.

In [49] authors observe that a continuum line on ontology can exist for system observers. Again, ontology is concerned with how an observer views the nature of reality, or how concretely the external world might be understood. This ontological continuum ranges from realism to nominalism. If we place the observer (requirements engineer) on this spectrum, a perspective rooted in realism would suggest that the process of requirements elicitation is an objective and repeatable one (objectivity dominates) that can exist with absoluteness and unwavering stability once defined. At the other end of our ontological continuum, we find nominalism. Nominalism suggests a philosophical disposition much less rigid. This perspective would find that requirements elicitation process is much more a construction of the observer where reality is not absolute (subjectivity dominates) and the (subjective) interpretation is in play to a much greater degree. Therefore, this philosophical disposition would more readily accept the potential shifting interpretative nature of requirements and the absence of absolute understanding. In the complex system domain, the gap between the two extremes of ontology, realism and nominalism, can become irreconcilable based on the intransigence of differing observer viewpoints. Such differences are more likely to become manifest when more “traditional” views of the concreteness of requirements clash with more complexity-driven views of requirements that are “emergent” under conditions of complex situations.

For practitioners, appreciation of the ontological differences for increasingly complex situations is critical. From a traditional requirements engineering perspective, a much more realist ontological philosophical disposition is not only expected, but also desirable. Hence, nailing down requirements early and with concreteness is a laudable goal. However, in more complex situations, where high levels of emergence, uncertainty, and ambiguity are prevalent, a more nominalist ontological perspective is more appropriate. If the practitioner does not recognize the nature of these distinctions between realism and nominalism in observer disposition, the potential exist to create conflict in requirements elicitation for complex situations. Unfortunately, the philosophical incongruities are more likely to come about through other conflicts (e.g., attacks claiming poor requirements engineering due to continual shifting interpretations inherent in complex situations). For a complex situation, what might be construed as poor requirements elicitation from a realist ontological perspective might be considered as effective requirements elicitation from a nominal ontological perspective.

Epistemologically (the nature of knowledge), the role of the system observer is considered to exist along a continuum between two extremes. The continuum ranges from positivism (knowledge is absolute) to antipositivism (knowledge is socially constructed). Epistemology deals with how a system observer might begin to understand a problematic situation and communicate knowledge to fellow observers. A positivistic system observer will assume that knowledge about the requirements is hard, real, and tangible. Therefore, from the positivist epistemological perspective, requirements elicitation is focused on creation of static, well defined (not subject to differential interpretations), and with the goal of intransigence. In contrast, an antipositivistic system observer will assume that knowledge about requirements is soft, subjective, and based on the interpretative beliefs of the observer [10, 49]. Thus, from the antipostivistic epistemological perspective, requirements elicitation is focused on accepting the transient nature of requirements based on shifting knowledge and circumstances, variability in interpretations, with a goal of refinement of requirements perspectives. Therefore, elicitation of requirements becomes a generalizable process under positivism, with replication attainable and more or less free from variability in interpretations. However, from the antipositivist perspective, the requirements elicitation process is subjective and based on interpretative forces beyond the ability of good requirements engineering to overcome. Increasingly complex situations, marked by high levels of uncertainty, ambiguity, and emergence, suggest that requirements elicitation processes based in the positivist paradigm may need to be closely scrutinized for their extensibility to complex situations, where antipositivist forces are the norm rather than exception. For practitioners, this implies careful consideration of the circumstances within which requirements elicitation is being conducted. For situations that are well understood, change in circumstances leans to being static, and knowledge is sufficient and not shifting, traditional thinking and approaches to requirements elicitation, rooted in the positivist paradigm, might be appropriate. However, for situations that are marked with complexity, including instabilities in the circumstances, incomplete/inadequate knowledge, and potential divergence in perspectives, approaches to requirements elicitation rooted in antipositivistic epistemological perspectives should be considered. For example, practitioners might consider that, for complex situations, continually shifting requirements and unstable requirements elicitation might be considered poor requirements elicitation from the positivistic epistemological perspective. On the contrary, from an antipostivist perspective, the same criticism of the requirements elicitation process could not be claimed. Appreciation of the epistemological disposition of observers in complex situations may help practitioners engage the requirements elicitation process with increasing confidence that can accrue with realistic expectations based on the complexities in the situation.

A further consideration for the system observers is how they view the nature of human beings. The way observers view the nature of human beings in requirements elicitation can be characterized along a spectrum ranging from determinism to voluntarism. In [49], it is noted that the determinism perspective suggests that human beings are “deterministic, determined by situation in the external world; human beings and their experiences are products of their environment; they are conditioned by external circumstances” ([49], p. 247). Hence, there is a limit as to how much control humans can exert on situations. In contrast, the voluntarism perspective of human beings suggests that human beings have a free will and can create their own environments and realities. Taking a deterministic perspective in a complex situation can suggest a limitation in appropriateness of particular requirements elicitation approaches. This is especially the case with the use of traditionally based approaches steeped in assumptions of a “determinism” perspective of human beings in relationship to systems being developed. For practitioners engaged in requirements elicitation for complex situations, the perspective of the nature of human beings suggests leaning more toward voluntarism. This would imply that the observer (requirements engineer) needs to be creative and less deterministic in nature since complex situations are much more fluid, uncertain, and not subject to explicitly constrained development processes.

A final aspect of the nature of system observer can be explained in terms of the methodological approach taken when confronting a problematic situation. A methodology is concerned with the way an observer “attempts to investigate and obtain knowledge about the world in which we find ourselves” ([49], p. 247). The two opposite extremes of methodology are nomothetic and idiographic. The nomothetic view is evident when the observer is concerned with definition and identification of requirements and how such requirements can contribute to the overall system design. The observer uses observation and experimentation to attain requirements knowledge by generalization using universals. In contrast, having an idiographic view during requirements elicitation suggests embracing the view that the requirements elicitation process is unique to the observer and largely dependent on ontological, epistemological, and methodological dispositions of the observer—in effect, the results of the process are not expected to be repeatable from one observer to the next. In complex situations, care must be taken to appropriately consider whether approaches based in a nomothetic perspective will indeed be appropriate. This is critical in requirements elicitation for complex situations with high degrees of emergence. For practitioners, the essence of methodological disposition lies in the degree to which requirements elicitation processes (methodologies) can be transportable and universally generalized to any requirements elicitation situation. If the complexity in a situation is such that standardized approaches are suspect, taking a more idiographic methodological stance in warranted. As such, a requirements engineer would be more focused on tailoring more nomothetic-based approaches and tempering them based on the uniqueness in context and circumstances of the situation. Practically, this suggests that for complex situations, one size does not fit all and practitioners ought to consider how rigid nomothetic-based methodological approaches might not best serve requirements elicitation.

This section amplified the need for consideration of the role of system observers on continuum lines of ontological, epistemological, and methodological perspectives and their impact on elicitation of requirements. In addition, the practical considerations for practitioners were amplified. Although at first glance the notions of the nature of the observer might appear abstract, they can be helpful to practitioners by (1) understanding the limitations of traditional approaches to requirements elicitation in complex situations, (2) suggesting considerations that should be engaged in thinking about complex situations, and (3) questioning assumptions that might unnecessarily constrain requirements elicitation approaches. As noted in [41], perspectives of system observers can differ greatly due to different philosophical dispositions. Such dispositions influence elicitation processes and the appropriateness of methods, tools, and approaches used in requirements elicitation. It is therefore critical to understand the nature of system observer in complex situations. In the following section, authors shift to expound on identifying the nature of system requirements in complex systems.

4 Nature of system requirements and their attributes in complex situations

Several authors have written extensively on complex systems [31, 39, 44, 51–59]. Rather than focusing on different definitions of complex systems, authors present several unifying themes commonly associated with such literature to elaborate the nature of complex systems as they pertain to requirements elicitation. In order to provide a succinct view, the nature of system requirements, the following descriptions are provided to illustrate types of complex systems:

  • Static complex systems—these are nondynamic systems and situations whose structure does not change over time [60]. In this case, obtaining a clear and complete set of requirements using TREPS is possible since the conditions of the situation are not subject to change. In [61], Goertzel concludes that static complex systems exhibit structural complexity that can be measured mathematically. Hence, the elicitation of requirements in complex systems may take time, but it is achievable. For example, consider the weight on a spring system. Physics and mathematical laws are capable of establishing solid mathematical relationships among different parts of the system since the relationships are static. In this system, the spring constant allows us to make calculations with respect different aspects of the spring such as the measurement of the elasticity of the spring. Hence, the probability of having emergent behavior and variability becomes minimal, and traditional requirements elicitation approaches are compatible with the situation.

  • Dynamic complex systems—the structure of such systems changes over time. Factors of time, size, and shape are considered in the understanding of these systems. Lucas [60] stipulates that these factors are critical in understanding the behaviors of a dynamic condition. Such factors include the time taken for elicitation, number of stakeholders involved, and boundary (shape) of the system involved. Working within a paradigm that does not consider time, number, and shape can have significant impact on the requirements for a system solution. Consider an example of developing a maintenance system for turbine generators. The dynamic behavior and degree of stability in this system is uncertain and marked with rapid changes over time due to uncertain capacity demands, maintenance scheduling changes, continued availability of skilled technicians, or system breakdowns. Aiming for development of objective, verifiable, and definitive requirements for a maintenance system in such a complex situation may introduce difficulties and result in a mismatch between the nature of the system and the capabilities of traditional approaches to appropriately deal with eliciting meaningful requirements for such a system.

  • Evolving complex systems—a good example of an evolving complex system is a human immune system. Such systems can change over time, and the path they take from one state to another cannot be predicted from past system states, making stable requirements elicitation problematic. Von Bertalanffy ([22], p. 187), notes that “chaos was the oft-quoted blind play of atoms which…appeared to represent ultimate reality, with life as an accidental product of physical processes.” This underscores the difficulty in understanding systems that evolve in ways that cannot be fully understood, even with the benefit of hindsight. Failure to recognize that a system can evolve through highly emergent processes can place requirements elicitation processes at irreconcilable odds with situations steeped in evolving complexity. Rapid technological and societal changes, coupled with high levels of contextual influences, can contribute to extensive emergent system behaviors. Therefore, the elicitation of requirements based in assumptions of limited emergence may not be appropriately suited to complex situations. Additional types of complex systems can be found in [53] as depicted in Fig. 1.

    Fig. 1
    figure 1

    Types of complex systems [53]

    Full size image

Thus, the process of elicitation of requirements is intricately connected to the complexity inherent in a system and corresponding situation. It is naïve to assume that use of TREPS is suitable for all situations, particularly in emerging areas such as critical infrastructures, which are dominated by high degrees of complexity and interconnectivity.

To expound on the process of elicitation of requirements in complex systems, Table 3 is provided to articulate the attributes upon which the determinations of complexity might be examined. In addition, authors have identified the implications of the system attributes for requirements elicitation based on traditional approaches.

Table 3 Complex system attributes
Full size table

Many other complex system attributes are further discussed in [2]. While this listing is by no means exhaustive, it has shown that complex systems can be categorized as static, dynamic, or evolving, and the degree of complexity in the situation is an important determination of those entering into requirements elicitation processes. Although the use and utility of TREPS in requirements elicitation is not in question for traditional situations, the presentation questions their direct applicability to situations characterized by higher levels of complexity.

5 Nature of complex system requirement environment

As described earlier, systems do not reside in a vacuum. In the domain of systems thinking, it is well established that systems reside in an environment separated by a boundary. The environment is often characterized by factors that are beyond the control of the system observer or the system itself. The principle of environmentalism further explains that the “behavior and the personality [of a system] are shaped by outside influences” ([22], p. 190). The argument here is not that the environmental factors (technological advancements, politics, economics, etc.) can be used to influence true system requirements. On the contrary, it is recognized that there are outside factors that can have a substantial effect on the nature of requirements and that such factors should be considered in requirements elicitation processes. The space in which requirements reside is the operational environment because it is where communication among systems takes place.Footnote 2 On the issue of environment, [65] notes that a comprehensive description of an environment is critical to the life cycle of a system and its related processes. Hall and David ([65], p. 254) suggest that in order to arrive at an accurate prediction of true system requirements, accurate description of the operating environment is necessary. The immediate factors (i.e., resources such as work force, costs, time, expertise, etc.) may be easy to relate to system requirements in using TREPS. However, differing worldviews, politics, high levels of ambiguity and uncertainty characteristic of complex situations are not so easily made explicit or incorporated. Such factors exist beyond the intentions or capability of TREPS to acknowledge, capture, or process.

The influence of system environment in complex situations calls into question the appropriateness of TREPS for handling requirements. The environment for complex situations is far from static, exhibiting high levels of uncertainty, emergence, and instability in boundary conditions. In many cases, the ability to develop a stable boundary to define what is included or excluded from the system in question may be undecidable at a present time. The result is the rendering of requirements elicitation processes based on assumptions of clear boundary definition, which may be inappropriate for complex situations. For example, is it possible to determine the boundary conditions for an adversary that is not totally known and seemingly “morphs” in unpredictable ways at unknown intervals? We would most appropriately conclude no. The instability of boundary conditions for complex situations suggests that a paradigm shift, consistent with appreciation of complexity, is in order to better serve the way observers might approach elicitation of system requirements for complex situations.

This section was intended to show that (1) system requirements do not exist in a vacuum. Requirements exist in an operating environment. Such an environment can be complex and dynamic suggesting differences in the way requirements are elicited and the type of requirements that can be elicited, and (2) the operational environment is used for communication and interplay among complex systems, adding significantly to the environmental instabilities challenging traditional approaches to requirements elicitation based on assumptions of relative environmental and boundary stability. Since the environment can influence a system, it is imperative to study a system with its environment in mind. To illustrate the need for this paradigm shift in requirements elicitation, an example is provided below.

6 The use of TREPS in “Vee” model example

First developed by Forsberg and Mooz in the 1980s, the Vee model (shown in Fig. 2) is widely used in government and industry applications, particularly in software requirements analysis. Since everything starts with user requirements, the success of the Vee model is highly dependent on TREPS used during user requirements elicitation. Prior to proceeding, a complete, unambiguous, consistent, understandable, traceable, and modifiable set of requirements is needed. User requirements are elicited from three main perspectives:

Fig. 2
figure 2

The “Vee” model showing technical aspects ([6], p. 2)

Full size image

  • System user perspective—point of view of a system and its requirements from the vantage point of the system owner, customer, or stakeholder who has envisioned the system-to-be. This perspective is needed for technical aspects under the Vee lifecycle. The assumption is that the elicited requirements provide all necessary information needed to move forward.Footnote 3

  • System engineer perspective—a perspective that encompasses all technical aspects of a system and usually includes subsystems, component, and item specifications.

  • Third party perspective—usually a third party is involved in requirements analysis, and their view must be captured as well. Requirements related to component specification, design, manufacturing, and testing of components are derived at this level. Even for a technical system, care is taken to ensure the correct requirements are elicited early in the design phase.

Since only technical aspects are dealt with in user requirements, this suggests that nontechnical aspects are either not explicitly explored or not a substantial element in the process of requirements elicitation. Further, agreement must be reached before progress can be achieved. Any change in user requirements often has an impact on system design and completion ([6], p. 2). The implicit assumption, which makes the “Vee model” appropriate with a high probability of success, is the application to systems that exist in relatively static environments and stable boundary conditions. If these conditions are not present (e.g., complex situations), the utility of traditional approaches such as the “Vee model” must be questioned.

To illustrate limitations associated with the use of requirements elicitation techniques unsuited for complex situations, Table 4 examines a Vee model example in light of several complex system attributes. This is necessary to illustrate that a representative TREPS model, while capable of achieving success when applied to the right circumstances, may offer limited utility when applied in complex situations. The “Vee model” is used for illustration purposes only. Any of the more traditional models (e.g., waterfall, spiral, etc.) involving aspects of requirements elicitation as a central element may have been used in lieu of the “Vee model.” Even the “spiral model” with elements of iteration embedded must be questioned with respect to assumptions of environmental stability and boundary certainty. The essence of this discussion is that the appropriateness, applicability, and success potential for more traditional approaches related to requirements must be questioned with respect to consideration of the complexity attributes identified in Table 3. If there is not sufficient confidence in the applicability of traditional approaches, or the ability to modify those approaches based on complexity in a situation, practitioners should proceed with extreme caution and temper expectations for success with traditional requirements processes. This is not to say that they cannot be successful. However, traditional approaches have not been designed or proven for the complex situations identified in this paper.

Table 4 Implications of using unfit tools and techniques
Full size table

Understanding a situation in which a technique or approach can be used is critical to success for the design of a system-to-be. Perhaps a major challenge in the use of TREPS has to do with accommodation of changes in the system, the environment, and perspectives of the situation. This places more traditional approaches to requirements elicitation at odds with the inevitable changes inherent in complex situations. In fact, [5], p. 6) notes that “modification of User Requirements after PDR [Preliminary Design Review] should be held for the next model or release. If significant changes to User Requirements must absolutely be made after PDR, then the project should be stopped and restarted at the start of a new ‘Vee,’ reinitiating the entire process.” In complex situations, potentially drastic changes are inevitable. These are not necessarily due to “poor engineering” efforts, but rather simply a function of the high levels of complexity in the situation that no amount of “engineering” will be capable of squeezing out. Such situations introduce “a not-definable problem” ([7], p. 3) mired with irreducible, intransient, and perceptual elements that are difficult to bound and subject to significant shifts.

From Table 4, one can conclude that while the use of TREPS might generate success in technical aspects of systems, it will be challenged as an equally appropriate approach to increasingly complex situations (shown by the attributes and their implications in the table). For complex situations, differences in the three natures suggested (system observer, requirements, and environment) proceeding with caution in the application of traditional approaches to requirements elicitation. The view presented here is consistent with [9], albeit in different context. For example, van Lamsweerde ([9], p. 219) notes “the world keeps moving…the system objectives, conception structures, requirements and assumptions that have been elicited, evaluated, specified and analysed…” In this situation, attaining stable, clear, verifiable, objective, and definitive requirements is not the norm. This claim may seem obvious to some, however, not eliciting requirements, and understanding the “whole” can have significant impact on a specific project and beyond. Table 5 provides a speculative sample of failures that authors suggest can be attributed to failing to account for one or more of the three aspects developed in this paper: observer, requirements, or environment inherent in a complex situation.

Table 5 Examples of failures in the government and private sectors
Full size table

While one could ask, how many of these tragedies are associated to TREPS?, authors argue that requirements elicitation processes are meant to reduce and at best eliminate such massive problems by ensuring that the right systems are built. If such problems are persisting, this is indicative of the weaknesses associated with methods, tools, approaches and the thinking employed to complex situations. While this does not disparage the particular traditional methods themselves, it does suggest that the complexities inherent in the situation makes them incompatible (incongruent with the ambiguity of the situation to which they were applied), not sufficiently robust (to include the multiple dimensions of the problem domain), and inappropriate for application (incapable of matching the complexities of the situation) and therefore not appropriate for requirements elicitation, development, and implementation. Elicitation of requirements from singular perspectives only provides a partial picture of the situation, and although it might effectively impose “technical” system requirements, it is not sufficiently robust. Robustness must appreciate the multitude of nontechnical aspects of a complex situation and the degree to which these aspects can constrain and render innocuous the most well-intentioned technical solutions.

Imposing requirements from a limited perspective can be disruptive and nonsensical considering impact and consequence they have on human ways of life [71]. Therefore, requirements elicitation for complex situations would be more appropriate with inclusion of three important fronts: (1) the role of the observer, (2) identifying nature of system requirements, and (3) the influence of operational environment. In the next section, authors suggest an emerging framework for requirements elicitation within complex situations.

7 Requirements elicitation in complex situations: an emerging framework

An emerging framework is captured by Fig. 3 and includes three phases that are meant to ensure a more robust system requirements elicitation process. This framework is a high-level approach concerned with laying a foundation for requirements elicitation in complex situations. The intent of the framework is not to be taken as a systematic process to solving requirement issues for complex situations. Instead, it stands as a guide to thinking more deeply about the requirements elicitation process, and the degree to which the situation within which the process is undertaken is appropriate for the approach being considered. It also differs from a theory in that it does not provide explanation for the associated phenomena related to requirements elicitation [72]. To be effective, the three phases of the framework should take place prior to selection and the use of TREPS for requirements engineering. At a minimum, this may preclude practitioners from mistakenly applying requirements elicitation processes that are incompatible, incongruent, and inappropriate for the complex situation within which they are being considered for deployment. Authors also argue for the framework applicability thought the requirements engineering process not just at initiation.

Fig. 3
figure 3

Steps in evaluation of system and its attributes

Full size image

  • Phase I: Understanding the nature of the system observer—before the selection of methods, tools, and approaches consider the ontological, epistemological, and methodological dispositions of the situation observers (owner, designer, user, etc.). The intention is to ensure that the right people work on the right problem appreciating multiple perspectives. Incompatibility among participants may result in serious miscalculation that will only be exacerbated as the process continues. This phase gives one the ability to attempt to understand how system observers view a problematic situation, how they approach a situation, and how knowledge is communicated. Incompatible paradigms are likely to be a source of problems in elicitation of requirements. It is recognized that, as stated earlier, that there may be different viewpoints, which can be resolved with engineering logic and resolution. However, the notion of incompatible paradigms (worldviews) exists at a different level, incapable of being necessarily resolved at the level of logical (engineering) argument. Incompatible paradigms exist at an entirely different (philosophical) level. At this level, the values, beliefs, and corresponding worldview (1) exist at a more fundamental (philosophical) level, not having the capability of rapidly shifting, (2) is not explicitly articulated or known beyond a tacit level, and (3) are a source of incompatibility in decision, action, or interpretation in addressing issues. Therefore, incompatibilities at this level, left unarticulated and unresolved, will invariably result in conceptual conflict incapable of being resolved through engineering logic. The result of unresolved philosophical divergence is that further requirements engineering efforts may be limited in effectiveness. If the situation is highly complex, the potential for divergence of system observers is exacerbated and care should be taken to proceed with caution if there is not sufficient alignment of perspectives. Different viewpoints (e.g., engineering, marketing, customer, production, etc.) have been suggested and recognized as enhancing requirements elicitation processes [45–48]. However, the distinction is made between a discipline- or experience-based viewpoint and an underlying philosophical divergence in paradigm(s) or worldviews. The suggestion for practitioners is to appreciate the potential of deeper divergence (beyond surface level or discipline-specific differing perspectives) in philosophical disposition and the potential impact on the decisions, actions, and interpretations inherent in any requirements elicitation process.

  • Phase II: Identification of the nature of system requirements—this phase seeks to understand the nature of complexity in the problematic situation. This assessment is done to provide a glimpse to determine success likelihood of different requirements elicitation processes. At a basic level, this requires considerations for classification of the system and situation into simple and complex with ramifications for errors stemming from misclassification. Miscalculation of assuming that a system situation is simple (e.g., well bounded, stable, low uncertainty, unambiguous, technically driven, and low emergence) versus highly complex (e.g., tenuously bounded, unstable, high uncertainty, high ambiguity, both technically and nontechnically driven, and highly emergent) should be avoided. If there is a significant mismatch, it is likely that a “glossed over” requirement will emerge at later point in the process. Identification of a mismatch at this phase should help preclude the inevitable disappointment and misallocation of resources sure to follow the miscalculation.

In a complex situation, there are several confounding assumptions. There is always the possibility that in a particular situation, requirements will not be captured. Depending on the necessity of the response, often something must be done to advance the situation. This suggests that there is a need for more informed approaches as suggested by this framework. This framework attempts to identify potential pitfalls in the requirements elicitation prior to the design process. Therefore, the burden of solving the wrong problem or operating from the wrong set of assumptions can be identified early on in the requirements elicitation process. This can help align expectations, process, and the complex situation to avoid disappointment in either of the three.

  • Phase III: Assessment of the nature of the environment—the approach to producing requirements does not exist in isolation. In phase three, the consideration shifts to the nature of the environment of the complex situation. Is the environment for the system stable, static, or dynamic? If the environment is dynamic, the process and tools used in requirements elicitation should be capable of coping with the environmental change as opposed to continuing inappropriate assumptions stemming from miscalculation as a stable environment. Considering the nature of the environment ensures that appropriate assumptions are set prior to requirements elicitation. This has significant implications for expectations of the requirements elicitation process. In effect, there must be a critical examination of the environment of the complex situation, and determination of the impact of that environment on the appropriateness of the approach and expectations for the requirements elicitation process.

The right implementation of this framework can enable the selection of appropriate methods, tools, and approaches for the requirements elicitation process. The common underlying fundamental for this framework is the role of the environment. In systems thinking, the position of observer within the environment shapes the observer’s worldview of system requirements. Understanding the role of the observer, the nature of the system requirements, and the environment can enable requirements engineers to engage systems thinking to encourage more robust and holistic assessment of the requirements elicitation process for complex situations.

A significant feature of the framework is the consideration of requirements from three major perspectives in complex situations: observer, requirements, and environment. In summary, ineffective elicitation of requirements for complex situations might be avoided by purposeful consideration of the three major elements presented in the framework. Failure to appropriately consider the framework elements may lead requirements engineering professionals to

  • Commit a Type III error of solving the wrong problem precisely in the most efficient way possible [8].

  • Inappropriately formulate the problem in a way that will lead to poor execution of elicitation. For example, if the problem is formulated strictly as a technical problem, while it is a socio-technical one, the final solution success will be doubtful, regardless of the adequacy of understanding the technical dimensions of the complex situation.

  • Not adequately knowing the degree of complexity for the situation under consideration. This may result in selecting and applying inappropriate strategies, tools, and techniques for design of a system-to-be.

  • Misunderstand the implications of behavior of dynamic systems changing over time and in unpredictable ways. Incorrectly assuming stability in the environment and situation might lead to elicitation of requirements that quickly become obsolete. Therefore, it is critical to differentiate between the static and dynamic environments as they influence appropriateness of requirements elicitation.

The view presented in this framework offers an alternative approach to thinking about the requirements elicitation process. Rather than depending only on observer dispositions [59, 73, 74], this paper argues that to have a complete view of system requirements one needs to more robustly account for the observer disposition, include the nature of system requirements, and account for the environment existing external to the situation under consideration. To further contrast usefulness of the framework, Table 6 is provided to illustrate the potential advantages of the framework for thinking about requirements elicitation in complex situations. Lack of consideration for the role of system observer, nature of system requirements, and the environment can be costly as illustrated in Table 5. The framework presented in this paper provides a foundation to guide further development to enhance effectiveness of requirements engineers who must deal with the ambiguity, uncertainty, and emergent behaviors inherent in engineering system solutions.

Table 6 Proposed framework advantages
Full size table

8 Conclusion: implications for further development and practice

This paper suggests that the future developments in the requirements elicitation process can benefit greatly by the consideration of the impacts of the role of the system observer, the nature of system requirements related to the system under consideration, and the nature of the environment. While this conceptual framework is in the preliminary stages of development, authors feel that the need to begin the difficult work of understanding the implications of complexity for requirements engineering must be accelerated. The use of TREPS has worked effectively, and will continue to work effectively, when applied to the right problem domains. These problem domains are marked by relatively stable environments (not changing significantly), well-understood boundary conditions, and static complexity. However, for the increasingly prevalent requirements engineering scenarios marked by high levels of ambiguity (fluxing boundary conditions), uncertainty, and emergence, new paradigms, models, and tools must be developed.

The framework presented in this paper is a first attempt to catalog the problem and offers a conceptual movement forward to better understand the nature and implications for requirements engineering. By their very nature, TREPS are rightfully focused on the technical elaboration of requirements. In the future, the nontechnical aspects of complex situations (organizational, managerial, human, social, policy, political) must be factored into the requirements elicitation process with greater appreciation and rigor.

This paper has also shown that TREPS are most effective when dealing with technical situations where requirements are stable, verifiable, unambiguous, definitive, and objective. However, in situations where complexity, stemming from various sources related to observers’ nature, system requirement attributes, and the environment call to question the appropriateness of using TREPS as an effective means of requirements elicitation for complex situations.

The proposed framework in this paper, while not a full-blown methodology, enables requirements engineering practitioners to more effectively engage in consideration of the role of the system observer, the nature of system requirements, and the influence of the environment on the process of system requirements elicitation. Since requirements enable the realization of a system-to-be, authors suggest that a more holistic approach to requirements elicitation is needed, and this paper represents a first attempt to contribute to this field of research by introducing a new framework for dealing with requirements in a complex situation. The intention is to sharpen the debate while arming practitioners with some new language and challenge to traditional thinking about the knowledge elicitation process.

The next stage for this development is to elaborate the framework with appropriate tools and methods to support the three phases suggested. The further development of the framework must concentrate on the validation of the approach, underlying theoretical formulation, and practical application. The framework is in the formative stages and therefore provides no specific tools, steps, or procedures. Future work must proceed in the area of implementation and applications of the framework. Implementing and modifying current tools for requirements elicitation can be useful in bringing the framework beyond the conceptual level to better enable practitioners to deal more effectively in these characteristically complex situation domains. In turn, development of new tools, methods, and techniques to deal with requirements elicitation in complex situations must be identified and work begin to produce them.

Authors close with three considerations for practitioners based on the current state of this work. First, practitioners should consider the compatibility of the worldviews of those engaging in the requirements elicitation process. Incompatibilities in the “observers” along philosophical lines presented in this paper will have broad ranging impacts on the effectiveness of any process related to elicitation of requirements.

Second, the nature of requirements for the system under consideration should be taken into account. If the system is of a “simple” nature, it should be treated with traditional requirements elicitation processes, as those are proven and are appropriate for primarily technical issues. These conditions are marked by unambiguous boundaries, certainty in definition, traceability, and verifiability of requirements, and a static nature of the environment. In contrast, practitioners should be wary of the use of TREPS under conditions marked by high levels of uncertainty, ambiguity of boundary conditions, complexity, and emergence. In these situations, practitioners would do well to proceed with caution when applying TREPS. TREPS-based methods, tools, techniques, and approaches have not been designed for and do not fully appreciate complex situations. Therefore, their utility and effectiveness is suspect at best.

Finally, practitioners should understand that, in complex situations, they should maintain flexibility in requirements elicitation and ensure that requirements can, and will, change as new knowledge and understanding of the system and context emerge. It is counterproductive to think that for complex situations requirements elicitation will be straightforward, static, or limited to purely technical considerations. To this end, assuming that traditional forms of requirements elicitation will yield stable, verifiable, definitive, and objective requirements for complex situations should be challenged.