The implications o f this research fall into its contributions to theory, practice, and method.
Contribution to Theory
As the researcher exposed through the Literature Review in Chapter 2, the body o f knowledge remains discemibly shallow in the area o f theory supporting SoS
Requirements (engineering, elicitation, development, definition). Why is this so? The researcher certainly does not proffer any definitive explanation, but draws the reader back to the Chapter 1 discussion under what motivated the researcher to embark on this study.
Perhaps, and the researcher offers this only anecdotally, the task o f defining requirements for SoS is hard to do. Perhaps the tools o f TSE have simply given all they can and the community has reached the proverbial ‘end-of-the-line.’ Bold assertions no doubt, but the researcher can’t help but think this same kind o f situation sparked ‘new thinking’ that finally resulted in the Soft-Systems Methodology (SSM) (Checkland, 1993, 1999). In fact, we get a glimpse o f the situation through Checkland’s own words:
We fo u n d that although we were armed with the methodology o f systems engineering and were eager to use its techniques to help engineer real- world systems to achieve their objectives, the management situations we worked in were always too complex fo r straightforward application o f the systems engineering approach. The difficulty o f answering such apparently simple questions as: What is the system we are concerned with? and What are its objectives? Was usually a reason why the situation in question had come to be regarded as problematical. We had to accept that in the
complexity o f human affairs the unequivocal pursuit o f objectives which can be taken as given is very much the occasional special case; it is certainly not the norm (Checkland, 2000, p. S14).
In no way is the researcher comparing the weight o f his contributions to that such as delivered by Peter Checkland, but the researcher will claim the contribution to the body o f theory for SoS requirements is the result o f ‘new thinking’ about the challenge, which is in itself a contribution to theory.
Though certainly not a new implication for research (Adams, 2007; Bradley, 2014), the researcher’s use o f inductive methods to engineering research forms yet another data point in the ongoing debate over its viability in comparison to deductive methods.
Contribution to Practice
The most significant implication stemming from this candidate method is that it begins to fill in a sizeable gap in the current prescriptive practice involving SoS
requirements definition. The author posits that in order to get to normative models for SoS requirements definition, more descriptive evidence must be generated that applies new approaches and ideas to practice so the community o f SoSE practitioners has a higher level of assurance the ideal state being defined by normative models is viable. The aim o f this method is to provide just that, a new approach - potential prescriptive
guidance, to defining SoS requirements.
Contribution to Method
An implication with this candidate method is its application for larger SoS analyses efforts. In the researcher’s experience, SoS analysis efforts often involve determining where an extant SoS has functional capability gaps and overlaps. In this problem context, a gap is the case where the SoS is in need o f something it does not possess, and an overlap is the case where the SoS has redundant functional capability, which could suggest either an effective (it may be good to have multiple systems doing the same thing for reasons o f fault-tolerance) or inefficient application o f resources across the SoS. In fiscally-constrained times, knowing what to apply sparse resources to or how
to conserve resources better can be a valuable end to SoS analyses. In order to know whether the SoS has a gap or overlap assumes the SoS practitioner also knows what is required o f the SoS overall. Given the SoS case where no top-level SoS requirements have been defined, this method can lead the SoSE efforts to readily seeing where these gaps and overlaps exist. Specifically, these gaps and overlaps become clear during Components 3 (where you see multiple systems are doing the same function - overlap) and 4 (where you see missing functions - gap).
The method can be applied in both hard (e.g., hardware/software system
dominant) or soft (e.g., organizational or human system dominant) environments. Though the example presented in this research was very hard system centric, the practitioner is encouraged to not limit its application or avoid soft system environments; the
organizational or human elements in this environment can be considered systems as well, and all systems perform functions.
A more significant implication exists in engaging the SoSE community in applying this method, and other new prescriptive ideas, to real-world SoS cases. The author posits that this method can be transported across SoS domains, but thus far it has not attained broad exposure to a wide range o f SoS domains. Therefore, practitioners across the spectrum o f SoS domains, are challenged to be bold and attempt applying this method to their SoS, to adapt it to fit their own needs, and where feasible publish their experiences and outcomes to the benefit o f the wider SoSE community.
Yet another contribution to method stemming from this research is the Construct Classification Method the researcher derived (discussed in Chapter 4) to assign a
review on construct paradigms, he derived a classification method that can be reused within the discipline o f engineering, possibly even other domains as well - the researcher offers this idea as an area o f future research below.