Skip to main content
SpringerLink
Log in

Eliciting gaps in requirements change

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

We consider requirements change due to system evolution which results from contextual forces such as the decision to standardise practices across subsidiaries of a company. Our experience with the financial branch of the French Renault group is that eliciting change requirements poses its own specific problems. We propose to model change as a set of gaps between the requirements specification of the current and the future system. Our approach is to define a generic typology of gaps to facilitate a precise definition of change requirements. It adopts a goal oriented requirements specification and shows how to customise the generic gap typology to this specific requirements representation formalism. The paper presents the approach to elicit gaps and illustrates it with the Renault case study.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1.
Fig. 2.
Fig. 3.
Fig. 4.
Fig. 5.
Fig. 6.
Fig. 7.
Fig. 8.

Similar content being viewed by others

References

  1. Lientz BP, Swanson, EB (1980) Software maintenance management, a study of computer application software in 487 data processing organizations. Addison-Wesley, Reading, MA

  2. Nosek JT, Palvia P (1990) Software maintenance management: changes in the last decade. J Softw Maint 2(3), 157–174

    Google Scholar 

  3. IPSE International Workshop on the Principles of Software Evolution

  4. Breche P (1996) Advanced primitives for changing schemas of object databases. In: Proceedings of the international conference CAiSE'96, Heraklion, Greece. Springer, Berlin Heidelberg New York

  5. Lauteman SE (1997) Schema versions in object-oriented database systems. In: Proceedings of the fifth international conference on database systems for advanced applications, Melbourne, Australia, 1–4 April 1997

  6. Banerjee J, Kim W, Kim H-J, Korth HF (1987) Semantics and implementation of schema evolution in object oriented databases In: Proceedings of the ACM-SIGMOD annual conference, San Francisco, CA, May 1987, pp 311--322

    Google Scholar 

  7. Casati F, Ceri S, Pernici B, Pozzi G (1996) Workflow evolution. In: Proceedings of 15th international conference on conceptual modeling (ER'96), Cottbus, Germany, pp 438–455

  8. Liu C, Orlowska M, Li H (1998) Automating handover in dynamic workflow environments. In: 10th conference on advanced information systems engineering, Pisa, Italy

  9. Sadiq S (2000) Handling dynamic schema change in process models. In: Australian Database Conference, Canberra, Australia

  10. Bandinelli S, Fuggetta A, Ghezzi C (1993) Software process model evolution in the SPADE environment. IEEE Trans Softw Eng 19(12), 1128–1144

    Google Scholar 

  11. Heimann P, Joeris G, Krapp C, Westfechtel B (1996) DYNAMITE: dynamic task nets for software process management. In: Proceedings of the 18th international conference on software engineering (ICSE 18), Berlin, Germany, March 1996, pp 331–341

  12. Si-Said S, Rolland C, Grosz G (1996) MENTOR: a computer aided requirements engineering environment. In: Proceedings of the international conference CAiSE'96. Heraklion, Greece. Springer, Berlin Heidelberg, New York

  13. Lehman MM, Ramil JF, Kahen G (2001) Thoughts on the role of formalisms in studying software evolution. In: Mens T, Wermelinger M (eds) International special session on formal foundations of software evolution, Lisbon, Portugal, March 2001. Co-located with the European conference on software maintenance and reengineering (CSMR 2001)

  14. Jarke M, Pohl K (1993) Establishing visions in context: toward a model of requirements processes. In: Proceedings of the 12th international conference information systems, Orlando, FL

  15. Jackson M (1995) Software requirements and specifications. Addison-Wesley, Reading, MA

  16. von Lansweerde A (2000) Requirements engineering in the year 2000: a research perspective. In: 22nd international conference on software engineering

  17. Dardenne A, von Lansweerde A, Fickas S (1993) Goal directed requirements acquisition. Sci Comput Program 20, 3–50

    Google Scholar 

  18. Jarke M, Pohl K (1994) Requirements engineering in 2001: managing a changing reality. IEEE Softw Eng J November, 257–266

    Google Scholar 

  19. Rolland C, Prakash N (2001) Matching ERP system functionality to customer requirements. In: Proceedings of RE'01, 5th international symposium on requirements engineering, Toronto, Canada, pp 66–75

  20. Rolland C, Prakash N, Benjamen A (1999) A multi-model view of process modelling. Requirements Eng 4: 169–187

    Article  Google Scholar 

  21. Kradolfer M, Geppert A (1999) Dynamic workflow schema evolution based on workflow type versioning and workflow migration. In: Proceedings of the fourth IFCIS international conference on cooperative information systems (CoopIS99). Edinburgh, UK, 2–4 September 1999

  22. Information technology–information resource dictionary system (IRDS) (1990) Framework, ISO/IEC International Standard

  23. Marttiin P (1994) Methodology engineering in CASE shells: design issue and current practice. PhD thesis, Computer science and information systems reports, Technical report TR-4

    Google Scholar 

  24. Grundy JC, Venacle JR (1992) Towards an integrated environment for method engineering. In: Cotterman WW, Senn JA (eds) Challenges and strategies for research in systems development. Wiley, Chichester, pp 45–62

  25. Plihon V, Rolland C (1997) Using a generic approach to support the construction of methods. In: Proceedings of the 8th international conference on database and expert systems applications (DEXA'97), Toulouse, France, 1–7 September 1997

  26. Prakash N (1999) On method statics and dynamics. Inform Syst 24(8), 613–637

    Google Scholar 

  27. Rolland C, Souveyet C., Salinesi C (1998) Guiding goal modelling using scenarios. IEEE Trans Softw Eng (special issue on scenario management) 24(12): 1055–1071

    Article  Google Scholar 

  28. Prat N (1997) Goal formalisation and classification for requirements engineering. In: Proceedings of the third international workshop on requirements engineering: foundations of software quality REFSQ'97, Barcelona, pp 145–156

  29. Easterbrook S. Resolving requirements conflicts with computer-supported negotiation. In: Jirotka M, Goguen J (eds) Requirement engineering: social and technical issues. Academic Press, New York, pp 41–65

  30. Nuseibeh B, Kramer J, Finkelstein A (1994) A framework for expressing the relationships between multiple views in requirements specifications. IEEE Trans Softw Eng 20(10, 760–773

    Google Scholar 

Download references

Acknowledgements

Sincere thanks are due to the anonymous reviewers who provided constructive criticism that has made improvements possible.

Author information

Authors and Affiliations

  1. CRI, Université Paris 1, Sorbonne, 90 rue de Tolbiac, 75013 , Paris, France

    Colette Rolland, Camille Salinesi & Anne Etien

Authors
  1. Colette Rolland
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Camille Salinesi
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Anne Etien
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Colette Rolland.

Appendix: Defining map change operators to specifying map gaps

Appendix: Defining map change operators to specifying map gaps

1.1 Rename

1.1.1 RenameIntention

As any element [Fig. 2] an intention is associated to a string that defines its name. This holds both before and as result of applying the RenameIntention operator to a given intention.

$$ \matrix{ {{\rm{RenameIntention:Intention}} \to {\rm{String}}} \hfill \cr {{\rm{RenameIntention(I) = I}}{\rm{.name(N)}}|{\rm{N}} \in {\rm{String}}} \hfill \cr } $$

1.1.2 RenameStrategy

As any element, a strategy has a name which is a string. Therefore, renaming a strategy is achieved by changing the string value that defines its name.

$$ \matrix{ {{\rm{RenameStrategy:Strategy}} \to {\rm{String}}} \hfill \cr {{\rm{RenameStrategy(St) = St}}{\rm{.name(N)}}|{\rm{N}} \to {\rm{String}}} \hfill \cr } $$

1.1.3 RenameSection

Names are given to sections as a means to refer to them more easily. Renaming a section is, therefore, not a very significant gap defined as follows:

  RenameSection: Section → String

  RenameSection(Se) = Se.name(N) | N ∈ String

1.2 Add

1.2.1 AddIntention

As a result of map invariants (section 3), any map intention is connected to other intentions through strategies. Therefore, when an intention I is added, it must be related by strategies to at least two other intentions of the map (I1 & I2 in the predicate). In order to preserve C2, a strategy St1 must have the added intention I as target intention and an I1 intention as source intention. To preserve C3, another strategy St2 must have the added intention I as its source and I2 as its target. By default I1 and I2 might be Start and Stop, respectively.

$$ \matrix{ {{\rm{AddIntention:Intention}}^{\rm{2}} \to {\rm{Strategy}}^{\rm{2}} ,{\rm{Intention}}} \hfill \cr {{\rm{AddIntention(I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} {\rm{) = St}}_{\rm{1}} {\rm{.has - for - source(I}}_{\rm{1}} {\rm{)}} \wedge {\rm{St}}_{\rm{1}} {\rm{.has - for - target(I)}} \wedge } \hfill \cr {{\rm{St}}_{\rm{2}} {\rm{.has - for - source(I)}} \wedge {\rm{St}}_{\rm{2}} {\rm{.has - for - target(I}}_{\rm{2}} {\rm{)}}|{\rm{(St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} {\rm{)}} \in {\rm{Strategy}},} \hfill \cr {{\rm{I}} \in {\rm{Intention}}} \hfill \cr } $$

1.2.2 AddStrategy

According to the map meta-model, any strategy in a map can only be defined between two intentions: its source intention and its target intention respectively. Therefore, when a strategy is added it must be linked to two existing intentions, one being the source intention and the other being its target intention.

$$ \eqalign{ & {\rm{AddStrategy}}:{\rm{Intention}}^{\rm{2}} \to {\rm{Strategy}},{\rm{Section}} \cr & {\rm{AddStrategy(I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} {\rm{)}} = {\rm{St}}{\rm{.has - for - source(I}}_{\rm{1}} {\rm{)}} \wedge {\rm{St}}{\rm{.has - for - target(I}}_{\rm{2}} {\rm{) | St}} \in {\rm{Strategy}} \cr} $$

1.2.3 AddSection

In order to preserve the invariant I3 and to conform to the corollary C5 the AddSection operator ensures that the added section (Is, It, St) is connected to the rest of the map. This is achieved by enforcing the existence of (a) the strategy St1 having Is as its target and an intention I1 already existing as its source and (b) the strategy St2 having It as its source and an intention I2 already existing as its target. By default, I1 and I2 may be the Start and Stop intentions, respectively.

$$ \eqalign{ & {\rm{AddSection}}:{\rm{Intention}}^{\rm{2}} \to {\rm{Section}},{\rm{Strategy}}^{\rm{3}} ,{\rm{Intention}}^{\rm{2}} \cr & {\rm{AddSection (I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} {\rm{) = St}}_{\rm{1}} {\rm{.has - for - source(I}}_{\rm{1}} {\rm{)}} \wedge {\rm{St}}_{\rm{1}} {\rm{.has - for - target(I}}_{\rm{s}} {\rm{)}} \wedge \cr & {\rm{St}}_{\rm{2}} {\rm{.has - for - source(I}}_{\rm{t}} {\rm{)}} \wedge {\rm{St}}_{\rm{2}} {\rm{.has - for - target(I}}_{\rm{2}} {\rm{)}}|{\rm{Se}}{\rm{.composed\_of(St)}} \wedge \cr & {\rm{Se}}{\rm{.composed\_of(I}}_{\rm{s}} {\rm{)}} \wedge {\rm{Se}}{\rm{.composed\_of(I}}_{\rm{t}} {\rm{)}},{\rm{(St}},{\rm{St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} {\rm{)}} \in {\rm{Strategy}}, \cr & {\rm{(I}}_{\rm{s}} ,{\rm{I}}_{\rm{t}} ,{\rm{I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} {\rm{)}} \in {\rm{Intention}},{\rm{ Se}} \in {\rm{Section}}{\rm{.}} \cr} $$

1.3 Remove

1.3.1 RemoveIntention

The execution of the RemoveIntention is concerned with the corollaries of map invariants C1, C2 and C3. Preserving them implies that any strategy \({\rm St}_{\rm i}^{\rm s}\) (or) \({\rm St}_{\rm j}^{\rm t} \) having the removed intention I as a source intention (or target intention) must henceforth have another source intention \({\rm I}_{\rm k}^{\rm s} \) (or target intention \({\rm I}_{\rm l}^{\rm t} \)). By default the Start (or Stop) intentions are used.

$$ \eqalign{ & {\rm{RemoveIntention}}:{\rm{Intention}},{\rm{\{ Strategy\} }},{\rm{\{ Strategy\} }},{\rm{\{ Intention\} }},{\rm{\{ Intention\} }} \to {\rm{\O }} \cr & {\rm{RemoveIntention(I}},{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }}{\rm{,\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} }},{\rm{\{ I}}_{\rm{k}}^{\rm{s}} {\rm{\} }}{\rm{, \{ I}}_{\rm{l}}^{\rm{t}} {\rm{\} )}} = {\rm{[}}\forall {\rm{i}},{\rm{St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(I}}_{\rm{k}}^{\rm{s}} {\rm{) | I}}_{\rm{k}}^{\rm{s}} \in {\rm{\{ I}}_{\rm{k}}^{\rm{s}} {\rm{\} ]}} \wedge \cr & {\rm{[}}\forall {\rm{j}},{\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(I}}_{\rm{l}}^{\rm{t}} {\rm{)}}|{\rm{I}}_{\rm{l}}^{\rm{t}} \in {\rm{\{ Itl\} ]}}{\rm{.}} \cr} $$

1.3.2 RemoveStrategy

Let assume that the section (Is, St, It) exists in the As-Is map. In order to preserve C1, C2 or C3 the Remove Strategy operator applied to the strategy St imposes the existence of two sections (Is, St1, I1) and (I2,Stt, It). Is and It remain therefore source intention (or target intention) of sections in the map. By default I1 and I2 can be Start and Stop respectively.

$$ \eqalign{ & {\rm{RemoveStrategy}}:{\rm{Strategy}},{\rm{Intention}}^{\rm{4}} \to {\rm{Strategy}}^{\rm{2}} \cr & {\rm{RemoveStrategy(St}},{\rm{I}}_{\rm{s}} ,{\rm{I}}_{\rm{t}} ,{\rm{I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} {\rm{)}} = {\rm{St}}_{\rm{1}} {\rm{.has - for - source(I}}_{\rm{s}} {\rm{)}} \wedge {\rm{St}}_{\rm{1}} {\rm{.has - for - target(I}}_{\rm{1}} {\rm{)}} \wedge \cr & {\rm{St}}_{\rm{2}} {\rm{.has - for - source(I}}_{\rm{2}} {\rm{)}} \wedge {\rm{St}}_{\rm{2}} {\rm{.has - for - target(I}}_{\rm{t}} {\rm{)}}|{\rm{(St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} {\rm{)}} \in {\rm{Strategy}} \cr} $$

1.3.3 RemoveSection

When a section Se (<Is,It,St>) is removed, its three components (the intentions Is & It and the strategy St) are removed. In order to preserve the map invariants, the Remove Section operation ensures that any strategy \({\rm St}_{\rm i}^{\rm s} \) having Is or It as source intention has in the To-Be map another intention \({\rm I}_{\rm k}^{\rm s} \) (Start by default) as source. The same holds for strategies \({\rm St}_{\rm j}^{\rm t} \) having Is or It as target intention. After the section removal, these strategies must have another target intention \({\rm I}_{\rm l}^{\rm t} \) (Stop by default).

$$ \eqalign{ & {\rm{RemoveSection: Section}}{\rm{,\{ Strategy\} }}^{\rm{2}} ,{\rm{\{ Intention\} }}^{\rm{2}} \to {\rm{\O }} \cr & {\rm{RemoveSection(Se}},{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} )}} = {\rm{[}}\forall {\rm{ i}},{\rm{St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(I}}_{\rm{k}}^{\rm{k}} {\rm{)}}|{\rm{I}}_{\rm{k}}^{\rm{s}} \wedge {\rm{\{ I}}_{\rm{k}}^{\rm{s}} {\rm{\} ]}} \wedge \cr & {\rm{[}}\forall {\rm{j}},{\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(I}}_{\rm{l}}^{\rm{t}} {\rm{)}}|{\rm{I}}_{\rm{l}}^{\rm{t}} \in {\rm{\{ I}}_{\rm{l}}^{\rm{t}} {\rm{\} ]}}{\rm{.}} \cr} $$

1.4 Merge

1.4.1 MergeStrategy

A strategy St can be considered as the result of merging two strategies St1 and St2 iff these have the same source intention Is and the same target intention It. If this condition is not met, then a different operator must be involved in the gap elicitation. For instance, if three different intentions are involved, the MergeSection operator can be used to elicit the gap.

$$ \eqalign{ & {\rm{MergeStrategy}}:{\rm{Strategy}}^{\rm{2}} ,{\rm{Intention}}^{\rm{2}} \to {\rm{Strategy}} \cr & {\rm{MergeStrategy(St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} ,{\rm{I}}_{\rm{s}} ,{\rm{I}}_{\rm{t}} {\rm{)}} = {\rm{St}}{\rm{.has - for - source(I}}_{\rm{s}} {\rm{)}} \wedge \cr & {\rm{St}}{\rm{.has - for - target(I}}_{\rm{t}} {\rm{)}}|{\rm{St}} \in {\rm{Strategy}} \cr} $$

1.4.2 MergeIntention

When two intentions I1 and I2 are merged, the intention I replaces I1 and I2 in any section having initially I1 or I2 as source intention or target intention.

$$ \eqalign{ & {\rm{MergeIntention}}:{\rm{Intention}}^{\rm{2}} ,{\rm{\{ Strategy\} }}^{\rm{2}} \to {\rm{Intention}} \cr & {\rm{MergeIntention(I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} ,{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} )}} = {\rm{[}}\forall {\rm{i}}{\rm{, St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(I}}_{\rm{r}} {\rm{) ]}} \wedge \cr & {\rm{[}}\forall {\rm{ j}},{\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(I}}_{\rm{r}} {\rm{)]}}|{\rm{I}}_{\rm{r}} \in {\rm{Intention}}{\rm{.}} \cr} $$

1.4.3 MergeSection

The merging of two sections Se1 (<Is1, It1, St1>) and Se2 (<Is2, It2, St2>) results in a section Ser (<Isr, Str, Itr>). There are pre-conditions for applying this operator: Is1 must be different from Is2 or It1 must be different from It2. In the resulting situation, Is1 and Is2 are replaced by Isr and It1 and It2 are replaced by Itr in any section having initially Is1, Is2, It1 or It2 as source or target intention.

$$ \eqalign{ & {\rm{MergeSection: Section}}^{\rm{2}} ,{\rm{\{ Strategy\} }}^{\rm{2}} \to {\rm{Section}},{\rm{Intention}}^{\rm{2}} ,{\rm{Strategy}} \cr & {\rm{MergeSection(Se}}_{\rm{1}} ,{\rm{Se}}_{\rm{2}} ,{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} )}} = {\rm{\{ }}\forall {\rm{ i}}{\rm{, St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(I}}_{\rm{r}} {\rm{)\} }} \wedge \cr & {\rm{\{ }}\forall {\rm{ j}}{\rm{, St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(I}}_{\rm{r}} {\rm{)\} }} \wedge {\rm{Se}}_{\rm{r}} {\rm{.composed\_of(Is}}_{\rm{r}} {\rm{)}} \wedge \cr & {\rm{Ser}}{\rm{.composed\_of(It}}_{\rm{r}} {\rm{)}} \wedge {\rm{Ser}}{\rm{.composed\_of(St}}_{\rm{r}} {\rm{)}}|{\rm{St}}_{\rm{r}} \in {\rm{Strategy}}{\rm{,}} \cr & {\rm{(Is}}_{\rm{r}} {\rm{, It}}_{\rm{r}} {\rm{)}} \in {\rm{Intention}}{\rm{, (Se}}_{\rm{r}} {\rm{)}} \in {\rm{Section}} \cr} $$

1.5 Split

1.5.1 SplitStrategy

Splitting a strategy St of a section <Is, It, St>results in two strategies St1 and St2. Defining the sections <Is, It, St1>and <Is, It, St2>.

$$ \eqalign{ & {\rm{SplitStrategy: Strategy}},{\rm{ Intention}}^{\rm{2}} \to {\rm{Strategy}}^{\rm{2}} \cr & {\rm{SplitStrategy(St}},{\rm{I}}_{\rm{s}} ,{\rm{I}}_{\rm{t}} {\rm{)}} = {\rm{St}}_{\rm{1}} {\rm{.has - for - source(I}}_{\rm{s}} {\rm{)}} \wedge {\rm{St}}_{\rm{2}} {\rm{.has - for - source(I}}_{\rm{s}} {\rm{)}} \wedge \cr & {\rm{St}}_{\rm{1}} {\rm{.has - for - target(I}}_{\rm{t}} {\rm{)}} \wedge {\rm{St}}_{\rm{2}} {\rm{.has - for - target(I}}_{\rm{t}} {\rm{)}}|{\rm{(St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} {\rm{)}} \in {\rm{Strategy}} \cr} $$

1.5.2 SplitIntention

The SplitIntention operator permits the replacement of one intention I by two intentions I1 and I2. In order to keep the invariants satisfied, the operator ensures that any strategy \({\rm St}_{\rm j}^{\rm t} \) having the intention I for target in the As-Is map has either I1or I2 as target in the To-Be map. The same holds for strategies \({\rm St}_{\rm i}^{\rm s} \) that initially had I as source intention.

$$ \eqalign{ & {\rm{SplitIntention}}:{\rm{Intention}},{\rm{\{ Strategy\} }}^{\rm{2}} \to {\rm{Intention}}^{\rm{2}} \cr & {\rm{SplitIntention(I}},{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} )}} = {\rm{[}}\forall {\rm{ i}}{\rm{, St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(I}}_{\rm{1}} {\rm{)}} \wedge \cr & {\rm{St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(I}}_{\rm{2}} {\rm{)]}} \wedge {\rm{[}}\forall {\rm{ j}}{\rm{, St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(I}}_{\rm{1}} {\rm{)}} \vee \cr & {\rm{St}}_{\rm{j}} {\rm{.has - for - target(I}}_{\rm{2}} {\rm{)]}}|{\rm{(I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} {\rm{)}} \in {\rm{Intention}} \cr} $$

1.5.3 SplitSection

A section Se (<Is, It, St>) can be split into two sections Se1 (<Is1, It1, St1>) and Se2 (<Is2, It2, St2>). This implies as shown by the predicate that

  • any strategy \({\rm St}_{\rm i}^{\rm s} \) having initially Is (or It) as source must have Is1 or Is2 (or It1 or It2) as source in the final situation. Similarly,

  • any strategy \({\rm St}_{\rm j}^{\rm t} \) having initially Is (or It) as target must have Is1 or Is2 (or It1 or It2) as target in the final situation.

$$ \eqalign{ & {\rm{SplitSection}}:{\rm{Section}},{\rm{\{ Strategy\} }}^{\rm{2}} \to {\rm{Section}}^{\rm{2}} ,{\rm{Intention}}^{\rm{2}} ,{\rm{Strategy}}^{\rm{2}} \cr & {\rm{SplitIntention(Se}},{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} )}} = {\rm{[}}\forall {\rm{ i}}{\rm{, St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(Is}}_{\rm{1}} {\rm{)}} \vee \cr & {\rm{St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(Is}}_{\rm{2}} {\rm{)}} \vee {\rm{St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(It}}_{\rm{1}} {\rm{)}} \vee {\rm{St}}_{\rm{i}}^{\rm{s}} {\rm{.has - for - source(It}}_{\rm{2}} {\rm{)]}} \wedge \cr & {\rm{[}}\forall {\rm{ j}},{\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(Is}}_{\rm{1}} {\rm{)}} \vee {\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(Is}}_{\rm{2}} {\rm{)}} \vee {\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(It}}_{\rm{1}} {\rm{)}} \vee \cr & {\rm{St}}_{\rm{j}}^{\rm{t}} {\rm{.has - for - target(It}}_{\rm{2}} {\rm{)]}} \wedge {\rm{Se}}_{\rm{1}} {\rm{.composed\_of(Is}}_{\rm{1}} {\rm{)}} \wedge {\rm{Se}}_{\rm{1}} {\rm{.composed\_of(It}}_{\rm{1}} {\rm{)}} \wedge \cr & {\rm{Se}}_{\rm{1}} {\rm{.composed\_of(St}}_{\rm{1}} {\rm{)}} \wedge {\rm{ Se}}_{\rm{2}} {\rm{.composed\_of(Is}}_{\rm{2}} {\rm{)}} \wedge {\rm{Se}}_{\rm{r}} {\rm{.composed\_of(It}}_{\rm{2}} {\rm{)}} \wedge \cr & {\rm{Se}}_{\rm{2}} {\rm{.composed\_of(St}}_{\rm{2}} {\rm{)}}|{\rm{(Is}}_{\rm{1}} ,{\rm{Is}}_{\rm{2}} ,{\rm{It}}_{\rm{1}} ,{\rm{It}}_{\rm{2}} {\rm{)}} \in {\rm{Intention}},{\rm{(St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} {\rm{)}} \in {\rm{Strategy}}, \cr & {\rm{(Se}}_{\rm{1}} ,{\rm{Se}}_{\rm{2}} {\rm{)}} \in {\rm{Section}} \cr} $$

1.6 ChangeOrigin

The ChangeOrigin operator execution permits a source intention (or a target intention) I of a strategy St to be replaced by another intention In. When the origin of a strategy is changed, the invariant I3 and the corollaries C1, C2 and C3 may not hold in the To-Be map. This issue is solved by ensuring that there exits in this map, a strategy Stn having I as source (or target depending on the initial link).

$$ \eqalign{ & {\rm{ChangeOrigin}}:{\rm{Strategy}},{\rm{Intention}}^{\rm{2}} \to {\rm{Strategy}} \cr & {\rm{ChangeOrigin(St}},{\rm{I}},{\rm{I}}_{\rm{n}} {\rm{)}} = {\rm{[St}}{\rm{.has - for - source(I}}_{\rm{n}} {\rm{)}} \vee {\rm{St}}{\rm{.has - for - target(I}}_{\rm{n}} {\rm{)]}} \wedge \cr & {\rm{[St}}_{\rm{n}} {\rm{.has - for - source(I)}} \vee {\rm{St}}_{\rm{n}} {\rm{.has - for - target(I)}}|{\rm{St}}_{\rm{n}} \in {\rm{Strategy}} \cr} $$

1.7 Retype

1.7.1 RetypeStrategy

The gap between a As-Is map and a To-Be map may correspond to the retyping of a As-Is strategy St into a To-Be intention I. In order to satisfy the corollaries C2 and C3, the intention which was source (or target) of St must remain the source intention (or target intention) of at least one strategy in the To-Be map. Furthermore, to preserve C1, the new intention I must not be isolated. A strategy St3 having I as source and another strategy St4 having I as target must exist in the To-Be map.

$$ \eqalign{ & {\rm{RetypeStrategy}}:{\rm{Strategy}},{\rm{Intention}}^{\rm{6}} \to {\rm{Strategy}}^{\rm{4}} \cr & {\rm{RetypeStrategy(St}},{\rm{I}}_{\rm{s}} ,{\rm{I}}_{\rm{t}} ,{\rm{I)}} = {\rm{St}}_{\rm{1}} {\rm{.has - for - source(I}}_{\rm{s}} {\rm{)}} \wedge {\rm{St}}_{\rm{1}} {\rm{.has - for - target(I}}_{\rm{1}} {\rm{)}} \wedge \cr & {\rm{St}}_{\rm{2}} {\rm{.has - for - target(I}}_{\rm{t}} {\rm{)}} \wedge {\rm{St}}_{\rm{2}} {\rm{.has - for - source(I}}_{\rm{2}} {\rm{)}} \wedge {\rm{St}}_{\rm{3}} {\rm{.has - for - source(I)}} \wedge \cr & {\rm{St}}_{\rm{3}} {\rm{.has - for - target(I}}_{\rm{3}} {\rm{)}} \wedge {\rm{St}}_{\rm{4}} {\rm{.has - for - target(I)}} \wedge \cr & {\rm{St}}_{\rm{4}} {\rm{.has - for - target(I}}_{\rm{4}} {\rm{)}}|{\rm{(I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} ,{\rm{I}}_{\rm{3}} ,{\rm{I}}_{\rm{4}} {\rm{)}} \in {\rm{Intention (St}}_{\rm{1}} ,{\rm{St}}_{\rm{2}} ,{\rm{St}}_{\rm{3}} ,{\rm{St}}_{\rm{4}} {\rm{)}} \in {\rm{Strategy}} \cr} $$

1.7.2 RetypeIntention

Vice-versa, an As-Is intention I can be retyped into a To-Be strategy St. The predicate of the RetypeIntention operator ensures that any strategy \({\rm St}_{\rm i}^{\rm s} \) having initially I as source (or target) must have another source \({\rm I}_{\rm k}^{\rm s}\) (or target \({\rm I}_{\rm l}^{\rm t} \)) intention. The new strategy St must have a source intention I1 and a target intention I2 as well in the To-Be map.

$$ \eqalign{ & {\rm{RetypeIntention}}:{\rm{Intention}}^{\rm{3}} {\rm{,\{ Strategy\} }},{\rm{\{ Strategy\} }},{\rm{\{ Intention\} }}, \cr & {\rm{\{ Intention\} }} \to {\rm{Strategy}} \cr & {\rm{RetypeIntention(I}},{\rm{I}}_{\rm{1}} ,{\rm{I}}_{\rm{2}} ,{\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} }},{\rm{\{ I}}_{\rm{k}}^{\rm{s}} {\rm{\} }},{\rm{\{ I}}_{\rm{l}}^{\rm{t}} {\rm{\} )}} = \cr & {\rm{[}}\forall {\rm{ St}}_{\rm{i}} \in {\rm{\{ St}}_{\rm{i}}^{\rm{s}} {\rm{\} }},{\rm{St}}_{\rm{i}} {\rm{.has - for - source(I}}_{\rm{k}} {\rm{)}} \wedge {\rm{I}}_{\rm{k}} \in {\rm{\{ I}}_{\rm{k}}^{\rm{s}} {\rm{\} ]}} \wedge \cr & {\rm{[}}\forall {\rm{St}}_{\rm{j}} \in {\rm{\{ St}}_{\rm{j}}^{\rm{t}} {\rm{\} }},{\rm{St}}_{\rm{j}} {\rm{.has - for - target(I}}_{\rm{l}} {\rm{)}} \wedge {\rm{I}}_{\rm{l}} \in {\rm{\{ I}}_{\rm{l}}^{\rm{t}} {\rm{\} ]}} \wedge {\rm{St}}{\rm{.has - for - source(I}}_{\rm{1}} {\rm{)}} \wedge \cr & {\rm{St}}{\rm{.has - for - target(I}}_{\rm{2}} {\rm{)}}|{\rm{St}} \in {\rm{Strategy}}{\rm{.}} \cr} $$

The Give, Withdraw and Modify operators apply on properties of Intentions (Verb, Target, Parameters) and properties of Sections (Business rules, Pre-condition, Post-condition). Any change of properties maintains the map invariants. Therefore, there is no need for a predicative definition of these operators.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Rolland, C., Salinesi, C. & Etien, A. Eliciting gaps in requirements change. Requirements Eng 9, 1–15 (2004). https://doi.org/10.1007/s00766-003-0168-y

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-003-0168-y

Keywords

Search

Navigation