Event Syndication – Requirements Specification For Linked Event Diaries


Published on

The requirements of a web-based networking tool that will improve knowledge transfer, regional learning and innovation among firms within the high-tech and knowledge-based clusters of Bedfordshire and the Oxford-Cambridge Arc

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Event Syndication – Requirements Specification For Linked Event Diaries

  2. 2. 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.
  3. 3. 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.
  4. 4. DEDICATION Para Antonia por tu amor, paciencia y por ser mi amiga. Te amo A mes parents et mes soeurs qui “mon amanene ici”
  5. 5. 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
  6. 6. 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.
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. Chapter 1 Introduction 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
  17. 17. Chapter 1 Introduction 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
  18. 18. Chapter 1 Introduction 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
  19. 19. Chapter 1 Introduction 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
  20. 20. Chapter 1 Introduction • 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
  21. 21. Chapter 1 Introduction • '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
  22. 22. Chapter 1 Introduction 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
  23. 23. Chapter 1 Introduction 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
  24. 24. Chapter 1 Introduction 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
  25. 25. Chapter 1 Introduction 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
  26. 26. 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
  27. 27. Chapter 2 Literature Review 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
  28. 28. Chapter 2 Literature Review • 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
  29. 29. Chapter 2 Literature Review 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
  30. 30. Chapter 2 Literature Review 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
  31. 31. Chapter 2 Literature Review 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
  32. 32. Chapter 2 Literature Review 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
  33. 33. Chapter 2 Literature Review 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
  34. 34. Chapter 2 Literature Review 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
  35. 35. Chapter 2 Literature Review 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
  36. 36. Chapter 2 Literature Review 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
  37. 37. Chapter 2 Literature Review 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
  38. 38. Chapter 2 Literature Review 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
  39. 39. Chapter 2 Literature Review 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
  40. 40. Chapter 2 Literature Review 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
  41. 41. 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
  42. 42. Chapter 3 Methodology 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
  43. 43. Chapter 3 Methodology 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
  44. 44. Chapter 3 Methodology 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
  45. 45. Chapter 3 Methodology 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
  46. 46. Chapter 3 Methodology 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
  47. 47. Chapter 3 Methodology 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
  48. 48. Chapter 3 Methodology 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
  49. 49. Chapter 3 Methodology 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
  50. 50. Chapter 3 Methodology 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
  51. 51. Chapter 3 Methodology 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
  52. 52. Chapter 3 Methodology 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
  53. 53. Chapter 3 Methodology 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
  54. 54. Chapter 3 Methodology 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
  55. 55. Chapter 3 Methodology 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
  56. 56. Chapter 3 Methodology 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
  57. 57. Chapter 3 Methodology 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
  58. 58. Chapter 3 Methodology 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
  59. 59. Chapter 3 Methodology 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
  60. 60. Chapter 3 Methodology 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
  61. 61. Chapter 3 Methodology 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