Dealing with Known Unknowns: Towards aGame-Theoretic Foundation for Software

Requirement Evolution ?

Le Minh Sang Tran and Fabio Massacci

Universita degli Studi di Trento, I-38100 Trento, Italy{tran, fabio.massacci}@disi.unitn.it

Abstract. Requirement evolution has drawn a lot of attention fromthe community with a major focus on management and consistency ofrequirements. Here, we tackle the fundamental, albeit less explored, al-ternative of modeling the future evolution of requirements.Our approach is based on the explicit representation of controllable evolu-tions vs observable evolutions, which can only be estimated with a certainprobability. Since classical interpretations of probability do not suit wellthe characteristics of software design, we introduce a game-theoretic ap-proach to give an explanation to the semantic behind probabilities. Basedon this approach we also introduce quantitative metrics to support thechoice among evolution-resilient solutions for the system-to-be.To illustrate and show the applicability of our work, we present anddiscuss examples taken from a concrete case study (the security of theSWIM system in Air Traffic Management).Keywords: software engineering, requirement evolution, observable andcontrollable rules, game-theoretic.

1 Introduction

“...There are known unknowns: that is to say, there are thingsthat we now know we don’t know...”

— Donald Rumsfeld, United States Secretary of Defense

In the domain of software, evolution refers to a process of continually updatingsoftware systems in accordance to changes in their working environments suchas business requirements, regulations and standards. While some evolutions areunpredictable, many others can be predicted albeit with some uncertainty (e.g.a new standard does not appear overnight, but is the result of a long process).

The term software evolution has been introduced by Lehman in his work onlaws of software evolution [17, 18], and was widely adopted since 90s. Recentstudies in software evolutions attempt to understand causes, processes, and ef-fects of the phenomenon [2, 14, 16]; or focus on the methods, tools that managethe effects of evolution [19,25,28].

? This work is supported by the European Commission under project EU-FET-IP-SECURECHANGE.

Requirement evolution has also been the subject of significant research [12,15, 24, 26, 31]. However, to our understanding, most of these works focus on theissue of management and consistency of requirements. Here, we tackle a morefundamental question of modeling uncertain evolving requirements in terms ofevolution rules. Our ultimate goal is to support the decision maker in answer-ing such a question “Given these anticipated evolutions, what is a solution toimplement an evolution-resilient system?”.

This motivates our research in modeling and reasoning on a requirementmodel of a system which might evolve sometime in the future. We assume thatstakeholders will know the tentative possible evolutions of the system-to-be,but with some uncertainty. For example, the Federal Aviation Authority (FAA)document of the System Wide Information Management (SWIM) for Air Traf-fic Management (ATM) lists a number of potential alternatives that subject toother high-level decisions (e.g., the existence of an organizational agreement fornation-wide identity management of SWIM users). Such organization-level agree-ments do not happen overnight (and may shipwreck at any time) and stakehold-ers with experience and high-level positions have a clear visibility of the likelyalternatives, the possible but unlikely solutions, and the politically impossiblealternatives.

Our objective is to model the evolution of requirements when it is known tobe possible, but it is unknown whether it would happen: the known unknown.

1.1 The Contributions of This Paper

We set up a game-theoretic foundation for modeling and reasoning on evolution-ary requirement models:

– A way to model requirement evolutions in terms of two kinds of evolutionrules: controllable and observable rules that are applicable to many require-ment engineering models (from problem frames to goal models).

– A game-theoretic based explanation for probabilities of an observable evolu-tion.

– Two quantitative metrics to help the designer in deciding optimal things toimplement for the system-to-be.

This paper is started by a sketch of a case study (§2). To our purpose, weonly focus on requirements of a part of the system-under-study. We distinguishwhich requirements are compulsory, and which are optional at design time. Basedon these, we construct simple evolution scenario to illustrate our approach insubsequent sections, i.e. some compulsory requirements become obsoleted, andsome optional ones turn to be mandatory.

Then, we discuss how to model requirement evolution (§3) using evolutionrules and probabilities of evolution occurrences. We employ the game-theoreticinterpretation to account for the semantic of probabilities.

We also introduce two quantitative metrics to support reasoning on rule-based evolutionary requirement models (§4). The reasoning is firstly performed

Table 1. High level requirements of ISS-ENT and ISS-BP in SWIM Security Services.

ID Requirement Opt.

RE1 Manage keys and identities of system entities (human, software, devices,...)

RE2 Support Single Sign-On (SSO) •RE3 Support a robust Identity and Key Management Infrastructure (IKMI)

that can be scaled up to large number of applications and users.•

RE4 Intrusion detection and response

RB1 Less cross-program dependencies for External Boundary Protection System

RB2 More robust and scalable common security solution •RB3 Simpler operation of External Boundary Protection System •RB4 Support overall security assessment •

The Opt(ional) column determines whether a requirement is compulsory or not at current designtime. Due to evolution, optional requirements may turn to be compulsory, and current compulsoryones may no longer be needed in the future.

on a simple scenario. Then we show a programmatic way to adapt the techniqueto a more complex scenario (e.g., large model, multiple evolutions) (§5).

In addition, we discuss current limits of our work, but not the approach, aswell as our plan to address them (§6). Finally, we review related works (§7) andconclude the paper(§8).

2 Case Study

Throughout this work, to give a clearer understanding of the proposed approachwe draw examples taken from the design architecture of SWIM [7,23] in ATM.

SWIM provides a secure, overarching, net-centric data network, and intro-duces a Service-Oriented Architecture (SOA) paradigm for airspace manage-ment. The United States FAA [7] has proposed a logical architecture of SWIMwhich consists of several function blocks, among which we choose to consider theSecurity Services block. At high level analysis of Security Services, there are fivesecurity areas: i) Enterprise Information Security System (ISS-ENT), ii) Bound-ary Protection ISS (ISS-BP), iii) SWIM Core ISS, iv) National Air Space (NAS)End System ISS, and v) Registry control. To avoid a detailed discussion on thearchitecture of SWIM Secure Services, which are not main topic of this work,while providing enough information for illustrating our work we refine our scopeof interest on two areas: ISS-ENT and ISS-BP.

– ISS-ENT includes security requirements that are provided as part of anunderlying IT/ISS infrastructure used by systems throughout the NAS.

– ISS-BP includes requirements with regard to control connections and in-formation exchanges between internal NAS and external entities. These re-quirements refer to both network layer control. (e.g., VPNs, firewalls) andapplication layer control.

Table 1 lists high level requirements of ISS-ENT and ISS-BP. For conve-nience, each requirement has a corresponding identifier: two characters for the

Table 2. Design elements that support requirements listed in Table 1.

ID Element Description RE1 RE2 RE3 RE4 RB1 RB2 RB3 RB4

A Simple IKMI •B1 OpenLDAP based IKMI • •B2 Active Directory based IKMI • • •B3 Oracle Identity Directory based IKMI • • • •C Ad-hoc SSO •D Network Intrusion Detection System •E Common application gateway for External

Boundary Protection System• •

F Centralized Policy Decision Point (PDP) •G Application-based solution for External

Boundary Protection System•

Each element in this table can support (or fulfill) requirements listed in columns. To prevent uselessredundancy, some elements are exclusive to due to functionality overlapping (e.g., A, B1, B2 andB3 are mutual exclusive each other).

security area (RE - stands for ISS-ENT requirements, RB - stands for ISS-BPones), and a sequence number. There are compulsory requirements (i.e. they areessential at the time the system is designed) and optional ones (i.e. they can beignored at present, but might be critical sometime in the future). Solutions forthese requirements are listed in Table 2. Each solution has an IDentifier, a shortdescription and a checklist of requirements that it can fulfill.

3 Modeling Requirement Evolution

In this section, we describe how we model evolution, which essentially affects toany further analysis. We capture evolutions by classifying them into two groups:controllable and observable. Furthermore, we include in this section the game-theoretic account for probability.

3.1 Evolution on Requirement Model: Controllable and Observable

Stakeholder requirements, mostly in textual format, are their wishes about thesystem-to-be. Analyzing requirements in such format is difficult and inefficient.Designer thus has to model requirements and design decisions by using variousapproaches (e.g., model-based, goal-based) and techniques (e.g., DFD, UML).

Generally, a requirement model is a set of elements and relationships, whichdepend on particular approach. For instance, according to Jackson and Zave [30],model elements are Requirements, Domain assumptions, Specifications; in a goal-based model (e.g., i*), elements are goals, actors and so on.

Here we do not investigate any specific requirement model (e.g., goal-basedmodel, UML models), nor go to details about how many kinds of element andrelationship a model would have. The choice of a one’s favorite model to representthese aspects can be as passionate as the choice of a one’s religion or football

team, so it is out of scope. Instead, we treat elements at abstract meaning, andonly be interested in the satisfaction relationship among elements.

In our work, we define the satisfaction relationship in terms of usefulness.That an element set X is useful to another element set Y depends on the abilityto satisfy (or fulfill) Y if X is satisfied. We define a predicate useful(X, Y) which istrue (1) if X can satisfy all elements of Y, otherwise false (0). The implementationof useful depends on the specific requirement model. For examples:

– Goal models [20]: useful corresponds to Decomposition and Means-end re-lationships. The former denotes a goal can be achieved by satisfying itssubgoals. The later refers to achieving an (end) goal by doing (means) tasks.

– Problem frames [13]: useful corresponds to requirement references and domaininterfaces relationships. Requirements are imposed by machines, which con-nect to problem world via domain interfaces. Problem world in turn connectsto requirements via requirement references.

For evolutionary software systems which may evolve under some circum-stances (e.g., changes in requirements due to changes in business agreements,regulations, or domain assumption), their requirement models should be ableto express as much as possible the information about known unknowns i.e. po-tential changes. These potential changes are analyzed by evolution assessmentalgorithms to contribute to the decision making process, where a designer decideswhat would be in the next phase of the development process.

Based on the actor who can decide which evolution would happen, we cate-gorize requirement evolutions into two classes:

– controllable evolution is under control of designer to meet high level require-ments from stakeholder.

– observable evolution is not under control of designer, but its occurrence canbe estimated with a certain level of confidence.

Controllable evolutions, in other words, are designer’s moves to identify dif-ferent design alternatives to implement a system. The designer then can choosethe most “optimal” one based on her experience and some analyses on thesealternatives. In this sense, controllable evolution is also known as design choice.

Observable ones, in contrast, correspond to potential evolutions of which real-ization is outside the control of the designer. They are moves of reality to decidehow a requirement model looks like in the future. Therefore, the stakeholderand designer have to forecast the reality’s choice with a level of uncertainty. Theresponses are then incorporated into the model.

We capture the evolution in terms of evolution rule. We have controllablerule and observable rule corresponding to controllable and observable evolution.

Definition 1. A controllable rule rc is a set of tuples 〈RM,RMi〉 that consistsof an original model RM and its possible design alternative RMi.

rc =

n⋃i

{RM

∗−→ RMi

}

RE1

B1 B2

B3A

(a) Controllable rule

a1

1- a1

ISS-ENT-1

ISS-ENT-2

RE1 RE2 RE3 RE4

ü ü ü ü ü ü

Description of models

ISS-ENT-1 ISS-ENT-2

(b) Observable rule

Fig. 1. Example of controllable rule (a), and observable rule (b).

Definition 2. An observable rule ro is a set of triples 〈RM, pi, RMi〉 that con-sists of an original model RM and its potential evolution RMi. The probabilitythat RM evolves to RMi is pi. All these probabilities should sum up to one.

ro =

n⋃i=1

{RM

pi−→ RMi

}Fig. 1 is a graphical representation of evolution rules taken from SWIM case

study. Left, Fig. 1(a) describes a controllable rule where a requirement modelcontaining IKMI (RE1) has four design choices: A, B1, B2, and B4 (see Table 1and Table 2). Right, Fig. 1(b) shows that the initial model ISS-ENT-1 (includingRE1 and RE4) can evolve to ISS-ENT-2 (including RE1 to RE4), or remainunchanged with probabilities of α and 1− α. These rules are as follows:

rc ={RE1

∗−→ A,RE1∗−→ B1, RE1

∗−→ B2, RE1∗−→ B3

}ro =

{ISS-ENT-1

α1−→ ISS-ENT-2, ISS-ENT-11−α1−−−→ ISS-ENT-1

}

3.2 Game-Theoretic Account for Probability

Here, we discuss about why and how we employ game-theoretic (or bettinginterpretation) to account for probabilities in observable rules.

As mentioned, each potential evolution in an observable rule has an associ-ated probability; these probabilities sum up to 1. However, who tells us? Andwhat is the semantic of probability? To answer the first question, we, as sys-tem Designers, agree that Stakeholder will tell us possible changes in a periodof time. About the second question, we need an interpretation for semantic ofprobability.

Basically, there are two broad categories of probability interpretation, called“physical” and “evidential” probabilities. Physical probabilities, in which fre-quentist is a representative, are associated with a random process. Evidentialprobability, also called Bayesian probability (or subjectivist probability), areconsidered to be degrees of belief, defined in terms of disposition to gamble atcertain odds; no random process is involved in this interpretation.

To account for probability associated with an observable rule, we can use theBayesian probability as an alternative to the frequentist because we have no event

to be repeated, no random variable to be sampled, no issue about measurability(the system that designers are going to build is often unique in some respects).However, we need a method to calculate the value of probability as well asto explain the semantic of the number. Since probability is acquired from therequirement eliciting process involving the stakeholder, we propose using thegame-theoretic method in which we treat probability as a price. It seems to beeasier for stakeholder to reason on price (or cost) rather than probability.

The game-theoretic approach, discussed by Shafer et al. [27] in Computa-tional Finance, begins with a game of three players, i.e. Forecaster, Skeptic, andReality. Forecaster offers prices for tickets (uncertain payoffs), and Skeptic de-cides a number of tickets to buy (even a fractional or negative number). Realitythen announces real prices for tickets. In this sense, probability of an event E isthe initial stake needed to get 1 if E happens, 0 if E does not happen. In otherwords, the mathematics of probability is done by finding betting strategies.

In this paper, we do not deal with stock market but the design of evolvingsoftware, i.e. we extend it for software design. We then need to change rules of thegame. Our proposed game has three players: Stakeholder, Designer, and Reality.For the sake of brevity we will use “he” for Stakeholder, “she” for Designer and“it” for Reality. The sketch of this game is denoted in protocol 1.

Protocol 1Game has n round, each round plays on a software CiFOR i = 1 to n

Stakeholder announces piDesigner announces her decision di: believe, don’t believeIf Designer believes

Ki = Ki−1 +Mi × (ri − pi)Designer does not believe

Ki = Ki−1 +Mi × (pi − ri)Reality announces ri

The game is about Stakeholder’s desire of having a software C. He asksDesigner to implement C, which has a cost of M $. However, she does not haveenough money to do this. So she has to borrow money from either Stakeholderor National Bank with the return of interest (ROI) p or r, respectively.

Stakeholder starts the game by announcing p which is his belief about theminimum ROI for investing M $ on C. In other words, he claims that r wouldbe greater than p. If M equals 1, p is the minimum amount of money one canreceive for 1$ of investment. Stakeholder shows his belief on p by a commitmentthat he is willing to buy C for price (1 + p)M if Designer does not believe himand borrow money from someone else.

If Designer believes Stakeholder, she will borrow M from Stakeholder. Lateron, she can sell C to him for M(1 + r) and return M(1 + p) to him. So, the finalamount of money Designer can earn from playing the game is M(r − p).

If Designer does not believe Stakeholder, she will borrow money from Na-tional Bank, and has to return M(1 + r). Then, Stakeholder is willing to buy Cwith M(1 + p). In this case, Designer can earn M(p− r).

Suppose that Designer has an initial capital of K0. After round i-th of thegame, she can accumulate either Ki = Ki−1 +M(r−p) or Ki = Ki−1 +M(p−r),depend on whether she believes Stakeholder or not. Designer has a winningstrategy if she can select the values under her control (the M $) so that shealways keeps her capital never decrease, intuitively, Ki >= Ki−1 for all rounds.

The law of large numbers here corresponds to say that if unlikely eventshappen then Designer has a strategy to multiply her capital by a large amount.In other words, if Stakeholder estimates Reality correctly then Designer has astrategy for costs not to run over budget.

4 Making Decision: What Are the Best Things toImplement

One of the main objectives of modeling evolution is to provide a metric (or set ofmetrics) to indicate how well a system design can adapt to evolution. Togetherwith other assessment metrics, designers have clues to decide what an “optimal”solution for a system-to-be is.

The major concern in assessment evolution is answering the question: “Whethera model element (or set of elements) becomes either useful or useless after evo-lution?”. Since the occurrence of evolution is uncertain, so the usefulness of anelement set is evaluated in term of probability. In this sense, this work proposestwo metrics to measure the usefulness of element set as follows.

Max Belief (MaxB): of an element set X is a function that measures the max-imum belief supported by Stakeholder such that X is useful to a set of toprequirements after evolution happens. This belief of usefulness for a set ofmodel element is inspired from a game in which Stakeholder play a gametogether with Designer and Reality to decide which elements are going toimplementation phase.

Residual Risk (RRisk): of an element set X is the complement of total beliefsupported by Stakeholder such that X is useful to set of top requirementsafter evolution happens. In other words, residual risk of X is the total beliefthat X is not useful to top requirements with regard to evolution. Impor-tantly, do not confuse this notion of residual risk with the one in risk analysisstudies which are different in nature.

Given an evolutionary requirement modelRM = 〈RM, ro,rc〉 where ro=⋃i

{RM

pi−→ RMi

}is an observable rule, and rc =

⋃ij

{RMi

∗−→ RMij

}is a controllable rule, the

calculation of max belief and residual risk is illustrated in Eq. 1, Eq. 2 as follows.

MaxB(X) = maxRM

pi−→RMi∈Spi (1)

RRisk(X) = 1−∑

RMpi−→RMi∈S

pi (2)

where S is set of potential evolutions in which X is useful.

S ={RM

pi−→ RMi|∃(RMi∗−→ RMij) ∈ rc st.useful(X,RMij)

}One may argue about the rationale of these two metrics. Because he (or

she) can intuitively measure the usefulness of an element set by calculating theTotal Belief which is exactly the complement of our proposed Residual Risk.However, using only Total Belief (or Residual Risk) may mislead designers incase of a long-tail problem.

The long-tail problem, firstly coined by Anderson [1], describes a larger pop-ulation rests within the tail of a normal distribution than observed. A long-tailexample depicted in Fig. 2 where a requirement model RM might evolve toseveral potential evolutions with very low probabilities (say, eleven potentialevolutions with 5% each), and another extra potential evolution with dominat-ing probability (say, the twelfth one with 45%). Suppose that an element Aappears in the first eleven potential evolutions, and an element B appears in thelast twelfth potential evolution. Apparently, A is better than B due to A’s totalbelief is 55% which is greater than that of B, say 45%. However, at the end ofthe day, only one potential evolution becomes effective (i.e. chosen by Reality)rather than ‘several’ potential evolutions are together chosen. If we thus considerevery single potential evolution to be chosen, the twelfth one (45%) seems to bethe most promising and Max Belief makes sense here. Arguing that A is betterthan B or versa is still highly debatable. Ones might put their support on thelong tail [1], and ones do the other way round [5]. Therefore, we introduce bothResidual Risk and Max Belief to avoid any misleading in the decision makingprocess that can be caused when using only Total Belief.

For a better understanding of Max Belief and Residual Risk, we concludethis section by applying our proposed metrics to the evolution of SWIM Secu-rity Services discussed in previous section. In Fig. 3, here we have an initial re-quirement model RM0(ISS-ENT-1,ISS-BP-1) that will evolve to RM1(ISS-ENT-2,ISS-BP-1), RM2(ISS-ENT-1,ISS-BP-2), and RM3(ISS-ENT-2,ISS-BP-2) with

5%5%5% 45%

RM

RM1

ARM2

ARM11

ARM12

B…....

Fig. 2. The long-tail problem.

ISS-ENT-2,

ISS-BP-2

B1 D

C E F

B2 D

E F B3 D

E

Security Services

(ISS-ENT-1,

ISS-BP-1)

AD

G

B1D

G

B3D

G

B2D

G

28%

12%

18%

42%ISS-ENT-1,

ISS-BP-2

A D

E FB1 D

E F

B2 D

E F

B3D

EISS-ENT-2,

ISS-BP-1B1

D

CG

B2D

G

B3D

G

Fig. 3. Evolution of the SWIM Security Service.

probabilities of 28%, 18% and 42%, respectively. There are 12% that RM0 staysunchanged. Each requirement model is represented as a bubble in which thereis a controllable rule with several design alternatives. Each design alternative isan element set represented as a rounded rectangle that contains elements (suchas A, D, and G) to support (fulfill) requirements of that requirement model.

Table 3 shows some examples, where the first column displays element sets,and the two next columns show values of max belief and residual risk. Noticethat the max belief and residual risk in the first row, where the element set is{A,D}, are n/a which means that we are unable to find any potential evolutionthat {A,D} can support all top requirements.

Table 3. Examples of Max Belief and Residual Risk

Element set Max Belief Residual Risk

{A, D,} n/a n/a

{A, E, D, G, F} 18% 70%

{B3, D, G} 28% 60%

{B1, D, G, C} 28% 60%

{B3, D, E, G} 42% 0%

{B2, D, E, F, G} 42% 0%

In Table 3, {B3, D,E,G} and {B2, D,E, F,G} seem to be the best choices,since they have a high max belief (42%) and low residual risk (0%). The zeroresidual risk means these element sets are surely still useful after evolution. Ifthe cost of implementation is the second criteria and assume that each elementhas equal cost, then {B3, D,E,G} seems to be better.

5 Handling Complex Evolution

If a model is too large and complex, instead of dealing with the evolution of thewhole model, we can consider evolution in each subpart. If a subpart is still toolarge and complex, we can recursively divide it into smaller ones, each with itslocal evolution rule, until we are able to deal with.

We then need to combine these local rules together to produce a globalevolution one for the whole model. For simplicity, we assume that:

ASS-1: Independence of evolutions All observable rules are independent. Itmeans that they do not influent each other. In other words, the probabilitythat an evolution rule is applied does not affect to that of other rules.

ASS-2: Order of evolutions Controllable evolutions are only considered afterobservable evolutions.

As discussed, observable rules are analyzed on independent subparts. Prevail-ing paradigms of software development (e.g., Object-Oriented, Service-Oriented)encourage encapsulation and loosely coupling. Evolutions applying to subparts,therefore, are often independent. Nevertheless, if there are two evolution ruleswhich influent each other, we can combine them into a single one. We assumethat dependent evolutions do happen, but not a common case. Hence manualcombination of these rules is still doable.

The second assumption is the way we deal with controllable rules. If we applycontrollable rules before observable ones, it means we look at design alternativesbefore observable evolutions happen. This makes the problem more complexsince under the effect of evolution, some design alternatives are no longer valid,and some others new are introduced. Here, for simplicity, we look at designalternatives for evolved requirement models that will be stable at the end oftheir evolution process.

After all local evolutions at subparts are identified, we then combine theserules into a global evolution rule that applies to the whole model. The rationale ofthis combination is the effort to reuse the notion of Max Belief and Residual Risk(§4) without any extra treatment. In the following we discuss how to combinetwo independent observable evolution rules.Given two observable rules:

ro1 =

n⋃i=1

{RM1

p1i−−→ RM1i

}and ro2 =

m⋃j=1

{RM2

p2j−−→ RM2j

}Let ro is combined rule from ro1 and ro2, we have:

ro =⋃

1≤i≤n1≤j≤m

{RM1 ∪RM2

p1i∗p2j−−−−−→ RM1i ∪RM2j

}

Fig. 4 illustrates an example of combining two observable rules into a singleone. In this example, there are two subparts of SWIM Security Service: ISS-ENTand ISS-BP. The left hand side of the figure displays two rules for these parts,and in the right hand side, it is the combined rule.

In general case, we have multiple steps of evolution i.e. evolution happensfor many times. For the ease of reading, step 0 will be the first step of evolution,where no evolution is applied. We use RMd

i to denote the i-th model in step d,and rod,i to denote the observable evolution rule that applies to RMd

i , i.e. rod,itakes RMd

i as its original model.

a1(1-a2)

(1-a1)a2

(1-a1)(1-a2)

a1a2

a1

1- a1

a2

1- a2

ro1

ro2

ro = ro1 + ro2

ISS-ENT-1 ISS-ENT-2

ISS-BP-2ISS-BP-1

Security Services

(ISS-ENT-1,

ISS-BP-1)

ISS-ENT-2,

ISS-BP-1

ISS-ENT-1,

ISS-BP-2

ISS-ENT-2,

ISS-BP-2

ISS-ENT-1

ISS-ENT-2

RE1 RE2 RE3 RE4

ü ü ü ü ü ü

Description of models

ISS-BP-1

ISS-BP-2

RB1 RB2 RB3 RB4

ü ü ü ü

Fig. 4. Example of combining two observable evolution rules.

ro0,1

ro1,3ro1,2

p13p12p11

p21 p22 p23 p26p24 p25 p27 p28p29

ro1,1

RM0

1

RM1

1

RM2

1

RM1

3RM1

2

RM2

2RM2

3 RM2

4 RM2

5RM2

6 RM2

7RM2

8 RM2

9

Fig. 5. Multiple steps (phases) evolving requirement model.

The multi-step evolution begins with an original model RM01 . This model

can evolve to one of the potential evolutions RM1i . In the second step, each

RM1i then also evolves to one of many potential evolutions RM2

j . The evolutionstops after k steps. If we represent a model as a node, and connect a model to itspotential evolutions as we have done as aforementioned, then we have a tree-likegraph, called evolution tree with k-depth.

Fig. 5 illustrates a two-step evolution, in which observable rules are denotedas dotted boxes. The original model lays on top part of a box, and all potentialevolutions are in sub boxes laid at the bottom. There are directed edges connect-ing the original model to potential evolutions. The label on each edge representsthe probability such that original model evolves to target model.

In Fig. 5, an initial requirement model RM01 evolves to either RM1

1 , RM12

or RM13 . Likewise, RM1

i evolves to RM2j , where i=1..3 and j=1..9. Here, we

have a ternary complete tree of depth 2. Generally, the evolution tree of a k -stepconsecutive evolution is a complete k -depth, m-ary tree.

We can always collapse a k -step evolution into an equivalent 1-step one interms of probability by letting the original model evolve directly to the very lastmodels with the probabilities that are multiplication of probabilities of interme-diate steps. Therefore, any k-step evolution has an equivalent 1-step evolution.Hence all analyses discussed in §4 are applicable without any modification.

6 Limitation

Obviously there are limitations in this work:

– Real world applicability. Even though we work on a real world case study,this work is still pure theory. It needs to be elaborated and then evaluatedwith the industry. We plan to prove our work in the field of Air TrafficManagement (ATM), where we interact with designers and stakeholder ofan ATM system, and get their feedback for validation.

– Obtaining probability. Since evolution probabilities are obtained from stake-holder, they are individual opinions. To deal with the problem, we shall workon an interaction protocol with stakeholder to minimize inaccuracy, as wellas equip an appropriate mathematic foundation (e.g., Dempster and Shafer’stheory) for our reasoning.

– Independence of evolution. Complex models may require many probabilitiesthat are not independent. This breaks the assumptions discussed in §5. Eventhough designers can solve this problem by manually combining dependentevolutions, we still need a more systematic way to deal with them.

7 Related Works

A majority of approaches to software evolution has focused on the evolutionof architecture and source code level. However, in recent years, changes at therequirement level have been identified as one of the drivers of software evolu-tion [4, 12, 31]. As a way to understand how requirements evolve, research inPROTEUS [24] classifies changing requirements (that of Harker et al [11]) intofive types, which are related to the development environment, stakeholder, devel-opment processes, requirement understanding and requirement relation. Later,Lam and Loomes [15] present the EVE framework for characterizing changes,but without providing specifics on the problem beyond a meta model.

Several approaches have been proposed to support requirements evolution.Zowgi and Offen [31] work at meta level logic to capture intuitive aspects ofmanaging changes to requirement models. Their approach involves modelingrequirement models as theories and reasoning changes by mapping changes be-tween models. However, this approach has a limitation of overhead in encodingrequirement models into logic.

Russo et al [26] propose an analysis and revision approach to restructurerequirements to detect inconsistency and manage changes. The main idea is toallow evolutionary changes to occur first and then, in the next step, verify theirimpact on requirement satisfaction. Also based on this idea, Garcez et al [4] aimat preserving goals and requirements during evolution. In the analysis, a spec-ification is checked if it satisfies a given requirement. If it does not, diagnosisinformation is generated to guide the modification of specification in order tosatisfy the requirement. In the revision, the specification is changed accordingto diagnosis information generated. Similar to Garcez et al, Ghose’s [9] frame-work is based on formal default reasoning and belief revision, aims to address

the problem of inconsistencies due to requirement evolution. This approach issupported by automated tools [10]. Also relating to inconsistencies, Fabrinni etal [6] deal with requirement evolution expressed in natural language, which ischallenging to capture precisely requirement changes. Their approach employsformal concept analysis to enable a systematic and precise verification of consis-tency among different stages, hence, controls requirement evolution.

Other notable approaches include Brier et al.’s [3] to capture, analyze, andunderstand how software systems adapt to changing requirements in an organiza-tional context; Felici et al [8] concern with the nature of requirements evolving inthe early phase of systems; Stark et al [29] study the information on how changeoccurs in the software system and attempt to produce a prediction model ofchanges; Lormans et al [21] use a formal requirement management system tomotivate a more structural approach to requirement evolution.

8 Conclusion

We have discussed a rule-based representation of evolutions on requirement mod-els. We proposed game-theoretic approach to explain the uncertainty of evolu-tions. We also introduced two notions of max belief and residual risk to reasonon evolutionary models, in which the higher max belief and lower residual riskmodels seem to be more evolution-resilient than others. Together with otheranalyses (e.g., cost, risk), these values can help designers in making decision.

During the discussion, we provided many examples taken from a real worldproject, SWIM. These examples not only help to explain better our idea, butalso show the promising applicability of our approach.

For future work, we plan to instantiate our approach to a concrete modelinglanguage (e.g., goal-based language) and apply to a more convincing case study.We shall interact with stakeholder and designers, show them our approach andget their feedback to validate the usability of proposed approach.

References

1. C. Anderson. The long tail. Wired, October 2004.2. A. Anton and C. Potts. Functional paleontology: The evolution of user-visible

system services. TSE, 29(2):151–166, 2003.3. J. Brier, L. Rapanotti, and J. Hall. Problem-based analysis of organisational

change: a real-world example. In Proc. of IWAAPF ’06. ACM, 2006.4. A. d’Avila Garcez, A. Russo, B. Nuseibeh, and J. Kramer. Combining abductive

reasoning and inductive learning to evolve requirements specifications. In IEEProceedings - Software, volume 150(1), pages 25–38, 2003.

5. A. Elberse. Should you invest in the long tail? Harvard Business Review,2008.6. F. Fabbrini, M. Fusani, S. Gnesi, and G. Lami. Controlling requirements evolution:

a formal concept analysis-based approach. ICSEA ’07, 2007.7. FAA. System wide information management (SWIM) segment 2 technical review.

Tech. report, 2009.8. M. Felici. Observational Models of Requirements Evolution. PhD thesis, 2004.

9. A. Ghose. A formal basis for consistency, evolution and rationale management inrequirements engineering. ICTAI ’99, 1999.

10. A. Ghose. Formal tools for managing inconsistency and change in re. In IWSSD’00, Washington, DC, USA, 2000. IEEE Computer Society.

11. S. Harker, K. Eason, and J. Dobson. The change and evolution of requirements asa challenge to the practice of software engineering. In RE ’01, 1993.

12. J. Hassine, J. Rilling, J. Hewitt, and R. Dssouli. Change impact analysis forrequirement evolution using use case maps. In IWPSE ’05, 2005.

13. M. Jackson. Problem Frames: Analysing & Structuring Software DevelopmentProblems. Addison-Wesley, 2001.

14. C. F. Kemerer and S. Slaughter. An empirical approach to studying softwareevolution. TSE, 25(4):493–509, 1999.

15. W. Lam and M. Loomes. Requirements evolution in the midst of environmentalchange: a managed approach. In CSMR ’98, 1998.

16. M. LaMantia, Y. Cai, A. MacCormack, and J. Rusnak. Analyzing the evolution oflarge-scale software systems using design structure matrices and design rule theory:Two exploratory cases. In Proc. of WICSA ’08, pages 83–92, 2008.

17. M. Lehman. On understanding laws, evolution and conservation in the large pro-gram life cycle. J. of Sys. and Soft., 1(3):213 –221, 1980.

18. M. Lehman. Programs, life cycles, and laws of software evolution. Proc. IEEE 68,9:1060 –1076, September 1980.

19. L. Lin, S. Prowell, and J. Poore. The impact of requirements changes on specifi-cations and state machines. SPE, 39(6):573–610, 2009.

20. L. Liu and E. Eric Yu. Designing information systems in social context: A goaland scenario modelling approach. Info. Syst, 29:187–203, 2003.

21. M. Lormans, H. van Dijk, A. van Deursen, E. Nocker, and A. de Zeeuw. Managingevolving requirements in an outsourcing context: an industrial experience report.In IWPSE ’04, pages 149 –158, 2004.

22. T. Mens, J. Ramil, and M. Godfrey. Analyzing the evolution of large-scale software.J. of Soft. Maintenance and Evolution: Research and Practice, 16(6):363–365,2004.

23. Program SWIM-SUIT. D1.5.1 Overall SWIM users requirements. Tech. report,2008.

24. Project PROTEUS. Deliverable 1.3: Meeting the challenge of chainging require-ments. Tech. report, Centre for Soft. Reliab., Univ. of Newcastle upon Tyne, 1996.

25. R. Ravichandar, J. Arthur, S. Bohner, and D. Tegarden. Improving change toler-ance through capabilities-based design: an empirical analysis. J. of Soft. Mainte-nance and Evolution: Research and Practice, 20(2):135–170, 2008.

26. A. Russo, B. Nuseibeh, and J. Kramer. Restructuring requirements specifications.In IEE Proceedings: Software, volume 146, pages 44 – 53, 1999.

27. G. Shafer, V. Vovk, and R. Chychyla. How to base probability theory on perfect-information games. BEATCS, 100:115 – 148, February 2010.

28. P. Soffer. Scope analysis: identifying the impact of changes in business processmodels. J. of Soft. Process: Improvement and Practice, 10(4):393–402, 2005.

29. G. Stark, P. Oman, A. Skillicorn and A. Ameele. An examination of the effects ofrequirements changes on software maintenance releases. J. of Soft. Maintenance:Research and Practice, pages 293–309, 1999.

30. P. Zave and M. Jackson. Four dark corners of req. eng. TSEM, 6(1):1–30, 1997.31. D. Zowghi and R. Offen. A logical framework for modeling and reasoning about

the evolution of requirements. ICRE ’97, 1997.