ENTERPRISE INFRASTRUCTURE PLANNING

Modelling and Simulation Using the Problem Articulation Method

Simon Tan, Kecheng Liu

Informatics Research Centre, University of Reading, Whiteknight, Reading, RG6 6AY, UK

Keywords: Enterprise Infrastructure Planning, Enterprise Modelling, Simulation, Problem Articulation

Abstract: Current systems development costs rise almost exponentially as development time increases, underlining the

importance of effective project management and enterprise planning. Enterprise infrastructure planning

offers an avenue to efficiently improve and shorten design time; and to develop a system of high quality and

with considerably lower operating and development costs. The Problem Articulation Method (PAM) is a

method for articulating business and technical requirements in an organisation. It is capable of assimilating

the internal systems changes in response to the dynamics and uncertainties of the business environment. The

requirements and specifications from this analysis constitute as a baseline for managing changes, and

provide the mechanism by which the reality of the enterprise and its systems can be aligned with planned

enterprise objectives. An illustration of planning and development of a procurement system will be used to

demonstrate the enterprise infrastructure requirements using a discrete-event enterprise simulation package

“Enterprise Dynamic”. This paper will examine the capability of PAM in the articulation and simulation of

complex enterprise requirements.

1 INTRODUCTION

The evolving business environment has caused a

paradigm shift in the way business operates. The

traditional business paradigm has changed

significantly with the integration of IT, business and

organisational systems. This transformation has

accelerated in response to the evolution and

globalisation of information and communication.

Unlike the business view of the old, which focused

on a one dimensional business domain, today’s

enterprise paradigm is dynamic and multi-

dimensional. It is more crucial then ever for

enterprise to remain agile and to integrate seamlessly

across the technical, business and organisational

functions. Enterprise infrastructure planning can be

used to adequately address the evolution of

requirements and the convoluted behaviours of the

enterprise.

Enterprise engineering as defined by Liles and

esley (1996) is referred to as the body of

knowledge, principles, and practices having to do

with the analysis, design, implementation and

operation of an enterprise. It uses a multi-

disciplinary engineering approach for analysis,

design, and implementation of enterprises. For

enterprise engineering to be effective it has to

address three fundamental issues. Firstly, the ability

to capture complex enterprise requirements and its

evolving needs. Secondly, the capability to embed

organisational behaviours in the enterprise

‘conceptual’ model. And thirdly, the ability to

incorporate and translate the enterprise model into

simulation software for the purpose of analysis and

validation.

An enterprise model is a dynamic representation of a

usiness organisation, in which activities, processes,

relationships, constraints, information, resources,

people, behaviour and goals are modelled. It must

therefore be able to represent organisational

behaviours and reflect the diverse enterprise

requirements. Tan and Liu (2004) have identified the

weakness of information requirements, attributing it

to the inability of requirements engineering to elicit

complex organisational behaviours. The dynamics of

process, however, cannot be sufficiently expressed

using either linear computation or graphical

representation alone, which is unfortunately still in

practice by many modellers. The existing problems

with most modelling method can be attributed to the

following reasons:

240

Tan S. and Liu K. (2005).

ENTERPRISE INFRASTRUCTURE PLANNING - Modelling and Simulation Using the Problem Articulation Method.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 240-245

DOI: 10.5220/0002519802400245

 SciTePress

• Lack of a comprehensive method to describe

and valuate the stakeholders’ feedback.

• Emphasis placed on hierarchical

decomposition of a system without placing

analysis of other related systems that form an

integral part of the organisational

infrastructure.

• Scalability is difficult, and often incompetent

in addressing the different levels of

enterprise modelling.

• Difficulty in estimating project resources

such as time, cost, and expertise in a

dynamic manner.

• Problem in integrating the diverse functions

of business and IT infrastructure within the

organisation.

This paper proposes an enterprise infrastructure

model, and examines the capability of Problem

Articulation Method (PAM) in the articulation of

problem situation, using simulation for analysis and

validation. Section 2 describes the integration of

enterprise model with simulation model. Section 3

highlights the problems associated with enterprise

modelling methods and explains how PAM may be

used to address these issues. Section 4 provides an

illustration of the collateral structuring technique

and explains how simulation model can be used for

enterprise requirements analysis and validation.

Finally, Section 5 concludes the paper with findings

and further work.

2 INTEGRATING ENTERPRISE

MODEL TO SIMULATION

In traditional simulation model building, the

simulation software application acts as a model

development environment. The simulation

development environment is a non-specific

modelling environment that supports an infinite

variety of modelling problem situations. It is

precisely this characteristic of modelling, with its

infinite scenario that makes enterprise simulation

extremely difficult. The simulation-based

application is likely to adopt different functions to

model the different aspects of an enterprise.

Enterprise infrastructure planning (EIP) model

(Figure. 1) provides a high-level model using PAM

for the capture of enterprise requirements using a

generic discrete-event simulation environments, and

the associated requirements of the model functional

layers as the basis for organisational simulation

standard. The requirements places upon this

software program allows the attributes to be

embedded within the simulation applications and are

therefore a better representation of the ‘real’

organisation, as oppose to one where the

requirements and attributes of the system are pre-

determine by the users. EIP uses PAM as an

enterprise model for assimilating the internal

systems changes in response to the dynamics of

enterprise requirements. The requirements elicited

from the enterprise must be able to interpret the

attributes directly from the modelling method.

The simulation model thus needs to provide the

attributes and parameters of human and software

agents to correctly model the enterprise. This

requires an interface, which could seamlessly

translate between the conceptual model and the

simulation software. Aalst (1990) realises the crucial

need to model the specification of concurrent and

dynamic systems, and has developed a framework

with a modelling language called ExSpect, which

serves to describe and simulate business processes

using discrete event systems. ExSpect is executable

in application and thus design for prototyping and

simulation modelling.

Enterprise Dynamic (Enterprise Dynamics 2003) is

an object-oriented software program for discrete-

event simulation to model, simulate, visualise and

control dynamic processes. This software is

designed for enterprise modelling where the user can

use the 4D-script programming language to create

and customise the conceptual model. It allows a

predefined set of simulation objects referred to as

‘atoms’ and statistical distributions to create the

model. Current simulation software provides the

tools to model the ‘real world’, but do not provide

methods for modelling specific entities of the

systems.

Conceptual

Modelling

Enterprise ‘Conceptual’

Model

Enterprise

Specification

Simul ation

Simul ation Model

Simul ation

Specification

Control, Activation,

Sequencing,

Patterns

Modelling Entities

Relationships, Concepts

Problem (PAM)

Articulation Method

PAM Techniques

-Unit Definition

-Stakeholder Analysis

-Collateral Structuring

-Organisational Containment

-Valuation Framing

Soci al

Technical

Business

Organi sat ion

Domai n

Conceptual

Mo del

Si mul at i on

Mo d el

Organisation Model

Ma ppi ng

Ma p pi n g

Req uir ements

Elicitation

Refi n ement

Enterprise Infrastructure

Enterprise Modelling

Ent e r p r i s e

Req uir emen t s

Validation

Figure 1: Enterprise Infrastructure Planning Using

PAM and Simulation

Conceptual

Modelling

Enterprise ‘Conceptual’

Model

Enterprise

Specification

Simul ation

Simul ation Model

Simul ation

Specification

Control, Activation,

Sequencing,

Patterns

Modelling Entities

Relationships, Concepts

Problem (PAM)

Articulation Method

PAM Techniques

-Unit Definition

-Stakeholder Analysis

-Collateral Structuring

-Organisational Containment

-Valuation Framing

Soci al

Technical

Business

Organi sat ion

Domai n

Conceptual

Mo del

Si mul at i on

Mo d el

Organisation Model

Ma ppi ng

Ma p pi n g

Req uir ements

Elicitation

Refi n ement

Enterprise Infrastructure

Enterprise Modelling

Ent e r p r i s e

Req uir emen t s

Validation

ENTERPRISE INFRASTRUCTURE PLANNING - Modelling and Simulation Using the Problem Articulation Method

241

3 THE PROBLEM

ARTICULATION METHOD

Probably the most difficult tasks in designing and

building a discrete-event simulation models is in

addressing the ambiguity and defining the scope of

the system. The modeller must explicitly translate

the ‘real’ system into an abstract system-of-entities,

interactions-between-entities, and entities

interactions-with-system environment. A modeller

who desire to create an abstract representation of

processes has three possible options: (1) build a

detailed model to capture actual problem situation,

(2) comprehensive modelling to capture the specific

aspects of processes, or (3) operation through a

process model “black box”. A modeller will make

the “level of detail” decision based his discretion on

whether he deems that additional detail will

significantly affect the output statistics he is

attempting to model.

The Problem Articulation Method was designed for

the analysis and planning of enterprise infrastructure

developed by Stamper and his colleagues (Stamper

et al. 1988, Kolkman 1993), based on organisational

semiotics (Stamper 1993, Liu 2004) offers an

effective means for enterprise modelling. PAM

addresses the complex organisational issues and

provides for the cost-benefit analysis, project

management and project planning. It facilitates the

co-design of business and IT systems by identifying

relevant agents, eliciting the domain language and

valuate stakeholders’ feedback to uncover the gross

architecture of the enterprise. Liu and Sun (2002)

highlighted the importance of the co-design of

business and IT systems, which facilitate the

evolution of information systems.

Collateral structuring, one of the PAM techniques is

concerned with the definition of unit systems that

forms the constellation or supporting structure of the

focal system. A focal system can be broadly defined

as a kernel that revolves around the problem

situation (Checkland 1981). The collateral systems

(Figure 2) are systems that surround the focal

system. Collateral analysis helps to place the focal

system in its context and uncovers the infrastructure

in which the focal system fulfils its functions. The

method provides structure and will reveal the

incompleteness of the infrastructure. It is possible to

configure these structures as cycles. The method

provides a guide to safeguard against

inconsistencies, incompliant and incompleteness of

the infrastructure. Collateral structuring forces the

analyst to focus on the structure in relation to the

overall system intervention and to consider

scenarios, which include external environments e.g.

suppliers process, economy, demand and supply.

Output

Environment

Backup

Recovery

Focal System

Successor

Predecessor

Description

Terminating

Launching

Available System

Dismantling

Constructing

Maintenance

Resources

Input

Fallback

Constructing Cycle

Launching Cycle

Backup Cycle

Operating Cycle

Output

Environment

Backup

Recovery

Focal System

Successor

Predecessor

Description

Terminating

Launching

Available System

Dismantling

Constructing

Maintenance

Resources

Input

Fallback

Constructing Cycle

Launching Cycle

Backup Cycle

Operating Cycle

Figure 2: Collateral Structuring Model

In technological innovation, the

focal system starts

as a new technical ‘

system-in-operation’. But before

the system can be installed to serve the organisation,

it must first be available and launch from the

launching System; which periodically needs to be

taken down for maintenance or repair. The

focal

system will eventually have to be taken down via

the

Terminating System, when the system-in-

operation

is no longer required. However, before

this takes place, the system must be switched off-

line for it to be used/re-used as an

available system.

The new system will then be constructed from the

Resources; and at the end of the lifecycle of the focal

system

, it will be dismantled (refer to the

Construction Cycle in figure 2). In the operation of

the

Focal System, a Backup System is usually

required in the event of system breakdown, where

the system can be switch to

Backup System with the

help of the

Fallback system. Once the focal system is

repaired and launched, the Recovery system can

switch the operation back from the

Backup system

to the

Focal system.

4 MODELLING A

PROCUREMENT SYSTEM

USING COLLATERAL

ANALYSIS

Purchasing and procurement represent different

processes, although people tend to use the words

interchangeably. Purchasing refers to the actual

buying of materials and activities associated with the

buying process, which focused on generating, and

processing orders. In this paper we define

procurement to include both human procedures and

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

242

IT systems functions. It is especially testing in the

acquisition of hardware and software Information

Technology (IT) sector, where there are many

suppliers and a wide variety of products and

services. The purchaser has to select the best

options by collating product availability and price

information from different sources, and then

acquires the lowest price product, which meets the

requestor needs through a series of selection

procedures.

Focal System

The focal system “procurement” represents the core

operation that provides services for the entire

organisation. At the inception of the system only the

central functions to be performed have to be given

attention. The focal system will have a start and

finish lifespan. The size of the focal system at this

stage is not significant, but a larger size will entail a

complex internal structure.

PAM addresses the planning of focal and collateral

systems (Figure 3), the attributes in the template

captures the resources and time required for building

each unit system. These attributes describe the

behaviours of the systems.

Figure 3: Procurement system and its collateral

Systems

The unit system template (Table. 1) defines the

objectives, stakeholders (skill-set, staff number,

responsibilities and estimated operating costs) of the

focal unit. The unit system templates also define the

unit system, objectives and comments on each

collateral unit.

Model Mapping

The process of developing a conceptual model and

attempting to represent this in the simulation

software has made a significant contribution towards

understanding the procurement process. The

conceptual model for simulation must address the

simulation’s context and how the entities and

relationship will be represented. It have to address

the issue of (1) assessing a simulation’s validity for

situation not explicitly tested and (2) determining the

appropriateness of a simulation (or its parts) for

reuse or use with other simulations. There are

currently no de-facto standards or approaches for

abstracting representation or translating the

conceptual model into the simulation model. It is

crucial to map the entities and relationship with the

aim of describing and documenting the conceptual

model, which must be incorporated in the simulation

model.

Specifying Simulation Requirements Using

Collateral Structure

Collateral structure provides a supporting framework

within the enterprise model. It forces practitioner to

consider systematically the overall enterprise

‘conceptual’ model, specifying the architecture

requirements. The unit system is not analysed in

isolation but within the collateral life cycle, which

explicitly define the behaviours of entities and its

relationship in relation to the overall system

intervention. The enterprise requirements elicited

from PAM are directly applicable for use in the

implementation of simulation model, ‘atoms’ in the

enterprise dynamics software.

Acquisition of S/Ware

& H/Ware product

Social/Legislature, Technology,

Systems compatibility

Contact vendor, direct action,

By users dept - purchase

Revert to Procurement

System

Procurement System

EU Standard

compliant

Non-Standard

compliant

Procurement of clients technological

& informational Requirements

Decommission Procurement

System

Commission of

Procurement System

Vendor contacts, price list,

Corporate account privileges

Scrape Procurement System

Establish policies, regulations

Standards, Procedures

Best practice / Code of conduct

Company regulations and policies, Consultants,

information database, Technological specifications

Clients

Requir ements

Notification of delays/

breakdown

Constructing Cycle

Launching Cycle

Backup Cycle

Operating Cycle

Acquisition of S/Ware

& H/Ware product

Social/Legislature, Technology,

Systems compatibility

Contact vendor, direct action,

By users dept - purchase

Revert to Procurement

System

Procurement System

EU Standard

compliant

Non-Standard

compliant

Procurement of clients technological

& informational Requirements

Decommission Procurement

System

Commission of

Procurement System

Vendor contacts, price list,

Corporate account privileges

Scrape Procurement System

Establish policies, regulations

Standards, Procedures

Best practice / Code of conduct

Company regulations and policies, Consultants,

information database, Technological specifications

Clients

Requir ements

Notification of delays/

breakdown

Constructing Cycle

Launching Cycle

Backup Cycle

Operating Cycle

Table 1: Unit system template

Focal System (Procurement IT System)

GOAL: TIME:

UNIT SYSTEM Start Date: 01-05-04

Procurement System in Operation End Date: 05-07-04

OBJECTIVE

Duration : 65days

1) Procurement of Software/Hardware/Services MTBF : 150days

2) Satisfy client requirements MTTR : 5 hours

3) Obtain product/services at best value FIFO/LIFO/Batch: Batch

4) Meet Procurement criteria Trigger(s) : Input (On Entry)

Import format: Requisition form

ROLES/RESPONSIBILITIES:

Stakeholders Skill-Sets #Staffs Responsibilities

Procurement Manager PAM method 2 Authorise and allocate projects

Procurement Supervisor ERP 3 Manage project

Consultant IT & Procurement 2 Consultancy services (integration)

Programmer C++ 4 Programming

COSTS:

Estimated Expenses:

(1) Programmer = £12 per/hr X4 person = £ 48per/hr [7x48x74=£24,864]

(2) Consultant = £100 per/hr X2= £200 per/hr [7x200x74=£103,600]

(3) Procurement Manager = £40per/hr X2 = £80 per/hr [7x80x74=£41,440]

(4) Procurement Supervisor = £30 per/hr X3= £90 per/hr [7x90x74=£46,620]

Total (Focal) Operating Costs £216,524

Actual Expenses £198,000

Balance (Surplus/Deficit) £ 18,524

INFORMATION:

Questions: 1) What is the required input for the system?

2) How should the input be presented?

3) What is the quality or quantity of input?

4) What are the alternative source of input?

Checklists: 1) Organisational policies?

2) Departmental budget?

3) Governmental laws?

Deliverables: 1) Lists of documents?

2) Work flow diagrams

3) Contracts (warranty)

Focal System (Procurement IT System)

GOAL: TIME:

UNIT SYSTEM Start Date: 01-05-04

Procurement System in Operation End Date: 05-07-04

OBJECTIVE

Duration : 65days

1) Procurement of Software/Hardware/Services MTBF : 150days

2) Satisfy client requirements MTTR : 5 hours

3) Obtain product/services at best value FIFO/LIFO/Batch: Batch

4) Meet Procurement criteria Trigger(s) : Input (On Entry)

Import format: Requisition form

ROLES/RESPONSIBILITIES:

Stakeholders Skill-Sets #Staffs Responsibilities

Procurement Manager PAM method 2 Authorise and allocate projects

Procurement Supervisor ERP 3 Manage project

Consultant IT & Procurement 2 Consultancy services (integration)

Programmer C++ 4 Programming

COSTS:

Estimated Expenses:

(1) Programmer = £12 per/hr X4 person = £ 48per/hr [7x48x74=£24,864]

(2) Consultant = £100 per/hr X2= £200 per/hr [7x200x74=£103,600]

(3) Procurement Manager = £40per/hr X2 = £80 per/hr [7x80x74=£41,440]

(4) Procurement Supervisor = £30 per/hr X3= £90 per/hr [7x90x74=£46,620]

Total (Focal) Operating Costs £216,524

Actual Expenses £198,000

Balance (Surplus/Deficit) £ 18,524

INFORMATION:

Questions: 1) What is the required input for the system?

2) How should the input be presented?

3) What is the quality or quantity of input?

4) What are the alternative source of input?

Checklists: 1) Organisational policies?

2) Departmental budget?

3) Governmental laws?

Deliverables: 1) Lists of documents?

2) Work flow diagrams

3) Contracts (warranty)

ENTERPRISE INFRASTRUCTURE PLANNING - Modelling and Simulation Using the Problem Articulation Method

243

Triggers

The collateral analysis template uses three types of

triggers, that is congruent to the Enterprise Dynamic

input parameters:

1) trigger on creation, 2)

trigger on entry and 3) trigger

exit. The collateral structure triggers regulate

and facilitate control over the activation, sequencing

and timing of the different events. The model

operates as an integrated sub-system, using a

dependency-linked mechanism within the business

processes.

Simulation Model

The procurement simulation model incorporates the

enterprise requirements from PAM. The building of

the simulation models will take a significant step

forward in supporting project plan and control

activities. This is made possible with better scoping

and reduction of ambiguity in the requirements of

enterprise infrastructure planning. It also provides

for a finer level of granularity and utilising lower-

level of requirements elicited from the enterprise.

The information from PAM will adequately guide

and provide the users with the information needed to

model a system that considers time, resources,

schedules, expertise and possible eventualities. The

properties of a unit system described in the unit

system template Table 1 will form as inputs to the

simulation model.

The repository of information templates, life cycle

structure and control, enable the modeller to

translate the requirements and specifications attained

from PAM to be used in the simulation model,

which can be easily interpreted by Enterprise

Dynamics. The attributes includes: MTBF, MTTR,

MTTF, FIFO, LIFO, Batch or Real-time system. The

mean-time-between-failure (MTBF) is equal to the

sum of the mean-time-to-failure (MTTF) and the

mean-time-to-repair (MTTR). FIFO (first-in, first-

out) and LIFO (last-in, first-out) is an approach to

handle program work requests from queues or

stacks. The attributes of agent’s behaviours within

the enterprise model are elicited from the PAM

specification, which includes the cycle-time,

products number and unit-capacity. The

organisational behaviours will be embedded into the

simulation model to reflect the behaviours and

characteristics of all the agents.

All systems are subjected to periodical breakdown

and down-time for maintenance, either online or

offline. The conditions or properties to calculate

approximate repair time or system downtime enables

the system to factor in eventualities in the simulation

of a ‘real’ environment. Collateral analysis as such

can provide a comprehensive set of properties and

structure needed for this purpose, which could be

entered directly into the simulation software. Based

on the PAM model requirements, a simulation

model can be created using the simulation package

provided by Enterprise Dynamics. The

determination of the business process of the

procurement cases is a result of selection, timing and

description of agent’s behaviour. In the simulation

model (Figure 4) the ‘source atom’ is the first

element created in the procurement model. The

‘source atom’ then sequences the products for entry

into the model at a pre-determined rate into the

Specifications process. ‘Specifications’ is the second

object created, which is a ‘server atom’. The server

atom is use to model the operations of parameters

such as triggers e.g. trigger-on-creation, trigger-on-

entry or trigger-on-exit, MTTF, MTTR and Cycle-

time. It generates the output (processing time) which

is illustrated in Figure 4 at 100% utilisation rate.

Figure 5. Simulation model for procurementFigure 5. Simulation model for procurement

Figure 4: Simulation procurement.

Next, the ‘queue atom’ places the procurement

request, in the Procurement queue and assigned

priorities to it. In the IT procurement system, there

are three procurement channels: 1) In-house

development (79.5%); 2) Outsourcing (79.7%); and

3) Software acquisition (80.2%). Prior to the channel

selection, the product will go through the norm-

specification or business rules, where a series of

rules will be checked to determine the option it

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

244

should take next, either queue 1, 2 or 3. Next the

central customer department handles the process of

procurements, operating at an utilisation rate of

99.7% and 99.7% respectively. Both teams upon

completion will hand the request ‘product’ to the

acquisition process for accrue of total output (2535)

produced by the procurement process.

5 CONCLUSION

This paper presents the concept, method and

techniques of PAM which allows simulation

software to be constructed within a well-defined

interface that can be easily embedded in the

Enterprise Dynamics simulation software. PAM is

an enterprise modelling method, which uses the

semiotic approach for enterprise requirements

engineering. Empirical studies in organisational

modelling have shown conclusively the importance

of social-technical, business and organisational

systems in modelling an organisation. This paper

makes a case for further research and development

in the next-generation of enterprise modelling for

simulation model. PAM is well equipped to meet

most of the enterprise requirements, which other

prominent methods do not adequately address in the

capturing of enterprise infrastructure and agents

behaviour modelling. The central problem addressed

by PAM, is to provide the modellers with

information about the organisation, but how it could

be use collaboratively with the simulation software

for analysis and validation. More importantly it

allows users to explicitly define the social-technical

context of the system, and how they can be

expressed unequivocally. By providing the

intellectual tools for these tasks, which should

empower analysts to correctly capture the

organisations requirements and therefore be able to

model the complex and evolving enterprise

requirements.

ACKNOWLEDGEMENT

This research is partly supported by EPSRC –

SEDITA project GR/S04840/01.

REFERENCES

Aalst, W. & A. Waltmans 1990. Modelling Flexible

Manufacturing Systems with EXSPECT. In B.

Schmidt, editor,

Proceedings of the European

Simulation Multiconference

, Nürnberg, Simulation

Councils Inc. pp. 330-338.

Bhaskar, R., H. S. Lee., A, Levas., R, Petrakian., F, Tsai.,

and B, Tulskie 1994. Analysing and Re-engineering

Business Processes Using Simulation. In the

proceedings of Winter Simulation Conference, Lake

Buena Vista, FL, USA, pp. 1206-1213.

Checkland, P. 1981. Systems Thinking, Systems Practice,

John Wiley & Sons, Chichester.

Enterprise Dynamics. 2003. Simulation Software Tutorial,

In control Enterprise Dynamics, The Netherlands.

Kolkman, M. 1993. Problem Articulation Methodology,

PhD thesis, University of Twente, Febo, Enschede,

ISBN 90-9005972-5.

Liles, D. H. & A. Presley 1996. Enterprise Modeling

within an Enterprise Engineering Framework. Winter

Simulation Conference, Coronado, CA, Association

for Computing Machinery.

Liu, K. 2000. Semiotics in Information Systems

Engineering, Cambridge University Press, Cambridge

UK.

Liu, K. 2004. Virtual, Distributed and Flexible

Organisations - Studies in Organisational Semiotics,

Kluwer Academic Publishers.

Liu, K., L. Sun and K. Bennett 2002. Co-Design of

Business and IT Systems – Introduction by Guest

Editors. Information Systems Frontiers, Vol. 4, No. 3,

pp. 251-256.

Stamper, R., K. Liu., L. Sun., S. Tan., H. Shah., B. Sharp.

and D. Dong 2004. Semiotic Methods for Enterprise

Design and IT Applications, Proceeding of the 7th

International Workshop on Organisational Semiotics.

Stamper, R. 1993. Social Norms in Requirements Analysis

– An Outline of MEASUR. In Jirotka, M., Goguen, J.

& Bickerton, M. (eds.), Requirements Engineering,

Technical and Social Aspects. Academic Press, New

York.

Stamper, R., K. Althaus. and J. Backhouse 1988.

MEASUR: Method for Eliciting, Analysing and

Specifying User Requirements. In Olle, T. W.,

Verrijn-Stuart, A. A. and Bhabuts, L., (eds.)

Computerised Assistance During the Information

Systems Life Cycle. Elsevier Science, Amsterdam, pp.

67-116.

Tan, S. & K. Liu 2004. Requirements Engineering for

Organisational Modelling, Proceedings of the 6th

International Conference on Enterprise Information

Systems (ICEIS). Portugal, Vol. 3, pp.383-388.

ENTERPRISE INFRASTRUCTURE PLANNING - Modelling and Simulation Using the Problem Articulation Method

245