event syndication – requirements specification for linked event diaries

8/14/2019 Event Syndication Requirements Specification For Linked Event Diaries

1/203

CRANFIELD UNIVERSITY

PETER J LOUIS

EVENT SYNDICATION: REQUIREMENTS SPECIFICATIONFOR LINKED EVENT DIARIES

SCHOOL OF INDUSTRIAL AND MANUFACTURING SCIENCE

MSc THESIS


2/203


3/203

CRANFIELD UNIVERSITY

SCHOOL OF INDUSTRIAL AND MANUFACTURING SCIENCE

MSc THESIS

Academic Year 2002-2003

PETER J LOUIS

Event Syndication: Requirements Specificationfor Linked Event Diaries

Supervisor: Associate Professor Steven Cousins

September 2003

This thesis is submitted in partial fulfilment of the requirementsfor the degree of Master of Science

Cranfield University 2003. All rights reserved. No part of this publication may bereproduced without the written permission of the copyright owner.


4/203


5/203

ABSTRACT

In the knowledge driven economy, organisational learning and business networking

time is crucial yet scarce and these resources need to be employed more efficiently to

maximise business benefits. To achieve this, organisations and individuals need

access to information on learning and networking opportunities that are not only

available within their cluster but also specific to their individual needs.

However, with the growth of stakeholders (businesses, organisations and individuals)

and the parallel growth of information to meet stakeholder needs, the current delivery

mechanisms are neither efficient nor effective at disseminating information to

stakeholders. Moreover, the same networks that seek to encourage networking and

collaboration, work, for the most part, uncollaboratively.

To address these shortcomings, information was elicited from 12 firms, organisations

and groups within the cluster communities of Bedfordshire and the Oxford-Cambridge

Arc to develop the requirements for a Linked Event Diaries system (LED) that would

improve the infrastructure for disseminating information about events that were relevant

to stakeholders within a cluster.

The Volere Requirements Process provided a set of 26 requirements categories that

allowed the behaviour of the LED to be fully specified. Requirements were

documented using the UML and English language statements.


6/203

DEDICATION

Para Antonia por tu amor, paciencia y por ser mi amiga. Te amo

A mes parents et mes soeurs qui mon amanene ici


7/203

EPIGRAPH

To generalize is to be an idiot. To particularize is the alone distinction of merit.General knowledges are those knowledges that idiots possess

William Blake, Discourses


8/203

ACKNOWLEDGEMENTS

Firstly, I would like to thank the Bedford Development Agency for sponsoring my

research and, in particular, Dr Mathew Cook for his support and contributions during

the project. Thank you.

Next, I would like to thank the organisations and employees that I have met during thisproject. However, I would like to thank especially all those employees who have

contributed directly towards my findings. No doubt, without their help, my research and

thesis would be incomplete.

I would also like to give a special mention to Kate Turabian. Although deceased, she

lives on through the excellent advice that she has given and still gives to students.

Lastly, but by no means least, I would like to thank my supervisor, Dr Steven Cousins.His advice, patience, enthusiasm and commitment throughout this project have been

invaluable. Thank you.


9/203

ix

LIST OF CONTENTS

LIST OF FIGURES __________________________________________________ xivLIST OF TABLES ____________________________________________________xvLIST OF ABBREVIATIONS ___________________________________________ xviINTRODUCTION______________________________________________________1

1.1 Introduction_________________________________________________________ 11.2 Cluster Economic Development ________________________________________ 11.3 Nurturing Cluster Development ________________________________________ 31.4 The Problem ________________________________________________________ 51.5 A Solution __________________________________________________________71.6 Structure of the Thesis _______________________________________________ 9

LITERATURE REVIEW________________________________________________ 112.1 Introduction________________________________________________________ 112.2 Characteristics of a Cluster___________________________________________ 122.3 The Economic Benefits of Clusters ____________________________________ 14

2.3.1 Regions of Competitiveness ________________________________________________142.3.2 Regions of Co-operation ___________________________________________________152.3.3 Regions of Learning_______________________________________________________15

2.4 Turning Clusters into Learning Regions ________________________________ 172.4.1 Institutions ______________________________________________________________172.4.2 Regional Support Initiatives _________________________________________________18

2.5 Summary __________________________________________________________ 24METHODOLOGY ____________________________________________________ 26

3.1 Introduction________________________________________________________ 263.2 Steps in Requirements Engineering____________________________________ 273.3 Considerations during the Elicitation Process ___________________________ 283.4 Risks during the Elicitation Process ___________________________________ 29

3.4.1 Human Dimensions _______________________________________________________293.4.2 Cultural and Organisational Dimensions _______________________________________313.4.3

Technical Dimensions _____________________________________________________32


10/203

x

3.5 Requirements Elicitation Techniques __________________________________ 333.5.1 Questionnaire Interviews ___________________________________________________ 333.5.2 Open-ended Interviews ____________________________________________________333.5.3 Scenarios_______________________________________________________________35 3.5.4 Prototyping______________________________________________________________36 3.5.5 Joint Application Development_______________________________________________373.5.6 Soft Systems Methods _____________________________________________________ 373.5.7 Observation and Social Analysis _____________________________________________38

3.6 Requirements Methods ______________________________________________ 393.6.1 Data Flow Modelling_______________________________________________________393.6.2 Structured Analysis and Design Technique (SADT)_______________________________403.6.3 Object-Orientated Analysis and Design (OOAD) _________________________________ 423.6.4 Formal Methods __________________________________________________________ 44

3.7 Summary __________________________________________________________ 47DATA COLLECTION _________________________________________________ 48

4.1 Introduction________________________________________________________ 484.2 Understanding the Domain ___________________________________________ 49

4.2.1 Stakeholders ____________________________________________________________494.2.2 Events and Networking ____________________________________________________514.2.3 Event Syndication ________________________________________________________55

4.3 Work Context ______________________________________________________ 574.4 Collecting Data _____________________________________________________ 58

4.4.1 Analysing the Data Requirements ____________________________________________584.4.2 Strategising Data Collection_________________________________________________594.4.3 Collecting and Validating Data_______________________________________________614.4.4 Specifying Requirements ___________________________________________________ 62

4.5 Summary __________________________________________________________ 65STAKEHOLDER EVENT ANNOUNCEMENT ______________________________ 66

5.1 Introduction________________________________________________________ 665.2 Bedford Development Agency ________________________________________ 675.3 Central Innovation Network___________________________________________ 685.4 Cranfield University Technology Park __________________________________ 695.5 Cranfield University _________________________________________________ 705.6 Knowledge Hub ____________________________________________________ 72


11/203

xi

5.7 Unilever R&D Colworth ______________________________________________ 745.8 Summary __________________________________________________________ 75

DEVELOPING THE REQUIREMENTS FOR THE LED _______________________ 766.1 Introduction________________________________________________________ 766.2 Gathering Requirements from Initial Stakeholders _______________________ 776.3 Partitioning the Work ________________________________________________ 836.4 Identifying the Product Boundary _____________________________________ 856.5 Gathering Requirements from the wider Stakeholder Group _______________ 886.6 Summary _________________________________________________________ 103

DISCUSSION ______________________________________________________1047.1 Project Methodology _______________________________________________ 1047.2 Limitations of the LED Specification __________________________________ 1057.3 Recommendations for Further Research ______________________________ 106

CONCLUSION______________________________________________________ 1088.1 Conclusions ______________________________________________________ 108

REFERENCES _____________________________________________________110APPENDIX A Selected Elicitation Techniques and Requirements Methods__ 117 APPENDIX B Stakeholders and Interviews ____________________________ 120APPENDIX C News and Event Syndication ____________________________ 123APPENDIX D Interview Questions and Background Information __________ 125APPENDIX E Volere Requirements Specification Template_______________ 131 APPENDIX F LED Project Documents ________________________________133APPENDIX G Results & Findings: Interviews and Correspondence ________137Product Constraints ________________________________________________ 141

1.1 Background_______________________________________________________ 1421.2 Goal of the Linked Event Diaries product ______________________________ 1422.1 Sponsor __________________________________________________________ 144


12/203

xii

2.2 Client ____________________________________________________________ 1442.3 Customer_________________________________________________________ 1442.4 Other stakeholders_________________________________________________ 1453.1 Users ____________________________________________________________ 1463.2 User priorities _____________________________________________________ 1484.1 Solution constraints________________________________________________ 1484.2 Implementation environment ________________________________________ 1494.3 Partner applications ________________________________________________ 1494.4 Existing commercial off-the-shelf software_____________________________ 1494.5 Development deadline ______________________________________________ 1494.6 Financial budget ___________________________________________________ 1495.1 Glossary of terms__________________________________________________ 1505.2 Acronyms and abbreviations ________________________________________ 1507.1 General __________________________________________________________ 1517.2 Technical _________________________________________________________ 151

Functional Requirements ____________________________________________1528.1 The Context of the work ____________________________________________1538.2 Work partitioning __________________________________________________ 1538.3 Product boundary__________________________________________________1549.1 Functional requirements ____________________________________________ 157

9.1.1 Record Dispatch Preferences ______________________________________________1579.1.2 Record Receipt Preferences _______________________________________________1589.1.3

Record Events __________________________________________________________159

9.1.4 Dispatch Events _________________________________________________________ 1609.1.5 Record LED Connections__________________________________________________161

9.2 Data requirements _________________________________________________ 162Non-functional Requirements ________________________________________ 163

15.1 Confidentiality_____________________________________________________ 16715.2 File Integrity requirements __________________________________________16715.3

Audit requirements_________________________________________________ 168


13/203

xiii

Project Issues _____________________________________________________16918.1 Regional Infrastructure for Innovation_________________________________ 17019.1 Coldfusion MX ____________________________________________________ 171

Acknowledgements_________________________________________________181List of Contacts ____________________________________________________182Appendix A UML Diagrams _________________________________________ 184


14/203

xiv

LIST OF FIGURES

Figure 1. Diamond of national advantage __________________________________________________2Figure 2. Clusters in Bedfordshire and along the Oxford-Cambridge Arc __________________________ 4Figure 3. Linked Event Diaries System____________________________________________________8Figure 4. Cambridge Network events diary________________________________________________19Figure 5. bFORA event calendar _______________________________________________________20Figure 6. Events calendar for Regional Infrastructure for Innovation ____________________________22Figure 7. DFD context diagram for an ATM problem ________________________________________39Figure 8. First level decomposition diagram for an ATM problem_______________________________ 40Figure 9. SADT notation ______________________________________________________________41Figure 10. SADT context diagram for an ATM problem ______________________________________41Figure 11. SADT First level decomposition for an ATM problem _______________________________42Figure 12. The UML context diagram for an ATM problem ____________________________________43Figure 13. UML Requirements Model for an ATM system ____________________________________44Figure 14. Structure of a Z-schema _____________________________________________________45Figure 15. Event Life Cycle____________________________________________________________ 52Figure 16. Networking Process_________________________________________________________ 53Figure 17. CIN News Item_____________________________________________________________56Figure 18. Work Context for Linked Event Diaries system ____________________________________57Figure 19. Requirements Process_______________________________________________________ 62Figure 20. BDA's "What's New" section __________________________________________________67Figure 21. CIN Event Diary ____________________________________________________________ 68Figure 22. Cranfield University Technology Parks "Latest news" section ________________________69Figure 23. Message of the Day and Diary of events_________________________________________71Figure 24. Knowledge hub's event calendar _______________________________________________73Figure 25. Elaborated Work Context_____________________________________________________81Figure 26. High-level use case diagram for LED____________________________________________85Figure 27. Fully Specified Linked Event Diaries System_____________________________________102Figure 1. Work context ______________________________________________________________153Figure 2. Use Case Diagram for LED ___________________________________________________154

Figure 3. LED Project Tasks __________________________________________________________ 174Figure 4. LED Project Plan ___________________________________________________________175Figure 5. LED Work Breakdown Structure _______________________________________________176Figure A 1. The main diagrams of the UML (used in this thesis)_______________________________119Figure C1. CIN Event _______________________________________________________________123Figure C 2. Observations: CIN event data entry ___________________________________________124Figure D 1. Organisational questions ___________________________________________________125


15/203

xv

Figure D 2. IT & system questions _____________________________________________________126Figure D 3. LED proposal document____________________________________________________130Figure F 1. Student project brief _______________________________________________________133

Figure F 2. BDA project agreement ____________________________________________________135Figure F 3. Open University IoP SETI event______________________________________________136


16/203

xvi

LIST OF TABLES

Table 1. Initial stakeholder interviews ____________________________________________________50Table 2. Event attendance ____________________________________________________________51Table 3. Elements of the Event Life Cycle ________________________________________________54Table 4. Stakeholders for data collection _________________________________________________59Table 5. Elicited information during initial interviews, examples of ______________________________80Table 6. LED control options___________________________________________________________82Table 7. Event list for Linked Event Diaries System _________________________________________84Table 8. Use Case Descriptions ________________________________________________________ 86Table 9. Use case 1: Record Dispatch Preferences _________________________________________86Table 10. Use case 2: Record Receipt Preferences_________________________________________87Table 11. Use case 3: Record Events____________________________________________________87

Table 12. Use case 4: Dispatch Events __________________________________________________87Table 13. Use case 5: Record LED Connections ___________________________________________87Table 14. Event syndication information elicited during wider stakeholder interviews _______________88Table 15. Email syndication information elicited during wider stakeholder interviews________________90Table 16. Frequency information elicited during wider stakeholder interviews _____________________92Table 17. Control information elicited during wider stakeholder interviews________________________ 93Table 18. Usability information elicited during wider stakeholder interviews_______________________ 94Table 19. Requirements for use case 1: Record Dispatch Preferences __________________________96Table 20. Requirements for use case 2: Record Receipt Preferences __________________________97Table 21. Requirements for use case 3: Record Events _____________________________________99Table 22. Requirements for use case 4: Dispatch Events ____________________________________99Table 23. Requirements for use case 5: Record LED Connections____________________________ 100Table 1. Event List for Linked Event Diaries System _______________________________________153Table 2. Use Case Descriptions _______________________________________________________ 156Table A 1. The stages of soft systems methodology________________________________________ 117Table B 1. Stakeholder interviews and meetings during data collection_________________________120Error! No table of figures entries found.


17/203

Chapter 1 Introduction

xvii

LIST OF ABBREVIATIONS

BDA Bedford Development Agency

CIN Central Innovation Network

EEDA East of England Development Agency

F2F Face-to-face

I10 Innovation 10

LED Linked Event Diaries System

MOTD Message of the DayO2C Oxford-Cambridge Arc

RDA Regional Development Agency

RII Regional Infrastructure for Innovation

SMEs Small and medium sized firms

UML The Unified Modeling Language


18/203


1

1 INTRODUCTION

1.1 Introduction

Inspired by the writings of Porter (1990, 1998) and Krugman (1991), there has been an

increasing appreciation of the role that geography plays in the location of industry, and

the benefits and economies that location provides to firms, regions and nations.

In the 1998 White Paper Our Competitive Future Building the Knowledge Driven

Economy, the British government outlined its strategy to reverse a century of relative

economic decline by raising the sustainable rate of growth (Department of Trade and

Industry 1998, p. 6). The government recognised that the global economy had

changed the fundamentals of competition: capital mobility allowed firms to produce in

low-cost countries; technology transfers increasingly occurred between the developed

and developing parts of the world; and goods made in developing countries were being

increasingly shipped to developed ones.

Further, the government acknowledged that in the global economy, the best ways in

which the UK could achieve competitive advantage were through developing UK

competencies1 (Prahalad and Hamel 1990) in knowledge, skills and creativity that were

key to Building the Knowledge Driven Economy.

1.2 Cluster Economic Development

In The Competitive Advantage of Nations, Porter (1990, p. 71) indicated that four broad

attributes shape the environment in which local firms compete that promote or

impeded the creation of competitive advantage (Porter 1990):

1 Firms realise their core competences in core products that form the basis of finished items.

(Prahalad and Hamel 1990)


19/203


2

1. Factor conditions the quantity and quality of productive factors required during

production, such as skilled labour, technology or infrastructure

2. Demand conditions the nature of demand in the domestic market for theproduct or service

3. Related or supporting industries the presence or absence of internationally

competitive supplier or related industries in the domestic economy

4. Firm strategy, structure and rivalry the domestic conditions that dictate how

companies are created, organised and managed, and the competitive forces

that determine industry competition

These attributes form a nations diamond and Porter has contended that nations aremost likely to succeed in industries or industry segments where the diamond is the

most favourable. To complete the framework, Porter added the role of chance (such

as acts of pure invention and war), how it creates discontinuities and shifts the

competitive position, and the role of government (for example, national, regional and

local), how it influences and is influenced by the various attributes of the diamond (see

figure 1).

Firm Strategy,Structure and

Rivalry

Related and

Supporting

Industries

Demand

Conditions

Factor

Conditions

Figure 1. Diamond of national advantage

Source: Porter, M. E. (1990). The Competitive Advantage ofNations. London: Macmillan Press Ltd., pp. 72 & 127


20/203


3

Porter (1990, p. 148) stated that the systemic nature of the diamond promotes the

clustering of a nations competitive industries, and Porter identified two types of

clusters:

Vertical clusters where firms are linked through buyer-supplier relationships

Horizontal clusters in which firms have, for example, common customers,

technology or channels

1.3 Nurturing Cluster Development

Our Competitive Future (Department of Trade and Industry 1998, p. 40) commented

that, Sectorial partnerships, including supply chain initiatives, networking and clusters

play a criticalrole [emphasis mine] in sharing knowledge and upgrading skills among

complementary businesses. The government tasked the Regional Development

Agencies (RDAs) with taking forward many of the proposals outlined in the White

Paper: raising regional skills, encouraging links between business and higher and

further education, working with Business Links to develop regional centres of expertise,

encouraging business collaboration and facilitating the development of clusters(Department of Trade and Industry 1998, p. 42) Initially, the government identified

clusters of critical importance around Cambridge, Oxford and Dundee in which the UK

had European leadership in biotechnology and genome research. Figure 2 illustrates

the clusters (in stars) of firms, organisations and individuals that form communities in

Bedfordshire and along the Oxford-Cambridge Arc.


21/203


4

Figure 2. Clusters in Bedfordshire and along the Oxford-Cambridge Arc

In Planning for Clusters (Office of the Deputy Prime Minister 2000), the government

analysed six clusters. They identified that location and spatial factors were critical to

early cluster development whilst economic and vertical factors (for example, the

operation of a supply chain) were critical to cluster consolidation. However, social and

cultural factors (labour mobility, sharing of information etc [sic]) were said to form the

glue which makes the cluster operational (Office of the Deputy Prime Minister 2000, p.

31).

Lorenzen (1999) pointed out, for a region to achieve knowledge, there needed to be

localised learning systems, such as systems of firms within high-tech industries, with

multiple extra-regional linkages to sources of codified (explicit) knowledge. However,

other systems, notably small and medium sized firms (SMEs), could learn by

leveraging linkages to obtain local (tacit) knowledge. Lorenzen considers the following

elements important in promoting the endogenous creation of knowledge:

Source: Oxford-Cambridge Arc (www.oxford2cambridge.net)


22/203


5

Education and training - the flexibility of the labour force but more importantly

how it increases the stock of local knowledge (human capital) and improves

regional core competencies Promoting experimentation and innovation within single firms firms are risk

averse, consequently, grants can encourage the use of experimental

technology or access to finance can encourage spinouts. Similarly, incubator

services can stimulate spinout and start-up activity.

1.4 The Problem

As described, clusters require mechanisms that not only support cluster development

but also assist the sustenance of competitive advantage. Within the East of England,

there have been a number ofsoft infrastructure initiatives, such as business networks,

developed with these aims in mind please refer to sections 2.4.2 and chapter 5 where

these are discussed.

Through events2 published on their event diaries, business networks seek to facilitate

and promote face-to-face interaction between members of the cluster community toincrease the rate of development and growth of innovation and technology-based

businesses within Bedfordshire and along the Oxford-to-Cambridge Arc. Through

these networks, stakeholders can obtain a number of benefits. The following are a

selection of benefits that membership of the Cambridge Network provides

(www.cambridgenetwork.co.uk):

Participation in events organised by our 'passport partners'

(Corporate Members only) Participation in investor tours, Special Interest

Groups and Corporate Gateway

2 Events are presentations, meetings or other similar activities that provide two main benefits to

clusters. First, there is the opportunity to acquire new knowledge and learning from the event.

Second, opportunities to network with other attendees facilitate the application of knowledge

either gained from the event or otherwise see section 4.2.2.


23/203


6

'Inside track' on business-to-business networking opportunities

Full participation in the Cambridge Network online community - post and

regularly update your company or individual profile and products/servicesinformation on the Cambridge Network Directory

(Corporate members only) Use of the Cambridge Network website for posting

information about vacancies, news and events

(Corporate Members Only) Free participation in our annual 4Rs (Remuneration,

Recruitment, Rent and Raising Money) survey. This fully confidential service

enables your company to benchmark itself against a local peer group

Invitations to all Cambridge Network events including Open Meetings and Caf

Networking which are free to members (depending on your membership typeyou will be badged/listed under your individual or company name)

This example illustrates the value proposition of business networks: Access to

information on networking activities that are targeted to meet the needs of the cluster

community.

However, the approach adopted by business networks is fragmented. There is little or

no effective co-operation thus, synergistic benefits are lost. Moreover, in the

knowledge driven economy, organisational learning and business networking

opportunities are crucial yet scarce. This is particularly true for SMEs where the

opportunity cost of attending a networking event can be very high. With the

proliferation of business networks, the cluster community is also facing increasing

opportunity cost decisions when searching networks for relevant content.

In short, current and proposed business networks whose charters are to facilitate and

promote face-to-face networking, through their increased content and numbers, are

providing a diminishing benefit due to information (or event) explosion. This arises

from their lack of focus on the actualneeds of the cluster community: relevant and

targeted information on networking opportunities, from whateversource, that can be

readily identified.


24/203


7

1.5 A Solution

The work in this thesis contributes to a solution to this problem. Generally, a cluster

stakeholder needs to access his or her network to view events. Where a cluster

stakeholder is a member of several networks, this process will need to be repeated for

each network.

This thesis specifies the requirements3 for a web-based networking tool that will

improve the infrastructure for disseminating information about events that are relevantto members of the cluster community. Through event syndication, events will be

distributed to participating event diaries and individuals.

The Work Context for this software tool is illustrated in figure 3. This specifies a Linked

Event Diaries System (LED) a system where event diaries work collaboratively

through event syndication. This system allows a network stakeholder to use his current

access to view the events on learning and networking opportunities that have been

exposed by other networks. More importantly, this specification also allowsstakeholders to specify the type of events they would like to receive and from which

participating networks.

3 Requirements (or a requirements specification) detail the behaviour of a software system (see

section 3.2).


25/203


8

Figure 3. Linked Event Diaries System

An investigation of the Work Context of the LED will result in the development of a

prototype set of requirements that will specify its behaviour. Next, this prototype will be

stakeholder testedamongst members of the cluster community both to refine existing

requirements and to elicit new requirements of the LED. Once stakeholder testing hasbeen completed, the LED requirements will be formalised in a requirements

specification document that can be used to develop the software design specification

for the LED (Maciaszek 2001; Sommerville 2001).

This solution will provide a more cohesive approach to supporting the cluster

community. The increased awareness of events, through a more efficient and effective

delivery mechanism, will intensify the level of event participation, which in turn will

increase both the knowledge within the cluster and the value of the cluster tostakeholders, thus providing the glue, which makes the cluster operational (Office of

the Deputy Prime Minister 2000, p. 31).


26/203


9

1.6 Structure of the Thesis

I have described the rational behind the current spatial economic policy of clustering

and I have given a brief introduction into why it should be supported and how it may be

developed. In the Literature Review, however, I will explore these areas in more detail.

I have also described the problem and the proposed solution.

The following describes the content of the chapters of this thesis.

Chapter 1 INTRODUCTION

Provides a background to the research and provides a statement of

the problem that this thesis seeks to solve.

Chapter 2 LITERATURE REVIEW

Identifies the characteristics of clusters, the rational behind cluster-

development policies and illustrates some of the main soft

infrastructure initiatives within the East of England region.

Chapter 3 METHODOLOGY

Details the requirements engineering process and identifies LED

project risks. Examines techniques for eliciting requirements and

considers methods for their specification. Details the stages

employed to perform the project: the elicitation of requirements

from various stakeholders, the specification of requirements and

their validation.

Chapter 4 DATA COLLECTION

Describes the methodology used to elicit information that would

provide the basis of developing the requirements of the LED.

Chapter 5 STAKEHOLDER EVENT ANNOUNCEMENT

Describes how project stakeholders announce events.


27/203


10

Chapter 6 DEVELOPING THE REQUIREMENTS FOR THE LED

Examines, in detail, the development of LED requirements fromelicited information.

Chapter 7 DISCUSSION

Discusses the research methodology, the specified LED

requirements and suggests areas for future work.

Chapter 8 CONCLUSIONS

Summarises the thesis.


28/203

Chapter 2 Literature Review

11

2 LITERATURE REVIEW

2.1 Introduction

The aim of this research project is to support the clusters of firms and organisations

within Bedfordshire and along the Oxford to Cambridge Arc, as cluster development is

crucial to the East of England and central to the economic policies of the government.

Hence, in this chapter, I first describe the nature of a cluster; I offer several definitions

and I select its main characteristics.

Next, I illustrate the differing reasons why cluster economic development is important,

both regionally and nationally, to achieving sustainable competitive advantage through

developing UK competencies (Prahalad and Hamel 1990) in knowledge, skills and

creativity (Department of Trade and Industry 1998).

Moreover, I identify methods that support learning within clusters. First, I illustrate

initiatives conducted by institutions that affect regional learning then I illustrate regional

support initiatives specifically targeted at encouraging regional learning.

Lastly, I summarise the chapter.


29/203


12

2.2 Characteristics of a Cluster

In the view of Doeringer and Terkla (1995, p. 225), clusters are geographical

concentrations of industries that gain performance advantages through co-location.

Porter (1998, p. 88) agreed that co-location creates the potential for economic value;

however, Porter (1998, p. 88) qualified his assertion by adding that, it [co-location]

does not necessarily ensure its realization. Moreover, Porter referred to clusters as

geographical concentrations of interconnected companies and institutions in a

particular field. Porter elaborated that:

Clusters encompass an array of linked industries and other entities important to

competition. They include, for instance, suppliers of specialized inputs such as

components, machinery, and services, and providers of specialized

infrastructure. Clusters also often extend downstream to channels and

customers and laterally to manufacturers of complementary products and to

companies in industries related by skills, technologies, or common inputs.

Finally, many clusters include governmental and other institutions-such as

universities, standards-setting agencies, think tanks, vocational trainingproviders, and trade associations that provide specialized training, education,

information, research, and technical support. (Porter 1998, p. 78)

Jacobs and De Man (1996, p. 425) noted, There is not one correct definition of the

cluster concept. Rather, they concluded that there were a set of dimensions to which

tailor-made policies could be developed. The dimensions identified were:

Geographical spatial clustering of economic activity

Horizontal relationships between industry sectors at similar stages in the

production process

Vertical relationships between industry sectors at different stages along the

production process


30/203


13

Lateral relationships where different sectors share certain capabilities that

lead to performance gains in the form of economies of scope4

Technological around a basic technology Focal a cluster of firms around a central actor (such as a firm, a research

centre or an educational institution)

Quality of the network the way in which firms cooperate and the relative

benefits that they receive will determine whether the network will be sustainable

and stimulating

Rosenfeld (1997, p. [4]) contended that the term clusterneeded to be clearly defined if

it was to become a useful subject of analysis and policy. Rosenfeld (1997, p. [4])described a cluster as a geographically bounded concentration of interdependent

businesses with active channels for business transactions, dialogue, and

communications, and that collectively shares common opportunities and threats."

Among these various definitions or dimensions of a cluster are clear set of

characteristics that help to distinguish a cluster from other forms of economic activity.

Firstly, spatial proximity is seen as an important dimension of a cluster (Doeringer and

Terkla 1995; Jacobs and De Man 1996; Porter 1990, 1998; Rosenfeld 1997). There is,nevertheless, no general agreement as to what qualifies as being within the spatial

proximity of a cluster. Nonetheless, I will accept the position that, Often a regional

cluster covers a local labour market area or travel-to-work area (European Commission

2002, p. 13).

Secondly, clusters are characterised by the active relationships that illustrate the

interdependencies among firms. These relationships can occur within a sector, across

sectors or across industries and they suggest the productive output of the cluster

(Jacobs and De Man 1996; Porter 1990, 1998; Rosenfeld 1997).

Lastly, Jacobs and De Man (1996), Porter (1990, 1998), and Rosenfeld (1997) have

described how flows of information, knowledge, capital, skills, new technology and

4 Long-run reduction in average costs as the range of activities increases.


31/203


14

innovations are an essential feature of a cluster, where these flows occur both within

the cluster, and to and from it.

2.3 The Economic Benefits of Clusters

2.3.1 Regions of Competitiveness

Porter (1998) has indicated that firms within a cluster are immersed within a

competitive business environment that provides three advantages. Firstly, firms

operate more productively (Porter 1998, p. 81). Firms can readily obtain access toinputs such as suppliers, information, technology and higher education institutions.

Costs related to searching for and hiring talented employees are reduced, as talent is

made available within the cluster. Often, firms can source products and services from

inside the cluster and thus forgo the (greater) cost of having to develop or produce the

product or service. Being within a cluster provides members with preferred access to

extensive market, technical, and competitive information (Porter 1998, p. 81) that

accumulates inside a cluster. Cluster members also benefit from being associated with

the cluster through efforts such as joint marketing, trade fairs, bulk purchasing andbrand recognition (Porter 1998).

Secondly, clusters are incubators of innovation. For example, through having a close

relationship with sophisticated buyers within a cluster, suppliers are more tuned to their

specific needs and market trends and are able to bring products to the market more

rapidly than isolated competitors. Clusters often provide the ability and the agility for

members to implement innovations more rapidly. The sheer competitive pressures

between peers that are exerted reinforce these advantages for innovation (Porter1998).

Thirdly, clusters encourage new business formation. Firms develop to take advantage

of the concentrated customer base. Gaps in the market lead to spinouts where product

and service innovations can be developed. These products and services can be

developed at considerably reduced cost and risk through the leveraging of established


32/203


15

relationships (Porter 1998).

2.3.2 Regions of Co-operation

As mentioned, Porter (1998) has asserted that competition is the dominant behaviour

among firms within a cluster and that, through this competitive behaviour, a nation

gains competitive advantage in the industries in which its clusters compete. Doeringer

and Terkla (1995), and Rosenfeld (1997) have identified collaboration as key means of

strengthening and developing a cluster. Rosenfeld observed that firms within a cluster

form networks that have common business goals. These networks are based on co-

operation, which allows them to benefit from specialised services at lower cost andengage in complex activities they would not otherwise perform.

Doeringer and Terkla have pointed out that efficiencies may be achieved through

horizontal competition. However, Facilitating cooperative relationships and promoting

vertical collaborations that lead to production channel clustering among suppliers and

customers appear to be more constructive directions for development policy

(Doeringer and Terkla p. 235).

Saxenian (1994, p[1]) noted that Silicon Valley had dense social networks the

organizational boundaries within companies are porous, as are the boundaries

berween [sic] companies themselves and between companies and local institutions

such as trade associations and universities. Moreover, in a pilot survey of 17 small

high technology firms in Oxfordshire and Berkshire, it was found that, The more

strongly firms interact with research laboratories and universities, the more likely they

are to have come up with at least one major recent product innovation (Romijn and

Albu 2002).

2.3.3 Regions of Learning

Florida (1995, p. 528) observed, Regions are becoming more important modes of

economic and technological organization in this new age of global, knowledge-

intensive capitalism. These regions take on the characteristic oflearning regions that

act as collectors and repositories of knowledge and ideas and provide the underlying


33/203


16

infrastructure, which facilitates the flow of knowledge, ideas and learning (Florida

1995, p. 532). Thus, competitive advantage lies within the region in its ability to

generate and harness knowledge and ideas.

Lawsons (2000) view is that regions obtain competitive advantage, just like firms,

through their system of core competences. Core competences represent the total

collective learning of firms, their ability to integrate multiple streams of technology and

coordinate diverse production skills.

In this move towards knowledge-intensive capitalism, the key economic unit of

production, and ultimately wealth creation, shifts from the firm to the region. It involvesthe development of new inputs and a broader infrastructure at the regional level on

which individual firms and production complexes of firms can draw (Florida 1995, p.

531).

Just as features such as continuous improvement, knowledge creation, new ideas and

organisation learning describe and characterise the knowledge-intensive firm the same

features describe and characterise the learning region:

Learning regions provide the crucial inputs required for knowledge and

intensive economic organisation to flourish: a manufacturing infrastructure of

interconnected vendors and suppliers; a human infrastructure that can produce

knowledge workers, facilitates the development of a team orientation, and

which is organised around life-long learning; a physical and communication

infrastructure which facilitates and supports constant sharing of information,

electronic exchange of data and information, just-in-time delivery of goods and

services, and integration into the global economy; and capital allocation andindustrial governance systems attuned to the needs of knowledge-intensive

organizations. (Florida 1995, p. 534)


34/203


17

2.4 Turning Clusters into Learning Regions

TSER European research network conducted research within ten regional clusters oftechnology intensive firms, namely Cambridge, Oxford, Sophia-Antipolis, Munich, the

Dutch Randstad, Pisa, Piacenza and NE Milano, Goteborg, Helsinki, and Barcelona.

Considering the heterogeneity of these regions, the research clearly identified in the

successful high-technology regional clusters active local inter-firm and inter-

organisational processes that promoted learning, knowledge development, and

exceptional levels of technological and product innovation (Keeble 2000, p. 220).

These key regional collective learning processes were the creation of new businesses

through spinouts and entrepreneurship, a dynamic knowledge-based labour market,active and relatively intense local networking (Keeble 2000, p. 214), and collaboration

linkages between local firms complemented by linkages to global innovation networks.

These processes operated mainly between individual firms irrespective of size.

However, regional institutional support mechanisms also had identifiable influences on

these processes (Keeble 2000).

2.4.1 Institutions

Institutions, such as major universities and research institutes, played an important role

in encouraging collective learning in their regional high-technology cluster. In relation

to the key regional collective learning processes, the roles played by institutions were

as follows (Keeble 2000):

Generating local technology-based spinouts for example, in Oxford, 18% of

high technology SMEs were spunout from Oxford University whilst in

Cambridge, Cambridge University accounted for 17%. In general, Britain'suniversities have spun out [sic] more than 4,000 companies, exploiting research

from their academics and securing external finance from investors (Jones

2002, p[3])

Training of knowledge practitioners such as scientists, engineers, researchers,

managers and other graduates for example, in Grenoble, The development

of skilled manpower in computing (software and hardware) has powerfully

influenced firm location in more profound ways than just as a result of traditional


35/203


36/203


19

Figure 4. Cambridge Network events diary

bFORA this is a forum for information exchange and exploration of other

business networks. bFORA categorises content such as jobs and news bynetwork, and events by areas such as Hi-Tech, Conference and Technology

Transfer (see figure 5). Access to content is through a link that transfers users

to the network that provided the content. Currently, there are seven bFORA

lines or high-level categories. Apart from those mentioned, they include

Business Cluster, Science Park, East of England and West Midlands

(www.bFORA.net).


37/203


20

Figure 5. bFORA event calendar

New Science Parks and Incubators apart from the original Cambridge

Science Park established in 1970, other parks that have been established

include St Johns Innovation Park, Melbourn Science Park, Granta Park,

Cambridge Research Park, a biotechnology incubator at Hinxton Hall, and a

technology park at the Babraham Institute (Keeble 2000).

East of England Development Agency (EEDA) EEDA was established on 1

April 1999 by the UK government as one of nine RDAs. The RDAs were taskedwith developing regional economic development strategies. Since January

2003, their remit has included both developing and implementing regional

cluster policies (Department of Trade and Industry n.d.). EEDA has outlined its

strategy for the East of England as identifying, developing and supporting local

initiatives; sourcing extra-regional finance and directing that finance to cluster

initiatives, accordingly; building on local network foundations; contributing

expert and specialist resources and sharing of accumulated knowledge and

experience. EEDA seeks to assist firms and organisations that


38/203


21

operate in the following clusters: environmental, motor sports, medical devices

auto (advanced engineering) and energy (EEDA n.d., Wathen 2003).

Regional Infrastructure for Innovation (RII) this is a regional collaboration often Higher Education Institutions (HEIs) in the East of England. Participating

HEIs include (www.rii.org.uk):

o Anglia Polytechnic University

o University of Cambridge

o Norwich School of Art and Design

o Cranfield University

o University of Lutono University of Essex

o University of Hertfordshire

o University of East Anglia

o The Open University

o Writtle College

The RII is developing ways for businesses and organisations in the East of

England to gain access to and support for the innovation services they requireto enhance their growth and development (www.rii.org.uk). Access to the

combined capabilities of regional universities will allow businesses and

organisations to capitalise on opportunities for knowledge sharing and

collaboration, which is particularly useful to SMEs that are looking to gain

access to both intellectual and physical resources and support innovation in

their quest for growth and greater profitability (www.rii.org.uk).

One way that the RII seeks to support business and organisations is by

providing information on events run by member HEIs through their event

calendar (see figure 6).


39/203


22

Figure 6. Events calendar for Regional Infrastructure for Innovation

In November 2003, RII will be re-launched as Innovation 10 (I10) (Website:

www.I10.org.uk). I10 has been funded by EEDA with the aim of providing

businesses with a central repository of the core knowledge, expertise and

facilities of regional HEIs so that businesses within the clusters targeted by

EEDAs cluster policy can more readily identify knowledge transfer institutions

(Kitson 2003b).

Like RII, I10 will also promote the events of member HEIs, and special I10

events. Events will be distributed through both traditional channels, such as the

post, and non-traditional ones for example, email and an event calendar

similar to RII (Kitson 2003b).

Oxford-Cambridge Arc (O2C) is an initiative of regional HEIs, sub-regional

economic partnerships (such as the Milton Keynes Economic Partnership and

the Northamptonshire Sub- regional Strategic Partnership), the


40/203


23

private sector and three regional RDAs. Its principal objective is to make the

region between and around Oxford and Cambridge the largest and most

successful knowledge-based economy in Europe with realistic ambitions tobecome the world leader (Oxford-Cambridge Arc 2003). As part of this policy,

O2C is looking to encourage and facilitate exceptional levels of interaction

between the various regional stakeholders through three main activities

(Oxford-Cambridge Arc 2003):

o Networking and Brokering developing a network of champions, formal

and informal contact facilitation, lobbying organisations, managing and

communicating the existence of events to foster networking and

knowledge transfer, issuing a regular e-newsletter on events and

activities within the arc

o Initiating and Managing Projects assessment of community needs,

infrastructure improvements, creating a database of organisations within

the arc, creating an O2C Arc website to communicate important

information and to facilitate community communication, developing

event planning capabilities to enable networking and brokering

o

Promoting of the Arc champion the region nationally andinternationally to attract inward investment, secure funding for

infrastructure improvement, promote sector-specific growth

(biotechnology, aeronautics, automotive, ICT and telecommunications),

infrastructure funding

O2C is still in its formative stages and its strategy to implement its mission is

still evolving.


41/203


24

2.5 Summary

It is my view that competitive advantage is gained not only through competition, as

attested by Porter (1998), but also through intense and active collaboration and

networking as stated by Doeringer and Terkla (1995), Rosenfeld (1997), Saxenian

(1994) and as evidenced by Romijn and Albu (2002).

Research clearly identified the creation of new businesses through spinouts and

entrepreneurship, a dynamic knowledge-based labour market, active and relatively

intense local networking (Keeble 2000, p. 214), and linkages, between local firmscomplemented by linkages to global innovation networks, as key local inter-firm and

inter-organisational processes in the successful high-technology regional clusters

(Keeble 2000).

As indicated in chapter 1, networks that facilitate face-to-face networking, such as the

Cambridge Network, offer a rich service to the cluster community. Nonetheless, this

service is fragmented and the synergistic benefits for the cluster are not maximised.

Network proliferation and the parallel growth in content impose additional demands on

stakeholder time, as stakeholders are forced to scan the cluster community to identify

specific events of interest. It is my contention that this increasingly fragmented service

is not maximising the opportunities to encourage the exceptional levels of

technological and product innovation as identified by Keeble (2000, p. 220).

Moreover, high-level categories do not allow stakeholders to identify networking

opportunities rapidly, and these opportunities are reduced when stakeholders cannotreadily select events by network, as with bFORA. Lastly, sites like bFORA are based

on providing unfiltered aggregated content from partner networks. SMEs have little

time to attend networking opportunities and even less time to discover them (Kitson

2003b).

Consequently, there is a need for a solution to correct the deficiencies of current

software-based regional support initiatives. As stated in chapter 1, the solution


42/203


25

involves the specification of the requirements of a Linked Event Diaries system (LED)

that will allow current event diaries to work collaboratively through event syndication.

As a result, in chapter 3, I will consider suitable techniques and methods ofrequirements engineering that will allow a software system to be specified.


43/203

Chapter 3 Methodology

26

3 METHODOLOGY

3.1 Introduction

In chapter 2, I demonstrated how established and planned networks are providing an

increasing fragmented and uncoordinated service and thus a diminishing benefit in

their support of face-to-face networking in Bedfordshire and along the Oxford to

Cambridge Arc.

As mentioned in chapter 1, the solution proposed by this thesis is a software system

that intensifies the level of event participation, which in turn increases both the

knowledge within the cluster and the value of the cluster to stakeholders. Therefore, in

this chapter, I introduce the field of requirements engineering that will allow the LED to

be specified both fully and successfully.

I explain the steps involved in producing the requirements specification and I offer

general considerations that need to be kept in mind. Since all projects involve a

measure of risk, I review possible risks that can be anticipated (human, organisational

and technical) and I offer risk management strategies that can increase the likelihood

of a successful outcome.

Also in this section, I describe the elicitation techniques that are more suitable to

discovering requirements for the LED and I consider their relative merits. Next, I

review a range of methods that may be used to represent the requirements elicited

from the various project stakeholders, and I comment on the intrinsic strengths andweaknesses of each method.

Finally, I summarise the chapter.


44/203


27

3.2 Steps in Requirements Engineering

Davis (1993, p. 371) has defined a requirement as a user need or a necessary feature,

function, or attribute of a system that can be sensed from a position external to that

system. Essentially, a requirement is a statement of a system service or constraint. It

defines what a system should do rather than how it should do it. Nevertheless, in

practice, requirements may include implementation descriptions, which are more

understandable than abstract problem statements; may conform to specified standards,

the implementation environment, or organisational concerns; or may include a

description of how an operation is to be performed (Kotonya and Sommerville 2002).

Requirements engineering pertains to three main activities. These are the elicitation

and analysis of requirements, the specification and documentation of requirements,

and the validation of those requirements to produce a software information system or

application. However, the methodology of requirements engineering is also applicable

to determining the requirements of a system as a whole and not solely the software

component. An important prerequisite of requirements engineering is that the methods

used must be systematic and repeatable (Kotonya and Sommerville 2002).

Elicited requirements are recorded in a requirements specification document.

Requirements can be specified in a number of ways, ranging from natural language to

more rigorous formal methods. Once recorded, they are then checked for consistency,

completeness and accuracy. Recorded requirements then form the basis for

developing a design specification for the system (Maciaszek 2001; Sommerville 2001).

The effectiveness of the requirements engineering process is critical to project successor failure. In a study conducted by Jones (1996a), it was discovered that requirements

engineering was deficient in 75% of organisations. If requirements are not captured

correctly, the system delivery date might be delayed and costs of delivery might


45/203


28

increase. Moreover, stakeholder5 dissatisfaction might lead to reduced system use or

system abandonment. Unreliable requirements might result in recurring system errors

that disrupt system use or, if the system continues to be used, might lead to higher-than-normal maintenance costs (Kotonya and Sommerville 2002; Saiedian and Dale

2000).

3.3 Considerations during the Elicitation Process

Since the requirements document forms the agreed description of the functions of a

software solution, the requirements engineer (or analyst) must understand both thepurpose of the software system and how it contributes to the development of the

business or organisation. Both sets of information can be derived from LED project

stakeholders (the individuals who may have a direct or indirect influence on the system

requirements) such as the client and the customer (Jalote 1991; Sommerville 2001).

An understanding of the system purpose allows the requirements engineer to represent

graphically the software system as an unexplored black box. This not only helps to

focus the requirements engineer onto the area of concern but also helps to obtain an

agreement from stakeholders as to the boundary of the target system the LED(Sommerville 2001).

With a clear boundary distinguishing the system from the environment, the

requirements engineer is able to identify other stakeholder groups who will be involved

in eliciting requirements, such as end users, Web designers and domain experts

(Saiedian and Dale 2000).

The requirements engineer also needs to understand from the stakeholdersperspective the work processes or business events that the system will perform and

the role of any existing systems in these work processes. This requires that the

5 Stakeholder, as used here, refers to any individual who directly or indirectly affects the

requirements of a software system. This includes users, customers, client (who authorise the

project), developers and, perhaps, even the tea person.


46/203


29

requirements engineer have not only general knowledge of the area where the system

is to operate (application domain) but also specific stakeholder knowledge, such as

where the software system will be applied (Sommerville 2001).

3.4 Risks during the Elicitation Process

The elicitation process involves stakeholders and the requirements engineer reaching a

shared understanding of both the problem and the proposed software solution.

Holtzblatt and Beyer (1995, p. 1) report, The success of customer-centred

requirements processes, indeed of any requirements process, depends on our successin dealing with the interpersonal, cultural, and organisational aspect of adopting these

[requirements engineering] methods. Therefore, the elicitation process must not only

address technical risks but also human risks.

3.4.1 Human Dimensions

The elicitation process entails active communication between the requirements

engineer and various stakeholders. If one assumes that stakeholders have adequateknowledge of their domain (Kotonya and Sommerville 2002), then the efficacy of the

elicitation process depends upon the domain knowledge of the requirements engineer

(Lawrence, Wiegers and Ebert 2001).

Byrd, Cossick and Zmud (1992) have described three different types of communication

problems that can occur during elicitation. Within obstacles occur because of the

cognitive limitations of humans. Stakeholders may not recall domain knowledge or

process steps, or may inadvertently omit information during elicitation. Cognitivelimitations also affect communication between stakeholders and the requirements

engineer. These between obstacles are compounded by both the newness of the work

context to the requirements engineer, and the differences in language used by

stakeholders and the requirements engineer to express ideas or concepts. Lastly,

amongobstacles arise due to the various stakeholder demands on the system, which

need to be negotiated to produce an agreed set of requirements.


47/203


30

On occasions, stakeholders do not know what the requirements should be for the

software system except in the most general terms (Sommerville 2001). Sometimes,

there are unexpressed requirements that need to be included in the system. Davis(1993, p. 43) indicated, It is the job of the analyst to uncover not only what the users

say they want but [also] what they really need. Not uncovering these needs may lead

to problems at later stages in the project. Lawrence, Wiegers and Ebert (2001, p. 1)

report, Often, the only way adapt [sic] a software-based system to accommodate an

important attribute [functional requirement] is to re-architect.

Heraclites said change alone is unchanging,6 yet human beings (naturally) resist it.

Therefore, the recognition, understanding and mitigation of resistance to change areessential to project success. Project review time should be explicitly allocated to cope

with resistance (Benjamin and Levinson 1993). Resistance from stakeholders may

take many forms; examples include (Saiedian and Dale 2000):

Time resistance not making the time to meet the requirements engineer

Silence resistance not responding to questions or requests

Compliance resistance not expressing opinions but always agreeing with what

the requirements engineer is saying Impracticality resistance refers requirements engineer back to the real world

Overload resistance always requests more information

Resistance also arises due to stakeholders not being timely informed, the change

implies less stakeholder influence or control, or the change requires greater

stakeholder commitment or work (Kanter 1985).

Some ways to overcome resistance include a greater empathy with stakeholders, an

earlier involvement of stakeholders in project decisions, a better communication of the

need to change and change benefits, and an understanding of stakeholders needs for

education and training to feel comfortable with the change (Iskat and Liebowitz 2003;

Kanter 1985)

6 Change, Heraclitus, in The Columbia Dictionary of Quotations, 1998.


48/203


31

3.4.2 Cultural and Organisational Dimensions

Organisational barriers can also inhibit the elicitation process due to political or socialfactors, or due to perceived threats from new industry structures. For example, there

might be subtle power and influence relationships between the different people in the

organisation that influence requirements but stakeholders may be reluctant to discuss

them. Furthermore, the published organisational structure may not reflect reality but

stakeholders may unwilling to discuss this either (Kotonya and Sommerville 2002).

In moving towards an industry strategy where organisations are linked through extra-

organisational systems7

, dynamics within the industry, such as perceived threats fromcompetitors, can affect industry collaboration or barriers could originate from

organisational culture or organisational inertia. The success of these systems depends

significantly on the level of commitment expressed by the participants (Howard, Vidgen

and Powell 2003).

Several authors have identified change projects that lack stakeholder commitment as

having a high level of risk (Benjamin and Levinson 1993; Iskat and Liebowitz 2003; Keil

et al. 1998). Complex change requires someone to champion the project through, forexample, funding the project, convening and participating in stakeholder meetings or

encouraging the participation of problematic stakeholders. On occasions, a project

may need more than one champion, such as one who will fight for funding and one

who will bring the stakeholders from multiple organizations together (Benjamin and

Levinson 1993, p. 32). This commitment, however, needs to be continuous throughout

the project. Where this is not possible, consideration should be made as to the

feasibility of the requirements engineering exercise (Keil et al. 1998).

7 A system that allows multiple organisations to share industry level software through electronic

portals and hubs.


49/203


32

3.4.3 Technical Dimensions

Technical dimensions are no less important. Potential risks arise from the inclusion ofnew requirements into the specification once the requirements specification process

has ended (requirements creep). Requirements leakage occurs when requirements

have crept into the requirements specification but have an unknown source. These

requirements are unowned by any stakeholder, yet their inclusion may affect both the

budget and the project schedule (Jones 1998; Robertson and Robertson 1999a).

On occasions, gold plated requirements may appear in the requirements specification.

These are requirements that contribute more to project cost than they do to systemfunctionality. They are marginally useful (Jalote 1991, p. 121) features that add

unnecessary risk to the project since they consume resources and time (Jalote 1991;

Robertson and Robertson 1999a).

As discussed in section 3.2, the requirements specification may include implementation

descriptions or other considerations, which may unfavourably influence design choices.

The benefits of these requirements need to be assessed against the constraints that

they may impose.

Addressing the human and organisational dimensions during the project will reduce

technical risks. These risks may also be reduced by having a thorough inspection of

requirements by a broad constituency (Lawrence, Wiegers and Ebert 2001, p. 2) of

stakeholders. Jones (1996b) points out the benefit of formalising this approach through

a Joint Application Design (Development) team (see section 3.5.5). Moreover, during

the requirements elicitation phase, a prototype (see section 3.5.4) of the target

software can be developed to both demonstrate and elicit requirements (Jones 1996b;Lawrence, Wiegers and Ebert 2001).


50/203


33

3.5 Requirements Elicitation Techniques

In this section, I review some of the elicitation techniques more suitable to eliciting therequirements for the LED and I discuss their relative strengths and weaknesses.

3.5.1 Questionnaire Interviews

Questionnaire interviews are a common tool for eliciting information and are an efficient

means of eliciting information from many stakeholders. A questionnaire consists of a

fixed number of predetermined questions from which the respondent may select one or

more responses. Since questions are closed-ended (i.e., each question has two ormore fixed alternatives (Robson 2002, p. 275)), statistical analysis may be used to

investigate the results (Goguen and Linde 1993; Maciaszek 2001).

The success of a questionnaire is predicated on the assumption that the requirements

engineer has sufficient domain knowledge to prepare relevant questions and their

corresponding responses; and that questions can be phrased in such a way that they

engender the same understanding among different individuals (Goguen and Linde

1993).

One advantage of the questionnaire interview is that the requirements engineer can

conduct an interview within his domain knowledge. Another advantage is that they

complement other techniques and are particularly suitable in low-risk projects where

project objectives are understood clearly. Additionally, questionnaires may be

undertaken unsupervised. However, with unsupervised questionnaires the respondent

is unable to clarify questions or responses immediately. Moreover, by being a passive

tool, the requirements engineer is unable to maximise the benefit of the interactionalevent with the respondent (Goguen and Linde 1993; Maciaszek 2001).

3.5.2 Open-ended Interviews

Interviews are a frequently used technique during requirements elicitation. It involves

the requirements engineer discussing the system with various stakeholders to develop

both knowledge of the system domain and an understanding of the system

requirements. Interviews are composed of a set of open-ended questions that


51/203


34

encourage free discussion though closed-ended questions may also be used (Goguen

and Linde 1993; Sharp 1994).

Interviews may be classified as structured, semi structured or unstructured. In

structured (or closed) interviews, the requirements engineer asks a set of

predetermined questions in a pre-ordered sequence. These interviews can provide a

rich set of data suitable for content analysis. However, they are less suitable where

flexibility is required (Robson 2002; Sharp 1994).

Semi structured interviews also use a set of predetermined questions, nevertheless,

the requirements engineer has the flexibility to alter both the wording of questions andthe sequence of questions during the interview. Moreover, questions, inappropriate for

the respondent, may be omitted and additional questions may be posed to discover the

knowledge range of respondents (Robson 2002, Sharp 1994). Nonetheless, there is a

possibility that the requirements engineer may loose control of the interview.

Additionally, the results are more difficult to analyse than in a structured interview

(Robson 2002).

Unstructured (or open) interviews do not use a predetermined set of questions. Thus,they provide a more informal milieu that allows the requirements engineer and

stakeholders to discuss areas that might not be raised during structured interviews.

However, unstructured interviews are difficult to analyse and are far more difficult to

control (Maciaszek 2001; Robson 2002; Sharp 1994).

Interviews are an effective technique for developing an understanding of the problem

and for eliciting general system requirements. They provide non-verbal clues that the

requirements engineer cannot pickup through non face-to-face methods. However,they require considerable skill, time and experience of the interviewer (Robson 2002;

Sharp 1994). Moreover, they are less effective at eliciting application domain

knowledge, due to communication problems (see section 3.4.1) and organisational

knowledge (see section 3.4.2).


52/203


35

3.5.3 Scenarios

Scenarios are a set of real life descriptions of how a software system might work.Using these scenarios, end-users simulate their interactions. During the simulation, the

end-user describes his or her interaction and the information that the system should

provide. Each scenario relates to a single type of interaction with the software system

and the requirements engineer can use discussions of these interactions to elicit and

clarify system requirements (Sommerville 2001).

What is more, scenarios can help to understand requirements even without considering

user interactions. Discovering the scenarios of a system generates a set of possiblesystem interactions from which system functions and features may be derived. The

requirements engineer can then use this information to elicit the corresponding set of

system requirements (Kotonya and Sommerville 2002).

Scenarios may be developed in different ways; use-cases (see section 3.6.3) are an

example of a scenario-based elicitation technique. Regardless of the method used,

they should include (Sommerville 2001):

A description of the system state before the scenario

A description of the normal flow of events in the scenario

A description of error events and how they are handled

Information about other activities which might be occurring simultaneously

A description of the system state after the scenario

Scenarios are particularly useful for developing detail from initial discussions of system

requirements with stakeholders. However, they are a time-intensive elicitation process,

involving recurrent interaction with stakeholders to understand system functionality

(Sommerville 2001).


53/203


36

3.5.4 Prototyping

Requirements prototyping involves developing an initial and early representation of asystem so that requirements can be either refined or eliminated, or additional

requirements derived. Prototypes can be software-based or paper-based but the key

feature of a prototype is that a prototype lacks the functionality or performance of the

final system (Sharp 1994).

There are two approaches to prototyping throwaway and evolutionary prototyping. In

throwaway prototyping, the requirements engineer discards the constructed prototype

once sufficient knowledge has been gained of the desired system. Usually, theprototyped requirements are those that are difficult to understand and the system is

developed quickly. In evolutionary prototyping, the constructed prototype is iteratively

refined until it converges to the desired system. The first set of requirements

implemented are those that are well-understood with more difficult requirements being

added once the system was undergone extensive testing (Davis 1993).

Both approaches to prototyping result in a better satisfaction of stakeholders needs

with a corresponding reduction in the total cost of ownership (TCO)8

by discovering agreater number of requirements and by reducing maintenance costs. Moreover,

prototyping unfreezes requirements allowing design and coding to be performed at the

same time as analysis. Consequently, evolutionary prototyping is particularly

susceptible to various forms of requirements creep (Carter et al. 2001; Davis 1993).

8 This is a type of calculation designed to assess both direct and indirect costs, and benefits

related to the purchase of any IT component. The intention is to arrive at a final figure that will

reflect the effective cost of purchase, all things considered. TCO analysis considers extended

cost not just purchase price. For a business purchase of a software system, the fully burdened

costs can also include such things as installation, service and support, user training, and

software licensing (www.search390.com).


54/203


37

3.5.5 Joint Application Development

Joint Application Development (JAD) brings together different stakeholders in anintensive workshop in a joint effort to elicit the software requirements. A JAD session

should contain no more than 25 individuals and it should be facilitated by an

experienced impartial moderator with good domain knowledge and excellent

communication skills. The moderator uses his skills to manage the group dynamics of

the workshop. Other JAD participants include the scribe who uses computer-assisted

software engineering (CASE) tools to both document the workshop and develop initial

models; the users and customer who are the main participants; and members of the

development team (Maciaszek 2001).

The virtue of JAD is that it brings together all of the main stakeholders. The group

synergy is likely to produce more optimised requirements than if stakeholders were

elicited individually since the groups collective domain knowledge is used to verify and

validate requirements. Moreover, the group dynamics allows more requirements to be

produced than would otherwise be the case, thus increasing productivity. Even so,

JAD is not suitable for eliciting tacit knowledge; differing stakeholder statuses or origins

can also inhibit the effectiveness of the workshop; and technical discussions mightalienate or lesson the contributions of non-technical individuals (Goguen and Linde

1993; Maciaszek 2001).

3.5.6 Soft Systems Methods

Soft Systems Methods (SSM) uses other elicitation techniques, such as interviews,

document collection and casual conversations, to collect quantitative and qualitative

information about a problem. The problem is then represented graphically from anunrestricted set of icons (for example, maps, schematic drawings and logos) to

illustrate the socio-technical components that exist in the system (for instance, actors,

procedures, policies, hardware and software) see table a 1 for a complete description

of the technique (Kotonya and Sommerville 2002; Ragsdell 2000).

SSM is an effective and flexible approach for ill-defined situations or in the early stages

of analysis where the requirements engineer does not understand the application


55/203


38

domain, the constraints on the solution, the problem and the organisational

requirements. Through SSM, abstract requirements can be derived by analysing the

organisational context, the problem and any existing systems. It is less suitable,however, for deriving detailed system requirements where other techniques are more

appropriate (Kotonya and Sommerville 2002).

3.5.7 Observation and Social Analysis

This technique uses tools from ethnography and involves the requirements engineer

observing st