Towards capturing Change in Socio-Technical Systems ... - CiteSeerX

Towards capturing Change in Socio-Technical Systems Requirements John Brier, Lucia Rapanotti and Jon Hall Computing Research Centre, The Open University Walton Hall, Milton Keynes, MK7 6AA, UK

Abstract. Within organisations, business processes are increasingly supported by socio-technical systems — combinations of people and technologies working synergistically. In the commercial sector at least, business processes are increasingly complex and volatile due to the rapid pace of change in the marketplace, and this has an impact on their supporting systems. In this sector, organisations feel the same pressures for change from their shared context, and similarities should therefore be found in their responses to it. In a change situation, an organisation will typically have already functioning systems and processes upon which the impact of change in the problem context is felt. The issues raised by change are not, therefore, those of building solutions from scratch but those of adapting a current solution to the change. This is not a new observation: it is the basis of Business Process Re-engineering, for instance. Problem modelling, as suggested by Jackson’s Problem Frames approach, is only beginning to be applied in an organisational setting; we suggest, in this paper, that it can (suitably extended) be used to capture patterns of change in this domain. One other characteristic of the Problem Frames approach is important to us: it provides a conceptual framework for correctness which, in this paper, we adapt to allow correctness of changed solutions to be inferred using stepwise arguments from those of the original solution. We illustrate our approach on a real world example taken from the files of a practising consultancy firm in the area of change management.

1

Introduction

The term ‘socio-technical system’ indicates the complex interrelationships of people and technology, including hardware, software, data, physical surroundings, people, procedures, laws and regulations [23]. Socio-technical systems are increasingly at the heart of organisations and support their main business processes. This has created for the software community in general and for the requirements engineering community in particular, a new focus for research and development. Approaches that explicitly integrate requirements analysis with the needs of organisations have started to appear in the requirements engineering literature [37, 24, 2, 36, 5]. These approaches have focused primarily on new system development.

The issue of how socio-technical systems adapt to changing requirements in their organisational context remains less well understood, but this form of change is typical: an organisation’s continuing competitive advantage can often depend on the response of their business processes [15] to environmental change. The drivers for change are typically in the environment of the organisation, and can take many forms: for instance, changed expectations of their services or products from their customers or changes in the services supplied by their business chain. From a Business Process Reengineering (BPR) standpoint, [15] suggests that, to respond to these changes, an organisation should understand its business processes, understand how to change them and understand either the consequences for their installed IT systems or the constraints which their installed IT systems impose upon change. Grant [8] argues that BPR should consider other important aspects of institutions such as organisational structure, people and communication. We feel that at least as important as these is the consideration that must be given to the organisation’s business environment, precisely because that is where the drivers for change reside and where the effects of change can be best reasoned about1 . With our framework, we are therefore working towards the BPR objective of tools that allow the evaluation of the effects of re-designed solutions before implementation ([17, 28, 33]). Our framework starts from an organisation’s understanding of a business process, and includes models of human and technological activity, the context of a process, and the important characteristics of the business process that makes it successful, captured in the reasoning — rigourous or otherwise — of why it meets its requirements. Given this starting point2 , we feel that there will be repeated structures and behaviours that are felt across organisations and that it is useful to capture and record these and to use them to index solutions. We therefore aim to provide a pattern-based way of relating changes in an organisation’s context and/or requirements to the components, actors and roles that appear in the business model, in which important changes — those that affect the characteristics of success — can be traced from the old system to the new. Indeed, Jarke, [20], identifies experience reuse as a necessity in order to control quality, costs, and time, as a result of change. Another contribution of this paper is a prototype notation for capturing changing socio-technical problems (see Figure 6). Within the software engineering literature, the issue of change has been considered mainly in relation to software, rather than its wider socio-technical context. Among the notable contributions from the literature on software maintenance and evolution [22] are, for instance, classifications of software change [4] or management techniques for increasing software flexibility in the face of possible future software changes, for instance, [1]. The requirements engineering literature has also addressed primarily software requirements [21]. Contributions include, for instance, classification of requirements change [25] or the relation between changing business goals and the evolution of software architecture [9]. 1 2

This is analogous to the approach taken by Jackson in, for instance, [19] Again analogous to Jackson.

Requirements traceability, see for instance [20], is a collection of techniques that exhibit the ability to describe and follow the life of a requirement, both forwards toward and backward from architecture and code throughout the whole of a system life cycle. However, although change is experienced in socio-technical systems through changing requirements, the source of the change has most often to do with the environment: the requirements change in response to environmental changes [13]; typically, it is the changing nature (or changing understanding) of real-world domains customers, suppliers, legislation, the marketplace, etc. that drives requirements change; understanding the changing context of a system is therefore an important aspect of dealing with change. In [27], the authors create classes of requirement changes prioritised according to the potential impact. This is a classification scheme for requirements, rather than for pattern forming. The Viewpoints approach expresses consistency relationships between ’viewpoints’ (parts or chunks) of a specification so that the automated support for propagation of change becomes possible [26]. Agile Software Processes (for instance, [16] are claimed able to deal smoothly with changing requirements. The presence of an on-site customer means that a conversation may be had between problem and solution owners, the low latency having a beneficial effect in recognising and communicating change. It is difficult to see, however, how expertise is captured for reuse in such processes. he lack of domain modelling, where the drivers for change reside could be another weakness. The paper is structured as follows. Section 2 introduces our approach. Section 3 discusses the example. Section 4 proposes the notion of change frame as a means to capturing and reasoning about change in socio-technical systems. Finally, Section 5 includes some reflection on the approach and concludes the paper.

2

Problem Frames for change

Our change approach is based on the socio-technical problems notation introduced by Hall and Rapanotti [11] as an extension to Jackson’s original Problem Frames [19] framework3 . Problem Frames are an approach for the representation, classification and analysis of software problems (a thorough introduction can be found in [19]). Problem Frames represent problems though the notation of problem diagram. A generic such diagram for socio-technical problems (in the notation of [11]) is given in Figure 1. There are three main parts to the diagram: – the context, which captures some relevant properties of the environment in which a socio-technical solution should reside; the context is described through its indicative properties, that is what is known to be true of it; in the notation it is represented by boxes, called given domains (or simply domains); – the solution, as a combination of socio-technical components; the solution is described through its optative properties, that is what we would like to 3

The main innovation being the introduction of designable knowledge domains, representing the social part of a solution.

be true of it; solution components are represented as barred boxes, called knowledge domains in the case of people, and machine domains in the case of technologies4 ; – the requirement, another optative description, which expresses what we would like to be true of the context once a socio-technical solution is designed; in the notation this is represented as a dashed oval. The three component parts of a socio-technical problem are related through shared phenomena, e.g., events, states or commands, which are represented as links between domains and requirement. For instance, in Figure 1 the ‘Real-world domain’ is linked to the ‘Machine domain’ through a set a of shared phenomena. In being shared, the phenomena are visible to both domains. The link between ‘Requirement’ and domains is also expressed in terms of phenomena. In the figure, the dotted arrow expresses the fact that the requirement constrains5 the phenomena in the set c, which belong to the ‘Real-world domain’. (Later on in the paper we will see how to define and associate phenomena with domains and requirements more precisely.) socio-technical solution

context

Machine domain

a Real-world domain

d

c

Requirement

b

Knowledge domain

Fig. 1. Extended Problem Frames notation for socio-technical problems

To solve a problem diagram two things must be defined: a specification of what the socio-technical components of the solution must do (in the case of knowledge domains, the specification should indicate some instruction or training to be designed); and a correctness argument that shows that the specification, in the given context, satisfies the requirement. Of particular importance to us 4

5

Although both are designable, the many obvious differences in their characteristics justify the different notations. If a dotted line were used instead, it would mean that the requirement only refers to the phenomena.

in this paper, the correctness argument is not necessarily formal or rigourous; there are many forms it can take, including natural language argumentation, some form of testing, or even the fact that it has been functioning for a long time. In a Problem Frames development, it is typical to begin with the description of the problem context – the domains in the real world that form the context of the solution – together with the description of the requirements. In a change situation, however, we need to (most likely, only partially) redevelop the current solution to produce a new solution. The issue of change is not, therefore, that of building a solution but that of adapting the current solution to the change, and of providing justification that the changed solution continues to be a solution. Hence the process of development in the presence on change becomes that outlined in Figure 2 (after [7, 14]) in which we are required to consider both before and after-change problems and their solutions, how the latter is arrived at from the former, and how the correctness argument for the latter can be derived from that of the former.

Current ProblemPF

change

New problemPF new correctness argument

correctness argument Current SolutionPF

New solutionPF

Fig. 2. The change analysis process

In the next section, we exemplify this change process on a small real world example. In the one after, we will abstract from the example and propose a new notation, the change frame diagram as a vehicle for change development. Its components are: a combined before- and after-the-change problem diagram, and their relations; and the representation of how a correctness argument for the before-the-change problem diagram should change to become a correctness argument for the after-the-change problem diagram.

3

Removing intermediaries — a real world example

The example is taken from (www.katotech.co.uk). It is small, but represents a real-world problem and its solution as determined by Katotech, a practising consultancy firm in the area of business process engineering and change management. In the example, the before-the-change situation is that an investment bank makes use of an intermediary to handle the settlements of their customers’ transactions. In turn, the intermediary, a third-party organisation, makes use of

CREST, a multi-currency electronic settlement system for UK securities. Communication between the bank and the intermediary is through the bank’s employees, who record customers’ requests and transfer the information by phone to the intermediary. The motivation for the change is as follows. Due to increased trading volume – a change in the marketplace – the bank seeks cost reduction through the elimination of the intermediary, and direct access to CREST. This also provides a competitive edge by allowing customers to trade closer to the exchange closing time. The following Problem Frames interpretation of the change has been made with reference to (www.katotech.co.uk). The authors have had no part in the work done by Katotech, and have only reverse engineered the Katotech’s change into our framework. To the best of our knowledge, Problem Frames were not used in producing the Katotech’s solution. 3.1

Before the Change

The current situation is captured in Figure 3 as the socio-technical problem diagram of handling customers’ transactions through an intermediary, which in turns makes use of CREST to settle the transactions. In the figure, the problem context is represented by the following domains and their interfaces: – Customer domain: this represents a customer of the bank, who may require transactions to be settled. – Intermediary domain: this represents the intermediary organisation which handles the settlements of customers transactions of the bank following the receipt of customer information from the bank employee. The intermediary makes use of CREST for transactions settlement. – CREST domain: CREST provide transactions settlement to registered organisations, such as the intermediary. The current solution is provided by the following socio-technical components: – Bank IT domain: currently the Bank IT is not directly involved in the process of settling customers transactions, although information of such transactions is recorded manually by a bank employee. – Bank Employee domain: the bank employee records the customers’ transactions information on the bank’s IT, and manually transfers such information to the intermediary. Note how the bank employee is considered as part of a socio-technical solution in servicing customer needs. That is, instead of being considered as a mere user of the IT system with some given (indicative) properties, they are seen as a provider of the service in conjunction with the machine, with some desirable (optative) behaviour, which is prescribed by some organisational customer management policy and might be induced, for instance, through specific training. As the socio-technical system changes in response to requirements change, both social and technical parts of the solution can change.

5. ... which settles the transaction... (domain description)

4. ... which, in turn, requests processing from CREST... (domain description)

6. ... satisfying the requirement. (requirement)

Bank IT

Intermediary

BE!b

I!d

CREST

BE!c Bank Employee

e a

C!a

Customer transaction settlement

Customer

3. ... where an employee records the customer's transaction on the bank IT and requests its processing from the intermediary ... (specification)

2. ... then the customer requests the transaction from the investment bank... (domain description)

1. When the customer wants to perform a transaction... (the requirement)

a: {requestTransaction} b: {recordCustomerTransaction} c: {requestCustomerTransactionProcessing} d: {requestTransactionProcessing} e: {settleTransaction} Fig. 3. The problem diagram and correctness argument for the current situation

Figure 3 includes details of all the shared phenomena of interest (this description is simplified as, for instance, no feedback is indicated from CREST back to the bank and its customers through the intermediary). Note: the ‘!’ written postfix to a domain abbreviation indicates control of the set of phenomena is held by that domain. Control here has a loose meaning and can take many forms, e.g., the encapsulation of a state, the issuing of a command, or the processing of information. For instance, in the figure, the customer generates events requestTransaction (the only phenomena in set a). This is captured by the notation as C!a. Also in the figure, there is a distinction between phenomena referenced or constrained by the requirement: reference phenomena are indicated on a dashed line, e.g., those in set a; while constrained phenomena are associated to a dashed line with an arrowhead, e.g., those in set e. In the current context, the given solution satisfies the (functional) requirement that requests from customers should be settled. As Problem Frames were not used in the original development, we have no access to any explicit justification for the correctness of this solution. However, having reverse engineered what we believe to be the important parts of the problem in Figure 3, we can also provide a correctness argument relating such parts. The argument is represented in the figure as a collection of numbered annotations related to the problem diagrams component parts; to follow the argument follow the numbers in the figure (from 1 to 6). Note how the argument relies on the statement of the requirement, on domain descriptions and on the specification of the socio-technical solution. In other words, the correctness arguments brings together all assumptions made of the problem in order to validate

that the requirement is satisfied by the solution in the given context. Note also that although an informal argumentation is used here, the correctness argument is still rigourous in the way it brings all descriptions together. 3.2

After the change

Eliminating the intermediary and establishing a direct link to CREST has the following impact on the problem context: – Intermediary domain: this domain ceases to be relevant to the problem as all transactions are handled directly between the bank and CREST. – CREST domain: this remains unchanged, except that the bank is now a registered organisation and has direct access to the offered services. The changes in the solution are: – Bank IT domain: the Bank IT is re-engineered for direct access to CREST. Hence, once an employee has recorded a customers request, this is immediately communicated to CREST for settlement (rather than going through the Intermediary). – Bank employee domain: The Bank Employee’s job is simplified: once a customers request is entered in the Bank IT, there is no need for the employee to take any further action. The new situation is represented in Figure 4 as a socio-technical problem diagram (derived from that of Figure 3). In this new problem, the socio-technical solution still satisfies the same functional requirement of settling customers’ transactions. The new correctness argument is also derived from that of the original problem by taking into consideration the removal of the intermediary and the changes to the socio-technical solution specification discussed above. 3.3

Summary of the change analysis process

The analysis of the change in the example has followed the process of analysis outlined in Figure 2. First of all, a representation of the before-the-change situation was provided as a socio-technical problem. The main advantage of this representation is a separation of concerns: the solution parts are clearly separated from their context, and the particular need they satisfy is recorded explicitly, together with a convincing argument for their correctness. A representation of the after-the-change situation was then derived as a revised socio-technical problem. This too maintained the same separation of concerns as the previous problem, with the added bonus that the impact of change could be analysed in terms of the problems component parts, in order to argue that the new solution still satisfies the original functional requirements. Although not conducted in this example, which is a post-rationalisation of the change process, it could be argued that such a representation may be a vehicle for reasoning about the improvements brought about by the solution; for instance,

4. ... which automatically requests its processing from CREST... (specification) Bank IT

BIT!c'

5. ... which settles the transaction... (domain description) 6. ... satisfying the requirement. (requirement)

CREST e

Customer transaction settlement

BE!b a Bank Employee

3. ... where an employee records the customer's request on the bank IT... (specification)

C!a Customer

2. ... then the customer requests the transaction from the investment bank... (domain description)

1. When the customer wants to perform a transaction... (the requirement)

a: {requestTransaction} b: {recordCustomerTransaction} c’: {requestCustomerTransactionProcessing} e: {settleTransaction} Fig. 4. The problem diagram and correctness argument for the new situation

that extended periods of service are now available to the bank’s customers, or that efficiency gains and cost reductions have been achieved through automation. Of course, this is only a conjecture at this point in time.

4

Towards a Change Frame

Let us assume that the change situation of the example is a recurring change problem for organisations: this is plausible because ‘remove intermediary’ is a generator of change at different levels of granularity of change in business processes, as acknowledged in [6, 29, 30, 32, 35]. The Problem Frames approach includes frame diagrams to represent classes of familiar and recurring software problems which are ‘intuitively recognisable’ [19]. Frame diagrams provide a general form for a problem class from which particular problem diagrams can be instantiated. Taking our inspiration from frame diagrams, we propose change frame diagrams which match a before-thechange situation for a particular class of change, allowing it to be transformed into the after-the-change problem diagram. Our proposed change frame diagram for the removal of intermediaries is given in Figure 56 . The Remove Intermediary change frame diagram is meant to capture the broad characteristics of the change problem’s context, the interfaces between the context and its solution, the requirements, and the correctness argument. In the figure, domain ‘Context’ represents an abstraction of the actual problem context, which can, of course be more complex than just a single domain; in the example of the previous section the ‘Context’ included both ‘Customer’ and ‘CREST’. The notational conventions used in the figure are: – elements that exist before the change and continue to exist unchanged after are shown as would be expected in (socio-technical) Problem Frames notation, e.g. domain Context or phenomena set a; – shared phenomena links that exist before the change but are removed by the change are shown with dotted lines, e.g. the link between Context and Intermediary; – domains or phenomena sets which have been modified because of the change are shown with their name suffixed by a prime, e.g. IT’ or b’; – transformations of phenomena sets and corresponding correctness argument statements are indicated as labelled arrows, e.g., b to b’. (A summary of the notation is given in Figure 6, assuming changes in a technological component of a socio-technical solution. A similar notation applies to social components.) A change frame diagram represent change by detailing its impact. For our example, Figure 5, the impact of the change is that shared phenomena with the 6

Note that, to be faithful to Problem Frames, in the diagram we should have also indicated domain and phenomena types [18]. This important aspect of frame diagrams is not central to our development and we omit here for clarity.

3'. ... which makes IT' do c' (specification) ...

4'. ... which causes d in the Context (domain description), hence providing the service required (requirement).

3. ... which makes Intermediary do c (domain description) ...

c to c'

IT'

Intermediary

IT

4. ... which causes d in the Context (domain description), hence providing the service required (requirement).

'!c

'

I!c

E'!b'

b

E! Employee' 2'. ... then Employee' does b' (specification) ... b to b'

C!a

2. ... then Employee does b (specification) ...

Context

a,d

Required service

1. When Context does a (the requirement) ...

Fig. 5. The Remove Intermediary change frame diagram

‘Intermediary’ have been removed and new phenomena shared with the ‘Context’ are introduced (b to b’ and c to c’). The impact is reflected in the correctness argument template, by which one can move between the correctness arguments before and after the change. The proposed change frame relates to the example in the previous sections by matching its ‘Context’ domain to the ‘Customer’ and ‘CREST’ given domains of Figures 3 and Figures 4. The derivation of the diagrams in those figures, and their correctness argument, from the change frame diagram is then straightforward. As for design (and other types of) patterns, whether this proposed change frame is actually representative of a class of change problems within organisations is, of course, still only a conjecture, and one that will require identification of a wide range of cases to be validated.

5

Discussion and Conclusion

The paper has proposed an approach for capturing change in organisations, a notation for capturing classes of recurrent change problems and some analysis tools for reasoning about the impact of change through correctness arguments. The approach has been illustrated using a small real-world example. The proposed approach has some notable characteristics. In being based on Problem Frames, it allows for a separation of concerns between a solution and its context, the expression within a unified framework of both requirements, solution specifications, and correctness statements to argue their consistency, and the representation of the complex context in which socio-technical systems operate. The socio-technical notation adopted from [11] also allows the separation of

Nothing has changed in D

D

D

D's description has changed

D

D'

D has been removed

D

D

D's phenomena shared with C have been removed, hence D has changed

D

D has been removed, hence its shared phenomena

D

D has changed, but not its shared phenomena with C

D

D has changed, and so its shared phenomena with C

D

D!a

D!a

D!a

D!a

C

D'

C

D

C

D'

C

D'

D!a

D!a

D'!a

D'!a'

C

C

C

C

Fig. 6. Summary of the notation

social and technical parts of the solution, allowing reasoning about design decisions which go beyond technology — this is crucial is organisational change is to be represented. The approach includes a prototype process for change analysis that leads from a current to a changed business situation through modelling and analysis of corresponding socio-technical problems and their correctness arguments, allowing for an impact analysis of the change. We conjecture that the approach could be the basis for the development of tools for capturing recurrent problem change, through the notion of change frame, aiming at the reuse of expertise within diverse business scenarios. Other approaches in Requirements Engineering have some commonalities with our work. The REVEAL process shares the same conceptual basis as Problem Frames in the reference model of Jackson et al. [38, 10], hence it includes a similar separation of concerns between solution and its context, and the need for correctness arguments. Importantly, the industrial use of the REVEAL process [12] has validated the reference model as a productive perspective on software development. Differently from our approach, however, the end point of the REVEAL process is a software system specification, and so the social aspect of a socio-technical system is missing. Also missing is a notation for the representation and analysis of change, which can only be dealt with as a complete new redevelopment, and for the capture of recurrent change patterns. Goal-based approaches (see, e.g., [37, 34, 24, 3]) share with our work the focus on socio-technical solutions. The notion of problem as a requirement in a context [19], however, is missing from goal-oriented approaches, which are based on the

notions of goal, task and agent instead. Also missing is the distinction between optative and indicative descriptions, which is the basis of our correctness arguments. As for REVEAL, goal-oriented approaches have yet to develop specific tools for dealing with change. Volere [31], a well-known scenario-based approach to requirements engineering, is predicated on the identification of business processes within an organisation, which need some form of automation. Such processes are collectively called ‘the work’. Relevant business rules that governs the work need be identified together with the work boundary, the external business events to which the work reacts, and the effect of such events. Scenarios are then used to identify the technical requirements that an automated system within the work should satisfy. Although similar to our work in intent and scope, Volere also lacks analytical tools for reasoning about correctness and change. As a component of the first author’s PhD studies, future work will take the approach forward in three main directions. First of all, a more abstract codification of the change analysis process will be provided. Akin to the way Problem Frames classify software problems ([19]), we envisage a classification of problem changes will be possible. The separation of requirement, context and solution allows us to locate the different parts of the problem where change may originate. In general, together with changes in the requirements, changes which originate from the problem context or even the solution are also possible: for instance in our example, a more competitive settlement system may become available; or the bank may need to downsize its operation and reduce personnel. Hence, we envisage a finer grain taxonomy of change, and a corresponding specialisation of the analysis process. Finally, the example used in this paper, although derived from a real-world problem, constitutes only an initial approach to a general framework. We will need to apply our the techniques to many, larger real-world problems for a more extensive and systematic validation of our work.

Acknowledgements We would like to thank many colleagues in the Computing Research Centre at the Open University for their help, advice and support, in particular, Michael Jackson, Bashar Nuseibeh, and Zhi Li. We would also like to thank the anonymous REFSQ reviewers for their detailed comments that have allowed us to improve this paper.

References 1. K. Bennett, D. Griffiths, P. Brereton, M. Munro, and P. Lazzell. Panel: Software maintenance in practice. In Proceedings of the International Conference on Software Maintenance ICSM. 1996. 2. S. Bleistein, K. Cox, and N. Verner. Problem frames approach for e-business systems. In K. Cox, J. Hall, and L. Rapanotti, editors, 1st International Workshop on Advances and Applications of Problem Frames, pages 7–15, Edinburgh, 2004. IEE.

3. P. Bresciani and P. Donzelli. A practical agent based requirements engineering framework:the conceptual modelling for novel application domains. Lecture notes in Computer Science,, Vol. 2814/2003:pp 217–228, 2003. 4. J. Buckley, T. Mens, M. Zenger, A. Rashid, and G. Kniesel. Towards a taxonomy of software change,. Journal of Software Maintenance and Evolution: Research and Practice, 2002. 5. K. Cox, K. Phalp, S. Bleistein, and J. Verner. Deriving requirements from process models via the Problem Frames approach. Information and Software Technology, 2004. to appear. 6. B. Dervin. Chaos order and sensemaking;. 1999. 7. H. M. Franken and W. Janssen. Get a grip on changing business processes results from the testbed project. Knowledge and Process Management, 5(4):208215, 1998. 8. D. Grant. A wider view of business process re-engineering. Communications Of The ACM, 45(2):85–86, 2002. 9. D. Gross and E. Yu. Evolving system architecture to meet changing business goals: an agent and goal-oriented approach,. In In Proceedings of the Fifth International Symposium on Requirements Engineering (RE01), 2001. 10. C. A. Gunter, E. L. Gunter, M. Jackson, and P. Zave. A reference model for requirements and specifications. IEEE Software, 17(3):37–43, 2000. 11. J. G. Hall and L. Rapanotti. Problem Frames for Socio-Technical Systems. In J. Mate and A. Silva, editors, Requirements Engineering for Socio-Technical Systems. Idea Group, Inc., 2004. 12. J. Hammond, R. Rawlings, and A. Hall. Will it work? In The proceedings of the 5th IEEE International Symposium on Requirements Engineering., 2001. 13. S. Harker, K. Eason, and J. Dobson. The change and evolution of requirements as a challenge to the practice of software engineering,. In In Proceedings IEEE International Symposium Requirements Engineering, San Diego, CA, USA., 1993. 14. P. J. M. P. K. Haumer, P.and Heymans. Bridging the gap between past and future in re: a scenario-basedapproach. In Requirements Engineering, 1999. Proceedings. IEEE International Symposium on, pages 66–73, 1999. 15. P. Henderson. Software processes are business processes too. In Proceedings of the Third International Conference on the Software Process, 1994. ’Applying the Software Process’, pages 181–182. Dept. of Electron. and Comput. Sci., Southampton Univ., 10-11 Oct 1994. 16. A. Highsmith, J.; Cockburn. Agile software development: the business of innovation. Computer, 34(9):120 – 127, 2001. 17. V. Hlupic and S. Robinson. Business process modelling and analysis using discreteevent simulation. In WSC ’98: Proceedings of the 30th conference on Winter simulation, pages 1363–1370, Los Alamitos, CA, USA, 1998. IEEE Computer Society Press. 18. M. Jackson. Problem Frames: Analysing and Structuring Software Development Problems. Addison Wesley, 2000. 19. M. A. Jackson. Problem Frames: Analyzing and Structuring Software Development Problem. Addison-Wesley Publishing Company, 1st edition, 2001. 20. M. Jarke. Requirements tracing. Commun. ACM, 41(12):32–36, 1998. 21. C. Jones. Variations in software development practices. Software, IEEE, 20(6):22– 27, 2003. TY - JOUR. 22. T. Katayama, T. Tamai, and N. Yonezaki. Principles of software evolution. In Proceedings of the International ISPSE 2000 Japan. IEEE inc., 2000. 23. J. L. Mate and A. Silva, editors. Requirements Engineering for Socio-Technical Systems. Information Science Publishing, 2005.

24. J. Mylopoulos, M. Kolp, and J. Castro. Uml for agent-oriented software development: The tropos proposal,. In Proceedings of the Fourth International Conference on the Unified Modeling Language UML 01 - Toronto, Canada,, 2001. 25. N. Nurmuliani, D. Zowghi, , and S. Williams. Using card sorting technique to classify requirements change. In Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), Kyoto, Japan, September 2004, 2004. 26. B. Nuseibeh, S. Easterbrook, and A. Russo. Leveraging inconsistency in software development. Computer, 33(4):24–29, 2000. TY - JOUR. 27. J. O’Neal and D. Carver. Analyzing the impact of changing requirements. In Proceedings of the IEEE International Conference on Software Maintenance, pages 190 – 195, 2001. 28. E. Paolucci, F. Bonci, and V. Russi. Redesigning organisations through business process re-engineering and object-orientation. In Proceedings of the European Conference on Information Systems, pages 587–601, Cork, Ireland, 1997. 29. M. Porter. Competitive Advantage:Creating and sustaining superior performance,. Free Press, 1985. 30. L. Prusak. The knowledge advantage. Strategy and Leadership, 24(2):6–8, 1996. 31. S. Robertson and J. Robertson. Mastering the Requirements Process. Addison Wesley, Harlow, England., 1999. 32. R. Stacey. Strategic Management and Organisational Dynamics. Prentice Hall., 2003. 33. K. Tumay. Business process simulation. In A. A., K. K., and L. W. G. D., editors, Proceedings of the WSC’95 - Winter Simulation Conference, pages 55–60, Washington DC, USA, 1995. 34. A. van Lamsweerde. Goal-oriented requirements engineering: A guided tour. In Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE2001), pages 249–263, Toronto, 2001. 27–31 August 2001. 35. K. E. Weick. Sensemaking in Organisations. Thousand Oaks, Calif. Sage Publications, 1995. 36. R. Weiringa, J. Gordijn, and P. van Eck. Value framing: A prelude to software problem framing. pages 75–84, Edinburgh, 2004. IEE. 24 May 2004. 37. E. S. Yu. Modeling organizations for information systems requirements engineering. In Proceedings 1st IEEE International Symposium on Requirements Engineering, pages 34–41, 1993. 38. P. Zave. Classification of research efforts in requirements engineering. ACM Computing Surveys (CSUR), 29(4):315 – 321, 1997.