d21 – user requirements 04/11/2004 › ... › deliverables › d21-user_requirements.pdf · the...

SIXTH FRAMEWORK PROGRAMMEPRIORITY 2

Information Society Technologies

Enabling an Intelligent Natural Language Based Hubfor the Deployment of Advanced Semantically

EnrichedMulti-channel Mass-scale Online Public Services

Project Number IST-2002-507967

D21 – User RequirementsVersion: 1.0404/11/2004

HOPS- IST-2002-507967 D21 – User Requirements

- 3 -

Deliverable number D21Deliverable title User RequirementsVersion 1.04Status FinalDate of issue 11/11/2004Author BCN, LBC, COT

ABSTRACTThis document presents the general framework that has been established to approachthe elicitation of user requirements, and reports a first set of user requirements definingsome sample services to be developed and demonstrated within the project scope

KEYWORDSWP2, User requirements, RUP, artifact, Local Authority, citizen

Version Date of issue Status Comments1.0 30/9/2004 Draft Release of first

version1.01 22/10/2004 Draft Check for

inconsistencies1.02 03/11/2004 Draft Inclusion of

partners comments1.03 04/11/2004 Pending of

approvalLinguistic revision

1.04 11/11/2004 Final Signed-off in the4th Plenary Meeting


- 4 -

D21 Table of Contents1 INTRODUCTION .....................................................................................................................6

1.1 GENERAL OVERVIEW ..............................................................................................................6

1.2 CONTENTS..............................................................................................................................6

2 METHODOLOGY....................................................................................................................8

3 ANALYSIS OF PREVIOUS RELEVANT PROJECTS......................................................11

3.1 INTRODUCTION.....................................................................................................................11

3.2 METHODOLOGY OF THE SURVEY..........................................................................................11

3.3 HIGHLIGHTS OF THE MOST RELEVANT PROJECTS ..................................................................11

3.4 CONCLUSIONS ......................................................................................................................12

4 PUBLIC SERVICE DELIVERY IN PARTICIPATING MUNICIPALITIES .................13

4.1 INTRODUCTION.....................................................................................................................13

4.2 BARCELONA.........................................................................................................................13

4.3 LONDON BOROUGH OF CAMDEN ..........................................................................................17

4.4 TORINO ................................................................................................................................22

5 HIGH-LEVEL NEEDS OF LOCAL AUTHORITIES ........................................................24

5.1 INTRODUCTION.....................................................................................................................24

5.2 INTERNAL DRIVERS ..............................................................................................................24

5.3 DRIVING USER REQUIREMENTS.............................................................................................25

6 NEEDS OF CITIZENS ...........................................................................................................27

6.1 INTRODUCTION.....................................................................................................................27

6.2 ANALYSIS OF PREVIOUS CITIZENS’ SURVEYS .......................................................................27

6.2.1 Barcelona .....................................................................................................................27

6.2.2 London Borough of Camden ........................................................................................29

6.2.3 Torino ...........................................................................................................................30

6.2.4 Previous Surveys general conclusions .........................................................................31

6.3 HOPS SPECIFIC SURVEY......................................................................................................31

6.3.1 Overview ......................................................................................................................31

6.3.2 Methodology for the HOPS Specific Survey ................................................................32

6.3.3 Analysis of preliminary results of HOPS specific survey.............................................33

7 SAMPLE SERVICES..............................................................................................................34

7.1 INTRODUCTION.....................................................................................................................34

7.2 SAMPLE SERVICE FAMILIES..................................................................................................34


- 5 -

7.3 SCHEDULING OF SAMPLE SERVICES ......................................................................................35

7.4 FIRST SAMPLE SERVICES ......................................................................................................37

7.4.1 Introduction..................................................................................................................37

7.4.2 Cultural Agenda ...........................................................................................................38

7.4.3 Large Things Collection...............................................................................................43

8 REQUIREMENTS SPECIFICATION..................................................................................51

8.1 INTRODUCTION.....................................................................................................................51

8.2 REQUIREMENTS IN HOPS.....................................................................................................53

8.2.1 Artifacts........................................................................................................................53

8.2.2 Discipline details ..........................................................................................................56

9 CONCLUSIONS......................................................................................................................59

10 REFERENCES .....................................................................................................................60


- 6 -

1 Introduction

1.1 General overview

HOPS is a three-year project focused on the deployment of advanced natural language enabledfront-end public platforms, aiming at enhancing convenient access for European citizens to theirnearest Public Administration.

The main objective is to address the mass-scale deployment of new online public servicessupported and made accessible by voice channels; the most accessible means of communicationused by European Citizens. As a natural extension, the overall architecture will also be able tosupport additional natural language based non-voice channels.

The project is based on the integration of voice portal technologies with natural languageprocessing techniques, complemented by a Public Administration sector-specific implementationof semantic web technologies.

The HOPS project pioneers in integrating these three technologies in a framework of services forthe Public Administration.

WP2 is the workpackage dealing with user requirements. The objective of this work package is togenerate a set of user requirements suitable to guide and set the basis for the further developmentand integration of operational prototypes. The activities are grouped into two subtasks, one dealingwith the production of a first set of user requirements and the other with its refinement with theconclusions reached after the evaluation coming out of the different trials.

This document, D21, has two main objectives:

- to present the general framework that has been established to approach the elicitation ofuser requirements

- to report a first set of user requirements defining some sample services to be developed anddemonstrated within the project scope

To achieve these objectives, the document: contextualises the user needs in the scenario of onlinepublic service delivery, focusing on natural language based semantically enriched services; reportsthe work performed so far; and describes the customised version of the Rational Unified Process(RUP)1- methodology adopted to gather the user requirements. A set of appendixes with the firstset of user requirements is also included. These appendices are the artifacts that are part of theRUP-based methodology adopted in the HOPS project, as described in the main document, andthey contain the current version of the permanently evolving artifacts.

The rest of the deliverables corresponding to WP2 -User Requirements (D22 – Refined UserRequirements; D23 – Final User Conclusions) will build upon the work of D21 using feedbackfrom the pilot implementations, technical specifications and restrictions encountered by thepartners, user testing of intermediate versions, and integration issues, to present a more completeset of requirements.

1.2 Contents

The rest of the deliverable is organised as follows: 1 Currently one of the main software development methodologies in use. For more information visit:http://www.rational.com.


- 7 -

- Section 2 describes the methodology followed to establish a framework to approach theelicitation of user requirements.

- Section 3 reviews and analyses previous projects relevant to HOPS, highlighting thenovelty of the application of voice portal, natural language and semantic webtechnologies to online public services.

- Given the fact that HOPS is focused on defining IST as a driver for governmentreorganization, section 4 deals with the evolution of public service delivery in theparticipating local authorities.

- Section 5 deals with the high-level needs of local authorities in terms of naturallanguage based semantically enriched online public services, describing a set of drivingrequirements for the whole project.

- Section 6 describes the effort devoted to understand citizen needs in terms of naturallanguage based semantically enriched online public services. A HOPS Specific surveyis described. As the timelines to perform the survey on each participating authority arenot in line with the D21 delivery date, some partial analysis of the preliminary resultsof the survey in Torino will be provided, together with some results of previous surveysthat are not HOPS specific.

- Section 7 describes the process of how the decision was made on which sampleservices will ultimately help to achieve the goal of generating a reusable platform. Thetwo first sample services are described.

- Section 8 describes the methodology adopted to define and evolve user requirements inthe HOPS project.

- Finally, section 9 draws some conclusions about the whole activity.

In regards to appendices:

- Appendix A contains the questionnaires received, reporting the experiences of previousrelevant projects and a list of interesting projects identified.

- Appendix B contains the questionnaire designed to be the core of the HOPS specificcitizen survey.

- Appendix C contains some extra information about Camden’s citizen’s panel.

- Appendix D contains the transcripts of real dialogues demonstrating the interactionbetween citizens and phone operators of one of the sample services, the Large ThingsCollection service.

- Appendix E contains all RUP artifacts as at 30th September 2004. As the requirementsare not frozen but continuously evolving, current artifacts may have since beenupdated. The current version can be downloaded from the HOPS RUP-based site, athttp://rup.hops-fp6.org. Extra information on how to access the RUP-based site (whichis password protected) can be requested to [email protected].


- 8 -

2 MethodologyThe participating cities have been in permanent contact in all WP2 activities and have decided on asequence of actions to achieve a requirements definition framework suitable to be used during thewhole life of the project. This section is a description of the work that the participating cities havecarried out to agree on a set of high-level drivers, a usable and easy to follow process, and a clearunderstanding of the success criteria for each administration.

Bridging the technological gap

The innovation of the HOPS project makes it very difficult to identify the user requirements fromthe very beginning of the project. The users do not yet know the possibilities of the technologies.To solve this technological gap, the first activity that the cities have undertaken has been a surveyof the existing knowledge, basically a survey of related literature and projects. The interest of thestudy of previous projects is twofold: on one hand, it allows for familiarisation with thepossibilities of the technologies, thus helping each city’s team have a clearer idea of what can bedone with this kind of technology. On the other hand, this activity helps to identify what the mainstrengths of the HOPS approach are, those that give HOPS a unique market position. Section 3describes with more detail the methodology used to perform analysis of previous projects whosescope is similar to HOPS, and draws the main conclusions of this study. The study identifies thatthe most relevant strength is the fact that HOPS aims to apply the integration of the three advancedtechnologies to the mass-scale deployment of public services, and not to other kind of services.

Putting HOPS into context

The application of HOPS to the specific domain of public services gives an opportunity to studythe impact of the HOPS technology in the reengineering of online public services. In this context,public service delivery in each of the participating authorities has been analysed to serve as aframework for the scope of the services that HOPS will address, and also for other Localauthorities interested in this technology to compare their service delivery with the participatingcities’ experience. Section 4 aims to report this analysis describing the scenario of the participatingmunicipalities in regards to their delivery of public services and the change management andreengineering methodologies they use for their applications.

Selecting a methodology for user requirements

In parallel with the analysis of previous projects and the description of the service deliveryscenario, a decision on the best suitable methodology to identify and evolve user requirements hasbeen endeavoured. This decision has been based on a review of literature on user requirements,and on the hands-on experience of partners in the identification of user requirements in largeprojects.

HOPS is a complex and innovative project, and therefore it is not easy to identify the userrequirements from the very beginning of the project. In a project like this, the use of a traditionalapproach based on a waterfall lifecycle is not recommended. The traditional waterfall lifecycleusually consists of the following steps:

- Identify and fix a complete and final set of requirements that will be fixed

- Design a system based on these requirements

- Implement the system according to the design

This approach, reported in [5], is not suitable to manage the requirements of complex andinnovative projects, mainly because the users do not know the possibilities of the technology at thestage of the definition of the user requirements. Currently, nor in the general case is the use of awaterfall lifecycle recommended. A two-year research project published in the MIT Sloan


- 9 -

Management Review [1] identified the iterative development (as opposed to the waterfalllifecycle) as the first key factor in successful software projects.

The iterative development provides the following benefits (according to Larman [4] ):

- Reduction of high risks (requirements, objectives, technological, usability)

- Visible progress in the initial stages

- Early feedback, user involvement and refinement of the system according to the user’sperception

- Efficient complexity management: the team can start working before finishing the analysisof complex aspects

- Reuse of knowledge acquired in previous iterations

These benefits clearly support the choice of an iterative development and requirementsmanagement model. The Unified Process [2] combines commonly accepted best practices as partof an iterative lifecycle or risk driven development in a consistent and well-documenteddescription. The Rational Unified Process (RUP) [3], a refinement of the Unified Process has beenadopted as the base methodology, and it has been customised for the actual needs of the HOPSproject. A detailed description of the customisation of RUP to conform the HOPS methodology toidentify and evolve user requirements is included in section 8.

High-level needs of Local Authorities

The HOPS project presents a series of challenges for the Local Authorities, namely:

• How to agree on a common vision, from a public service delivery point of view, for aproduct based on evolving technology?

• What are the internal drivers for each local authority?

• How to effectively cross-fertilise efforts with other local authorities which operate in adifferent way?

• How to maintain a balance between the internal demands of the authorities, the interest andcapabilities of the technical partners and the guiding principles of the project as a whole?

In order to answer these questions the cities worked together, meeting on several occasions todiscuss positions and understand priorities.

The main results of the approach to these challenges are:

• Agreement on a common vision, understanding of internal drivers and setting up of a list ofdriving requirements, as described in section 5.

• Sample services as a means to achieve the high level goals of the authorities, through anaccurate design of the scheduling of sample services, as described in section 7.

Citizen needs

With regards to the citizen needs, the cities agreed early on that a survey would be the best way totarget the citizen and understand their needs and expectations in the area of public service delivery.

First of all, an analysis of relevant existing surveys conducted by the cities has been carried out.Then, a HOPS-specific survey was designed to be carried out in the three participating cities. Theresults of the HOPS-specific surveys will be further analysed in future deliverables. Section 6gives more details about the citizen survey process and outcomes.


- 10 -

Evolving requirements

Requirements will not be frozen, but will be continuously evolving. The first user requirementsdelivered as an appendix to this document are just a picture of the requirements at the end ofSeptember 2004, but will kept up to date on the RUP-based website that has been created (seehttp://rup.hops-fp6.org). That is, this document only contains the first user requirements identifiedso far, which will evolve during the life of the project.


- 11 -

3 Analysis of previous relevant projects

3.1 Introduction

The Information Society Technologies fifth framework and sixth framework programmes fundedtwenty-seven projects that have been identified as having relevance to the HOPS project. That is,they have dealt with voice portals, natural language processing (NLP) or semantic webtechnologies, in some cases two of these technologies, or have addressed the improvement ofpublic administration services for the citizen. These projects were found on the CORDIS websitehttp://www.cordis.lu/ist/projects/projects.htm.

3.2 Methodology of the Survey

The survey of previous projects focuses on EU-funded projects. A questionnaire was sent to eachidentified project. However, the response rate was poor with only six replies received. We believethis is due to the fact that most of the projects have already been completed.

These six completed questionnaires can be found in section 8.1 of the Annexes.

As a result of the poor response rate, we have incorporated information on each project from theproject’s website, which can also be found in section A of the Appendices. The list does not intendto be exhaustive, but to give a qualitative impression of the scope of a sample of previous projects.

3.3 Highlights of the most relevant projects

18 projects deal specifically with only one of these areas; 10 explore the use of semantic webtechnologies, 5 provide voice portals, and 3 deal specifically with NLP. Only 4 projects of 27 lookat more than one area. The following projects are of specific interest to the HOPS project due totheir similarity in the use of technology, or they have a similar end user of the project’sdeliverable.

The IMAGINE2 (Interfacing Mobile Applications with Voice Natural Language Interface) projectuses both voice portals and natural language processing to develop software technology that allowselectronic interaction with business applications using a multilingual natural language interfacefrom mobile devices and other appliances.

The BASURDE3 (Spontaneous Speech Dialogue System In Limited Domains) project aimed toincorporate both voice portals and natural language processing to develop an oral human-machineinterface, by way of dialogue, for a semantically limited task (for instance: queries into a databasewith information regarding train information).

The C-CARE4 (Continuous Care) project uses both voice portals and the semantic web, aiming todevelop tools in support of continuity of care by collecting and storing essential, relevant and up-to-date patient health-related information accessible to authorised users, any time anywhere.

The MEANING5 (Developing Multilingual Web-scale Language Technologies) project usessemantic web technologies and NLP which is focused on automatically collecting and analysing

2 http://www.hltcentral.org/projects/detail.php?acronym=imagine3 http://necio.dsic.upv.es/4 http://www.telepolis.be/c-care/5 http://www.talp.upc.es/TALPCatala/index.html


- 12 -

language data from the WWW on a large scale, and building more comprehensive multilinguallexical knowledge bases to support improved word sense disambiguation (WSD)

The MAP 6 (Mobile Adaptive Procedure) project looks at providing prompts for publicadministration employees to assist them with the answers they provide to a citizen’s query,however, it only addresses the semantic web.

The EU E-gov7 project addresses the improvement of government services for the citizen byaiming to create a platform for ‘one-stop’ interaction between the citizen and publicadministration. However, this project uses none of the three technologies used by the HOPSproject.

The QUALEG8 project looks to improve the transparency of local government by creating a‘policy lifecycle management’ software solution. This will improve the citizen’s perception oflocal government, but the product itself will not have an immediate impact on the servicesprovided to the citizen, nor is it aiming to use the advanced technologies explored in HOPS.

3.4 Conclusions

These earlier projects are very interesting case studies for the HOPS project, however none havetackled the use of all three technologies simultaneously. Unlike these previous projects, HOPSwill be incorporating natural language processing with voice portals as well as semantic webtechnologies to deliver a citizen-friendly portal for the delivery of public administration services.

The partners from the 27 projects have been a mixture of organisations each with their ownspecific drivers and objectives. Most have been led by either an academic institution or by aprivate company, hence in the case of the former they are driven by funding for research, and inthe latter, they are driven by the potential to commercialise the deliverables. The products of theseprojects is catered to specific audiences, that is, those organisations that already have a high degreeof expertise with these technologies, and will be looking to improve the services they provide totheir customers.

HOPS, in this respect, stands out as a unique project in that the system will ultimately improve theservices for citizens in a highly accessible way. In the particular case of HOPS, the citizen is thecustomer. No other project looks to improve the performance of public sector organisationsthrough the use of voice portals, NLP and semantic web technologies, in a highly accessible way(through the use of a telephone) like HOPS.

The aim of the HOPS project is not only to improve citizen-public administration interaction, butis also led by three leading local authorities, each highly regarded and with a great deal ofexpertise in service delivery and in the use of new technologies. Coupled with the partnership ofsome of the world’s leading technical developers, the HOPS project is a unique example of a trans-national partnership of organisations that are leaders in each of their fields. Ultimately, therecipient of the benefits of this unique undertaking will be the citizens of three major EuropeanCities; London, Torino and Barcelona.

6 http://www.forumpa.it/archivio/1000/1200/1230/1239/map.htm7 http://www.egov-project.org/8 http://www.qualeg.eupm.net/my_spip/index.php


- 13 -

4 Public Service Delivery In Participating Municipalities

4.1 Introduction

As the survey of previous projects revealed, one of the things that make the HOPS project differentto other previous experiences is the scope of the applications that it aims to address. Theapplication scope of the HOPS project is the main aspect that makes HOPS different from otherexperiences. It has very clear boundaries on its scope: public services delivered by LocalAuthorities.

Local Authorities participating in the HOPS project have a remarkable experience in providingpublic services to their citizens, and in using technological innovations to improve their internalprocesses. Unlike previous projects dealing with voice, natural language and semantic webtechnologies, in the HOPS project there is an important fourth dimension, which is the know-howin the delivery of public services, which should ultimately drive the research, development andintegration of the enabling information and communication technologies.

This section aims to describe the scenario of each participating municipality in regards to thedelivery of public services and the change management and reengineering methodologies that theyuse for their applications. After a short historical introduction, the current state-of-the-art servicedelivery in each of the participating Municipalities is analysed, along with the strategy for the nearfuture. The reengineering methodologies and the introduction of new services is also analysed.

This section will give a global picture that illustrates the framework in which the HOPS Platform9

will fit, thus providing important information helping to contextualise the user requirementsexpressed by the participating authorities.

4.2 Barcelona

Historical introduction

The Municipality of Barcelona has pioneered delivering innovative public services for a long time.

In the eighties, the Municipality of Barcelona became an important producer, gatherer anddistributor of information. In that time, the information was only provided to the citizens throughcustomer service offices. For that reason, the need to develop a sound architecture allowing the useand update of this information -fully integrated in corporate databases- emerged. As a result, in1985 the 010 telephonic platform was created to allow citizen access to the municipal and cityinformation through a one-stop telephone number. This was a pioneering service at that timebecause it not only offered transparency of information but also became a fully citizen-oriented

9 In the HOPS Project, as far as the user requirements are concerned, HOPS Toolkit, HOPS Platform andHOPS Application has been considered as synonims, as defined in the HOPS Glossary (see the artifact inAppendix E):

“The HOPS Platform is an integrated solution utilising Voice Technologies, Natural Language Processingand Semantic Web to deliver online public services to citizens. The HOPS Platform consists of:

-A hardware/software environment to deliver HOPS Services to the citizen

-A set of tools to facilitate or automate the production of resources needed to produceHOPS services”


- 14 -

service. The interaction between the citizen and the Municipality was extremely improved in 1990when information systems allowing transactions over the phone were developed.

By the mid-nineties, the introduction of a third channel based on the internet was considered,which had to be integrated with the available technology. In 1995, the first release of theBarcelona website was launched. From the very beginning, a lot of information in the corporatedatabases used by 010 operators was exposed in the website, providing computer access to a hugeamount of information that previously was only possible to get by visiting the citizen serviceoffices or calling to the 010 telephone number.

In 1997, some two-directional procedures based on the downloading of forms were introduced,and by 1999 full transactions were already possible for some administrative procedures.

The creation of the web site was very successful and the internet was the soundest consolidatingchannel. Progressively, new online transactions and more services were included, relating totraffic, environment, transport, education and citizen participation, to mention some examples. In2000, the website incorporated the realization of administrative transactions and payments ofseveral rates and municipal taxes. From that time, the Municipality of Barcelona has been steadilyincreasing the number of available online procedures, showing a clear strategic interest in e-Government.

The three main channels (website, phone and presential) have been increasing their benefits andattentions, and consequently their take-up by citizens. The chart below shows the evolution of theuse of the different channels over the last five years.

0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

1999 2000 2001 2002 2003

Calls answered by010

Queries attended to inperson by OACs

Visits to the Municipalwebsite

The procedures requested over the phone and over the web are shown in the chart below.


- 15 -

0

200000

400000

600000

800000

1000000

1200000

1999 2000 2001 2002 2003

Administrativeprocedures over thephone

Procedures requestedover the web

The increasing demand for new online public services and the will to keep integrated centraliseddatabases -that are updated according to distribution- led to the creation of the MISS platform(Multi-channel Integrated Service System) which consists of the integration -in a network mostlybased on internet technology- of all citizen service channels that the Municipality of Barcelonaoffers, such as its website, its 010 phone platform connection to internal databases and themunicipal departments network. The HOPS project is seen as an opportunity to extend thisstrategy further, allowing for voice and natural language access to automated services.

Service delivery today

Currently, the Municipality of Barcelona offers an important portfolio of informational andtransactional services. All access channels share unique databases. Thanks to these extensivedatabases, it has been possible to develop applications, services and products unified for the threechannels, and services can be requested through the website, the phone (010 and Audiotext) or theinformation offices to the citizen (OACs).

The on-line services that are on offer today can be categorised according to their informational ortransactional dimension.

Services and information about the city: citizens can find information such as city maps,facilities location, agenda of events, phone directories, educational centres or healthservices. Also, information about the more than 600 administrative procedures (both fromthe Municipality itself and from other public administrations) is provided.

Online administrative procedures: there are a number of administrative procedures that canbe requested online. More than 60 administrative procedures can be performed through thewebsite, and the 010 offers even more. The scope of the services covers virtually all theareas of the local government. Some of the areas are listed below with some relevantexamples:

Vehicles and transportation: Request of transportation card for retired people

Commerce and industry: Consultation of the state of business activities license requests

Business activities: Starting of a business activity in Barcelona

Image and Communication: Request for videos and pictures of the city, as well as thecorporate communication standards

Education: Registration in primary and secondary schools


- 16 -

Taxes and finance: Change of fiscal address, payment of fines, and payment ofmunicipal taxes.

Cleaning services: Large things collection service

Population and citizen participation: Registration of changes in the municipal census

Town planning: Consultation on the state of a building license request

Street: Notification of a move

An example of a recent initiative to gain transparency and to provide a better online service hasbeen the Barcelona Citizen’s Folder Service. The Barcelona’s Citizen’s Folder service has beendesigned to personalize the citizen access to public services whilst facilitating completetransparency of access to all citizen information and related services. The interface focuses entirelyon the citizen’s perspective.

The project supplies the citizens all (and only) the information the City Council has recorded aboutthem, which is permanently updated, be it personal or fiscal, whilst guaranteeing and fulfilling allprivacy requirements as imposed by legislature. Therefore citizens can see at a glance with alltransparency their entire personal relationship with the City Council.

The project’s philosophy implies a substantial change in the paradigm in that now the citizenbecomes the core focus of the service, displaying all information and actions, completelypersonalized to their own and individual reality. The service presentation is made from thecitizen’s perspective, making the citizen’s access easier, intuitive and totally accessible.

The importance of reengineering

Some technological advances provide the opportunity to rethink administrative procedures. Anexample of the recent reengineering of a procedure that resulted in a clear benefit has been thereengineering of the procedure of the requests for licences to open a new commercialestablishment. The reengineering of this procedure has resulted in a dramatic shortening of itsoverall duration, the elimination of most of the manual a priori technical verifications, the instantprovision of almost 70% of the total requests and the overall simplification of the complete processand all related documentation.

The reengineering project has enabled the City of Barcelona a by-default instant acceptance ofabout 70% of the total requests for licences for opening new commercial establishments.

Before the project, the overall procedure duration for a licence grant varied from 2 up to 4 months,for an amount of around 4700 licence requests per year. Currently about 3200 licence requests peryear can be given instantly to the citizen when they submit the application, as the new procedureallowed securing that no risks are entailed.

The project has automated all the a priori technical controls and the validation process in itself.The automation combines both the specifics of the requested licence and the physical addresswhere the activity is to be developed, fully complying with all applicable legislature.

The application has also allowed staff with a non-technical profile to properly deliver the grantingof licences. Thanks to the project, a procedure, which previously took months, has now become aformality delivered within minutes.

Additionally, the system also allows every citizen to directly engage in consultations aboutwhether it is possible to initiate a commercial activity at a specific address. This new service isreceives around 15,100 annual consultations.

In another scope of action, the project “e-Transformation for citizens’ empowerment” has tackledimpressive reengineering of the existing content production, resulting in a total reorganisation ofthe operational procedures. The project has also faced a migration process in order to consolidate


- 17 -

the existing disaggregated websites into a common and shared municipal infrastructure and portalumbrella.

Barcelona is now providing citizens intuitive and agile access throughout a single and flexibleportal to a wide and increasing variety of integrated municipal websites, due to the adoption of amulti-site content management strategy resulting in extensive and comprehensive contentreengineering and integration.

The provision of a unified single access point consolidating a galaxy of municipal websites isconsidered to be of significant importance in order to allow citizens to access municipalinformation and services. The idea behind http://www.bcn.es is not only to be the website of theMunicipality of Barcelona, but to also become the website of the city.

The HOPS project is seen as another opportunity to rethink and improve the modes of interactionwith the citizens and the delivery of online public services.

4.3 London Borough of Camden

Introduction

Camden is one of 32 London Boroughs that are responsible for the delivery of a variety of publicservices in the capital. Situated in central to northwest London, Camden’s community of nearly200,000 contains some of the greatest diversity of ethnicity and income in the United Kingdom

The London Borough of Camden has been a high performing authority, receiving the highest“excellent” rating from the inspection by the central government agency responsible for assessingpublic services; the Audit Commission.

Camden’s success has been largely built on strong services, with skilled professionals in the fieldsof Housing, Environment, Education and Social Services identifying strongly with theirdepartments and recognised for the effectiveness of their work. However the change agenda ingovernment in the UK means that the traditional ways of working are no longer the best way tomeet some of the challenges that Camden now faces.

The Council has recognised this and one of four priorities for the 2004-5 financial year is the“Serving Camden” programme. This work is the co-ordination of a series of projects, which aim totransform the way services are delivered and make the organisation more “customer orientated”.Electronic Service Delivery is a key component of this work.

Electronic service delivery

The importance now placed on electronic service delivery by central government has never beenas great. All public services have requirements to pursue the electronic agenda to modernise theway they work.

There have been two main drives that have made electronic service delivery the most importantway services are changing and will be changed:

• The drive for customer orientated government

• The drive towards the Knowledge Economy.

These two drives have resulted in the national framework and context within which Camden isaiming to deliver services electronically.

The drive for customer oriented government


- 18 -

In 1999 the United Kingdom government published plans to modernise public services. The aimswere to move away from services arranged to suit the service provider and instead made sure that“citizens and businesses come first”10.

The government believed that its citizens expected more of the services paid from their taxes.They felt that services were not being delivered in ways that citizens wanted. The various differentorganisations, departments and divisions providing services to the public did not work togethereffectively from the citizen’s point of view. Services were not pro-active or responsive to theneeds of customers, instead delivering one-size-fits-all services in age of greater individual needand demand.

Instead the government proposed that the citizen should be at the centre of relationships withpublic agencies. Citizens should be able to give their information just once to an organisation andnot every time they interact with a different service. They should be able to contact services howand when they wish. Services should be responsive and adaptable to the needs of citizens. Theyshould not deliver services within their own narrow remit but work in partnership with other publicorganisations, charities, the private sector and community groups and individuals.

The drive towards the Knowledge Economy

The importance for the UK to embrace the information age and to become a leading member of theKnowledge Economy has also been a key feature of the government’s modernising plans.Speaking at “Knowledge 2000”, a government sponsored conference, Prime Minister Tony Blairsaid:

“I strongly believe that the knowledge economy is our best route for success and prosperity.” 11

The Prime Minister set out three goals to ensure that the UK would be well placed to reap therewards of the Knowledge Economy:

• To be the best place in the world for e-commerce

• To get universal access to the internet

• To put all government services online

Public sector agencies have been set various targets and have been given different deadlines tomeet these goals. There have been huge change programmes in agencies as diverse as the NationalHealth Service (NHS) and Customs and Excise.

A central government division was created to oversee and drive this body of work across all areasof government – initially called “The Office of the e-Envoy” and now renamed as the “e-Government Unit”. This has worked with relevant departments in setting out the requirements fordifferent public services.

In the case of local government, the central government department responsible is the Office of theDeputy Prime Minister (ODPM).

As local government delivers over 70% of government services12 and the greatest variety ofservices13 this represents a significant challenge and has required a national framework to supportall authorities in meeting the targets and improving the delivery of services.

10 Modernising Government UK White Paper - http://www.archive.official-documents.co.uk/document/cm43/4310/4310-03.htm

11 http://www.dti.gov.uk/knowledge2000/blair.htm


- 19 -

The national framework and context for local government

Both the customer orientation and the knowledge management drives have results in a set ofrequirements, targets and standards that all local authorities need to meet in order to secureadditional funding, receive favourable ratings through a Council-wide assessment by auditors or aspart of legal requirements.

Included in this agenda have been changes to the political structure of local government and thefunding mechanisms for some services. Electronic service delivery has been one of the largest andmost complex areas.

Electronic Service Delivery Targets

Delivering Services Online

The government drive to have all services online is a formal national target. These national targetsare called “best value performance indicators” (BVPI) and the one relating to electronic servicedelivery is number 157. For this reason the target is usually referred to as “BVPI 157”.

Each service provided by local government is made up of a series of processes. For each of theseprocesses, there are a number of potential transactions that can be made – such as paying forservices, making an application and so forth.

The target is therefore to deliver each of these interactions, for each of the processes,electronically. The BVPI 157 target is expressed as a percentage of services deliveredelectronically – called “e-enabled”. All authorities must reach 100% e-enablement by 2005.

“Priority Service Outcomes”

The aim for the delivery of services online was not simply to provide an alternate route for citizensto interact with the authority. The goal was for the introduction of online services to be a driver oforganisational change, enabler of joined-up services for citizens and a means of creating efficiencysavings by translating reduced costs dealing with interactions into spending on priority areas orsavings.

In order to ensure that the process of “e-enabling” will provide distinct outcomes that are of valueto citizens and businesses government therefore set a series of specific requirements out in April2004, called “Priority Service Outcomes”.

These are similar to the BVPI 157 targets but go into more detail. Not only must all interactions bee-enabled, but also certain outcomes have to be provided for the citizen. For example, it is notenough to allow a benefits query to be submitted online; the Council must provide a one-stop shopfor all benefits queries to customers14.

Investment in solutions

The government has recognised that the targets to deliver services online are challenging to localauthorities. The central government department responsible for local authorities, the Office of theDeputy Prime Minister (ODPM) has therefore invested in three main programmes of activity tosupport electronic service delivery. 12 Source: SOCITM (http://www.socitm.gov.uk/NR/rdonlyres/33D84BED-A1E4-40B8-A3D7-3EFACEB21F6E/0/IntermediariesconsultationFinal.doc)

13 Source: ntl (http://business.ntl.com/en/resourcecentre/display_article.jhtml?categoryarticle=&articlename=E-Government&file=129)14 ODPM Priority Service Outcomes


- 20 -

Implementing Electronic Government funding

The government has made a significant amount of funding available each year since 2001 forauthorities that complete an Implementing Electronic Government (IEG) statement. This describeshow the authority is progressing against the BVPI 157 target of delivering all serviceselectronically. It also sets out how the funding will be used to ensure that the target is met byDecember 2005.

Pathfinders and National Projects

Delivering services electronically requires new kinds of systems and changes to past ways ofworking. They require investment and often a large element of risk.

“Pathfinders” and “National Projects” were a means of providing solutions for the localgovernment community. They identified different issues that had to be addressed in tackling thechallenges of electronic service delivery. They brought together the expert ability of localauthority, public and private sector organisations to complete different projects.

The first round of these projects were called “pathfinders”. The outcomes were then built onthrough “national projects”. Outcomes have included systems, guidance, networks andinformation.

For example, Camden led a pathfinder project of which one product developed was the APLAWS(Accessible, Personalised Local Authority Web Sites) Content Management System15. Camdenthen worked with other authorities on the LAWS national project16, which “productised” some ofthe outputs of the APLAWS pathfinder. These included providing generic content for localauthorities, so that when they introduced the APLAWS content management system they wouldhave existing content ready to edit.

These national activities are seen by the ODPM as key to enabling local authorities to deliverelectronic services. By providing these generic solutions the aim is to avoid expensive andinefficient exercises in “reinventing the wheel” whilst still allowing authorities to act in principlewith the priorities for their own communities.

National Standards

A key element of the government’s electronic service delivery agenda is ensuring that differentpublic sector agencies are able to be “joined-up” in the way they delivery services. For example, ifa citizen submits a claim for income support then they should not have to provide the same set ofinformation and go through the same set of checks when they also apply for Housing Benefit.

To allow this kind of innovation to happen there has been an emphasis on developing a set ofnational standards for electronically delivered services. The Government Metadata Standard (e-GMS) ensures that all information is categorised in the same way. The GovernmentInteroperability Framework (e-GIF) aims to ensure that all systems are capable of “talking” toeach other.

Local government therefore has to comply with these standards when it delivers its serviceselectronically. The e-Standards Body17 is responsible for ensuring that existing projects, productsand services can be exploited and is largely made up of local government professionals.

15 For more information about the APLAWS Pathfinder project please visit http://www.aplaws.org.uk/home/index.php

16 For more information about the APLAWS Pathfinder project please visit http://www.aplaws.org.uk/home/index.php17 For more information about the e-Standards Body please visit http://www.localegov-standards.org/default.htm


- 21 -

Electronic Service Delivery in Camden

The framework and standards described above detail the context in which Camden operates.Achieving the targets for electronic service delivery is important to the Council, and Camden hascontributed widely to the national agenda for electronic service delivery.

However, the main priority for the Council is about providing better services for the community,and all the efforts that Camden puts into national and European projects have this outcome as thecore reason.

Current electronic service delivery projects in Camden include the rollout of the APLAWS contentmanagement system throughout the Council – providing a means for non-technical staff to updateweb pages and therefore produce more timely and accurate information to the public. The Councilis also investigating an e-procurement system aimed at making efficiency savings throughreducing administration costs and better leveraging the purchasing power of the authority throughcentrally orchestrated contracts.

The electronic service delivery project given the highest priority in Camden - which theinvolvement in the HOPS project is in part a reflection of - is the expansion of the CustomerService Centre.

Expanding the Customer Service Centre

The Customer Service Centre is the name given to the Council’s corporate telephone contactcentre. It was established originally in 2002 with five high volume services, such as payment ofcouncil tax, able to be dealt with in one phone call.

The leadership of the Council has made expanding the Customer Service Centre one of its keypriorities as part of an organisation-wide programme aiming to make the Council more customer-orientated. This programme, called “Serving Camden”, aims to improve the experience thecustomer has of the Council. The choice of “customer” reflects that businesses and externalagencies, as well as residents and service users, are recipients of Camden’s services.

The Customer Service Centre expansion will also involve meeting targets under BVPI 157 and thePriority Service Outcomes. In May 2004 the Council approved plans to expand the Contact Centreto incorporate 60 services by 2005. This will involve the procurement of Customer RelationshipManagement (CRM) software, changing the ways that services are currently delivered and joiningup the delivery of discrete services to a more customer-orientated, holistic experience.

The involvement in the HOPS project is therefore a means for Camden to learn from the approachof two leading municipalities on call centres. It provides an opportunity to understand, contributeand influence the development of exciting new technology and to gain the best outcome forCamden’s customers.

The future of electronic service delivery in Camden

Camden does not see fulfilling the electronic service delivery targets as the ultimate aim of thiswork. Nor is the development of technological capability. Electronic service delivery, and theHOPS project, are ways in which Camden is seeking to use innovation and technology to deliverbetter outcomes for its customers.

Much of this work will emerge from a “Customer Service Strategy” produced from the ServingCamden project. This aims to provide an account for the improvements to be made for all thedifferent ways that customers want to deal with the council. It covers work in Camden on BVPI157 and the Customer Service Centre as well as identifying the need for a rationalising of face-to-face reception points, and new standards of customer care for all front-facing staff to adhere to.


- 22 -

It is also expected that there will be a great deal more integration between public agencies inproviding interaction routes, as the different technical standards become enshrined and theemphasis given to greater customer-orientation makes an impact on the way that service deliveryis perceived. This is already starting with national projects such as Direct.gov18 aiming to providean entrance portal for customers of any public service.

Finally, the investment that has been put into the different solutions needs to have some return oninvestment. The intention has been that through modernising services and providing more accesschannels, many of which transfer the administrative cost to the customer, more resources can bereleased to front-line delivery and savings made in administrative costs19. The next phase forelectronic service delivery is therefore likely to have the twin aims of encouraging more people tomake use of the different access channels and realising the ensuing efficiency savings.

4.4 Torino

The City of Torino is the main town in the Piedmont Region, a highly developed area in the NWpart of Italy. Torino’s municipal area counts over 900,000 inhabitants settled over 130,17 Km2,while the metropolitan area is wider and includes over 50 smaller municipalities with about 1.7million inhabitants.

Torino has an economically dynamic environment and the whole area is experiencing quite acrucial period. In fact, the socio-economic pattern is deeply changing, moving from being the mainItalian automotive industrial district to becoming an innovative district based on high-leveleducation, research, and tourism.

The local public administrations, and in particular Torino Municipality (www.comune.torino.it),has a strong role in the town’s regeneration process. The City’s overall strategy, which contributesto the regeneration process is presented in the City Strategic Plan; an integrated development andpromotion plan called “Torino Internazionale” (www.torino-internazionale.org). Within this plan,ICT are a cross-cutting tool that affects most of the action lines in the plan.

The City Municipality is committed to supporting the development of the digital economy, as itconsiders the physical transformation into an ICT district to be highly strategic. “Digital economy”is meant in a wide sense: it includes not only TLC and ICT companies, but all ICT-based servicesand activities that are performed by public bodies, local public administration, non-profitorganizations, and the private sector, both as suppliers and as users. We can say the City ofTorino’s e-strategy is addressed to two main lines of action: on the one hand the Municipality aimsto improve the administration of the organization and the citizens’ quality of life through thesupply of e-government services; on the other, Torino Municipality supports local economydevelopment through actions addressed at companies and opportunities for business; SMEs andstart-ups in particular.

The Torino Municipality has been investing in ICT-based services and infrastructures since the‘50s, (an internal EDP Centre was set up after WWII) both for internal organization and for e-government services. In the ‘60s it was the first city to use magnetic tape. In 1970, the City ofTorino was the first Italian city with a real time terminal delivering certificates in populationregistry, and in 1977 all internal budget procedures were set up in a teleprocessing environment. In 18 Please see http://www.direct.gov.uk/Homepage/fs/en

19For more information please see the Gershon report, “Releasing resources to the front line”, http://www.civil-service.gov.uk/reform/documents/efficiency_review120704.pdf


- 23 -

mid ‘95 all EDP services were outsourced to CSI-Piemonte, starting a long running project tochange all mainframe procedures to a client server architecture. Investments in ICT services havebeen assessed up to 30m € per annum since 1999. All major procedures are computerised. Someinternal assets are excellent: for example, a civil servants digital expertise is certified by ECDL;most computer-based services can be considered innovative and examples of “good practice” (e.g.detailed technical mapping, population registration, and online service provision through theTORINO FACILE card are examples of excellence); resources, such as application-oriented webarchitectures and a widespread intranet spanning all of the municipality’s premises, are in line withthe goal of improving the administrative organisation through ICT.

In several cases, the results’ excellence has been recognized and awarded, both on a national andon an international level. It is worth mentioning the award in the “From Policy to Practice”European Commission November 2001 event. Last but not least, CENSIS 2004 'Rapporto sullecittà digitali' (Digital cities report), published on September 23th, 2004, places the TorinoMunicipality website in first position in Italy, following an extensive evaluation of Italian citieswebsites, both considering the number of services available and overall quality of the site.

The official website, launched on November 1994, is currently viewed by 125,000 unique visitorsper month. In 2003 more than 40 million pages were read by users, with more than 1,100 GB ofdata transferred.

Services vary from simple information to advanced user interaction; from city procedures to userdigital identification to access personal data.

The City website aims to be accessible and usable, using XHTML and CSS2 to deploy a betterpresentation. Aside from the official site, in 2001 a focused site devoted to cultural agendainformation was set up: www.torinocultura.it. It is based upon Oracle portal technologies, with allinformation saved in database tables, making it possible to syndicate news (rss/xml format) or tohave them in a structural framework to be used through multi-channel delivery.

This architecture makes it possible to design a new way to access data, in the form of a voiceportal application.

In preparing the city’s website for the 2006 Winter Olympic, voice access to the cultural agendawill allow for the testing of the effectiveness of this solution.


- 24 -

5 High-level Needs of Local Authorities

5.1 Introduction

As described earlier, the HOPS project presents a series of challenges for the Local Authorities:

• How to agree on a common vision, from a public service delivery point of view, for aproduct based on evolving technology?

• What are the internal drivers for each local authority?


• How to maintain a balance between the internal demands of the authorities, the interest andcapabilities of the technical partners and the guiding principles of the project as a whole?

In order to answer these questions the cities worked together, meeting on several occasions todiscuss positions and understand priorities. One of the first steps was to agree on a common vision:

“HOPS not only has to provide some operational sample services developed over aplatform, but it must also provide tools allowing Local Authorities to develop new serviceswith their own resources or their usual technological partners (not voice, NLP or semanticweb experts)”

5.2 Internal drivers

The next sections describe what the internal drivers for each of the participating local authoritiesare, and report a first set of global driving requirements agreed by the local authorities. A closerview of user requirements is given in the RUP Artifacts delivered as an appendix. Internal driversfor each local authority

In order to maximise the real exploitation potential of the HOPS project, the local authoritiesdecided to get together and use problem definition and business modelling techniques to define theinternal drivers for each organisation.

This not only helped target the efforts better, it also served as a basis to build a very initialschedule. In a nutshell the internal drivers are the following:

• BCN: To own a set of tools allowing to develop mass-scale multi-channel services withtheir own resources or their usual technological partners

• COT: To develop a Cultural Agenda service and test it in the Winter Olympics in 2006

• LBC: To evaluate the “value for money” proposition of HOPS technology, to furtherdevelop the UK national efforts around public service taxonomies20, and to integrate theHOPS platform with the open source content management21 system APLAWS22.

20 http://www.esd.org.uk/standards/21 The APLAWS CMS has been a project in Sourceforge since May 2004http://sourceforge.net/projects/aplaws/22 http://www.aplaws.org/home/index.php


- 25 -

It should be clear that the satisfaction of these internal drivers is not the objective of the project asa whole. Nevertheless, these internal drivers are interesting because they can show differentpossibilities of real exploitation in the public sector of the expected outcome of the project. Thisfact can encourage buy-in from decision makers in the public sector, so whenever these particularexploitation interests are achievable following the common goals of the project, it is positive tomeet them.

5.3 Driving user requirements

Starting from the background high-level requirements stated in the Technical Annex, the LocalAuthorities have agreed on a set of global requirements that should lead the development of theHOPS solution. The following list describes this set of driving requirements that have beenpresented in different HOPS Plenary Meetings.

• Multi-channel approach

HOPS is a solution that aims to be accessible through different channels. Voice accessthrough the telephone channel is obviously one of the most important access modes,because of its high availability and accessibility by the citizens of all conditions, butthis is not the only channel that the project has to implement. Other access means, aswritten text, must be supported by the HOPS solution.

• Reusability

The features of the HOPS solution must be able to be used beyond the demonstrationservices that will be actually deployed during the project. This idea leads to the conceptof HOPS as offering features that will allow cities to build their own applications.

• Openness

All components must offer the possibility to be called from other software systems.APIs to exploit all components must be available with proper documentation.

• Extensibility

It must be easy and efficient to add or change any of the components necessary to builda public service:

§ Linguistic resources

§ Domains and business rules

§ Access channels

§ Knowledge repositories

§ Backend systems

• Quality of service

The services developed in the HOPS Platform should be able to keep the current highcitizen satisfaction (according to the surveys reported in section 6).

• Interoperability with the cities’ backend systems


- 26 -

The HOPS solution should not constrain the cities to use specific backend systems. Itshould be compatible with the existing or intended databases, application servers andcall centre components (CTI23, ACD24, and others)

• Flexible development model

The development model must allow the early use of the prototypes created during thedevelopment process, i.e. the sample services should be developed using the HOPSPlatform whenever operational versions of the required tools are available.

As already mentioned, requirements will evolve during the life of the project, and will bemaintained in a RUP website. However, this short list of core high-level driving requirements isnot expected to change significantly.

23 Computer-Telephony Integration24 Automatic Call Distributor


- 27 -

6 Needs of Citizens

6.1 Introduction

Accessing information is a daily activity for everybody: network technologies have brought anew dimension to this everyday human task. Now information seems to be at a fingertip and justsome click away. Nevertheless many people are not used to digital world. Computers maybe apainful tool, for the elderly or people with disabilities, for example. The HOPS project is seen asan opportunity to enhance the usability and accessibility of online public services.

HOPS project enters here to give the user new tools, using innovative technologies, verycomplicated on the backend, but that have to be very simple to use on the frontend. The projectgoal, indeed, is to get this final result, otherwise it will fail.

Making information available through a familiar tool may simplify the way citizens access onlinepublic services.

Voice is the first way we ask for information: it is the primary communication tool for mankind.Telephone indeed is a very simple but effective tool we are now used to interacting with.

From Meucci’s invention till today, the telephone is a completely new tool that helps our need tocommunicate. Today it is impossible for us to think about our life without a telephone. And from acultural point of view this tool is yet in our habits, in our behaviours, while computers aren’t yet.We don’t’ fear using the phone, we don’t need much instructions to call, we don’t ask ourselveshow and why it works and we don’t have to reboot it.

Voice access over the telephone reveals itself as a solution that can bring online public services tocitizens that are not computer skilled. However, there is still a cultural gap that has to beovercome. When calling a computer operated system many users change the way they talk whenreplying to a person enquiring: they use infinitive verbs, single words, rarely they speak bysentence. This a cultural behavior that will not be easily addressed.

However, voice is not the only possible access channel. Text-based interaction and other advancedchannels are possible gateways to services that should be investigated.

Understanding how people naturally express is not an easy task. One of the long term goals ofprojects like HOPS is to take these technologies at their best and to raise their accuracy inunderstanding people while behaving normally.

Getting to the citizen is important to see whether the ideas expressed so far are aligned with thereality, and to get a real impression of the preference of the citizens when contacting localauthorities. This section aims to describe the effort that has been undertaken from the beginning ofthe project to be aware of citizen preferences. First of all, an analysis of the existing citizensurveys that address the issue of preferred ways to contact their local authorities has been carriedout, as described in next section. Then a HOPS-specific survey has been designed, and although itsexecution is ongoing, there are already some results available from Torino. The issues related tothe HOPS-Specific survey are reported in section 6.3.

6.2 Analysis of Previous Citizens’ surveys

6.2.1 Barcelona

The Municipality of Barcelona regularly performs opinion polls to get the citizen’s impression ona number of issues and to draw conclusions that help to improve the service of the Municipality.


- 28 -

The “Òmnibus Municipal” is a quarterly survey in which all departments can add some questions.The Department of Citizen Attention regularly includes a set of questions of relevance to theHOPS project.

In this section the conclusions relevant to HOPS of a survey performed in March 2004 arepresented.

The questions that have been found to be relevant are:

q In which topics are you most interested when trying to get information about Barcelona?

q Which means do you use when you need information about the city of Barcelona?

q Which means would you use if you needed to make a transaction in the Municipality ofBarcelona? And if you needed information about the Municipality of Barcelona?

q Awareness / Use / Evaluation of: 010 telephone, Oficines d’Atenció al Ciutadà25,municipal website

Methodology

The methodology of the survey is statistically sound, and the technical details are as follows:

q Sample size: 1.000 interviews.

q Universe: Population of Barcelona over 15

q Methodology: Telephone interview

q Sampling procedure: Random sample according to quotas on gender, age and district,proportionally calculated from the municipal census

q Sample error: On the assumption of a simple random sampling, for a confidence level of95,5% (2 σ), and P=Q, the error is + 3,16% for the sample set.

The consultation is performed by phone, so respondants are not necessarily familiar with newtechnologies.

Results and conclusions

Respondents immediately claim that when getting information about the city of Barcelona, theirpreferred topic is information about leisure time activities (cinema, theatres, restaurants...)(47,3%). After that, information about city facilities (18,3%) and transportation (14,6%) is alsopopular. Other issues that generate some interest are security (9,2%), news (7,2%), cleaningservices (6,7%), streets (3,1%), traffic (2,9%) and others. The 4,1% are not interested at all and the11,2% don’t know. The high amount of people interested in cultural information reinforces theinterest of having a cultural agenda sample service during the life of the HOPS project.

When the respondents need information about the city of Barcelona, respondents claim that theyuse the 010 phone (23.5%), newspaper (22.4%), municipal websites (17.4%), other websites(16.3%) and the Municipal publication “Guia de la Ciutat” (15.9%). They also get informationspeaking with other people (7.1%), on the TV (1.2% in the local television channel BTV and 4.5%in other channels), in the “Oficines d'Atenció al Ciutadà” (5.1%), radio (2.8%), the 012 phone ofthe Government of Catalonia (2,4%), the Magazine Barcelona Informació (2.3%), the yellowpages, the Magazine “Guia del Ocio” and the 11888 phone (operated by a private company).

In case of needing to perform a transaction with the Municipality of Barcelona, 45.0% ofrespondents say they would go to a presential “Oficina d'Atenció al Ciutadà”, 22.9% would use 25 Offices that the Municipality has in all districts


- 29 -

010 phone, 12.1% the municipal website and 6,.7% other means. Some people answer that they donot need to perform transactions (7.4%) or that they do not know where to go (5.9%). HOPS isseen as an opportunity to offer that 45% of people that would go to a presential office thepossibility of performing more convenient transactions without moving from their homes.

In case of needing information about the Municipality of Barcelona, the 34.0% would call 010phone, 26.1% would go to a “Oficina d'Atenció al Ciutadà” and 18.0% would check the municipalwebsite. 3.6% would use the municipal publication “Guia de la Ciutat”, and 10.3 % would useother means. The rest do not need information (5.1%) or don’t know (2.9%).

As far as the awareness and the evaluation of the services are concerned,

q 98.8% of the respondents know the 010 phone, and 67.8% also use it. In a range from 0 to 10,where 0 is the minimum and 10 the maximum, 010 phone gets a 7.3 grade. Only the 5.5% givea grade lower that 5, 13.2% from 5 to 7, 28.0% from 7 to 9 and 18.5% 9 or more. This is arelevant result, because the HOPS solution must take into account the good performance of the010 call center, because those acceptance levels should be maintained even with semi-automatic solutions.

q 75.9% knows about the existence of “Oficines d’Atenció al Ciutadà”. 45.2% are users of them,while 30.7% are not.

q 54.4% know the municipal website. The 31.5% of respondents have accessed, and theiraverage grade is 7.5.

6.2.2 London Borough of Camden

We have decided to incorporate a selection of relevant results from Camden’s annual resident’ssurvey for 2003 to deliverable D21 for the following reasons:

• Although this survey is not HOPS-specific, it is a statistically valid survey, which gathersinformation on council services (transactional and informational).

• The methodology used in this survey employs in-home and street interviews for gatheringinformation, which provides an interesting complement to web and telephone surveys.

• One of the main objectives of this survey is to determine the quality of local servicedelivery. This is of extreme importance to the HOPS project, which attempts to enhanceand further develop the citizen’s perception of public services.

• This survey is a very important instrument for defining service policies by Camden’sdecision-makers. If any improvement in the results of this survey in the future can beattributed to HOPS technology it would help drive adoption and exploitation.

The annual survey addresses each borough’s resident’s opinions on three particular areas:

• Local issues of concern

• The image of the council

• Quality of local service delivery

The 2003 survey in Camden was also required to address, besides other specific issues,“Contacting the council”

The fieldwork was conducted between 3rd and 30th March 2003.

1019 interviews were conducted in-home and in street using quota sampling at 75 sampling pointswithin Camden. Those living in the borough for less than six months were excluded.


- 30 -

Quotas were set on age, gender, ethnic origin, housing tenure and working status of women. Allquotas were based on 1991 census figures. These variables were used to analyse the results,together with other factors such as presence of children, social class, working status and usage ofservices.

All interviews were conducted in accordance with the Interviewer Quality Control Scheme(IQCS), which is the market research industry standard, and were subject to a 10% quality controlcheck.

Results of the aggregate data was then used to Benchmark performance. Benchmarking is done intwo ways: firstly, by showing average trends for inner and outer boroughs; secondly, by showingthe best and worst scores among participating boroughs (11 in 2002/2003). This frames the results,providing a meaningful context for interpretation.

For the purposes of the HOPS project, within the main topic of “Quality of public servicedelivery” we have chose results from the sections addressing ‘Image of the Council’ and ‘Contactwith the council’.

Conclusions

• Regarding the “image of the council” data, there is a very high standard of 70% who thinkthe staff are friendly and polite. It is a major challenge for HOPS technology to replicatethis level of satisfaction and is perhaps one of the key factors for mass scale deployment inthe public sector.

• Regarding the “image of the council” data, there is a very high standard of 70% who thinkthe staff are friendly and polite. HOPS technology should make every effort not to affectthis perception.

• 49% feel that Camden is quick to answer when asking for help. This is another importantchallenge when evaluating the performance of the system.

• 44% feel it is difficult to phone the council. This is an excellent chance to enhance theservice through HOPS technology.

• In terms of demographics, older people are the happiest with the service. It is known thatvoice portals are not well received by this age group. This is another challenge for theproject and an interesting issue to study during pilot phase.

• A 72% of residents prefer to contact the council by telephone. This is a very encouragingstatistic, which echoes one of the objectives of the project of targeting mass scale onlinepublic services and usage of voice channel to bridge the digital divide.

• Finally, there is an interesting requirement in this survey, which could be considered by theproject: How could HOPS define a time and date and perform a call back to a citizen if itcannot provide the information immediately. 11% of Camden residents thought it would bea useful feature.

6.2.3 Torino

The city issues a regular report from ‘Osservatorio del Nordovest’ (a joint initiative with theUniversity of Torino Social Science Faculty, City of Torino, Chamber of Commerce, and otherlocal Government institutions) about public services.

Interviews are conducted regularly (each quarter) to a constant panel (5,000 individuals).


- 31 -

The last report (issued on June 2004) has focused specifically on the local government website andpublic services, analysing 5187 interviews. Comments about this report are summarised in nextsection.

6.2.4 Previous Surveys general conclusions

Since all the 3 cities have a general survey available we can first comment on these reports.

About using the city’s website: in Torino 36.3% of citizens says they use it, in Barcelona 31,.,while Camden scores a 6% (but it may depends on survey methodology and goal)

About the user’s evaluation (available information, accessibility and so), Torino and Barcelonashow a good mark: Torino 73.1%, Barcelona 73.3% from good to best evaluation.

In Barcelona citizens use the telephone to call the city OAC (67,8%) as a main tool, the sameapplies in Camden where 72% of users prefer to call, even though they have difficulties to get to.This high number of calls represents a challenge for the HOPS project and confirms its need.These services share a good evaluation. Unfortunately there is no data available on this matter forTorino: city main operators answer more than 1800 calls daily, on an average weekday.

To summarize, this first analysis confirms the City’s need to find new tools to access efficiently,easily and immediately, from simple to complex information. Using voice and phone, still a mainaccess tool, combined with interaction with the city’s information databases, may cope with thegrowing demand for citizen interaction with city departments. The opportunity to be a used tooldepends mainly on its quality and usability, and on specific service target that comply witheveryday citizen need.

6.3 HOPS Specific Survey

6.3.1 Overview

HOPS has set up a survey to analyse user needs for accessing public services data; knowing the 3cities ITC architecture and their citizens needs, we will narrow the possible services to theavailable ones.

Questions will give us an idea about which would be the user’s inclination to use voice accesswhen looking for some kind of city info/service. In reading such results some corrections may beneeded since the user’s inclinations on an abstract subject, i.e. something the user can’t test now,could vary from the reality.

Even though the survey’s questions have a unique goal, different collecting approaches have beenset up due to the city’s habits to make surveys.

While in Barcelona and Camden there are specific departments to conduct regular surveys aboutcity services, in Torino this survey has been made available, as a self-service fill in form via theinternet providing an email invitation to the city’s web newsletter subscription. The fact that eachcity has used a different methodology is relevant from the point of view of the analysis of theresults, since any bias introduced by the methodology can be reduced.

Besides demographical data, topics in surveys vary from very simple, one-way type services (suchas asking for very simple information) to more complex interactions (question-answer in whichcomputer has a record of the dialog, so it can refine its search), with database reading or writing(such as bookings or payments).


- 32 -

Firstly, user habits to contact the city’s information system were collected on selected services,both informative and transactional, (through call centres, web, email, frontdesk and so on), andthen user expectations were gathered on the use of voice access technology for those services.

Questions about using natural language to fill a form on a website and user habits when acomputerized answering machine is on, has been collected too.

11 service scenarios were set up to simplify users’ answers and to create a common playground.From the events agenda to tourism info (hotel, restaurants….), public transport, traffic info, citydepartments or procedure, booking for large furniture collection or for a frontdesk appointment.

The core questionnaire of the HOPS Specific Survey is included in Appendix B. Each city hasadapted the questionnaire to their own methodology and has planned the execution of the surveyaccording to their internal procedures.

6.3.2 Methodology for the HOPS Specific Survey

6.3.2.1 BarcelonaThe Municipality of Barcelona has a department “Departament d’Estudis i Avaluacions”responsible for the design and execution of survey and opinion polls to the citizens of Barcelona.They offer to the rest of the departments of the Municipality the possibility of performingcustomised, statistically accurate surveys to sound out the opinion of the citizens on any subjectrelevant to the internal management. This department also conducts quarterly general surveys,called “Òmnibus Municipal”, in which all departments can add some questions.

The Municipality of Barcelona has decided to perform the HOPS Specific Survey as an appendixof the periodical “Ómnibus Municipal”, thus saving the extra resources needed to perform anisolated on demand survey. The consultation is performed by phone, so respondents are notnecessarily familiar with new technologies. The core of the HOPS Specific Survey has beenadapted to the telephonic channel and to the interests of the Municipality of Barcelona.

The methodology of the survey is statistically sound, and the technical details are the following:

q Sample size: 1.000 interviews.

q Universe: Population of Barcelona over 15

q Methodology: Telephone interview

q Sampling procedure: Random sample according to quotas on gender, age and district,proportionally calculated from the municipal census

q Sample error: On the assumption of a simple random sampling, for a confidence level of95.5% (2 σ), and P=Q, the error is + 3,16% for the sample set.

The survey was executed during the second half of September 2004, and results are expected byNovember 2004.

6.3.2.2 CamdenIn order to carry out the HOPS survey, the London Borough of Camden will use its Citizens’Panel. The Citizens’ Panel is a consultative body of 1800 Camden residents. It has been set up byCamden Council, the Police and Camden NHS Primary Care Trust (PCT) as a way of regularlyconsulting and involving residents.


- 33 -

MORI26, the independent research company, recruited a wide range of local residents to theCitizens’ panel during May-July 2004.

The panel is a way of exploring residents’ views on a wide range of issues affecting the delivery ofpublic services and quality of life in the borough, and allows key providers of public services to bein touch with a wide range of people.

The HOPS team will try to get the questions into the next postal survey of the Citizens’ Panel(October 2004). If the questions get accepted by the Consultation Board results should be availableearly 2005. Since this is a postal survey it complements the other methods (phone, web) very wellso it is worth waiting for the results.

6.3.2.3 TorinoTo collect users’ answers, the City of Torino has set up an internet service running an open sourcesurvey system (phpSurveyor). City newsletter subscribers (12,000) have been invited to access thisservice to help the city to understand user behavior in a new technology architecture: 623 answerswere collected (a 5% ratio).

A web survey was chosen because it is easy and fast to set up and it generates immediate datareports.

Since there is no city department devoted to create such a survey, this methodology gave the Cityan immediate understanding about service usage from the technological panel: thus not involvingusers other than web user, these answers need to be read in this context and some corrections haveto be applied.

6.3.3 Analysis of preliminary results of HOPS specific survey

While the survey is still operational, a first analysis is not yet possible for Torino.

Survey confirms a high user expectation to use vocal access technology in asking for info (morethan 60%), natural speaking is a very important issue (76%) as well as easy navigation andimmediate replies (85%).

More than 85% are interested in filling in web forms with sentences instead of keywords.

Nevertheless, computerized access in transactional services (such as booking resources) or directinteractive calls (as in claims) probably won’t be used, since they scored a more than 50% ‘neveror rarely’ usage preview.

It needs to be understood why certain events score a 50% positive usage preview while touristinformation scores a 50% ‘never and rarely’ usage preview (may it depends on the complexinformation structure or because the citizen already knows their city?).

An update of the results, with a global analysis for the three cities, will be added to the next WP2deliverable.

26 http://www.mori.co.uk/


- 34 -

7 Sample services

7.1 Introduction

As stated before, the common vision is based on the idea that HOPS must provide featuresallowing Local Authorities to develop new services with their own resources or their usualtechnological partners. Assuming that as the main long-term goal of the project, the sampleservices that will be implemented could be seen as a way to reach a proper definition of thecomponents the platform must address. Apart from their own inherent interest, they serve as ameans to a higher-level plan.

The early definition of some interesting sample services allows technical partners to focus theirwork in some real application. The specification of a walkthrough service has been a need statedby technical partners in order to gain enough knowledge to bootstrap the process of integration ofthe different technologies: voice portals, Natural Language and Semantic Web. This basicintegration is expected to underline the need of producing the necessary inputs and outputs in aspecific standard format that enable to put together the technologies involved.

In order to give an abstraction layer to the specific services, the cities have agreed to work out adefinition of service families, which is presented in section 7.2.

The plan to achieve a detailed platform definition (both in its frontend and management features)through a careful scheduling of sample services is presented in section 7.3.

Finally, 7.4 offer a description of the two first services that have been chosen for theimplementation with the HOPS solution.

7.2 Sample Service Families

In order to gain abstraction from specific services, the cities have decided to elaborate theirclassification into two families:

• Informational services: those services that only need read access to the backend databasesand knowledge repositories, since they do not update any information. A representative ofthis service family would be the cultural agenda service (see a description in section 7.4).

• Transactional services: those services that need read and write access to the backenddatabases and knowledge repositories, since they need to update information. Arepresentative of this service family would be the large things collection service (see adescription in section 7.4).

This two-families representation is convenient for the categorisation of services because of itsdifferent level of complexity in terms of integration with the backend system.

Informational services are usually simple services that just generate a query to a database, andtherefore do not need a high integration effort, while some of the components developed in theHOPS Platform for the first informational service may be useful for the others.

Transactional services depend more heavily in the specific business rules of the service andtherefore need much organisational and technological integration.

A number of different models describe the development of e-government services in the literature,and it seems interesting to compare them with our categorisation. One of the more popular models


- 35 -

is that suggested by NOIE and DMR27. It describes the development of e-government services infour characteristic stages:

• Level 1. Presence: publishing information.

• Level 2. One-way interaction: allowing the download and printing of forms withoutfinishing the full transaction online.

• Level 3. Two-way interaction (or transaction): offering transactions that range from thetriggering of processes using electronic forms to full electronic implementation ofservices and corresponding processes.

• Level 4. Transformation: allowing integrated services to be offered on the “one-stop-shop” principle.

It is not possible to make an exact one-to-one mapping from our families to the characteristicstages of four levels models as the previous one, since our classification is made according totechnical criteria -the read or read/write access to Municipal databases-, while common e-government models deal with the degree of interaction with the citizen and with the organisationalchange. However, we can say that our transactional family is quite aligned with level three,although our definition also covers stages two or four. Although the whole classification appliesbetter to transactional services, the informational family can be matched with stage 1.

We believe that a technical classification as ours is more convenient to define the abstract featuresthat the HOPS Platform should have. The HOPS Team has decided that both families should berepresented in the sample services that will be developed during the project.

It could be argued that it would be better to concentrate in services requiring a high amount ofinteraction, but recent surveys in the participating authorities indicate that more that 70% of thecontacts with the Municipality are for informational services. Having the objective of developing asolution to allow the delivery of a mass-scale service, it seems reasonable to us to devote asignificant effort also to informational services.

7.3 Scheduling of sample services

The scheduling of sample services is a vital process to deal with the last two challenges statedbefore:


• How to maintain a balance between the internal demands of the local authorities, theinterest and capabilities of the technical partners and the guiding principles of the project asa whole?

As the shared vision states, HOPS should provide a toolkit28 to develop new services, rather than aset of sample services. The elicitation of user requirements of a platform based on emergingtechnologies in which the users do not have relevant expertise is not easy. Unfortunately, cities arenot familiar with the capabilities of the involved technologies, and the technologies are not matureenough in some cases, thus making it very difficult to formalise the specification of requirements

27 NOIE and DMR (2003). e-Government Benefits Study. Commonwealth of Australia. Similar models are currentlyused, also in some European Commission DG Information Society documents.28 In the HOPS Project, as far as the user requirements are concerned, HOPS Toolkit, HOPS Platform and HOPSApplication has been considered as synonims, as defined in the HOPS Glossary: (see the artifact in Appendix E)


- 36 -

for an abstract platform without moving the focus to a highly technical scenario rather that to afunctional one. This is the reason why the local authorities have suggested to define the platformthrough the development of sample services.

The specification and scheduling of carefully selected sample services would lead to the buildingof an abstract toolkit that will be used to develop the sample services. The platform will bespecified through a sequence of case studies scheduled in a way that ensures the creation of the setof tools that will allow Local Authorities to develop their own services.

The scheduling of case studies should ensure:

- that prototypes of the HOPS Platform support both informational and transactional services

- that the cost of introducing new services (also new domains and new languages) is takeninto account and is minimised (through the creation of support tools that help to generateresources)

The adopted solution has been to use iterations not only to refine sample services, but also tochange domains and languages and evaluate the implications.

This approach should ensure a minimum cost of developing new services and the development ofprototypes that will support informational and transactional services.

Two sample services, the Cultural Agenda and the Large Things Collection Service (the formerinformational, the latter transactional, see section 7.4 for a description) have been selected asboosters. Once they have been implemented in the three cities, new services or refinements ofthose services will be performed, forcing changes in the language, business logic or backendsystems, to ensure a large reuse of the designed components. These changes will be used to getexpertise on how to define an abstract toolkit.

The two diagrams below reproduce the proposed scheduling for informational and transactionalsample services:

Figure 1: Informational sample service proposed schedule29

29 For more information on the proposed schedule please see (http://groups.hops-fp6.org/fileviewer.php?file_id=111)


- 37 -

Figure 1: Transactional sample service proposed schedule30

These schedules deal with the issue of cross-fertilising efforts across European local authorities bydeveloping and deploying the same sample services in three different environments with differentlanguages, business rules and technical specifications. It also tests the concepts of reusability andtransferability of efforts not only across services but also across countries. HOPS is placed in aunique market position and these efforts should demonstrate it.

Regarding the last challenge, the local authorities are aware that the proposed schedule and theplanned deployment of sample services works for their particular needs, that is why these are“proposed” schedules that can be modified by the technical partners. This is an initial attempt andthe main objective is to state clearly what the citizens and the local authorities want. How toachieve these objectives is a task for the project as a whole.

7.4 First Sample Services

7.4.1 Introduction

As stated before, sample services are a way to reach a proper definition of the components theHOPS Application must address. Apart from their own inherent interest, they serve as a mean to ahigher-level plan.

Two services have been selected to be implemented to help the development of a general platform.These services are an informational one and a transactional one.

As the first representative of the informational category, it has been decided to implement acultural agenda service. There are some reasons that support our decision. First of all, it is aservice that does not offer a high overload of integration effort, and allows us to concentrate onwhat is really relevant to the HOPS Platform. Another important reason is the possibility ofperforming a real high-level mass-scale production trial during the Winter Olympics of Torino2006.

30 For more information on the proposed schedule please see (http://groups.hops-fp6.org/fileviewer.php?file_id=111)


- 38 -

As the representative of the transactional family, the large things collection service has beenselected. The service consists in the possibility of requesting the collection of old furniture or otherlarge objects, according to some specific business rules. It is an example of service that hasdifferent business rules in the three cities (thus allowing us to evaluate how cross-reusable thecomponents can be) and that receives a large number of requests daily in Barcelona. Another keyreason to choose the service of large things’ collection was the availability of a set of realdialogues transcripts that can be used to model the dialogue flows, illustrating very well theimplication of the different core technologies, including the Semantic Web.

Next section gives a description of the two services with the specific details of each of the cities.RUP appendixes offer more detailed information about the requirements of the system (at themoment, only frontend requirements, those requirements for backoffice processes as thegeneration of resources are being gathered). Torino has been defining the cultural agenda andBarcelona has concentrated on the large things collection service. Each of the cities shows its ownversions of the services and studies how the work performed by the others can be applied to theirorganisation. Camden is working on a mapping with eGovernment UK taxonomies that wouldhelp to cross-fertilise efforts with other local authorities which operate in a different way.

7.4.2 Cultural Agenda

7.4.2.1 BarcelonaThe Municipality of Barcelona has a system called ASIA that allows different organisations toupload information of cultural events in a distributed environment. The information can beaccessed in multiple ways because it offers the results in XML format. It can be accessed throughthe web, and it is the same system that call centre operators use to give information on the phoneregarding cultural events. Different search criteria can be added according to a semantic-like set ofparameters. An analysis on how to adapt the specification, started by Torino, to the organisationalparticularities of the Municipality of Barcelona is ongoing.

7.4.2.2 London Borough of CamdenThe Customer Service Centre (Camden’s call centre) deals with cultural information. It isestimated that the enquiries on this particular service are not very high (approximately 200 permonth). The Customer Service Agent answers these queries using primarily Camden’s website,CINDEX (a database of contacts and external organisations) and a combination of publicationsand other websites.

It is important to point out that the London Borough of Camden does not hold “London-wide”information. A cultural agenda as such is an integrated service which is better understood at a Citylevel rather than a Borough level.

7.4.2.3 Torino

7.4.2.3.1 IntroductionThe Cultural Agenda service provides information about any cultural events that will occur duringthe following three days in Torino and towns inside the metropolitan area.

Users can ask for specific information about a known event, providing the system with the eventname or any description more or less detailed, but enough to identify a single event. In this casethe system will supply the information required with a very short answer.


- 39 -

Otherwise users can ask for information about when events of a specific type will occur, providingthe system with some parameters needed for the search.

These parameters are: channel or sub-channel, kind of event, title or name, date, location oraddress, price.

The system needs at least the date and channel provided to be correctly understood, to be able toanswer something. If the system does not have these two parameters, then it can ask the userspecific questions to get this information. In other cases it is able to get a list of events accordingto the supplied parameters.

On the basis of number of events in the list, the system decides if it needs to ask for moreinformation, for example if the number is greater than 20, or it can start to tell the user the numberof event found and the first 5 events titles or short descriptions. The user than can browse the list, 5events at time, with a suitable vocal command.

At the end, when the user finds the event of interest he selects this, giving the name/title or thecorresponding list order number, and the system provides the user with the details of the event.

Next section describes the core process of the Cultural Agenda using use case diagrams. Extendedinformation can be found in the RUP artifacts (appendix E).

7.4.2.3.2 Description of the core process of the Cultural Agenda service

Main Use Case Diagram

Brief DescriptionDescription of Cultural Agenda Service. The citizen calls when he would like to have someinformation about cultural events in Torino. Depending on the type of question, the system willanswer with a list of events or with one or more information about a specific event.

Actors

Name Description

Citizen The citizen calls to use CA Service

Constraintso The system has available phone lines to deliver the service


- 40 -

Basic Flow of Events1. The system welcomes and asks for the language

2. The system asks for the possible request of information

3. The citizen asks for information

4. The system answers

Alternative flows

User asks for helpA3.1 The system asks to citizen if he wants browse the events by channel and sub-channel

Request Information Use Case Diagram

Brief DescriptionIn this particular case, all the possible steps to follow when a citizen asks for information about acultural event are described. He may ask for specific information about an event or ask for a list ofevents. Both cases require the user to define the date ( day of the call or the day after ) of the event.

Basic Flow of Events1. The system asks for request

2. The citizen asks for a single piece of information about a specific event. The question may specifyone or more of these options:

• name of the event

• location

• kind of event (channel or sub-channel)

• city

3. The system asks for the day (current or the day after), if not specified in the question.

4. The citizen specifies the day

5. The system answer with the correct single information.

6. The system asks to citizen if he wants the complete information of the event.


- 41 -

Alternative flows

A2 The citizen asks a list of free eventsA2.1 The system answer with a list of events

SEE USE CASE: BROWSE EVENTS LIST IN RUP ARTIFACTS (Appendix E)

Exception flows

A5 The citizen doesn’t specify enough information to identify immediately a single eventSEE USE CASE: BROWSE EVENTS LIST IN RUP ARTIFACTS (Appendix E)

B5 The system doesn’t understand any information about the eventB5.1 The system asks to repeat

B5.2 The citizen asks again.

B5.3 The system doesn’t understand again.

B5.4 The system starts to ask step-by-step questions

SEE USE CASE: 1.2.2 STEP BY STEP QUESTIONS IN RUP ARTIFACTS (AppendixE)

C5 The system doesn’t find any event matching the requestC5.1 The system answers : no events found.

C5.2 The system asks to citizen if he wants information about other events or if he prefers tobrowse by channel

Activity diagram


- 42 -

Browse Event List

Basic Flow of Events

1. The system verifies how many events have returned through the search by parametersspecified by citizen

2. The number of events are less than 5 (this value must be configurable by the system admin)then the system gives the citizen a short description of each event

3. The citizen selects one of the events ( he could select by position number or by name )

4. The system answers with the event’s basic information

Alternative flows

A2 The number of events are great than 5 but less than 20

A2.1 The system answer giving how many events are in the list, and asks thecitizen how many events he wants to hear at a time.

A2.2 The citizen answers the number x (or all)

A2.3 The system tells to the citizen the short description of x events

A2.4 The citizens selects one of the event or says next to hear the next events in thelist

A2 The number of events are great than 20

A2.1 The system ask user a specific question to get more information.

A2.2 The citizen answers with information required

A2.3 The system gets the new list of events


- 43 -

The use case restarts from point 2

Exception flows

A4.1 The system doesn’t understand the selection by name and asks for repeat

A4.2 Citizen repeats the selection by name

A4.3 System doesn’t understand again and asks for the numerical answer.

Activity diagram

7.4.3 Large Things Collection

7.4.3.1 Barcelona

7.4.3.1.1 IntroductionThe objective of the Large Things Collection Service (also referred as LTC) is to build anautomated application allowing citizens to request the Municipality to collect any large object(furniture, ruins, etc) in their homes or in the street. The idea is to make an application capable ofdistinguishing automatically between different modalities of the service according to some specificbusiness rules (for example, understanding whether a request corresponds to a free or a paymentservice) and capable of understanding the semantic of the objects to collect applying theappropriate procedures depending on the object’s nature (furniture, fridge, ruins…).

The Large Things Collection Service has been specified mainly by Barcelona. However, the firstspecification of this service has constituted a walkthrough service for all partners, that is, it hasbeen used as a booster to focus all partners in a real scenario. So, the specification does not onlyrespond to the business rules of the service in Barcelona, but it offers a subset of them and someextra definitions to provide a case study that deals with all the technologies involved in the project.


- 44 -

The architecture coming from the implementation of this sample service should be compliant, asfar as its required components are concerned, with the requirements of any other transactionalservice.

Next section describes how the service is currently performed in Barcelona by human operators,and gives a high level description -through charts- an automated system offering a possible subsetof the options of the service (in the real service there are too many options with complexprocedures to be followed in different cases)

Finally, the resources that are already available for the large things’ collection service aredescribed.

UML notation has been used whenever possible for the description of use cases and specificationof business rules.

7.4.3.1.2 Description of core processes involved in the serviceThis section gives some background information that is interesting to illustrate how the service isprovided now by human operators (in the case of Barcelona). First of all, there is an overview ofthe general processes that the call centre operators follow to satisfy the citizens’ requests. Afterthat, a high level description of the current human-operated large things’ collection process isprovided. Finally, there is also a simple description of a new machine operated large things’collection service. This service would implement a subset of all the possible parametercombinations in the human-operated service.

A detailed use case specification of the proposed service, together with the stakeholder requestsgathered through personal interviews, is provided in the RUP Artifacts (Appendix E)

Description of the general processes of the Call Centre Agent

Use Case:

Call Centre Application Tools

Actors:

Call Centre Agent (initiator)

Purpose:

The Call Centre Agent interacts with the Call Centre Application Tools in order to satisfythe citizens’ requests.

Summary:

The Call Centre has an Application Tool used by its Agents to help them satisfy all thecitizens’ requests about different information (agenda, events, services, etc.) and that it isalso used to do a complete transaction such as large things’ collection.

Call Center Agent Call Center Application Tools


- 45 -

Type:

Primary and essential

Typical course of the events:

Actors Actions System Answer

The Call Centre Agent executes the STPapplication (that contains all informationabout transactions) from the generalApplication Tool to know the procedure tofollow to carry out the transaction that thecitizen has requested.

The STP returns, having previouslyintroduced the transaction keywords ofcitizen’s request, all the steps to follow tocarry out this transaction.

The Call Centre Agent follows all theprocedures indicated by the STPApplication to carry out the transaction. Inthe case of large things’ collection, theapplications needed to complete thetransaction are STN Application (used toknow which company is in charge of thecollection depending on the street) and ITCForm (used to enter all citizen’s dataneeded).

The system registers all the informationentered by the agent and the transaction.

Figure 1. Application Tool Figure 2. STN Application


- 46 -

High-level description of the current large things’ collection process

Use Case:

Large things’ collection

Actors:

Citizen (initiator), Call Centre Agent

Purpose:

Complete collection of large things

Summary

Collection of large things put in front of the solicitors’ building.

The collection is not made in a fixed day so it is necessary to do the request to include theaddress to the itinerary and depending of this address, a collecting day will be fixed.

It is necessary to give personal details to formalize the request.

The collection is will be made on the day that has been fixed

Type:

Primary and essential

Typical course of the events:

Actors Actions System Answer

Citizen

Large things' collection

Call Center Agent


- 47 -

The use case starts when the citizen callsfor a large things’ collection.

The Call Centre Agent checks inApplication Tools the procedure to followabout large things’ collection (heintroduces key words)

The system (Application Tools) returns allthe information needed about the largethings’ collection procedure.

The Agent selects, between a set ofpossible options, which one satisfies thespecific case of the citizen.

The system executes the application STN,that corresponds to large things’ collectionand it shows to the Agent all the steps tofollow included all the informationrequired.

The Call Centre Agent asks theinformation needed to the citizen such ashis address, name and contact phone.

The citizen gives all the information.

The Call Centre Agent introduces thisinformation.

All the information introduced by theAgent is registered by the system in an ITCForm and the STN Application returns thecollection day or other information,depending on the type of object.

The Call Centre Agent gives the citizen thecollection day assigned to the givenaddress and asks for a detailed descriptionof the object to be collected.

The citizen gives the description of theobjects.

The Call Centre Agent introduces thedescription.

The system registers the information givenin the ITC Form.

The Call Centre Agent confirms to sendthe ITC Form to the company in charge ofcollecting large things and confirms thetransaction.

The system sends the ITC Form to therespective company


- 48 -

The citizen hangs up.

Next high-level charts are included to get a clear understanding of the machine operatedsimplified service that can be implemented, offering a possible subset of the options of theservice (in the real service there are too many options with complex procedures to befollowed in different cases, and it is better to focus in some of them)

Figure 1. Large things collection transaction

Figure 2. Large things collection information


- 49 -

The system should also be able to make a “Large things collection cancellation”. If a citizen callsfor a cancellation of a previously requested large things’ collection, the system asks to the citizenhis details and to delete the request from the internal records.

7.4.3.1.3 Available resourcesCurrently there are about 70 transcripts of real dialogues of citizens calling to the Municipality ofBarcelona Call Centre to have their large things collected. These are not literal transcripts butdetailed reports of the conversations that can be instantiated into real questions and answers in anylanguage.

The transcripts come from an anonymous real-time supervision of a representative sample of callsduring 2003. An overall amount of 1903 calls were supervised, 70 of them dealing with largethings’ collection service.

It is important to emphasize that the transcripts correspond to the service as provided now byhuman operators, and therefore the dialogues have a high complexity. The new automatic largethings’ collection service that has been proposed is much more simple and can be addressed withsimple system driven questions.

7.4.3.2 TorinoThe Large things collection service in Torino is provided by AMIAT (Azienda MultiserviziIgiene Ambientale Torino), not directly by the Torino Administration. Today users can call aphone service to inform that they want throw out something large. The service asks for the addressand the object description, as well as the citizen’s name and telephone number. The service doesnot communicate with the citizen any data for collection, but the day before collection, an operatorcalls citizen to inform that he can put outside the house the object to be collected.

7.4.3.3 London Borough of CamdenThe Large Things Collection service in Camden is called “Special collections for bulky items”, itis Service number 52831 in the UK service taxonomy32 works in the following way:

A member of the public calls the Customer Service Centre located at Cressy Road on (020) 79746914/5 and requests a special collection. The customer service agent then informs the member ofthe public of the special collections process. The customer service agent then transfers the call toextension number 3296, which is the street environment services back office located at CockpitYard.

The support assistant in the back office confirms that the number of items to be collected is nomore than 4, and that the items are not green waste, hazardous waste, white goods, a grand piano,or anything that can’t be removed from the premises through the door way and will not requiremore than two men to lift. The support assistant then confirms that the price of the collection is£20 as a minimum, unless they are an old age pensioner or receive a state benefit, which entitlesthem to this service free of charge. This includes those on income support such as job seekers orthe disabled.

31 http://www.esd.org.uk/standards/lgsl/viewer/main.aspx?Id=52832 http://www.esd.org.uk/standards/lgsl


- 50 -

The support assistant enters the customer’s details onto the Contender system. This involvesentering the customer’s postcode, which is then verified against the property’s address. The code isentered followed by the customer’s contact details together with a description of the items to becollected. The support assistant informs the customer that they can either pay by supplying carddetails over the phone there and then, instructs them to put a cheque in the post, or tells them topay by cash in person on the fifth floor of the town hall extension on Argyle Street. At this pointthe customer informs the support assistant of their preferred method of payment.

If the customer would like to claim their entitlement to a free service, they are asked for theirnational insurance number as proof of evidence for this entitlement. The national insurancenumber is stored in Contender, which will also hold a record of all previous collections. Acustomer is entitled to no more than 2 free collections per year and the support assistant will see allprevious requests while still on the telephone with the customer.

Once the preferred method of payment has been declared or a national insurance number has beenobtained, the support officer gives the customer a reference number, which has been issued bycontender. They also inform the customer of the next available collection date according to thecustomer’s ward area. Each street is assigned to a ward. The borough is divided into 10 wards, and4 to 5 wards are collected in a day.

If the support assistant is given credit card or bankcard details, they then call the cashiers office onextension 6104 to have the payment processed. The support assistant always assumes that thepayment has gone through. Only if the payment is not accepted will the support assistant call thecustomer back to inform them of this and asks for an alternative method of payment, resulting inthe rescheduling of the collection date when payment is received.

If the customer prefers to pay in person or by a cheque through the mail, the customer is calledback by the support assistant once the payment has been received to book in the collection.

The support assistant updates both Contender and the Special Collection Schedule with the newcollections details.


- 51 -

8 Requirements specification

8.1 Introduction

The management of user requirements is a very important discipline of software development. TheEuropean Software Process Improvement Training Initiative (ESPITI)33, a framework programme3 project conducted a survey in 1995 to identify the relative importance of various types ofsoftware problems in industry. The results of this survey, based on 3,800 responses, is summarisedin the following chart:

Requirements specifications and managing customer requirements are the main problem areas.This section of D21 will propose the use of the Rational Unified Process34 to improve the qualityof the requirements and try to avoid results such as the ESPITI survey found.

In order to understand such a big methodology it is useful to start with its guiding principles, RUPis based on best practices that have been around for a long time in the industry. Of these, one ofthe most important concepts is iterative development and HOPS fully embraces this concept whenit proposes an approach based on the deployment of incremental pilot implementations. Iterativedevelopment is also present in the structure of WP2 deliverables as it is tasked with an initial userrequirements specification and later a refinement (based on the experience of implementing theiterative code).

33

http://ica.cordis.lu/search/index.cfm?fuseaction=proj.simpledocument&PJ_RCN=2805181&CFID=721803&CFTOKEN=3100909034 http://www.rational.com


- 52 -

Another important best practice present in RUP, which is tackled in WP2, is to “continuouslyengage users”. By identifying the correct stakeholders in the organisations and keeping theminvolved through the process HOPS will ensure it deals with the relevant issues for thestakeholders. This is very important as this project is focused on real exploitation.

To “carefully manage requirements” is another important best practice promoted by RUP, which isat the core of WP2. In RUP, requirements are not set in stone as soon as they are gathered, theyneed to be managed: changes need to be followed up and stakeholders need to be kept involved.This means that some effort must be devoted to manage change requests.

The RUP is not only a series of best practices; it is also a complex software development processwith structured inputs and outputs. One of its main advantages is the ability to customise it to caterfor projects of all sizes and this is what we will do for HOPS. A tailored version that gives usenough structure to give guidance without being a burden, which describes a series of documents(artifacts) and provides tools to maintain order in a series of constantly evolving documents andactivities.

Without trying to be exhaustive, this is a very simple summary of the software developmentprocess, with particular emphasis on some concepts that will become common terminology in thisdocument. The RUP is based on four main elements:

• Roles (who)• Activities (how)• Artifacts (what)• Disciplines (when)

“A role defines the behaviour and responsibilities of an individual or a group of individualsworking together as a team. The behaviour is expressed in terms of activities the worker performs,and each worker is associated with a set of cohesive activities. The responsibilities of each workerare expressed in relation to certain artifacts, or work products, that the worker creates, modifies, orcontrols.

Disciplines allow the grouping of activities into meaningful sets that provide some result for thedevelopment organization and show how various workers interact.” (RUP)


- 53 -

The following diagram illustrates the disciplines within the RUP:

8.2 Requirements in HOPS

Following the previous diagram, WP2 in HOPS deals with Business Modelling and Requirements.The Annex I – “Description of Work”35 in HOPS is the result of business modelling activity, it setsout the guiding principles of the project and defines clear indications to monitor progress. We willconcentrate particularly in the Requirements discipline for WP2; we will describe our process intwo separate sections: Artifacts (documents) and Discipline details (subtasks in requirements)

8.2.1 Artifacts

One of the concepts that is difficult to understand when new to the RUP is that all artifacts(documents, diagrams, models) are optional:

“The set of possible artifacts described in the UP should be viewed like a set of medicines in apharmacy. Just as one does not indiscriminately take many medicines, but matches the choice tothe ailment, likewise on a UP project, a team should select a small subset of artifacts that addressits particular problems and needs”36

As a staring point, we think the following diagram represents a good set of artifacts WP2 in HOPSshould create, update and maintain throughout the project:

35 http://groups.hops-fp6.org/fileviewer.php?file_id=3636 Larman, Craig. Applying UML and patterns: an introduction to object oriented analysis and design andthe Unified Process. Prentice Hall 2003, p. 23


- 54 -

Following the best practice of iterative development, this set of artifacts will be constantly refinedthat is why we have decided to situate them as appendices in D21 and also to generate a RUPwebsite37 to hold the current version and share with the partners.

8.2.1.1 Vision DocumentThe vision document is one of the first artifacts created in RUP projects:

“The vision defines the stakeholders’ view of the product to be developed, specified in terms of thestakeholders’ key needs and features. Containing an outline of the envisioned core requirements, itprovides the contractual basis for the more detailed technical requirements” (RUP)

As mentioned before, in HOPS there is a “Technical annex” document, which outlines the mainobjectives and ideas for the project. We think it will be useful to have a separate vision documentfollowing the RUP template that will focus the whole team around a common and current view ofproblems and solutions. The idea is not to set a Vision document in stone now and expect it to bestill valid in three years’ time, but if we keep it up to date the Vision can not only represent ourview of HOPS but also document the changes in priorities throughout the project.

8.2.1.2 Stakeholder requests.Since HOPS is such a long project dealing with changing technology, an essential part of changemanagement is to keep up to date a document with the most recent set of requests fromstakeholders. This will include:

• Public administrations who will update their requests based on their own service deliveryplans,

• Research partners who will follow the cutting edge in their own fields and• Integration partners who will have pressure to install and maintain an executable

architecture.

37 http://rup.hops-fp6.org


- 55 -

Up to now we have based the stakeholder requests on the cities staff, but we expect thesedocuments to be alive and updated as the project moves forward.

8.2.1.3 Use Case ModelThis is the organised set of use cases, which constitutes the bulk of the requirements. In here wewill use textual descriptions, use case diagrams, state diagrams, sequence diagrams, etc.

8.2.1.4 Supplementary SpecificationThis document captures other kind of requirements such as documentation, packaging, licensing,supportability, etc. In general terms it deals with most of the non-functional requirements and thedesign constraints.

We have decided to produce the first version of the complementary specification when we have aclearer picture of the technical details of implementation and integration. We plan to initiate thisartefact after the Proof of Concept (POC) system is built, so no version of it will appear in D21.

8.2.1.5 GlossaryThe Glossary captures terms and definitions and later on can become a data dictionary for theproject. Although in general this artifact is not included in simplified versions of the RUP, webelieve it would be very useful in such a large and complex project as HOPS.

Although we recommend only these artifacts, there is a document that is very common inrequirements and is an international standard.


- 56 -

8.2.1.6 Software requirements specificationThe software requirements specification (IEEE Std 830-1998)38 is an IEEE standard for describinguser requirements. We don’t think the SRS adds anything to our recommended list of artifacts, butit is a very well recognised document and it could be an interesting outcome for the project. If wedecide to include this document it will be delivered as an appendix to D22. This decision willdepend on the resources available and will be discussed with other partners.

8.2.2 Discipline details

As we discussed previously, the RUP is a series of best practices, recommended (optional)artifacts and a process. It is now time to turn to the process.

In order to work through the Requirements discipline, the RUP considers six “discipline details”which give the project a clear path to follow when dealing with such a complex problem domain.The six discipline details are the following:

• Analysing the Problem• Understanding User and Stakeholder Needs• Defining the System• Establishing Project Scope• Refining the System Definition• Managing changing requirements

For each of these discipline details there are a number of techniques and methodologies that wewill summarise here. If we try to apply some of these ideas systematically to the HOPS problemdomain we should be able to reduce complexity and define a tighter set of requirements.

8.2.2.1 Analysing the ProblemThis discipline detail seems to be quite obvious but in the case of HOPS finding the problemhasn’t been so easy. We have been internally discussing this issue between the cities with someparticipation from other partners. Taking clues from Annex I we know that HOPS shouldconcentrate on generating more online services based on voice functionalities, natural languageprocessing and semantic web, that these services should be deployed in a mass scale, that thesenew services should enhance the experience of the citizen, that HOPS should describe thenecessary technical components and system architecture that would allow these services to bedeployed.

RUP proposes the following techniques to “Analyse the problem”:

• Five-Step analysis• Business Modelling• Systems engineering

We organised a specific meeting between the cities and using these and other techniques came toan agreement on the problem, on the priorities for each municipality and in a way forward tocross-fertilise our efforts. Using the Vision document template presented in RUP this is a summaryof the problem definition:

38 http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html


- 57 -

The problem of Lack of good and efficientsolutions to deliver naturallanguage based semanticallyenriched online public services ina mass scale

affects public administrations needing todeliver improved public services.

The impact of whichis

the high cost of setting upadvanced public services withresource growth restrictions.

A successfulsolution would

provide the Local Authorities withthe necessary tools andexpertise to build advancedpublic services in an economicaland self-sustainable way.

8.2.2.2 Understanding User and Stakeholder Needs

This is another discipline detail where the municipalities can provide the most information.Common techniques that we are familiar with are:

• User stories• Requirements workshops• Interviews• Brainstorming sessions• Storyboarding

After exhaustive work between the three participating municipalities and internally in eachmunicipality it was agreed that the HOPS project would concentrate on two main services: “Largethings collection” (LTC) and “Cultural agenda” (CA). For this version of the user requirementsBarcelona would work with their stakeholders with regards to LTC and Torino with CA. Camdenwould validate their results internally and concentrate on service taxonomies and advanced contentmanagement system integration.

We agreed to use the “Stakeholder requests” artifact from RUP to capture the needs of theStakeholders and keep them involved.

Interviews and Brainstorming sessions were carried out in Barcelona and Torino and the initialresults will feed into D21.

8.2.2.3 Defining the SystemThis is where we work on the use cases, concentrating carefully on functionality and interactingwith the other work packages. Some important issues during this discipline detail are:

• Use case modelling• Organising the use cases• Vision document


- 58 -

Our initial use case model gives a very basic idea of the application focusing on the selectedservices (LTC and CA) and also emphasising the need for a toolkit that goes beyond the twosample services selected. We expect the use case model to grow considerably as we pilot the earlyversions and refine the use cases. D22 will have a very developed and refined use case modelincluding the efforts to test the transferability of the selected services.

8.2.2.4 Establishing Project ScopeHaving defined the features of the system it is very important to define a realistic boundary ofwhat’s possible within the project deadlines. Some useful activities:

• Setting priorities• Calculating effort• Risk assessment

So far we have been working with stakeholders and identifying what the cities need. In thisactivity the technical partners will have a significant role in defining scope. In this process weexpect the cities to be actively involved in particular when setting priorities.

8.2.2.5 Refining the System DefinitionHere the initial use cases are reworked into fully dressed examples with pre and post conditions,alternative flows, etc. The idea is to move from a high level feature set to a more rigorous softwarerequirement set. This not only helps understand the system better; it also helps to define the testcases. Some recommended steps during this stage:

• Refine use cases• Supplementary Specification• Additional diagramming techniques useful for complex use cases• Initiate test cases

This is all work that will start after the PoC is delivered and will feature heavily in D22

8.2.2.6 Managing changing requirementsThis is all about change control, version control or configuration management. It addresses how tocreate an environment to manage changes in a structured and organised way. We have decided toutilise a RUP website to keep the artefacts current. This is not a proper change control method butwe think we should be able to maintain efficient control using this website.


- 59 -

9 ConclusionsFirst of all it is important to state that following our chosen methodology a user requirementsdocument is not “set in stone” so a section with conclusions is probably not the easiest to write atthis stage of the process. Having said that, it is still possible to derive important conclusionsregarding the thinking process, the work to identify the critical success factors and the definition oflinks between thorough research into public service provision and the creation of a software toolkitincorporating cutting edge technology.

Looking at the project structure, D21 is essential feedback for WP3 and WP4 so it has been veryimportant to keep a balance between providing a “real” service defined in great detail and also toprovide a common vision, which aligns the effort of the other work packages towards a publicservice oriented toolkit.

Throughout this process the local authorities have discussed their perspectives and revised theirpriorities, shared information on the details of the business rules of a particular service and alsodiscussed the “big picture” reengineering processes shaping each organization. By doing this thelocal authorities have come across a series of overriding principles that shape this project. D21 is adocument that attempts to bring out an open discussion that will engage the partners and realignthe project towards an enriched understanding of the factors that will make HOPS a success.

In order to organise such a complex set of ideas, a list of these overriding principles follows with abrief summary of how D21 contributes to their understanding from the public service deliveryperspective.

Mass Scale: For HOPS to be truly mass scale not only the technical aspects of performance shouldbe taken into account, there should also be an economically viable way of adding new services tothe platform.

Exploitation: For HOPS to live up to its exploitation potential, the internal drivers for each localauthority have been identified to serve as a way to define success and to encourage buy-in fromdecision makers in the public sector.

Cross-fertilisation: The local authorities have committed to transfer the sample servicesdeveloped in the project to their own environments, testing the capacity to move a service not onlyfrom one language to another, but also from one backend to another and one set of business rulesto another.

Toolkit: Throughout the process the local authorities have realised that a project that delivers oneor two services does not solve the needs of advanced public services. What is needed is a platformwhere new services and capabilities can be added in an economically viable way.

Multi-Channel: The need to expand this technology to multiple channels is the only way to makeit future-proof as it is expected of local authorities to adapt to new channels as they becomeavailable.

Quality of service: From all the information gathered it is clear that the citizen expects publicservice delivery to improve constantly. HOPS, by automating processes and improvingeffectiveness, should not sacrifice usability or quality; it should enhance it.

The user requirements presented here, in a high level and very detailed form, are alive. They areexpected to provoke discussion and to challenge the technologies. The process of refining themand using them as a tool to drive the development aligned to a shared vision is a commonresponsibility.


- 60 -

10 References

[1] MacCormack, A. Product-Development Practices That Work. MIT Sloan ManagementReview, 2001.

[2] Jacobson, I., et al. The Unified Software Development Process. Addison-Wesley, 1999.

[3] Kruchten, P. The Rational Unified Process. An Introduction. 2nd edition. Addison-Wesley,2000.

[4] Larman, C. Applying UML and Patterns. An Introduction to Object-Oriented Analysis andDesign and the Unified Process. 2nd edition. Prentice Hall, 2002.

[5] Royce, W. Managing the Development of Large Software Systems. Proceedings of IEEEWESCON, 1970.

[6] Esteve Ollé, Manuel Castells. El model Barcelona II: L’Ajuntament de Barcelona a lasocietat xarxa. Research report. Universitat Oberta de Catalunya.(http://www.uoc.edu/in3/pic/cat/pic5.html

d21 – user requirements 04/11/2004 › ... › deliverables › d21-user_requirements.pdf · the...

Documents