Reconstructing the past: the case of the Spadina Expressway

In order to build resilient systems that can be operational for a long time, it is important that analysts are able to model the evolution of the requirements of that system. The Evolving Intentions framework models how stakeholders’ goals change over time. In this work, our aim is to validate applicability and effectiveness of this technique on a substantial case. In the absence of ground truth about future evolutions, we used historical data and rational reconstruction to understand how a project evolved in the past. Seeking a well-documented project with varying stakeholder intentions over a substantial period of time, we selected requirements of the Toronto Spadina Expressway. In this paper, we report on the experience and the results of modeling this project over different time periods, which enabled us to assess the modeling and reasoning capabilities of the approach, its support for asking and answering ‘what if’ questions, and the maturity of the underlying tool support. We also demonstrate a novel process for creating time-based models through the construction and merging of scenarios.


Introduction
Goal-oriented requirements engineering (GORE) focuses on modeling and reasoning about early-phase project requirements through the lens of system goals and stakeholder intentions. A number of approaches have been developed, for example, NFR [8], i* [45], GRL [2], Tropos [16], and KAOS [42]. While these approaches vary in their notation and semantics, they all connect high-level stakeholders' goals to trade-offs in the system and consider the problem space and environment that the system will interact with.
In order to build resilient systems that can be operational for a long time, it is important that analysts model the evolution of the requirements of that system [31]. Recently, a number of solutions for modeling how stakeholders' goals change over time have been proposed [5,19]. Aprajita and Mussbacher provided a quantitative framework (called TimedGRL) that enables stakeholders to consider possible evolutions and trends through visualizations [5]. In the associated thesis, Aprajita provides a detailed example of how TimedGRL can be applied to review the performance of a project [3]. In subsequent work, Aprajita et al. added support for feature models [4] and provided full tool support [30]. Our prior work proposed a qualitative framework (called Evolving Intentions) that focuses on answering 'what if' questions about possible evolutions and futures [17][18][19]. We demonstrated effectiveness of the approach on a large example [19] and established that graduate students can use evolving intentions and simulation through a controlled experiment [20]. To the best of our knowledge, Evolving Intentions currently remains the only framework that enables modelers to generate and explore future evolutions of stakeholders' intentions, and so we choose it as the focus of our investigation.
In this paper, we aim to examine the applicability and effectiveness of the Evolving Intentions approach. Specifically, we study whether it can be used to simulate future evolutions of models where actor compositions and their intentions change.

Case scenario
Our intention was to find a well-documented example where sufficient evolution took place. In the absence of software 1 3 engineering examples satisfying these criteria, we used historical data and rational reconstruction to examine how a controversial infrastructure project evolved in the past. The Spadina Expressway was a city planning and infrastructure development project in Toronto, Canada, that spanned five decades. See Fig. 1 for further exposition of the project scenario, as well as Figs. 2 and 3 for visualizations of the route map. This project has been well studied and is a fitting example to evaluate Evolving Intentions because the project has a strong temporal component with many changes, including the introduction and withdrawal of stakeholders.

Investigation criteria
Within the domain of the Spadina Expressway case, we used the following investigation criteria to explore the historical documents in order to elicit evidence that forms our universe of discourse: ( IC 1 ) supporters and opponents of the project, ( IC 2 ) proposed highway configurations, ( IC 3 ) proposed timelines for construction, and ( IC 4 ) potential funders of the project. While not complete, we selected these for the availability of data based on a survey of the historical documentation (see Sect. 3 for further information).

Model creation with varying actors
Historical documents show significant changes in the actors over the course of this case with multiple actors existing over only part of the study. The Evolving Intentions framework assumes that all actors are present for the entire period of the project being modeled [19]. We need a process for representing which actors are active at each time point. TimedGRL is able to represent the presence and absence of actors through Deactivation Changes [5]; but there is no literature on handling variance among actors for the creation of goal models. Given the changes in actors present over time, it was unclear how to build a single model containing all actors from scratch. Inspired by feature models in software product lines [25], we envisioned building individual scenario models and then merging the models to include the full timeline and all actors. Thus, we propose a process to generate a time-based goal model with varying actors by creating scenario models and merging them into one model for the entire case. Once we create the full goal model, we consider possible evolutions using the Evolving Intentions framework and ask 'what if' questions, such as: 'What if the downtown section was built first?' and 'What if the Yorkdale project was not developed?' The Spadina Expressway was designed to connect Toronto's Downtown core with the Macdonald-Cartier Freeway (Highway 401), the closest intercity controlled access highway. The Spadina Expressway would also give downtown residents and Highway 401 users access to the Yorkdale Shopping Plaza (see Fig. 1 and Fig. 3 for project illustrations). It was part of a larger highway network first conceived in Toronto in the 1940s. The project was never fully completed and was finally closed to future development in the 1980s. Fig. 1 illustrates the order and location of each of the road segments.
Many have written about the project's controversy and how this project led to a change in the structure of city planning. The expressway is an interesting case because it demonstrates the conflict between local interests and regional needs. It was instigated by politicians and planners in the downtown core of the City of Toronto as a method of growth and connection with the surrounding region. Proponents, who instigated the project, first lobbied the provincial government to force the suburbs to support infrastructure development through municipal restructuring. With growth in both the suburbs and downtown, the project gained traction in the suburbs, while downtown residents associations became more opposed to the project given the perceived destruction on local neighbourhoods. These opponents lobbied the province to stop the project and prevent the municipality from completing it.  In describing the rationale reconstruction, we present our novel process for building time-based models based on merging scenarios that focus on groups of actors.
The remainder of this paper is organized as follows. Section 2 introduces the Evolving Intentions framework and relevant goal modeling background. Section 3 gives an overview of the methodology for the rational reconstruction. Section 4 models each scenario and explores simulations over each scenario model. Section 5 defines the algorithm for merging evolving goal models and evaluates the full case model. Section 6 discusses study challenges and answers our overarching research question. Section 7 discusses related work. We conclude in Sect. 8.

Background
Here we introduce relevant background using the model in Fig. 4. We illustrate the goal model attributes used in the figures in this paper in Fig. 5.

Goal modeling
In the Tropos methodology, a goal model consists of actors and intentions as well as relationships (i.e., links) between intentions [16]. Figure 4 shows two actors, Metro and the Spadina Project, with their intentions (i.e., goals, tasks,  resources, and soft goals) within the dotted actor boundary. The Spadina Project has the goal to Have Spadina Expressway. This goal is and-decomposed into the intentions Plan Project, Get Funding, and Build Spadina Expressway, meaning that all three are required for the satisfaction of Have Spadina Expressway. Build Spadina Expressway is further decomposed into two options, Connected Expressways and Terminal Expressway using the or-decomposed relationship. In this model, Metro has a single task Approve Project Funding, which is connected to Get Funding From Metro with a ++ contribution link. Finally, there is a ++S contribution link between Get Funding From Metro and Get Funding.
In this paper, we use the evaluation and propagation rules defined by Giorgini and collaborators [15,39]. Each intention can be evaluated using an evidence pair (s, d), where s is the level of evidence for and d is the level of evidence against the fulfillment of the intention. Intentions can have one of five values: (Fully) Satisfied (F, ⊥) , Partially Satisfied (P, ⊥) , Partially Denied (⊥, P) , (Fully) Denied (⊥, F) , and None (⊥, ⊥) , where ⊥ indicates no evidence, P -partial evidence and F -complete evidence (see Fig. 5 for the name and visual representation of each evidence pair). As a result of propagation, intentions can have one of four conflicting evidence pairs: (F, F) , (F, P) , (P, F) , and (P, P) . For example, Plan Project is assigned (F, ⊥) in Fig. 4, meaning full evidence for and no evidence against, as the project plan has already been completed. Approve Project Funding is assigned a (⊥, F) meaning no evidence for and full evidence against because Metro has not approved the funding. As introduced above and shown in Fig. 4, there is a ++ link from Approve Project Funding to Get Funding From Metro meaning that if Approve Project Funding is satisfied, then Get Funding From Metro will be satisfied. In fact, the ++ link propagates both evidence for and evidence against the fulfillment of the intention. The ++S link from Get Funding From Metro to Get Funding means that if Get Funding From Metro is fully [resp. partially] satisfied, then there exists full [resp. partial] evidence that Get Funding is also satisfied.

Evolving Intentions
We specify how the evaluation (i.e., an evidence pair) of an intention changes over time with evolving functions [19]. Between two time points (i.e., within an interval), the evaluation of an intention, if known, can become more fulfilled, or Increase; become less fulfilled, or Decrease; remain constant; or change randomly, displaying a stochastIc pattern. Each evolving function is a sequence of these atomic functions over disjoint neighboring intervals, with interval boundaries denoted by symbolic constants. When functions are defined over multiple intervals, they are called User-Defined ( UD ) functions. For example, Plan Project remains Satisfied ( (F, ⊥) ), so we assign a single constant function over the entire period of analysis, identified by the C label on Plan Project in Fig. 4.
We identify functions that occur commonly over two time intervals (see [19] for a full list). For example, Denied-Satisfied ( DS ) specifies that the evidence pair assignment of an intention remains Denied (⊥, F) over one interval and then remains Satisfied (F, ⊥) over a second interval. Approve Project Funding follows this pattern and is assigned a DS label in Fig. 4. See Fig. 5 for the remaining evolving functions used in this paper.

Evolving goal model and simulation
In general, an evolving goal model is a tuple M = ⟨A, G, R, EF, MC, maxTime⟩ , where A is a set of actors, G is a set of intentions, R is a set of relationships over intentions, EF is a set of evolving functions, MC is a set of constraints over time points in the model, and maxTime is the maximum absolute time over which any function or constraint is defined by the user.
M A (see Fig. 4) is an example of an evolving goal model, prior to analysis. The complete specification of M A is given in Fig. 6. In this case, maxTime is assigned the value eight, meaning that all simulations will have at most eight time points. The EF set contains evolving functions for Plan Project and Approve Project Funding. Notice that since Approve Project Funding is defined over two intervals, we add a symbolic constant t apf to specify this transition between intervals. We can declare that this transition will occur at time point five by adding the model constraint t apf = 5 to the set MC. When referring to elements of models used in this paper, such as M A , we refer to its components . In this paper, we prevent strong conflicts, so that no intention has the evidence pair (F, F) meaning that it is both Fully Satisfied and Fully Denied.

Simulation output:
The computed simulation consists of two parts: a sequence of time points and the evaluation of the goal model at each time point.
In order to generate simulation paths, we create a constraint satisfaction problem (CSP) using the inputs described above, and a CSP solver gives a simulation path that satisfies a given set of constraints if a path exists.

Methodology
We conducted a rational reconstruction of third degree data [12,28], i.e., using archival data, on a real-world descriptive case where the unit of analysis is the Spadina Expressway project itself. This rational reconstruction is unique among the requirements and modeling literature because we used multiple books written for other purposes [9,34,36,40,43], rather than a single requirements description. After an initial review of the historical documents, we decided on the actors and scenes discussed in Sect. 3.1. To create each model, we followed the process specified in [18]. To elicit model elements, we used keyword searches on variations of 'Spadina Expressway' (including 'Allen Road', its current name). For each positive result, we reviewed the entire section of the reference as well as the end of the previous section and the beginning of the following section, checking for relevance. For each section deemed relevant, we reviewed the section, tagged the elements, and assigned intentions and evolving functions to actors, creating the scene models. Each intention and evolving function maps to one of the historical documents. The full documentation of this traceability as well as the full models are available online. 1 In order to answer questions about the entire project , we chose to model groups of actors over three purposely chosen critical time periods in the project and then merge them to create a single model for the entire history. This allowed us to answer questions about individual actors' behavior over shorter periods of time and see how the answers to these questions differ between models. We used the work of Runeson et al. [37], and Yin [44] as guidelines for conducting and reporting this study.

Overview of Scenes and models
The key stakeholders of the Spadina Expressway project were the Province of Ontario (Province), local governing bodies (i.e., City of Toronto (Toronto), County of York, York, and Municipality of Metropolitan Toronto (Metro)) and their planning boards, the Yorkdale Plaza project (Yorkdale Project), and local citizens and rate payers associations, collectively called the Opposition. We modeled three scenes to capture different groups of stakeholders over explicit time periods: Scene I (1947)(1948)(1949)(1950)(1951)(1952)(1953) looks at when the Toronto and York Planning Board initially envisioned the Spadina Expressway as part of a network of highways. Scene II (1960)(1961)(1962)(1963)(1964) looks at the project when it was being approved by the Municipality of Metropolitan Toronto (Metro), and the interactions with the Yorkdale Project and the Province. Scene III (1970)(1971)(1972)(1973)(1974)(1975)(1976)(1977)(1978)(1979)(1980)(1981)(1982)(1983)(1984)(1985) looks at the project when sufficient grassroots organizing had developed in an attempt to stop the project by the Opponents, prior to the project's cancelation.
The three scene models were then merged to create the initial version of the Full Model , using the algorithm described in Sect. 5.1. Figure 7 illustrates the mapping between the timelines of each scene and the full case. In this paper, we only present the most up-to-date fragments of each model. We describe the context and scope of each scene using the investigation criteria IC 1 -IC 4 introduced in Sect. 1. We then show how the scene is modeled and how changes within the scene are captured using the Evolving Intentions framework, which provides evidence for RQ 1 .

Simulation
We generate a simulation of historical events (to generate evidence for RQ 2 ) using the methodology and simulation inputs, as described in Sect. 2. For the purpose of reconstructing the historical timeline, the passage of time is observed in 6 month increments, with time points of January 1 and July 1 of each year. The timeline is then mapped to simulation times from t 0 = 0 to the maxTime , as illustrated in Fig. 7.

Alternative
Finally, we consider one alternative future (to collect evidence for RQ 3 ) for each scene. Table 1 lists questions that we posed in order to generate alternative futures. We generated simulations of alternative events by altering some of the simulation inputs used for reproducing the historic events. Specifically, we altered the evolving functions and model constraints associated with the intentions involved in the trade-off decisions under question, by using our best judgment and domain expertise.

Model scope and assumptions
In modeling, we used an open-world assumption, meaning that the model is incomplete and can be added to; but, for the purpose of analysis, the model is considered to be closed. We chose the level of abstraction for this study to be the high-level objectives and plans that would be presented by city planners. We scoped each model to include what was minimally needed for answering our research questions. For example, we modeled the Network Project's goal to Have a Unified Arterial Road System, but we did not model whether cars were inherently good or the environmental impacts of building a road system. We also abstracted away the details of the other road projects in the network to focus on the Spadina project. We limited our universe to actors mentioned in the historical documents and did not consider any events prior to 1947 and after 1985.
In building these models, we made several assumptions resulting in specific modeling decisions. We did not model the explicit costs of the project, but did explicitly consider which stakeholders would agree to pay for the highways. As shown in Fig. 4, we modeled Approve Project Funding to represent Metro's commitment to funding the Spadina Expressway project.

BloomingLeaf
This study was completed using BloomingLeaf, 2 a webbased tool we built to implement the Evolving Intentions framework [21]. In addition to the canvas for modeling, we use the Simulate Single Path feature in BloomingLeaf to answer RQ 2 and RQ 3 , which uses the JaCoP solver [27] to find a simulation path over the model.

Scene models
In this section, we introduce each scene chronologically and describe the model we created using the historical documents. For each model, we generate simulations of the historical events and alternative futures (probed using the questions in Table 1) in order to provide evidence for our research questions. The screenshots in Figs. 8, 9, and 10 show a generated simulation of the historical events for each scene model at a single time point. These models are also used to describe each scene.

Scene I (1947-1953)
Scene I (see M PLAN in Fig. 8) focuses on the inspiration of the Spadina Project and its connection with other highway infrastructure. The Planning Board investigated creating a network of highways to connect the region with the City of Toronto. We focus on the intentions of the Toronto and York Planning Board (Planning Board). Planning Board was the initial supporter of the project (investigation criteria IC 1 ) and was motivated by their desire to Have a Unified Arterial Road System. The Spadina Project was seen as one component of the Network Project aligning with Toronto's 'Master Plan' to Be a World Class City.
Looking at the network of roads, there were two options: Build Road Network-Single Project, where Planning Board treated the whole road network as a single project; and Build Road Network-Multiple Projects, where Planning Board treated each highway as a single project ( IC 2 ). Toronto and the County of York were the possible funders of this network ( IC 4 ), with the County of York actively opposing to both funding the project and the Planning Board's activities. Toronto agreed to pay for two-thirds of the startup costs (i.e., satisfying Get Startup from Toronto), but the County of York refused to pay the other one-third. Planning Board wanted the entire network to be built, but no concrete timelines for the expressways were determined ( IC 3 ) because Planning Board was unable to persuade the County of York to fund the network.
Planning Board strongly believed that the County of York would not overturn their decision to deny the board funding (i.e., Get Startup from York has a constant function with the value Denied, (⊥, F) , in Fig. 8), so they considered alternative means to acquire the funding. The most likely way to force the County of York to fund the project was to amalgamate the region, enabling a municipality to collect taxes and develop infrastructure across the region. This is represented by the additional goal Amalgamate Toronto and York. This goal was achieved in 1953 with the inauguration of the Municipality of Metropolitan Toronto. M PLAN simulation (evidence for RQ 2 ). Using M PLAN as input, we generated a simulation of the events from July 1947 to July 1953 ( maxTime = 12 ). Figure 8 is a screenshot of this simulation result at t = 12 . The resulting simulation (see Video I Hist online 1 ), with time points (0, 1,3,4,9,12), shows that very few goals are becoming Satisfied, and there is little movement on the Spadina Project or the Network Project. At t = 3 , t = 5 and t = 9 , changes occur in Get Crosstown Design Approved and Get Lakeshore Design Approved, but neither become satisfied. Planning Board believed that the project could not move forward without funding from the County of York and that the County of York would continue to refuse funding indefinitely. Planning Board had the task Lobby for Singular Municipality to remove the responsibility from the County of York. This task becomes Satisfied at t = 12 (see also Fig. 8).
Alternative (evidence for RQ 3 ). The goal Have a Unified Arterial Road System in Network Project (see Fig. 8) can be satisfied by one of two tasks: Build Road Network-Single Project or Build Road Network-Multiple Projects.
In the original simulation, Build Road Network-Multiple Projects was selected (but not Satisfied). We consider this trade-off as an alternative future, asking the question AQ 2 (see Table 1): How can the highway development proceed as a single project (w.r.t. funding and construction)? Starting with the initial simulation, we assigned Build Road Network-Single Project a Stochastic-Constant ( RC ) function (with (F, ⊥) as the constant value). RC specifies that the evidence pair assignment of an intention starts as a stochastic function over one interval and then remains constant, in this case Satisfied, over a second interval. We also removed some absolute time assignments (i.e., constraints in M PLAN .MC ). However, no simulation could be generated as the model was over constrained: Get Network Funding could not be satisfied without the County of York's approval of initial funding. Next, we changed the evolving function for Approve Planning Board Funding Y to be a Denied-Satisfied function transitioning in 1950. In the simulated timeline, this results in the satisfaction of Build Road Network-Single Project, but only if Get Road Funding is approved. Our

Scene II (1960-1964)
In Scene II, we focus on the proponents of the Spadina Project. At this point, the project was under the authority of the Municipality of Metropolitan Toronto (Metro), but was dependent on the Yorkdale Project, York, and the Province of Ontario (Province) ( IC 1 ). Figure 9 shows the M PRO model, a simplified fragment of Scene II. The central goal of the Spadina Project is to Have Spadina Expressway. This goal is decomposed into the tasks Plan Project, Get Funding, and Build Spadina Expressway.
In this period, Metro had considered two different configurations of the Spadina Expressway ( IC 2 ): the Connected Expressway which would connect with the Crosstown and Lakeshore Expressways; and the Terminal Expressway which would transition to a full access road (i.e., Spadina Avenue) at Bloor Street. In Fig. 9, Build Spadina Expressway is decomposed into these two configuration trade-offs. Connected Expressway and Terminal Expressway are then decomposed into the road segments required for each plan. Most segments are required for both, but Build Bloor to Lakeshore and Build Crosstown Interchange are only required for the connected plan (see Fig. 2 for the segment map).
The Yorkdale Project has the goal Have Yorkdale Shopping Plaza, proposing to build a large shopping plaza at the junction between the proposed Spadina Expressway and the Highway 401. Plan for Shopping Plaza is assigned (F, ⊥) because the plan for the shopping plaza has already been released. The Yorkdale Project needs access to Highway 401. To achieve this goal, both Build Wilson-401 to Lawrence to Have access to 401 must be satisfied. The +S link from Have Yorkdale Shopping Plaza to the Economic Development soft goal in the Province actor means that if the Have Yorkdale Shopping Plaza is satisfied, then there exists partial evidence that Economic Development is also satisfied.
Scene II models the approval and initial construction of the project between 1960 and 1964 ( maxTime = 8 , see Fig. 7). Plan for Shopping Plaza remains Satisfied ( (F, ⊥) ), so we assign a single constant function over the entire period of Scene II, identified by the C label on Plan for Shopping Plaza in Fig. 9. York was still opposed to both configurations as planned because it meant disrupting a local community and the Cedarvale Valley, and refused to release the land required for the Spadina Expressway. York's  Fig. 9). At the beginning of the simulation, Plan for Shopping Plaza is satisfied. As the simulation progresses, Metro satisfies Approve Project Funding as well as Approve Construction to Lawrence and Approve Plan in the Spadina Project, at t = 3 (July 1961). The Province then satisfies Approve Funds. These approvals are denoted by the (F, ⊥) label on each intention. Next, Build Mall has the value (⊥, P) at t = 4 (January 1962) and (P, ⊥) at t = 5 (July 1962). Figure 9 shows the results of the simulation at t = 4 (January 1962). In subsequent time points, Build Wilson-401 Lawrence and Build Lawrence to Eglinton are no longer Denied (see Fig. 2 for the project map). At the end of the simulation, t = 8 (January 1964), Have Spadina Expressway is still Denied, and both Build Wilson-401 Lawrence and Build Lawrence to Eglinton are Partially Denied.
Alternative (evidence for RQ 3 ). Looking at the interactions between the Spadina Project and the Yorkdale Project, we considered the inevitability of satisfying Build Wilson-401 to Lawrence, and explored question AQ 9 in Table 1: What if the Yorkdale project was not developed? For this alternative, we configured the model so that the elements of the Yorkdale project would not be fulfilled, by assigning each element a constant function with the value Denied (⊥, F) . We removed the evolving functions for Build Wilson-401 to Lawrence and Build Lawrence to Eglinton, in order to allow the solver to select evidence pairs. We generated multiple simulations and observed that without the Yorkdale Project, building the Wilson-401 to Lawrence segment may still have occurred but was not inevitable. Simulation results varied between completing no construction prior to maxTime to partially completing a segment but not necessarily Build Wilson-401 to Lawrence. This suggests that an alternative ordering for construction (e.g., satisfying Build Bloor-Sussex To Lakeshore first) may have been possible without the influence of the Yorkdale Project, but Metro was still influenced by their goal Honour Interchange Agreement, which ensured continued funding from the Province.

Scene III (1970-1985)
Scene III (see M OPP in Fig. 10) examines the opposition to the project and its ultimate cancelation. The primary goal of the Opposition ( IC 1 ) was to Stop Spadina Expressway. This goal is or-decomposed into their efforts to Lobby Metro, Lobby Province, and Litigate Spadina, where the opposition brought suit with the Ontario Municipal Board (OMB).
By 1970, construction of the first segment (i.e., Wilson-401 to Lawrence, see Fig. 2 for segment map) of the Spadina Expressway was complete, but with budget overruns. There was significant growth in the outer suburbs and infill in the city center where the expressway was to be built, and attitudes about expressway developments and the importance of neighborhoods changed. Metro required approval for additional loans for the expressway from the OMB (see Fig. 10 for the additional decomposition from Get Funds From Metro). Metro and the OMB were still focused on development through infrastructure projects, and both ignored the Opposition. However, the Opposition was successful in persuading the Province, which also controlled funding, that the original plan for the Spadina Expressway should not be built because it no longer served the people.
In Fig. 10, the -S relationship between Block Spadina and Approve Funds, within the actor boundary of the Province, indicates that when Block Spadina is Satisfied, then there exists full evidence that Approve Funds is Denied (as demonstrated in Fig. 10).
Since the Spadina Expressway was not built, we focused our investigation on how stakeholders gave closure to the project. Construction was finished by satisfying Build Lawrence to Eglinton, within the decade ( IC 3 ), and was funded ( IC 4 ) by Metro and the Province.
M OPP Simulation (evidence for RQ 2 ). We created a simulation of the events between January 1970 and July 1985 ( maxTime = 31 ), using M OPP (see Fig. 10 for the result at t = 12 ). The visualization (captured online 1 in Video III Hist) has time points (0, 2, 3, 5, 12, 13, 20, 30). At the beginning of the simulation, construction is underway on the Lawrence to Eglinton segment (see Fig. 2). Metro's task Consult with Citizens is Satisfied, but Listen to Opposition is Denied. All of the Opposition's intentions to persuade other actors remain Denied, until t = 3 when the Province Satisfies Listen to Opposition and Block Spadina, which results in the Denial of Get Funding in the Spadina Project actor. Figure 10 depicts M OPP at t = 12 , but all the changes that occurred at t = 3 are visible as they did not change afterward. At t = 12 Toronto finished their task to Create Central Area Plan, which is adopted by Metro at t = 22 with the satisfaction of their goal Adopt Centres Policy. Eventually ( t = 30 ), the Province satisfies their task Lease Toronto Blocking Land which prevents future development on the Spadina Expressway.
Alternative (evidence for RQ 3 ). In the end, it was determined that the Spadina Expressway should not be built in some part due to the lobbying efforts by the Opposition. Next, we ask the question AQ 6 (see Table 1): What if the Opposition had never successfully organized? We assigned Denied (⊥, F) to all of the lobbying efforts by the Opposition and created a new simulation that resulted in the completion of the Spadina Expressway (i.e., Have Spadina Expressway becoming Satisfied (F, ⊥) ). This led us to consider whether Toronto would have opposed the Spadina Expressway without the lobbying efforts of the opposition to protect local neighborhoods.

Spadina Expressway model (1947-1985)
In this section, we focus on modeling and understanding the entire Spadina Expressway case taken together. We construct the full model, using our merge algorithm, by combining the scene models together and resolving conflicts. We then explore the events of the full timeline and evaluate project trade-offs through simulation.

Merge algorithm
In this section, we describe the merge algorithm and demonstrate it on M PRO and M OPP . In this study, we used this algorithm to merge M PRO and M OPP and repeated the process to merge the result with M PLAN , in order to create M FULL in Fig. 13.
Merge unifies information from two evolving goal models, specified over two absolute time periods. Inputs to merge are two evolving goal models  Fig. 7).
The steps are as follows: (  merge actors and intentions (i.e., A, G,) based on element names [32]. We require a unique identification of intentions. Conflicts may arise when performing a union of the intentions if two intentions have the same name but are not elements of the same actor. In this case, we prompt the user to resolve the conflict. For example, Fig. 11 shows snippets of the M PRO model from Fig. 9 and the M OPP model from Fig. 10. In this step, any actor and intention that appears in either model will appear in the merged model (see Merge of Fig. 11). No links are yet created. (4) Merge relationships in the model (i.e., R). We automatically add identical relationships and relationships whose goals only exist in one model and prompt the user to resolve the remaining relationships. For example, if two goals are connected with a ++ relationship in one model but are not related in the second, the user must resolve the conflict. For example, when merging the relationships in Fig. 11 evolving functions (i.e., EF). For all intentions that exist in only one model, we prompt the user to either review each function to add further specification, Build Lawrence to Eglinton was not yet specified over the period between 8 and 20, so we had the choice of leaving the function undefined or connecting the two functions. Build Lawrence to Eglinton was defined in both models with a UD function, as illustrated in Fig. 12. Since we had additional information from the historical documents we chose to connect the two UD functions transitioning from (⊥, P) to (P, ⊥) at t = 12.  Table 2 lists the number of actors, intentions, and links in each of the scene models and the merged model. We also list the number of evolving intentions in Table 2, column Functions. Since M PLAN , M PRO , and M OPP are fragments of the original scene models, M FULL has more elements than the sum of the scene fragments. For example, the Opposition actor in M FULL contains additional intentions (e.g., Anti-Automobilism), but we chose to exclude these from M OPP for brevity and because they acted similarly to Save Old Neighbourhoods.

Actor presence
As mentioned in Step (5) of the merge algorithm (see Sect. 5.1), the user assigns presence conditions in the merge process, visualized by drawing bubbles (i.e., loops) around regions of the model, and assigns presence conditions to each bubble, which are then assigned to each intention within the bubble. The model in Fig. 13 is annotated with the bubbles and presence conditions that we assigned while creating the full model of the Spadina Expressway project. For example, Toronto has two bubbles: one for prior to amalgamation ([0, 12]) and another for after the creation of Metro ( [13,76]). BloomingLeaf does not have tool support for simulation with presence conditions. Future work will implement this feature.
In summary, the Evolving Intentions framework with path-based analysis is able to fully reproduce the timeline of actual events as documented based on our rational reconstruction (for both the scene models and M FULL ), addressing RQ 2 .
Alternative (answering RQ 3 ). Having reproduced the timeline of historical events, we can explore alternative scenarios across the whole project. Consider AQ 11 (see Table 1): Is it possible to satisfy Have a Unified Arterial Road System by 1980? We start by removing the evolving functions for each of the building tasks (e.g., Build Bloor To Lakeshore) and allow the analysis to choose values for these tasks. Other changes are documented online 1 . With these new inputs, we created a simulation result where the expressways were built by 1980. The simulation did not assume that the Spadina Expressway would be build from North to South, and instead selected segments at random. When all segments of the Spadina Expressway were build prior to 1971, then Have Spadina Expressway and Have a Unified Arterial Road System were temporarily Satisfied (at least until Province removed funding).
In summary, using the Evolving Intentions framework with path-based analysis, we were able to produce alternative futures, successfully answering RQ 3 . Furthermore, by generating alternative scenarios, we discovered and corrected incompletenesses in the original model improving the overall quality of the model.

Results and discussion
In this section, we answer RQ 1 and describe how we validated the models with experts. We also discuss observations made during the study and their implications on future research. We finish by discussing threats to validity and answering our overall research question.

Challenges gathering data
Not all the required information was available in the historical documents. For example, it was challenging to decide the evolving intention for the task Get Crosstown Designed Approved because the historical documents stated that the Crosstown was removed in 1955 and 1961, and it was unclear when in the interim the Crosstown was added back into the design, or whether this was a distinction between upper tier and lower tier municipal plans. We experimented with two different functions and determined that they did not impact the model overall, so this ambiguity was accepted. It was sometimes difficult to determine the evolving functions of some of the intentions from the historical documents, because they were written for a different purpose. The original source material used by the authors of the books we read (e.g., meeting minutes) did not prove helpful because they lacked contextualization. We believe that this is not a weakness of the Evolving Intentions approach but rather the fact that we did rational reconstruction. For example, we had hoped to capture the intended timelines for the construction at specific time points; however, the historical documents only contained this information in generalities, so we used estimates to generate alternative timelines.

Modeling challenges
As mentioned in Sect. 5.3, we had difficulty modeling 'continuous' funding behavior. For example, in creating alternative futures, we defined a scenario where both Metro and Province funded and built the Spadina expressway resulting in the satisfaction of Have Spadina Expressway. After Build Spadina Expressway was satisfied, Province would no longer need to fund the expressway, and funding levels could become Denied; but this would result in the denial of Have Spadina Expressway due to the nature of the AND-Decomposition. Goal models were not originally intended to model behavioral aspects; instead, we modeled funding projects as tasks that are completed, as opposed to continuous levels as in stock and flow diagrams [41].
The framework does not allow for changes in the names of actors and intentions. In the historical documents, York could refer to Township of York, Borough of York, or the City of York, none of which should be confused with the County of York or Regional Municipality of York. Toronto might also refer to Old Toronto, the City of Toronto or a particular sub-committee of the City Council. We were unable to visualize such name changes and thus considered them all as the same entity.
Much of the discourse among proponents and opponents of the project was about convincing others to change their opinion and/or shift their priorities. It was difficult to represent power struggles in the model. For example, we modeled the influence of the Opposition on other actors through lobbying tasks and the effectiveness of lobbying as tasks labeled Listen to Opposition. This limitation comes from the underlying GORE approach [23].

Externalities of analysis
Creating alternative futures allowed us to understand limitations of our initial models. For example, in Scene II, as we were building alternative futures and simulating the results of the Spadina Project without the Yorkdale Project, we did not model the impact of the 401 Interchange Agreement between Metro and the Province. We added additional links to connect Metro's goal to Honour Interchange Agreement to the Spadina Project.
Our models did not capture all possible constraints; and therefore, simulation may produce unrealistic scenarios. For example, one of our simulations resulted in the satisfaction of Have a Unified Arterial Road System in 3 years. This result is unrealistic given our real-world knowledge of how long it takes to build a highway. In this case, the model was missing timing constraints on required time for road construction. As with all automated analysis techniques in GORE, results should be reviewed by stakeholders. To what extent can the changes in the elements in our universe be captured in the framework? We conclude that the Evolving Intentions framework has been successful at capturing all changes required to understand the case and answer questions. The framework can be improved to allow changes in the names of actors and intentions.

Validation with experts
Having constructed the models of the Spadina Expressway project, next we intended to interview experts in order to validate the accuracy of our models and discuss the benefits and obstacles of using the Evolving Intentions framework for modeling municipal planning projects. We aimed to interview the original creators of the historical information we used, in order to understand whether we correctly modeled the project; therefore, we contacted the living authors of the books we cite in this paper. We also contacted the planning department at the City of Toronto, aiming to understand whether this approach can be used in a real-world setting. Out of these requests, three individuals agreed to be interviewed, all of them being book authors, and two of them gave first-hand accounts of the project. Since we did not interview the city staff, we cannot decisively discuss the benefits and obstacles of the framework for city planning; however, we did succeed in validating our models. In the remainder of this section, we present a summary of what we learned in conducting these interviews. Our first goal was to improve the accuracy of our models. The historical documents we reviewed contained ambiguities, and domain experts helped us affirm (or refine) our selection of evolving functions for intentions of concern. In this paper, we show the most recent, corrected models. In our original models, we had grouped all citizen groups who opposed the project under the name Stop Spadina Save Our City Coordinating Committee (SSSOCCC). While this was not technically incorrect, one expert argued that it would have been more appropriate to call this grouping Opponents (see Fig. 10). Furthermore, in the models in this paper, we made the relationship between the Opponents and the Ontario Municipal Board (OMB) explicit. The Opponents opposed Metro in hearings held by the OMB. One expert argued that it would be better described as the task to Litigate Spadina rather than as a lobbying effort (see Fig. 10). We further differentiated the contributions of York and County of York which we had originally merged in M FULL . Our original modeling of Toronto's opposition to the Spadina Expressway project was too strong. The experts helped us understand how Toronto's opposition was more subtle, and how we could show the internal conflict within Toronto to both support local neighborhoods and support Metro as a whole. Finally, the experts pointed out a few typos and errors in the model.
Since the book authors are academics and historians and not experts on current city planning practices, we include their views on whether the Evolving Intentions framework can be used for city planning for completeness, but do not believe we can make any claims based on these interviews. The first expert commented that these models could be used with stakeholders to review developer's characterizations of their concerns, stating that the key to understanding these projects is the goals of the stakeholders. He thought that these models could help people examine their own goals and the goals of others, and help stakeholders explore ways to achieve a common objective while avoiding concerns held by individuals. He recommended adding the ability to hide tasks to allow users to focus on goals. Our second expert expressed doubt about whether politicians and the general public would take the time to review the models. Our third expert argued that the key to the effectiveness of our models is their complexity, citing criticism of the overly simplistic models used in the Spadina Expressway project in the 1950s and 1960s. He felt that such models could be used with engaged people and project stakeholders with sufficient time and some guidance. He thought the models could be used to show people the outcome or recommendation of a decision, but not the 'nuts and bolts' of how outcomes were determined.
In summary, our interviews with experts validated and improved the quality of our models. We have no validation whether the Evolving Intentions framework can be used for city planning, but experts thought that experienced stakeholders would find the analysis interesting and useful. Based on this anecdotal evidence, future work will focus on whether the framework can be used by city planners for making project recommendations.

Merge
In the absence of tool support for auto-merge, we performed the merge manually (see Sect. 5.1) by adding the scenarios to a single canvas in BloomingLeaf and then matching and merging information about each element using our expert knowledge of the semantics of the model. In some cases, the model was simplified by redrawing individual elements rather than merging multiple ones.
In merging the Scene models, we encountered the tradeoff in how to model Toronto's intentions before and after the creation of Metro. We first tried modeling Toronto as two different actors and then merged their intentions into one actor afterward. At the time of submission, BloomingLeaf did not distinguish between active and inactive versions of actors and was unable to visualize nonexIstent intentions. Our workaround was to create space in the middle of Toronto to make this distinction. Future research is required to validate the merge algorithm and implement tool support for auto-merge.

Model creation process
As introduced in Sect. 1, we chose to create scene models to focus on individual actors and specific time points. To create each model, we followed the process outlined in [18]. Conducting this study was a significant undertaking. However, the majority of time (6-8 weeks) was devoted to researching and reviewing the historical documents. Each model was built over a few hours, but a lot of this time was spent cross-checking elements. Without tool support, creating the merged model required 4-5 h. We believe this can be reduced by automating the matching parts of steps 2, 3, 4, and 6 of the merge algorithm (see Sect. 5.1) and providing additional automation. In a real-world example, stakeholders would be familiar with the project and would not require additional research time, nor would they need to be present for the merge process. In our interviews (see Sect. 6.2), experts were able to identify errors in our models quickly by 'walking through' the models with us. We anticipate that this process can be taught by means of existing requirements workshops, using processes such as RESCUE [24].
In this paper, we demonstrated our process for creating evolving models based on merging scenes that focus on groups of actors, with the goal of answering time-based questions. Table 1 lists each question and whether it can be answered using each model. While some questions could not be fully answered by the scene models (e.g., AQ 5 ), it was more convenient to use the scene models to answer questions about a specific model part or time period (e.g., AQ 9 ). Although we found the process of creating scene models useful, this paper does not compare the effectiveness of using our merge process to the reverse, where modelers would generate a single large model initially and use slicing to create scene models. Future research could compare these two approaches to investigate which stakeholders find more valuable.
Another advantage of our merge process is that it mitigated some of the issues with visual scalability. By reviewing each scene model, alone and with experts, we were better equipped to navigate the full model which was much larger in size. Using the zoom features in BloomingLeaf, we could focus on the current actor under discussion. The visual scalability of models in BloomingLeaf can be improved further by hiding or minimizing actors and parts of task decompositions. Further validation is required to understand the impact of each of these methods on visual scalability.

Tool maturity
BloomingLeaf [21] was sufficient to model the stakeholders and intentions in the example, within the limitations in the underlying language as discussed above. Using the analysis techniques provided in BloomingLeaf, we were able to complete our intended analysis to answer our research questions, but found that the tool was not mature enough for widespread adoption.
We make the following recommendations to improve BloomingLeaf: In the model specification (see Sect. 2), maxTime and the set MC are part of the model specification, but in BloomingLeaf, they appear in the Analysis view. Conversely, the initial values are inputs to analysis, but they appear in the Modeling view. It is also unclear which elements are saved as part of the model, using the save / load feature. We recommend adding Dynamic Contexts and Evaluation Strategies [5] to ease the configuration of analysis. In this paper, we proposed a model merging algorithm and thus recommend adding auto-merge to BloomingLeaf. We also recommend adding support for hybrid SD/SR models from i* and allowing stakeholders to minimize / maximize individual actors or decomposition trees. In addition to our own observations, this was discussed by experts wanting to hide tasks in the Spadina & Network projects to focus on the interactions between the goals (see Sect. 6.2). Finally, we recommend adding additional documentation and clarifying how to connect simulation paths to stakeholder questions.

Threats to validity
We use a case study-specific classification of threats to validity [37]; however, we had to adapt the classification because our primary methodology (i.e., rational reconstruction) did not involve interviewed or observed persons.

Construct validity
We are the creators of the Evolving Intentions framework, so there is no risk of misinterpreting the framework's constructs. There is a risk that we misinterpreted the meaning of constructs in the historical documents. We mitigated this threat by providing traceability between model elements and the historical documents as well as interviewing the authors of our source materials (see Sect. 6.2) and conducting this study over the period of months and returning to the historical documents multiple times.

Internal validity
In this study, we did not aim to make causal claims but instead showcased how the Evolving Intentions framework could be applied to a large real-world example. Since we created the 'what if' questions listed in Table 1, we may have introduced researcher bias into the analysis of RQ 3 . As mentioned above, there is a risk that there may be errors in our interpretation of the historical documents and, by extension, our modeling and simulation results. We believe that the M PLAN model is most at risk because we were unable to verify the trade-offs of the Planning Board with any of the experts we interviewed. These errors would threaten the internal validity of the results of the rationale reconstruction process but not necessarily signal a problem with the framework itself.

External validity
This study gives evidence to the generalizability of the Evolving Intentions framework for analyzing historical case studies. There is still a notable risk that this approach is not generalizable to allow stakeholders to make decisions about projects in the future. As this was outside the scope of the design of this study, further evaluation of the Evolving Intentions framework is required. Furthermore, since the domain under study was outside software engineering, there is a risk that these results may not generalize to software projects.

Reliability
All case studies involving goal modeling have a reliability risk, and our study is no exception. This is due to the open-world nature of goal modeling and the degree to which model generation is dependent on the subtle decisions made by the modeler. Given that individuals interpret data differently, reproductions of this study using the same historical documents will result in different models; however, we believe that the process can be reliably used by other researchers. This study triangulates the results of our prior controlled experiment to validate the Evolving Intentions framework [20].

Answering the overall research question
We modeled the Spadina Expressway project by creating smaller scenes and then produced the full model. We were able to investigate RQ 1 -RQ 3 in each of the three scenes and the full model. By simulating the historical timelines and alternative futures, we demonstrated the analysis of this approach. This allows us to answer the overarching research question affirmatively (see RQ in Sect. 1): this rational reconstruction using the Evolving Intentions framework was successful in capturing the evolution of the Spadina Expressway project.

Related work
This work extends and validates the Evolving Intentions framework [19]. Here, we put this study in the context of related work.
TimedURN supports the addition and removal of actors through DeactivationChanges, where an actor is still part of the model but is grayed out. We aim to provide a similar visualization. TimedURN captures evolution of a goal model using a 150% representation. On the surface, our merged model ( M FULL ) has many similar elements (i.e., bubbles discussed in Sect. 5.2); however, during the merge process, the user updates the evolving functions for each intention, removing traceability to the original scene models. With quantitative data, TimedURN defines changes using Deactivation, Numeric (e.g., Linear and Quadratic), and Enumerative Changes, allowing for a greater precision in changes. The analysis capabilities of TimedURN differ from the approach used in this paper, in that the Evolving Intentions approach can prove reachability or unreachability of a particular future state (e.g., answering AQ 11 in Table 1), whereas TimedURN can only check whether this state happens to be on the generated path.
Other approaches consider changes in requirements after the initial design is complete. For example, Dalpiaz et al. monitors changes in goal evaluations at runtime [10]. Ernst et al. [13] and Nguyen et al. [33] study how to minimize total effort in implementing requirements changes. Hartmann et al. support modeling evolution of each element independently by capturing element change histories [22]. Changes in goal satisfaction are also represented in other approaches through support for temporal goal types (e.g., achieve and maintain goals) based on temporal logic [6,11,14,42]. Agent-based approaches allow stakeholders to consider how the evaluation of intentions may change over time by observing simulations where agents attempt to achieve specific goals [38]. Future work could investigate whether these goal types would improve the expressive power of our models of the Spadina Expressway.

Methods
We built on the methodology of similar studies in RE and followed the guidance provided by [37,44]. Aprajita validated TimedGRL with a small reconstruction of reports from the Auditor General of Ontario [3]. Letier presented reconstructions of the London Ambulance Service and San Francisco Bay Area Rapid Transit systems using SRS documents [29]. Our study is similar to these in that each uses third-degree data to validate their respective frameworks; however, the size of our models and depth of investigation is greater than previous work. As mentioned in Sect. 1, we considered using case reports from software engineering (e.g., [7,26,35]) but without documented future evolutions, we were unable to establish ground truth.

Conclusions and future work
In this paper, we validated the applicability and effectiveness of the Evolving Intentions framework in Tropos. In the absence of ground truth about future evolutions, we used historical data and rational reconstruction to understand how a project evolved in the past. We selected requirements of the Toronto Spadina Expressway because it spanned a substantial period of time, had varying stakeholders, and was well documented. In this paper, we reported on our experience with rational reconstruction and the results of modeling the Spadina Expressway project over three different time periods. We demonstrated a novel process for creating time-based models through the construction and merging of scenarios, which resulted in creating a model representative of the complete timeline. We found the analysis capabilities to be sufficient for generating alternative futures. We conclude that the Evolving Intentions framework has sufficient expressive power to capture the evolution of the Spadina Expressway project.
In future work, we will formally validate our merge algorithm and plan to extend BloomingLeaf by implementing presence conditions and a semi-automated merge algorithm. We hope to support the developers of BloomingLeaf and will recommend that they implement additional syntax checking and the model management features we discussed in this paper. We hope to identify case studies from software engineering, where we could longitudinally witness goals as they change in a software project, to validate both TimedGRL and the Evolving Intentions framework.