Event Syndication – Requirements Specification For Linked Event Diaries

CRANFIELD UNIVERSITY

PETER J LOUIS

EVENT SYNDICATION: REQUIREMENTS SPECIFICATION
FOR LINKED EVENT DIARIES

SCHOOL OF INDUSTRIAL AND MANUFACTURING SCIENCE

MSc THESIS

CRANFIELD UNIVERSITY

SCHOOL OF INDUSTRIAL AND MANUFACTURING SCIENCE

MSc THESIS

Academic Year 2002-2003

PETER J LOUIS

Event Syndication: Requirements Specification
for Linked Event Diaries

Supervisor: Associate Professor Steven Cousins

September 2003

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

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

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.

DEDICATION

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

A mes parents et mes soeurs qui “mon amanene ici”

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

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 this
project. 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.

LIST OF CONTENTS

LIST OF FIGURES __________________________________________________ xiv

LIST OF TABLES ____________________________________________________ xv

LIST OF ABBREVIATIONS ___________________________________________ xvi

INTRODUCTION ______________________________________________________ 1

1.1 Introduction_________________________________________________________ 1

1.2 Cluster Economic Development ________________________________________ 1

1.3 Nurturing Cluster Development ________________________________________ 3

1.4 The Problem ________________________________________________________ 5

1.5 A Solution __________________________________________________________ 7

1.6 Structure of the Thesis _______________________________________________ 9

LITERATURE REVIEW________________________________________________ 11

2.1 Introduction________________________________________________________ 11

2.2 Characteristics of a Cluster___________________________________________ 12

2.3 The Economic Benefits of Clusters ____________________________________ 14
2.3.1 Regions of Competitiveness ________________________________________________14
2.3.2 Regions of Co-operation ___________________________________________________15
2.3.3 Regions of Learning _______________________________________________________15

2.4 Turning Clusters into Learning Regions ________________________________ 17
2.4.1 Institutions ______________________________________________________________17
2.4.2 Regional Support Initiatives _________________________________________________18

2.5 Summary __________________________________________________________ 24

METHODOLOGY ____________________________________________________ 26

3.1 Introduction________________________________________________________ 26

3.2 Steps in Requirements Engineering____________________________________ 27

3.3 Considerations during the Elicitation Process ___________________________ 28

3.4 Risks during the Elicitation Process ___________________________________ 29
3.4.1 Human Dimensions _______________________________________________________29
3.4.2 Cultural and Organisational Dimensions _______________________________________31
3.4.3 Technical Dimensions _____________________________________________________32

ix

3.5 Requirements Elicitation Techniques __________________________________ 33
3.5.1 Questionnaire Interviews ___________________________________________________33
3.5.2 Open-ended Interviews ____________________________________________________33
3.5.3 Scenarios _______________________________________________________________35
3.5.4 Prototyping______________________________________________________________36
3.5.5 Joint Application Development_______________________________________________37
3.5.6 Soft Systems Methods _____________________________________________________37
3.5.7 Observation and Social Analysis _____________________________________________38

3.6 Requirements Methods ______________________________________________ 39
3.6.1 Data Flow Modelling_______________________________________________________39
3.6.2 Structured Analysis and Design Technique (SADT)_______________________________40
3.6.3 Object-Orientated Analysis and Design (OOAD) _________________________________42
3.6.4 Formal Methods __________________________________________________________44

3.7 Summary __________________________________________________________ 47

DATA COLLECTION _________________________________________________ 48

4.1 Introduction________________________________________________________ 48

4.2 Understanding the Domain ___________________________________________ 49
4.2.1 Stakeholders ____________________________________________________________49
4.2.2 Events and Networking ____________________________________________________51
4.2.3 Event Syndication ________________________________________________________55

4.3 Work Context ______________________________________________________ 57

4.4 Collecting Data _____________________________________________________ 58
4.4.1 Analysing the Data Requirements ____________________________________________58
4.4.2 Strategising Data Collection_________________________________________________59
4.4.3 Collecting and Validating Data _______________________________________________61
4.4.4 Specifying Requirements ___________________________________________________62

4.5 Summary __________________________________________________________ 65

STAKEHOLDER EVENT ANNOUNCEMENT ______________________________ 66

5.1 Introduction________________________________________________________ 66

5.2 Bedford Development Agency ________________________________________ 67

5.3 Central Innovation Network___________________________________________ 68

5.4 Cranfield University Technology Park __________________________________ 69

5.5 Cranfield University _________________________________________________ 70

5.6 Knowledge Hub ____________________________________________________ 72

x

5.7 Unilever R&D Colworth ______________________________________________ 74

5.8 Summary __________________________________________________________ 75

DEVELOPING THE REQUIREMENTS FOR THE LED _______________________ 76

6.1 Introduction________________________________________________________ 76

6.2 Gathering Requirements from Initial Stakeholders _______________________ 77

6.3 Partitioning the Work ________________________________________________ 83

6.4 Identifying the Product Boundary _____________________________________ 85

6.5 Gathering Requirements from the wider Stakeholder Group _______________ 88

6.6 Summary _________________________________________________________ 103

DISCUSSION ______________________________________________________ 104

7.1 Project Methodology _______________________________________________ 104

7.2 Limitations of the LED Specification __________________________________ 105

7.3 Recommendations for Further Research ______________________________ 106

CONCLUSION______________________________________________________ 108

8.1 Conclusions ______________________________________________________ 108

REFERENCES _____________________________________________________ 110

APPENDIX A Selected Elicitation Techniques and Requirements Methods__ 117

APPENDIX B Stakeholders and Interviews ____________________________ 120

APPENDIX C News and Event Syndication ____________________________ 123

APPENDIX D Interview Questions and Background Information __________ 125

APPENDIX E Volere Requirements Specification Template_______________ 131

APPENDIX F LED Project Documents ________________________________ 133

APPENDIX G Results & Findings: Interviews and Correspondence ________ 137

Product Constraints ________________________________________________ 141

1.1 Background_______________________________________________________ 142

1.2 Goal of the Linked Event Diaries product ______________________________ 142

2.1 Sponsor __________________________________________________________ 144

xi

2.2 Client ____________________________________________________________ 144

2.3 Customer_________________________________________________________ 144

2.4 Other stakeholders_________________________________________________ 145

3.1 Users ____________________________________________________________ 146

3.2 User priorities _____________________________________________________ 148

4.1 Solution constraints________________________________________________ 148

4.2 Implementation environment ________________________________________ 149

4.3 Partner applications ________________________________________________ 149

4.4 Existing commercial off-the-shelf software_____________________________ 149

4.5 Development deadline ______________________________________________ 149

4.6 Financial budget ___________________________________________________ 149

5.1 Glossary of terms __________________________________________________ 150

5.2 Acronyms and abbreviations ________________________________________ 150

7.1 General __________________________________________________________ 151

7.2 Technical _________________________________________________________ 151

Functional Requirements ____________________________________________ 152

8.1 The Context of the work ____________________________________________ 153

8.2 Work partitioning __________________________________________________ 153

8.3 Product boundary__________________________________________________ 154

9.1 Functional requirements ____________________________________________ 157
9.1.1 Record Dispatch Preferences ______________________________________________157
9.1.2 Record Receipt Preferences _______________________________________________158
9.1.3 Record Events __________________________________________________________159
9.1.4 Dispatch Events _________________________________________________________160
9.1.5 Record LED Connections__________________________________________________161

9.2 Data requirements _________________________________________________ 162

Non-functional Requirements ________________________________________ 163

15.1 Confidentiality_____________________________________________________ 167

15.2 File Integrity requirements __________________________________________ 167

15.3 Audit requirements_________________________________________________ 168

xii

Project Issues _____________________________________________________ 169

18.1 Regional Infrastructure for Innovation_________________________________ 170

19.1 Coldfusion MX ____________________________________________________ 171

Acknowledgements _________________________________________________ 181

List of Contacts ____________________________________________________ 182

Appendix A UML Diagrams _________________________________________ 184

xiii

LIST OF FIGURES

Figure 1. Diamond of national advantage __________________________________________________2
Figure 2. Clusters in Bedfordshire and along the Oxford-Cambridge Arc __________________________4
Figure 3. Linked Event Diaries System ____________________________________________________8
Figure 4. Cambridge Network events diary________________________________________________19
Figure 5. bFORA event calendar _______________________________________________________20
Figure 6. Events calendar for Regional Infrastructure for Innovation ____________________________22
Figure 7. DFD context diagram for an ATM problem ________________________________________39
Figure 8. First level decomposition diagram for an ATM problem_______________________________40
Figure 9. SADT notation ______________________________________________________________41
Figure 10. SADT context diagram for an ATM problem ______________________________________41
Figure 11. SADT First level decomposition for an ATM problem _______________________________42
Figure 12. The UML context diagram for an ATM problem ____________________________________43
Figure 13. UML Requirements Model for an ATM system ____________________________________44
Figure 14. Structure of a Z-schema _____________________________________________________45
Figure 15. Event Life Cycle____________________________________________________________52
Figure 16. Networking Process _________________________________________________________53
Figure 17. CIN News Item_____________________________________________________________56
Figure 18. Work Context for Linked Event Diaries system ____________________________________57
Figure 19. Requirements Process_______________________________________________________62
Figure 20. BDA's "What's New" section __________________________________________________67
Figure 21. CIN Event Diary ____________________________________________________________68
Figure 22. Cranfield University Technology Park’s "Latest news" section ________________________69
Figure 23. Message of the Day and Diary of events _________________________________________71
Figure 24. Knowledge hub's event calendar _______________________________________________73
Figure 25. Elaborated Work Context_____________________________________________________81
Figure 26. High-level use case diagram for LED____________________________________________85
Figure 27. Fully Specified Linked Event Diaries System_____________________________________102
Figure 1. Work context ______________________________________________________________153
Figure 2. Use Case Diagram for LED ___________________________________________________154
Figure 3. LED Project Tasks __________________________________________________________174
Figure 4. LED Project Plan ___________________________________________________________175
Figure 5. LED Work Breakdown Structure _______________________________________________176

Figure A 1. The main diagrams of the UML (used in this thesis)_______________________________119

Figure C1. CIN Event _______________________________________________________________123
Figure C 2. Observations: CIN event data entry ___________________________________________124

Figure D 1. Organisational questions ___________________________________________________125

xiv

Figure D 2. IT & system questions _____________________________________________________126
Figure D 3. LED proposal document____________________________________________________130

Figure F 1. Student project brief _______________________________________________________133
Figure F 2. BDA project agreement ____________________________________________________135
Figure F 3. Open University IoP SETI event ______________________________________________136

xv

LIST OF TABLES

Table 1. Initial stakeholder interviews ____________________________________________________50
Table 2. Event attendance ____________________________________________________________51
Table 3. Elements of the Event Life Cycle ________________________________________________54
Table 4. Stakeholders for data collection _________________________________________________59
Table 5. Elicited information during initial interviews, examples of ______________________________80
Table 6. LED control options___________________________________________________________82
Table 7. Event list for Linked Event Diaries System _________________________________________84
Table 8. Use Case Descriptions ________________________________________________________86
Table 9. Use case 1: Record Dispatch Preferences _________________________________________86
Table 10. Use case 2: Record Receipt Preferences _________________________________________87
Table 11. Use case 3: Record Events____________________________________________________87
Table 12. Use case 4: Dispatch Events __________________________________________________87
Table 13. Use case 5: Record LED Connections ___________________________________________87
Table 14. Event syndication information elicited during wider stakeholder interviews _______________88
Table 15. Email syndication information elicited during wider stakeholder interviews________________90
Table 16. Frequency information elicited during wider stakeholder interviews _____________________92
Table 17. Control information elicited during wider stakeholder interviews________________________93
Table 18. Usability information elicited during wider stakeholder interviews_______________________94
Table 19. Requirements for use case 1: Record Dispatch Preferences __________________________96
Table 20. Requirements for use case 2: Record Receipt Preferences __________________________97
Table 21. Requirements for use case 3: Record Events _____________________________________99
Table 22. Requirements for use case 4: Dispatch Events ____________________________________99
Table 23. Requirements for use case 5: Record LED Connections ____________________________100
Table 1. Event List for Linked Event Diaries System _______________________________________153
Table 2. Use Case Descriptions _______________________________________________________156

Table A 1. The stages of soft systems methodology________________________________________117

Table B 1. Stakeholder interviews and meetings during data collection _________________________120

Error! No table of figures entries found.

xvi

Chapter 1 Introduction

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 Day

O2C Oxford-Cambridge Arc

RDA Regional Development Agency

RII Regional Infrastructure for Innovation

SMEs Small and medium sized firms

UML The Unified Modeling Language

xvii


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)

1


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 the
product 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 nation’s diamond and Porter has contended that nations are
most 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

Factor Demand
Conditions Conditions

Related and
Supporting
Industries

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

Figure 1. Diamond of national advantage

2


Porter (1990, p. 148) stated that the “systemic nature of the ‘diamond’ promotes the
clustering of a nation’s 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 critical role [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.

3


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

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:

4


• 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 of soft 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 to
increase 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.

5


• '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/services
information 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 type
you 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 actual needs of the cluster community: relevant and
targeted information on networking opportunities, from whatever source, that can be
readily identified.

6


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 relevant
to 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 allows
stakeholders 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).

7


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 tested amongst members of the cluster community both to refine existing
requirements and to elicit new requirements of the LED. Once stakeholder testing has
been 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 to
stakeholders, thus providing the glue, “which makes the cluster operational” (Office of
the Deputy Prime Minister 2000, p. 31).

8


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.

9


Chapter 6 DEVELOPING THE REQUIREMENTS FOR THE LED
Examines, in detail, the development of LED requirements from
elicited information.

Chapter 7 DISCUSSION
Discusses the research methodology, the specified LED
requirements and suggests areas for future work.

Chapter 8 CONCLUSIONS
Summarises the thesis.

10

Chapter 2 Literature Review

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.

11


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 training
providers, 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

12


• 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 cluster needed 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.

13


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 to
inputs 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 and
brand 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 (Porter
1998).

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

14


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 and
engage 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 of learning regions that
act as collectors and repositories of knowledge and ideas and provide the underlying

15


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.

Lawson’s (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 involves
the 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 and
industrial governance systems attuned to the needs of knowledge-intensive
organizations. (Florida 1995, p. 534)

16


2.4 Turning Clusters into Learning Regions

TSER European research network conducted research within ten regional clusters of
technology 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's
universities 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

17


labour market considerations’” (de Bernardy, 1999, pp. 349, 351)
• Collaborating with regional firms in research and technology development
activities – for instance, 54% of SMEs report close links with Oxford University
or a local public research institute; however, the research suggests the need to
obtain specialised technological expertise is more national and global than
regional

2.4.2 Regional Support Initiatives

Keeble (2000) noted that during the 1990s, in several regional high technology
clusters, regional initiatives were aimed specifically at encouraging regional collective
learning. Keeble suggested that this trend involved a coalition of diverse organisations
such as large firms, universities, SMEs, local and regional governments, trades unions,
public research institutions and business and training agencies. The principal aim was
to reduce or remove barriers that affected regional business growth, such as access to
venture capital and financing, developing collaborative relationships between local
firms and universities and using tools, such as the Internet, to market and brand the
region. Specific examples of regional support initiatives include:

• Cambridge Network – a high-technology business-led initiative aimed at raising
the global profile of and increasing the degree of local networking between
Cambridge IT companies (Keeble 2000). Support now extends to other high-
tech areas, such as biotechnology, and the Cambridge Network provides an
online service where members and non-members, for example, can obtain
news and up-to-date information on events for networking opportunities, post
job opportunities and CVs, or access a local directory of companies and
individuals (see figure 4) – (www.cambridgenetwork.co.uk). Moreover, visitors
to the Cambridge Network can use the bFORA link on the Website (see figure
4) to navigate to other partnered networks, such as OxIT and the Munich
Network.

18


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 by
network, 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).

19


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 John’s 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 tasked
with 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

20


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 of
ten 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 Luton
o 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 require
to 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).

21


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
EEDA’s 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

22


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 to
become 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 and
internationally 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.

23


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 firms
complemented 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 cannot
readily 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

24


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 of
requirements engineering that will allow a software system to be specified.

25

Chapter 3 Methodology

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 and
weaknesses of each method.

Finally, I summarise the chapter.

26


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 success
or 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

27


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 the
purpose 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 stakeholders
perspective 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.

28


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 success
in 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 adequate
knowledge 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. Cognitive
limitations 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,
among obstacles arise due to the various stakeholder demands on the system, which
need to be negotiated to produce an agreed set of requirements.

29


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 are
essential 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.

30


3.4.2 Cultural and Organisational Dimensions

Organisational barriers can also inhibit the elicitation process due to political or social
factors, 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 from
competitors, 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, for
example, 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.

31


3.4.3 Technical Dimensions

Technical dimensions are no less important. Potential risks arise from the inclusion of
new 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 system
functionality. 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).

32


3.5 Requirements Elicitation Techniques

In this section, I review some of the elicitation techniques more suitable to eliciting the
requirements 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 or
more 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 interactional
event 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

33


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 and
the 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).

34


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 possible
system 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).

35


3.5.4 Prototyping

Requirements prototyping involves developing an initial and early representation of a
system 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, the
prototyped 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 a
greater 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).

36


3.5.5 Joint Application Development

Joint Application Development (JAD) brings together different stakeholders in an
intensive 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 group’s 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 might
alienate 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 an
unrestricted 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

37


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 stakeholders in their normal work environment to understand their software
requirements. It is particularly useful where a stakeholder is unable to recall or
communicate information, where the complete knowledge of a process is fragmented
among different individuals or where stakeholders work in a social environment. For
example, an ethnographic study of air traffic controllers derived additional requirements
that would not have been educed with other elicitation techniques (Kotonya and
Sommerville 2002).

Ethnographic studies may be preformed either passively or actively. In passive
ethnography, the requirements engineer observes the behaviour of the stakeholder
without intruding or interfering. In active ethnography, the requirements engineer also
takes part in activities and becomes a member of the team (Maciaszek 2001).

Ethnography, however, is focused on the behaviour of the end-user and is not suitable
for deriving organisational or domain requirements. Further weaknesses are that it
does not always identify new features that should be a part of a system, and the act of
observing persons tends to influence the way observed persons work (to be more in
line with work norms and procedures) although non-invasive recording can be used to
reduce this problem (Maciaszek 2001; Sommerville 2001).

38


3.6 Requirements Methods

In this section, I review structured analysis methods (informal and formal) that can be
used for specifying the requirements for the LED. Moreover, for each method I
consider its intrinsic strengths and weaknesses. However, in considering the
respective strengths and weaknesses of the various methods, it should be noted that
each method may be supplemented with informal descriptions.

3.6.1 Data Flow Modelling

Data Flow Modelling (DFM) uses Data Flow Diagrams (DFDs) to describe an existing
or proposed system without considering the physical environment in which data either
flows or is stored. In this method, a high-level context diagram describes the target
system and its connections to other systems within its environment. Decomposition
(i.e., further elaboration) of the system illustrates the sub-functions of the target system
together with the data interconnections between sub-functions. Each sub-function,
potentially, can be further decomposed providing greater system detail (Aktas 1987).

Figure 7 and figure 8 illustrate this approach for an Automatic Telling Machine (ATM)
System. (For clarity, messages have been omitted.) In the context diagram (figure 7),
five data flows occur between the ATM and the environment.

Figure 7. DFD context diagram for an ATM problem

In figure 8, the ATM System has been decomposed to expose its four sub-systems. In
both figures, named arrows represent data flows; rounded rectangles represent
systems, functions, transformations or processes; rectangles represent entities

39


from which data originates or is sent; and open-ended rectangles represent static data
stores (Aktas 1987).

Figure 8. First level decomposition diagram for an ATM problem

Data Flow Modelling illustrates a top-down method that starts with the problem and
develops increasing levels of detail. It is simple to use and maintain. Another one of
its major benefits is that it facilitates communication between the requirements
engineer and stakeholders. Criticisms of Data Flow Modelling are that it has difficulty
describing sub-systems with more complex events, such as graphical interfaces with
mouse clicks and menu selections, it may be misinterpreted as implying an ordered
sequence of events and it does not show looping in a system (Aktas 1987, Sommerville
2001).

3.6.2 Structured Analysis and Design Technique (SADT)

The Structured Analysis and Design Technique is a top-down method that decomposes
a problem into a set of hierarchical diagrams, where each diagram consists of a
number of activities, represented by rectangles, that have inputs, outputs, controls and
mechanisms. Figure 9 illustrates an SADT activity box.

40


Figure 9. SADT notation

Initially, a high-level abstract view (context diagram) is drawn that consists of a single
activity to represent the system and the various interactions with its environment. On
another diagram, sub-problems are illustrated by decomposing the context diagram.
Each sub-problem is then illustrated by its activities and corresponding inputs, outputs,
controls and mechanisms. With each successive refinement, the requirements
engineer achieves a more detailed and clearer understanding of the initial problem
(Jalote 1991). Figure 10 and figure 11 illustrate this method for the ATM problem
already considered.

Figure 10. SADT context diagram for an ATM problem

41


Figure 11. SADT First level decomposition for an ATM problem

The basic idea behind SADT is similar to DFDs although SADT imposes precise rules
on the meaning of arrows. For example, arrows entering an activity from below are the
means used to transform inputs into outputs whilst arrows entering from above are pre-
conditions or constraints that need to be satisfied in order for the transformation to
occur (Jalote 1991).

A feature of SADT is its separation of the representation of both data and activities
whilst illustrating their linkages. SADT is also a rich requirements method that allows
the specification of system detail. However, because of this richness, an SADT
diagram may contain substantial information that may make it difficult for stakeholders
to interpret as representing their system. Another disadvantage of SADT is that it only
illustrates multiple views of a system at the context level. However, variations of this
method, such as IDEF0, do allow systems to be decomposed from multiple viewpoints
(Aktas 1987; Kotonya and Sommerville 2002).

3.6.3 Object-Orientated Analysis and Design (OOAD)

Object-Orientated Analysis (OOA) is the process of translating a problem into a model
that uses objects and classes that have significance in the problem domain. Object-
Orientated Design (OOD) takes as input the problem model produced by OOA and
produces a solution model that specifies all the logical objects to be included in the

42


solution together with their relationships (Johnson 2002).

In OOA with the Unified Modelling Language (UML), use case diagrams are used to
model both the context of a system and its requirements (Booch, Jacobson and
Rumbaugh 1999). In figure 12 the context diagram of the ATM problem is illustrated.

Figure 12. The UML context diagram for an ATM problem

Use cases (bubbles) describe what should be performed by the system and how the
system interacts with various actors or classes (stick figures) in the environment. For
example, Joe Public interacts with the ATM through the use cases Validate card and
Dispense cash. Similarly, the Validate card use case also interacts with the Customer
DBMS to confirm the details supplied by Joe Public. Generally, modelling the context
of a system requires identifying all of the use cases in a system, all of the actors in the
environment with an illustration of the interactions between them (Booch, Jacobson
and Rumbaugh 1999).

To model system requirements, first, the context of the system is drawn identifying
actors and the common behaviours of the system through use cases. Common
behaviours between use cases are placed in their own use case. Non-standard
behaviours are also placed in their own use case. Finally, these use cases, actors and
relationships are modelled in a use case diagram (Booch, Jacobson and Rumbaugh

43


1999). Figure 13 illustrates this for the ATM problem.

Figure 13. UML Requirements Model for an ATM system

The [sic] UML is a flexible modelling tool that allows for the specification of system
functionality independent of its implementation. The UML provides a design process,
which is comprehensible to not only requirements engineers but also other
stakeholders; this active participation of stakeholders in requirements development
helps to reduce project development time. Use case diagrams, however, are stated in
natural languages and lack a formal syntax, which can lead to their misinterpretation.
Additionally, on occasions, the use of use cases involves using design solution
compromises when, for example, system functionality needs to be shared across
multiple objects (Kotonya and Sommerville 2002; Schmuller 2002).

3.6.4 Formal Methods

A formal method uses mathematical notation to describe system requirements. An
example of such a method is Z that uses schemas, structures that contain state
variables, constraints and operations on the states, to describe requirements
(Sommerville 2001) – see figure 14.

44


Source: Sommerville, I. (2001). Software Engineering. New York:
Springer-Verlag, p. 206

Figure 14. Structure of a Z-schema

The schema signature identifies the entities of the schema and the schema predicate
describes those conditions that are always true for those entities. Schema predicates
also define operations that allow the schema to be manipulated. The operations
allowed include composition, schema renaming and schema hiding. Where an
operation is defined, the predicate may also specify conditions that exist before the
operation (pre-conditions) and after the operation (post-conditions). The action in the
operation schema is defined by the difference between the pre- and post-conditions
(Sommerville 2001).

Formal methods provide a high degree of correlation between system functionality and
specifications. As a rigorous method, they remove areas of doubt in specifications and
avoid misinterpretations due to the use of natural language. Thus, they may be used to
refine detailed but informal specifications. Moreover, formal methods force an analysis
of system requirements at an early stage where the costs of correcting errors are much
lower (Boriani 1997; Johnson 1996).

45


Nonetheless, because of their mathematical origins, formal methods require expert
knowledge to interpret9, and specifications can be long and tedious to read. Moreover,
formal methods have technical limitations in, for example, specifying system recovery
following failure, and the expressiveness of the language (mathematics) might lead to
an unimplementable design. Lastly, formal methods are ideal for specifying function or
data but are less able to specify non-functional requirements (Boriani 1997; Johnson
1996; Sommerville 2001).

9
However, Z requires that specifications be complemented by informal descriptions.

46

Event Syndication – Requirements Specification For Linked Event Diaries

Event Syndication – Requirements Specification For Linked Event Diaries

Recomendados

Recomendados

Más contenido relacionado

Similar a Event Syndication – Requirements Specification For Linked Event Diaries

Similar a Event Syndication – Requirements Specification For Linked Event Diaries (20)

Más de Peter Louis

Más de Peter Louis (7)

Último

Último (20)

Event Syndication – Requirements Specification For Linked Event Diaries