Selecting Features for the Next Release in a System of Systems Context
Carsten Wiecher, Carsten Wolff, Harald Anacker, Roman Dumitrescu
SSelecting Features for the Next Releasein a System of Systems Context
Carsten Wiecher
Dortmund University of AppliedSciences and Arts44139 Dortmund, Germany [email protected]
Carsten Wolff
Dortmund University of AppliedSciences and Arts44139 Dortmund, Germany [email protected]
Harald Anacker
Fraunhofer IEM33102 Paderborn, Germany [email protected]
Roman Dumitrescu
Fraunhofer IEM33102 Paderborn, Germany [email protected]
Abstract —Smart Cities are developing in parallel with theglobal trend towards urbanization. The ultimate goal of SmartCity projects is to deliver a positive impact for the citizens andthe socio-economic and ecological environment. This involvesthe challenge to derive concrete requirements for (technical)projects from overarching concepts like Quality of Life (QoL)and Subjective Well-Being (SWB). Linking long-term, impactoriented goals with project outputs and outcomes is a complexproblem. Decision making on requirements and resulting featuresof single Smart City projects (or systems) is even more com-plex since cities are not like monolithic, hierarchical and well-structured systems. Nevertheless, systems engineering providesconcepts which support decision making in such situations.Complex socio-technical systems such as smart cities can becharacterized as systems of systems (SoS). A SoS is composedof independently developed systems that nevertheless provide ahigher-level integrated functionality. To add new functionality toa SoS, either existing systems must be extended or new systemsmust be developed and integrated. In both cases, the extension offunctionality is usually done in small increments and structuredvia software releases. However, the decision which features toinclude in the next release is complex and difficult to managewhen done manually. To address this, we make use of the multi-objective next release problem (MONRP) to search for an optimalset of features for a software release in a SoS context. In orderto refine the search in an early planning phase, we propose atechnique to model and validate the features using the scenariomodeling language for Kotlin (SMLK). This is demonstrated witha proof-of-concept implementation.
Keywords —System of Systems, Multi-objective Next ReleaseProblem, Scenario-based Requirements Modeling
I. I
NTRODUCTION
Decision making, project selection and goal-setting forprojects are a very relevant long time issue in politics and cityplanning. E.g., in Germany, there is a long history of attempts,methods and tools in order to manage the development of citiesand the political decision making [1]. Several programs withtop-down planning and decision making where implemented.It is an ongoing debate if they met their goal and if they had aclear goal. Cities are highly complex, highly connected andorganic, self-organizing systems. The digital transformation towards Smart Cities is adding to this complexity. Decisionson which steps to take next, which projects to do, whichgoals to set for the projects and which features to implementare difficult. This makes the requirements engineering andproject management for engineering projects in the Smart Citycontext very difficult, too. This contribution intends to delivera decision support approach which is based on systems engi-neering methodology. It is believed that the approach supportsthe effort to link impact-oriented indicator systems for SmartCities like Quality of Life (QoL) or Subjective Well-Being(SWB) to the requirements for concrete engineering projects.Complex systems like smart cities can be characterized assystem of systems (SoS) [2]. These SoS are composed ofindividual constituent systems (CSs) that are independentlydeveloped and operated but nevertheless can be integratedto provide a higher level functionality [3]. One use case ina Smart City context is smart charging of electric vehicles(EV). To realize a smart charging use case, different systemsfrom different domains (energy conversion, energy transferfrom/to EV, EV user premises etc.) must be considered andintegrated [4].In contrast to the development of complex monolithicsystems, new functionality in a SoS context is usually createdby selecting, adapting and integrating systems [5]. Since thesesystems are independently operated and managed, can havedifferent life cycles and evolve over time, the decision whichfunctionality shall be added is a complex task. It is necessaryto make trade-off decisions based on expected costs and valuesfor the realization of new functionalities. The estimation of thevalue of a new feature in the context of Smart City projects isparticularly challenging as we describe in section II. Therefore,the indicators of cost and value of new functionalities form theinterface to the decision-making processes of the Smart City.In this context, we address the problem that in a SoSwe do not have a fixed set of requirements that we canuse to decompose the system requirements into subsystemrequirements [6] [7] in order to estimate the cost and value a r X i v : . [ c s . S E ] M a r or realizing these requirements.In this paper, we propose an iterative and tool-supportedprocess that helps the release engineer to identify a set offeatures that can be considered for a next release to add newfunctionality to a SoS. We use a software release to group a setof features, where features are used to summarize a consistentset of requirements from one or more stakeholders.As introduced in previous work [8]–[10], we show howto specify stakeholder expectations in a comprehensive andstructured form using feature files and usage scenarios. Basedon this feature specification, we use a test-driven specificationapproach [8] to iteratively model the intended SoS behavior inform of a scenario specification [11]. By creating, executingand testing the scenario specification, we are able to refine theinitial feature specification.Subsequently we use this feature specification along withthe scenario specification to manually estimate the costs itcan take to realize the feature and the value it can create. Thisestimation is used as input to a multi objective next releaseproblem (MONRP) [12] that we apply to automatically searchfor an optimal set of features. The resulting feature sets ofpossible release candidates can be used by the release engineerto select the next release.We show a proof-of-concept implementation, where featuresare specified using the Gherkin syntax [13] within the Cu-cumber tooling [14]. The SoS behavior is modeled using thescenario modeling language for Kotlin (SMLK) [15], and theMONRP is implemented using the MOEA framework [16].As a result, we see that the iterative process of 1) structuredfeature specification, 2) test-driven and scenario-based require-ments modeling, and 3) a tool-supported search for releasecandidates, can be supportive to identify a next release in aSoS context. II. B ACKGROUND
A. Smart City projects
Citizens expect from Smart City projects a positive impact.Nevertheless, it is difficult to define this positive impactclearly and it is even more difficult to link it to concreteevents or elements within a Smart City. E.g., there are at-tempts to link concepts like Quality of Urban Life (QOUL)and Subjective-Well Being (SWB) to concrete features of acity [17]. This involves two underlying problems: one is thedefinition and measurement of indicator sets describing QOULor SWB. The second issue is the linking of long-term impactgoals like QOUL or SWB to concrete project outputs whichcan be described by user requirements. Systems engineeringmethodology requires such well-defined user requirements inorder to develop features of technical systems. The systematiclinking of inputs, outputs, outcomes and impact of projectsis a relevant research topic in project management [18]. Thecost of a new functionality in the sense of this study isderived from the inputs required by the respective project. Thevalue is addressing the impact which is difficult to determineat the time of decision-making. This can be addressed bya result-oriented logic defining potential cause and effect chains between the different levels of results. Nevertheless,such logic remains incomplete and insufficient in complexreal-world scenarios like Smart Cities due to the high levelof uncertainty. This leads to a more incremental process ofdefining and selecting projects which add systems to the SmartCity step-by-step. Decision making has to focus on selectingprojects and Smart City features and functionalities whichare implemented and released to the public. The managementand decision-making for the release of such new featurescan be supported by systems engineering methodology. Doing"good" decisions can be supported by optimization methodsfrom operations research. The following sections describe howfeatures can be selected for inclusion into the release of anew system and how these systems can be integrated into theoverall Smart City system.
B. System of Systems
SoS are distinguished from complex monolithic systems bythe operational, managerial and evolutionary independence ofits CSs [3]. Accordingly, each CS can perform a meaningfultask, even if it’s not integrated into the SoS. Since the CSsare self-administered and individually managed, this can leadto conflicting development goals between the single CSs, orbetween CSs and the SoS. Also, objectives and functionality ofan SoS can change constantly, as they can be added, modifiedor removed based on experience. Therefore an SoS neverappears to be fully completed [19].Due to these SoS characteristics and in contrast to the devel-opment of complex monolithic systems, we do not have a fixedset of requirements that can be decomposed for an linear andtop-down system design [6] [7] and validation [20]. However,requirements decomposition techniques and the alignmentof stakeholder expectations via validation are mandatory toestimate the value and the costs of requirements and to decidewhich requirements should be realized with the next release. O1 System of Systems
O2 O3CS1 CS2 CS3 ownsownsowns contractual relationship contractual relationship SoSboundarys1s2 s3directsoperation directsoperation
Fig. 1. Acknowledged System of Systems, based on [5] [7]
To support SoS requirements engineering, Ncube and Limargue that it’s necessary to define a SoS type in an earlydevelopment phase [7]. This is fundamental to understandthe dependencies and responsibilities between the SoS andts CSs, and also between the individual CSs owner and otherstakeholder during SoS development [7] [6]. Therefor, in thispaper we make use of an acknowledged SoS [3] [5] [19] asoutlined in Fig. 1, which is suitable to describe systems likeSmart Cities [7]. Here, we assume that we have three CSs(CS1, CS2, CS3) with each CS having one system owner (O1,O2, O3), who is responsible for the development and operationof the respective CS. We also see external stakeholders (s1,s2, s3), that have an interest in the SoS development (e.g. SoSuser). In this acknowledged SoS, O1 directs the operation andthe choice of CSs. For this, O1 can define requirements thatmust be fulfilled by the CSs. However, the CSs retain theirindependent ownership, funding, objectives, and developmentapproaches. Hence, the realization of a SoS functionality isdirected by a central authority but requires the collaborationon CS level [7].
C. Multi-Objective Next Release Problem
According to [21], a release is a collection of new and/orchanged features that form a new version of an evolutionaryproduct/system. Thereby, a feature serves to summarize aconsistent bundle of requirements from one or more stake-holders [22].If we characterize a Smart City as a SoS, the local govern-ment is an example of a central authority (O1 in Fig. 1) thatdefines the collection of features that should be included intothe next release to form a new SoS. To support the centralauthority in deciding which features should be included intothe next release, the application of the MONRP formulated in[12] is suitable.As outlined in Fig. 1 we have multiple stakeholders request-ing new functionality from the SoS. On an SoS level, O1 hasto select a set of features for the next release, where eachfeature is realized by a CS or by a combination of CSs. Torealize a feature, each system owner has to spend an amountof resources resulting in a certain amount of costs. At thesame time, when providing a specific feature, this providesa specific value. From the perspective of O1, the goal is tominimize the costs and maximize the value. As a result wehave two conflicting objectives. According to [12] and [23],finding the optimal set of features is a
N P -hard problem andcannot be resolved by exact optimization. For this reason, weuse a metaheuristic search technique [12] to approximate anoptimal set of features.
D. Scenario-based Requirements Modeling
In this paper, we argue that early requirements modelingand testing can support cost and value estimation of featuresto be implemented. Requirements modeling with scenariosand use cases gives stakeholders a better tool for decision-making since the scenarios and use cases can be formulated innatural language and they can be linked to real-life situationsof the stakeholders. Therefore, on the one hand, require-ments engineering based on scenarios and use cases offersa "common language" to involve non-technical stakeholdersinto the process. On the other hand, scenario and use case descriptions can be transformed into formal descriptions forrequirements engineering by using model-based approaches.For this requirements modeling we use the scenario modelinglanguage for Kotlin (SMLK), which is based on the conceptsdescribed in [24]–[26].In SMLK, functional requirements are modeled with be-havioral threads which we call scenarios. These scenarios areloosely coupled via shared events. Within a scenario, we canrequest events that shall be executed. If an event is selectedfor execution, it can trigger the execution of other scenariosthat in turn can request additional events. By iteratively addingscenarios to a scenario specification, we obtain an increasinglycomplete specification of the intended system behavior overtime. During execution of the scenario specification as ascenario program, the scenarios are interwoven to produce acoherent system behavior that meets the requirements of allscenariosAn example scenario specification as part of a simplifiedsmart charging use case is shown in Listing 1. class EVU{ // Electric Vehicle User fun energyPriceInformation() = event(){} } class App{ // Smartphone App fun enterChargingPreferences() = event(){} fun calculateChargingPlan() = event(){} } class EV{ // Electric Vehicle fun chargingPlan() = event(){} fun executeChargingPlan() = event(){} } scenario(EVU sends App.enterChargingPreferences()) { request(App.calculateChargingPlan()) request(App sends EV.chargingPlan()) request(EV.executeChargingPlan()) } Listing 1. SMLK scenario specification
In this specification we modeled two CSs (smartphone app andelectric vehicle) and one external stakeholder (electric vehicleuser). The scenario in line 13 is triggered when a electricvehicle user enters charging preferences to the app, i.e. theevent
EATURE S ELECTION FOR THE NEXT R ELEASE
We propose an iterative process as shown in Fig. 2. Theintent of this process is to support the definition of cost andvalue information that will serve as input to the automatedsearch for an optimal set of features for the next release. Westart with a specification of features (1) which are manuallyderived from stakeholder expectations. Subsequently we modeland execute the expected system behavior in short iterations(2) in order to elaborate a formal and scenario based specifica-tion of technical requirements. In (3) we iteratively refine theinput data for the automated search which is executed in (4). onvert stakeholderexpectations intofeature descriptions1 create/test/refineSoS model2 refine cost and valueestimation for eachfeature 3 search for optimal set of features for thenext release 4trigger implementationplanning
Fig. 2. Steps for the tool supported selection of features for the next release.
As a result of this search, we get a set of features which canbe used as a starting point for the implementation planning.As outlined in Fig. 3, the process aims to link the business-level definitions of features with the specification of technicalrequirements. By utilizing usage scenarios, the artifacts in bothviews are connected with each other. In this way, features
Business LevelObjectives/Features Technical Requirements
Usage Scenarios
Sect. III.B: Definition of features Sect. III.B: Specification of usagescenarios Sect. III.C: Formal and scenarios-based modeling of systemrequirements
Fig. 3. Definition of features and formal, scenario-based technical require-ments, that are linked via usage scenarios. and technical requirements can be executed and refined it-eratively. As a result, we obtain a feature specification thatsupports value estimation and a scenario-based specificationof technical requirements that supports estimation of the costof implementing a particular feature.
A. Objective Functions
To perform an automated search for an optimal set offeatures for the next release, we use the MONRP as proposedin [12].We assume that we have a set of stakeholders, S = { s , ..., s m } that have an legitimated interest in the realization of a newSoS functionality. Based on the desired SoS functionality, wederive a set of features, F = { f , ..., f n } and for each feature f i (1 ≤ i ≤ n ) we define the estimatedcosts Cost = { c , ..., c n } for the realization of that feature.According to Fig. 1, we see the stakeholder outside of theSoS boundary. Within the SoS, the system owner O1 directsthe composition of the individual CSs. From the perspective ofthis system owner, the importance of the individual stakeholdermight vary. Consequently, as proposed in [12], the relativeweight for each stakeholder s j = (1 ≤ j ≤ m ) is denoted by: W eight = { w , ..., w m } with w j ∈ [ 0 , and (cid:80) mj =1 w j = 1 .In addition, for each stakeholder s j (1 ≤ j ≤ m ) , we assigna value to a feature f i (1 ≤ i ≤ n ) indicated with value ( f i , s j ) where value ( f i , s j ) > if the stakeholder j is interested infeature i and otherwise.The resulting importance of a feature is calculated with: score i = m (cid:88) j =1 w j · value ( f i , s j ) Based on this, we can define the two objective functionsfor the metaheuristic search. First, we want to maximize theoverall value:
M aximize f ( (cid:126)x ) = n (cid:88) i =1 score i · x i and second, we want to minimize the overall costs: M inimize f ( (cid:126)x ) = n (cid:88) i =1 cost i · x i Within the decision vector (cid:126)x = { x , ..., x n } , x i is if thefeature i is selected for the next release and otherwise. B. Feature Specification
To support the estimation of concrete values for value ( f i , s j ) , we enter the first step in the process outlinedin Fig. 2. In this step, we collect stakeholder information andconvert the expectations into a comprehensive and structuredfeature specification using the Gherkin syntax [13]. One exam-ple is shown in Listing 2. In this way, we can create multiplefeature files, where each feature file contains one or moreusage scenarios that describe the expected system behaviorfrom a user’s point of view. Feature : User-managed charging (UMC): The user of an electricvehicle requests up-to-date information on energy pricesand enters preferences into a smartphone app to calculatean optimized charging plan.2
Scenario : The EVU requests information on energy prices3 When the EVU request information on energy prices via thesmartphone app4 Then the smartphone app requests these information from anenergy information service5 And the energy information service sends this information tothe smartphone app6 And the smartphone app displays the received information7
Scenario : The EVU user enters charging preferences8 When the EVU user enters charging preferences9 Then the smartphone app calculates an optimized chargingplan10 And the smartphone app sends the charging plan to theelectric vehicle11 And the electric vehicle executes this charging plan
Listing 2. Feature specification with the help of usage scenarios. n the SoS example shown in Fig. 1, this step is done by thesystem owner O1, who directs the operation of the integratedSoS functionality. On this level of abstraction, the individualCSs are seen as black boxes and the usage scenarios are usedto document how the CSs must interact to realize the expectedSoS functionality.By using this kind of feature specification, we can createseparate files for each feature f i (1 ≤ i ≤ n ) to provide aninitial overview of the desired system functionality. C. Definition of Systems and their Interaction
Based on the initial set of features, we create scenariospecifications that include definitions of all CSs and how theseCSs interact (see. example in Listing 1). By executing andtesting these scenario specifications we successive refine both,the initial feature specifications and the scenario specifications.As outlined in Fig. 3, this is done by utilizing usage scenariosto link features and technical requirements. To bridge the gapfrom the feature specification to the technical requirements, wegenerate test steps from the usage scenarios and apply the test-driven scenario specification approach (TDSS) as introducedin previous work [8], [9].As outlined in Fig. 4, we do this on two levels of abstractionwithin a SoS context. In a first step we define the interaction
App EV EISEVU When ... Then ...
Fig. 4. Identified systems with different levels of detail. between CSs, where these systems are seen as black boxes.The focus is to identify the required systems and modeltheir interaction. Subsequently we create separate scenariospecifications to model the internal behavior of selected CSs(see. [11]).As an example, to realize the feature specified in Listing 2,we can define three systems (smartphone app, electric vehicle,and an energy information service), where an electric vehicleuser is interacting with a smartphone app. Now we can assumethat the smartphone app and the energy information serviceare existing systems that should be integrated with an electricvehicle under development. In this case, it is also necessaryto identify the components of the electric vehicle that areinvolved in the desired SoS functionality, which can be donein a separate scenario specification that details the internalbehavior of a CS [11].IV. P
ROOF OF C ONCEPT
To exemplary apply our approach, we integrated SMLK [15]with the Cucumber tooling [14] and the MOEA framework[16]. Subsequently we executed the steps shown in Fig. 2 and thereby created the artifact shown in Fig. 5 with the numbers1-4 indicating the associated process step.
ScenarioSpecificationFeaturesFeaturesFeatureSpecificationsScenarioSpecificationsTest Steps ReleaseCandidates cost i value(s i , f i )generatecreate manuallydriven by tests refine derive from stakeholderexpectations automated search
12 2 33 4 estimateestimate
Fig. 5. Resulting artifacts when executing the process steps
We started with the creation of feature files containing usagescenarios as already shown in Listing 2. After we created afirst set of features, we generated the test steps. Based on theexample feature in Listing 2, we generated the test steps inListing 3 and iterated the TDSS sub-process (step 2 in Fig. 2).In each iteration we a) added SMLK events to the generatedtest steps, b) executed the tests, and c) refined the scenariospecification until all tests passed.
Listing 3. Generated test step from the usage scenario in Listing 2.
After several iterations within step 2, the test results couldbe used to refine the initial feature specifications. Then weused these feature specifications to manually derive the valuevector. To do this, we defined hypothetical values based onthe amount of usage scenarios for a specific feature andthe respective stakeholder. In the same way, we derived acost vector depending on the complexity of the scenariospecification with its CSs and their subsystems, representingthe technical requirements of a specific SoS. search results with possible release candidates iteration 1iteration 2iteration 30 200 400 600 800 1,000-80-60-40-200 value c o s t s Fig. 6. Search results after three iterations with 10 stakeholder and 40 features.
With this input we exemplary executed the automated searchfor 10 stakeholder and 40 different features. In Fig. 6 weee the search results with the input data of three iterations.For every iteration we got a pareto optimal front, where eachpoint indicates one possible release candidate. Each releasecandidate includes a vector containing all features, with 1 ifthe feature should be selected for the release and 0 otherwise.V. S
UMMARY AND O UTLOOK
In this work, we combine a structured feature specificationwith a scenario-based modeling technique to assist the releaseengineer in identifying costs and values for the specifiedfeatures in an early planning phase of an SoS. The cost andvalue are forming the link into the decision-making processesof the stakeholders in a Smart City since they can be linkedto the inputs and the impact of the respective project.Feature specifications in natural language are used to sup-port the identification of values that these features can create.Using natural language supports the involvement of the stake-holders into the decision-making. The formal and scenario-based modeling of technical requirements is used to supportthe estimation of costs, depending on the effort it can taketo realize the requirements via different CSs. We connectboth artifacts (feature specification, scenario specification)with a test-driven specification approach based on stakeholderexpectations formulated as usage scenarios.With this approach we address SoS characteristics likeevolving development of individual CSs, where requirementscan change constantly but nevertheless can be part of a higherlevel SoS functionality. The used modeling techniques andmethods [8]–[11] support the iterative analysis and refinementof the changed requirements. The iterative specification pro-cess combined with the automated search for release candi-dates based on the MONRP is a promising approach to supportthe release engineer in complex trade-off decisions.Future work should consider how to extend the modelingcapabilities to estimate more realistic input data for the search.The objective functions should also be adapted to allow thesearch for features in a realistic release situation. Since thisfirst approach is based on the problem statement in [12], itis assumed that all features are independent from each other,which is an unrealistic assumption. One possible improvementwould be to combine the feature specifications with goalmodels, as done by Aydemir et al. [27], and in this wayalso consider dependencies between features and requirementswhen searching for optimal release candidates.R
EFERENCES[1] R. Zabel and Y. Kwon, “Evolution of urban development and regener-ation funding programs in German cities,”
Cities , no. xxxx, p. 103008,2020.[2] J. Lane and D. Epstein, “What is a System of Systems and Why ShouldI Care.” 2013.[3] M. W. Maier, “Architecting Principles for Systems-of-Systems,”
IN-COSE International Symposium , vol. 6, no. 1, pp. 565–573, 1996.[4] B. Kirpes, P. Danner, R. Basmadjian, H. de Meer, and C. Becker, “E-Mobility Systems Architecture: a model-based framework for managingcomplexity and interoperability,”
Energy Informatics , vol. 2, no. 1, 2019.[5] J. S. Dahmann and K. J. Baldwin, “Understanding the Current Stateof US Defense Systems of Systems and the Implications for SystemsEngineering,” in , pp. 1–7,2008. [6] C. Ncube, “On the engineering of systems of systems: Key challengesfor the requirements engineering community,” in , pp. 70–73, IEEE, 2011.[7] C. Ncube and S. L. Lim, “On systems of systems engineering: Arequirements engineering perspective and research agenda,”
Proceedings- 2018 IEEE 26th International Requirements Engineering Conference,RE 2018 , pp. 112–123, 2018.[8] C. Wiecher, J. Greenyer, and J. Korte, “Test-Driven Scenario Spec-ification of Automotive Software Components,” in , (Munich, Germany), pp. 12–17,2019.[9] C. Wiecher, S. Japs, L. Kaiser, J. Greenyer, R. Dumitrescu, and C. Wolff,“Scenarios in the Loop : Integrated Requirements Analysis and Auto-motive System Validation,” in
ACM/IEEE 23rd International Conferenceon Model Driven Engineering Languages and Systems (MODELS ’20Companion) , 2020.[10] C. Wiecher, “A Feature-oriented Approach: From Usage Scenarios toAutomated System of Systems Validation in the Automotive Domain,” in
ACM/IEEE 23rd International Conference on Model Driven EngineeringLanguages and Systems (MODELS ’20 Companion) , (Virtual Event,Canada), 2020.[11] C. Wiecher, J. Greenyer, C. Wolff, H. Anacker, and R. Dumitrescu,“Iterative and Scenario-based Requirements Specification in a Systemof Systems Context,” in preprint - arXiv:2102.05400 , pp. 1–16, 2021.[12] Y. Zhang, M. Harman, and S. A. Mansouri, “The multi-objectivenext release problem,” in
Proceedings of GECCO 2007: Genetic andEvolutionary Computation Conference , pp. 1129–1137, 2007.[13] SmartBearSoftware, “Gherkin Syntax - Cucumber Documentation:https://cucumber.io/docs/gherkin/.”[14] SmartBearSoftware, “BDD Testing & Collaboration Tools for Teams |Cucumber: https://cucumber.io/,” 2020.[15] J. Greenyer, “Scenario Modeling Language for Kotlin:https://bitbucket.org/jgreenyer/smlk.”[16] D. Hadka, “MOEA Framework, a Java library for multiobjective evolu-tionary algorithms.”[17] S. Ala-Mantila, J. Heinonen, S. Junnila, and P. Saarsalmi, “Spatial natureof urban well-being,”
Regional Studies , vol. 52, no. 7, pp. 959–973,2018.[18] Rodney, Turner, and R. Zolin, “Forecasting Success on Large Projects:Developing Reliable Scales to Predict Multiple Perspectives by Mul-tiple Stakeholders Over Multiple Time Frames,”
Project ManagementJournal , 2012.[19] C. Nielsen, P. Larsen, J. Fitzgerald, J. Woodcock, and J. Peleska,“Systems of Systems Engineering,”
ACM Computing Surveys , vol. 48,pp. 1–41, 2015.[20] E. Honour, “Verification and Validation Issues in Systems of Systems,”in
Electronic Proceedings in Theoretical Computer Science , pp. 2–7,2013.[21] X. Franch and G. Ruhe, “Software Release Planning,” in
Proceedingsof the 38th International Conference on Software Engineering Compan-ion , ICSE ’16, (New York, NY, USA), pp. 894–895, Association forComputing Machinery, 2016.[22] Kun Chen, Wei Zhang, Haiyan Zhao, and Hong Mei, “An approach toconstructing feature models based on requirements clustering,” in ,pp. 31–40, 2005.[23] C. Papadimitriou and K. Steiglitz,
Combinatorial Optimization: Algo-rithms and Complexity , vol. 32. 1982.[24] D. Harel, A. Marron, and G. Weiss, “Behavioral programming,”
Comm.ACM , vol. 55, no. 7, pp. 90–100, 2012.[25] W. Damm and D. Harel, “{LSCs}: Breathing Life into Message Se-quence Charts,” in
Formal Methods in System Design , vol. 19, pp. 45–80, 2001.[26] J. Greenyer, D. Gritzner, T. Gutjahr, F. König, N. Glade, A. Marron, andG. Katz, “ScenarioTools – A tool suite for the scenario-based modelingand analysis of reactive systems,”