Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
Project co-funded by the European Commission within H2020-EURO-2014-2015/H2020-EURO-6-2015
Dissemination Level
PU Public x
PP Restricted to other programme participants (including the Commission Services
RE Restricted to a group specified by the consortium (including the Commission Services
CO Confidential, only for members of the consortium (including the Commission Services)
Towards We-Government: Collective and participative
approaches for addressing local policy challenges
Grant Agreement number: 693514
Deliverable
D2.2
WeGovNow Use Cases v.1
D2.2 WeGovNow Use Cases v.1
2
Author List
Organisation Name Contact Information
Mapping for Change Louise Francis [email protected]
empirica Lutz Kubitschke [email protected]
Status, Abstract, Keywords, Statement of originality
Dissemination level: Public
Contractual date of delivery: 31 July 2016
Actual date of delivery: 16 November 2016
Work Package: WP2 Stakeholder engagement & local test trials
Type: Report
Approval Status: Final
Version: 1.0
Abstract
The report describes the revised methodological approach adopted for service scenario
and use case design in the context of development of the WeGovNow online platform. It
then presents the outcomes generated in terms of an initial set of use cases to be further
refined / extended according to the workplan. A brief outlook to the upcoming worksteps
is included as well. A number of annexes include detailed outcomes of a method review
undertaken; generic user requirements and several examples of personas and user stories
derived from the initial scoping analysis; and the reporting template used for user
scenario analysis.
Keywords
Community engagement, engagement methods, participative development, citizen
participation, use cases, target groups, neighbourhood development, stakeholders
Statement of originality
The information in this document reflects only the author’s views and the European
Community is not liable for any use that may be made of the information contained
therein. The information in this document is provided as is and no guarantee or warranty
is given that the information is fit for any particular purpose. The user thereof uses the
information at its sole risk and liability.
D2.2 WeGovNow Use Cases v.1
3
Contents
Executive Summary ................................................................................................................... 6
1 Introduction ........................................................................................................................ 9
2 Methodological approach ................................................................................................ 10
2.1 Challenges experienced ............................................................................................. 10
2.1.1 A multi-dimensional innovation challenge ........................................................... 10
2.1.2 Review of existing methodological approaches ................................................... 11
2.2 Methodological approach adopted ........................................................................... 15
2.2.1 Service scenario description ................................................................................. 16
2.2.2 Use cases derivation ............................................................................................. 16
2.2.3 Requirements elicitation ....................................................................................... 17
2.2.4 Legacy process analysis ......................................................................................... 17
2.2.5 Value case analysis ............................................................................................... 17
2.2.6 Options for service scenario optimisation ............................................................ 18
3 Initial use cases ................................................................................................................. 18
3.1 WeGovNow service scenario #1 (San Donà di Piave) ................................................ 18
3.1.1 General Background ............................................................................................. 18
3.1.2 Role Naming .......................................................................................................... 19
3.1.3 Role Descriptions .................................................................................................. 19
3.1.4 Related Use cases ................................................................................................. 23
3.2 WeGovNow service scenario #2 (Southwark) ........................................................... 30
3.2.1 General Background ............................................................................................. 30
3.2.2 Role Naming .......................................................................................................... 31
3.2.3 Role Descriptions .................................................................................................. 31
3.2.4 Related Use cases ................................................................................................. 35
3.3 WeGovNow service scenario #3 (Turin) .................................................................... 40
3.3.1 General Background ............................................................................................. 40
3.3.2 Role Naming .......................................................................................................... 41
3.3.3 Role Descriptions .................................................................................................. 41
3.3.4 Related Use cases ................................................................................................. 45
3.4 Further service scenarios currently analysed ............................................................ 49
D2.2 WeGovNow Use Cases v.1
4
3.4.1 WeGovNow service scenario #4 (San Donà di Piave) ........................................... 50
4 Outlook ............................................................................................................................. 52
ANNEXES .................................................................................................................................. 54
5 Annex I: Outcomes of method review .............................................................................. 54
5.1 Requirements ............................................................................................................ 54
5.2 Approaches to Development ..................................................................................... 54
5.2.1 Waterfall Method – Limited User Involvement .................................................... 55
5.2.2 Spirals and Rapid Application Development – Increasing User
Involvement .......................................................................................................... 55
5.2.3 Agile – Ongoing User Involvement ....................................................................... 55
5.2.4 User-Centred Design ............................................................................................. 56
5.3 Users .......................................................................................................................... 57
5.4 Gathering and Documenting Requirements .............................................................. 58
5.4.1 Facilitating Interaction between Users and Developers ....................................... 58
5.4.2 Requirements Lists ................................................................................................ 59
5.4.3 Use Cases .............................................................................................................. 60
5.4.4 Scenarios ............................................................................................................... 61
5.4.5 User Stories ........................................................................................................... 61
5.4.6 Personas in UCD .................................................................................................... 63
5.4.7 Comparing User Stories with Other Approaches .................................................. 63
5.4.8 Requirements Gathering and Interface/Interaction Design and Usability ........... 65
5.5 Requirements Gathering and Software Design in WeGovNow ................................. 66
5.5.1 User Proxies .......................................................................................................... 66
5.5.2 Best Practice Approach to Requirements Gathering ............................................ 67
6 Annex II: Generic User Requirements Derived From the Initial Scoping Exercise ............ 68
6.1 Usability User Requirements (non-functional user requirements) ........................... 68
6.2 Other Non-Functional User Requirements ................................................................ 69
6.3 Registration User Requirements ............................................................................... 69
6.4 Data User Requirements ........................................................................................... 70
6.5 Voting User Requirements ........................................................................................ 71
6.6 Communication and other Social Interactions User Requirements .......................... 72
D2.2 WeGovNow Use Cases v.1
5
6.7 Uncategorised Technical User Requirements (functional and non-
functional) ................................................................................................................. 72
7 Annex III: Example of personas derived from the initial scoping exercise ....................... 74
8 Annex IV: Example of user stories derived from the initial scoping exercise ................... 76
9 Annex V: Reporting template used for user scenario analysis ......................................... 80
A Introduction .......................................................................................................... 82
B Structure of the service scenario template .......................................................... 83
10 References ........................................................................................................................ 90
D2.2 WeGovNow Use Cases v.1
6
Executive Summary
WeGovNow strives for breaking new ground by employing digital technologies as a game-
changer in the relationship between citizens and government. To this end, a digital platform
will be developed and validated for engaging local civil society in the co-production of
citizen-centred services and in the co-development of strategic approaches to community
development. From the initial stakeholder interactions organised within WP2 it became
clear that the general promise held by ICT to enable tailoring of public services to user needs
and preferences requires a multi-pronged innovation approach, one that simultaneously
pays attention to the particular working models of different administrative units to be
involved and to the technology to be employed. From the perspective of the three cities
participating in the project, this has highlighted the need that technology innovation and
organisational process innovation must be pursued at the same time.
Against this background, the methodological approach to be adopted for the purposes of
use case development in the framework of WeGovNow has been designed to enable
identification of both, functional/non-functional user requirements on the WeGovNow
platform and process-related requirements on new public service models that need to be
put in place. The chosen approach commenced with preliminary scoping workshops with
representatives from government units to be involved in further use case development
work. This was then followed by a discussion of work programmes across local government
units, their objectives and scope, potential ICT use, challenges and risks within the context
of the WeGovNow Platform development, organisational processes and citizen-centred
services delivery. A critical appraisal of an initial set of use case scenarios that were based
on a selection of identified work programmes and potential technology requirements
followed. These were consolidated in terms of illustrative personas and related user
stories. Based on transcriptions from the initial scoping workshops an initial set of user
requirements was derived.
Based on the findings from initial scoping a set of analytical service scenarios was
developed in close collaboration with local government departments and other
stakeholders. Service scenarios set the context within which the WeGovNow platform will
be applied in the pilot city. It provides an informal narrative description that outlines human
activities and tasks (or else use cases) in a story that allows exploration and discussion of
contexts, need and requirements. It is aimed to ensure that stakeholders understand the
requirements, with a focus on what the users are trying to achieve. In WeGovNow, service
scenarios illustrate the advantages of new participatory online services, made possible by
the WeGovNow platform, for enabling, deepening and/or widening involvement of citizens,
civil society organisations or local businesses in public service delivery at municipal level.
For each of the service scenarios one or more use cases are specified. A use case represents
a particular task or problem a user wants to achieve/address according to the service
scenario developed earlier, and should refer to a specific user/system interaction that
D2.2 WeGovNow Use Cases v.1
7
captures the users’ goal. For our purpose we consider a “user” any benevolent individual
trying to achieve something with the help of the WeGovNow platform. A user acts within a
particular role at a given point in time as defined earlier in the service scenario, e.g. as a
representative of a public administration or as a citizen. For each use case – i.e. a specific
task or problems a user wants to address – functional and non-functional requirements are
derived.
A further analytical step, legacy process analysis, focuses on identification of requirements
on the WeGovNow platform stemming from historically grown legacy service processes and
infrastructures prevailing in the various pilot cities. It aims at identifying organisational/
service interfaces and collaboration models existing prior to the implementation of the
WeGovNow service scenario. Value case analysis focuses on identifying innovative aspects
in relation to the participation of stakeholders in service delivery within the new service
scenario. It documents how the use case is expected to help addressing current challenges/
problems by the participatory public service. A final analytical step, focuses on identifying
possible variants of the service scenario and options for improvements potentially to be
explored. Here we are interested in learning whether possible variations or room for
improvement the current service scenario can be anticipated at this stage.
The main part of the present document comprises a first version of use cases derived from
an initial set of service scenarios. In line with the multi-staged methodology chosen this
starts with a brief summary of three selected service scenarios, for each of which a set of
use cases is presented. Each use case is analysed according to a number of dimensions,
including:
the primary role(s) that interacts with the system and performs the use case to
accomplish tasks;
the goal and context of the use case;
preconditions that must be in place before the use case can be started;
postconditions, i.e. the state of the system at the conclusion of the use case execution;
functional requirements the WeGovNow platform needs to meet in order to enable the
user to actually perform the desired task.
The service scenarios and use cases presented in the present document will be further analysed and refined in an iterative manner, and new ones added, for which all stakeholders / user groups concerned will be involved by means of series of workshops, interviews and prototype demonstrations/tests. The results will be reported, before the start of the project’s piloting stage, in D2.3 (WeGovNow Use Cases v.2) due in M18. In the weeks and months after submission of this deliverable, use cases and RTD across WeGovNow will be integrated in an iterative process of agile development. This process will include:
Assessment of listed use cases in accordance with agreed criteria to enable the
prioritisation of use cases in close coordination with WP3;
Conversion of prioritised use cases to an extracted set of functional and non-functional
requirements;
D2.2 WeGovNow Use Cases v.1
8
Coordination of development tasks and collaboration with pilot site managers via
assigned task leaders with responsibility for specific WeGovNow platform components.
D2.2 WeGovNow Use Cases v.1
9
1 Introduction
This document represents the 2nd deliverable of WP2. A set of initial use cases is presented
which will be further extended and refined until the starting of the project’s piloting stage,
and reported in D2.3 (WeGovNow Use Cases v.2) due in M18.
With its ambitious objectives, WeGovNow is entering new ground in several respects. ICT-
supported co-creation of new services requires hitherto unprecedented collaboration of the
participating public authorities with a range of other stakeholders (e.g. citizen groups,
NGOs). A key challenge experienced during the initial stage of the project concerns the fact
that, from the perspective of the participating public authorities, a multi-faceted innovation
process needed to be launched. In fact, WeGovNow needs to pursue public service process
innovation complemented by simultaneous technology innovation.
It has finally turned out that launching this two-pronged innovation process at the side of
the participating public administrations took more time than expected.
Also, it has turned out that the originally envisaged methodological approach to be pursued
for the purposes of use case development needed to be adapted, with view to enabling
elicitation of requirements on both, new public service delivery process and the new
technological infrastructure to be built in order to effectively support these. As a result, a
multi-method approach has been adopted combining elements of the originally envisaged
SCRUM methodology with elements from other methodological approaches.
The required extension of the originally envisaged methodological approach (introducing
service scenarios identifying stakeholder roles and collaboration processes) has lead to the
present deliverable being submitted 3.5 months later than foreseen in the original
workplan. It is, however, not expected that this delay will have any negative knock-on
effects on the schedule for delivery of the final WeGovNow use cases.
The remainder of the present report is structured as follows:
After a summary of the challenges experienced during the development of the initial set
of use cases (chapter 2.1), chapter 2.2 describes the extended methodological approach
adopted to appropriately address these challenges.
Chapter 3 presents the outcomes generated in terms of an initial set of use cases to be
further refined / extended according to the workplan.
A brief outlook to the upcoming worksteps is presented in chapter 4.
The annexes in chapters 5 to 10 include: detailed outcomes of method review (ch. 5),
generic user requirements (ch.6) and several examples of personas (ch. 7) and user
stories (ch. 8) derived from the initial scoping analysis, the reporting template used for
user scenario analysis (ch. 9) and references (ch. 10).
D2.2 WeGovNow Use Cases v.1
10
2 Methodological approach
2.1 Challenges experienced
WeGovNow has the objective to augment existing eGovernment solutions with a new type
of civic engagement digital infrastructure which combines social network features, issue
reporting and OSM-based Geoweb applications. In doing so the project does not consider
technological innovation as an end in itself. Ultimately, WeGovNow aims at having
transformational impact on public services as they are currently delivered. In this respect,
the work pursued within WP2 throughout the initial stage of the project revealed some
unanticipated challenges. These derive from the way existing services are currently
organised in the three pilot cities, and from the diversity of issues concerned when it comes
to developing new organisational processes for collaborating with individual residents,
citizen groups and the civil society in more general. In turn, the methodological approach
initially envisaged for use case development needed to be extended. This is described in the
following subsection.
2.1.1 A multi-dimensional innovation challenge
WeGovNow strives for breaking new ground by employing digital technologies as a game-
changer in the relationship between citizens and government. To this end, a digital platform
will be developed and validated for engaging local civil society in the co-production of
citizen-centred services and in the co-development of strategic approaches to community
development. From the initial stakeholder interactions organised within this work package it
became clear that the general promise held by ICT to enable the tailoring of public service
delivery processes around the citizens’ needs and aspirations rather than administrative
“silos” is anything else but a self-fulfilling prophecy. Putting such an approach into practice
does not only require a supportive digital infrastructure being put in place. Beyond this, it
requires shifting power – at least to a certain extent – from public administration to citizens
as ‘customers’.
From the perspective of the three cities participating in the project, this has highlighted the
need for pursuing a multi-pronged innovation approach, one that simultaneously pays
attention to the particular working models of different administrative units to be involved
and to the technology to be employed. In fact, technology innovation and organisational
process innovation must be pursued at the same time. Besides the mere implementation of
ICT systems and applications, innovative practices need to be put in place that enable
collaboration of different parties along service delivery processes that are tailored around a
broader spectrum of stakeholder needs and aspirations, rather than “traditional” working
models of established government units.
D2.2 WeGovNow Use Cases v.1
11
As revealed by the initial stakeholder interactions pursued within WP2, the desired end user
support can usually not be delivered by ICT services alone but by a socio-technical system1.
In a socio-technical system, service delivery incorporates a number of elements in addition
to ICT, in particular specific roles played by a range of staff with appropriate qualifications.
Such a perspective does not however exclude that in some cases, service automation can be
– or for cost reasons must be – virtually complete, with no personnel roles in day to day
service provision. Here overall services and ICT services are close to identical. For
sustainable delivery even of fully automated services, the wider socio-technical system is
never completely absent. Where there is an organisation with responsibility for the
automated service, organisational processes are always necessary, if not for acquiring data
then for maintaining and updating software.
Against this background, the methodological approach to be adopted for the purposes of
use case development in the framework of WeGovNow needs to enable identification of
both, functional/non-functional user requirements on the new technical platform to be
developed and process-related requirements on new public service models that need to be
put in place respectively.
2.1.2 Review of existing methodological approaches
This section presents a broad overview of various methodological approaches to use case
development and user requirements gathering, both in the context of traditional
approaches and in the context of AGILE software development. A more detailed review on
the literature is included in Annex I (Chapter 5) in which the strengths and weaknesses of
these method are outlined.
The subsequent subsection goes on to describe how these methods have been combined
and adapted to the WeGovNow context, where two key factors mean that the standard
approaches cannot be applied ‘out of the box’, namely: the development of new public
service delivery processes coupled with technology innovation to effectively support these.
The wide geographical distribution of the end users of the system and the exploitation of
existing software provide further support for the need for a more tailored methodology.
Approaches to Development
Several different models or approaches to software development have been developed over
the years, which can be broadly characterised by the level to which users are involved in the
full software development cycle (requirements gathering, requirements documentation,
software development, testing, deployment). Involving users in this process takes time and
levels of involvement may vary. However, stakeholder engagement has been identified as
an important success factor in the context of the WeGovNow platform uptake and sustained
use and is therefore seen as essential.
1 The concept of socio-technical systems has been developed as an approach to complex organizational work
design, thereby recognizing the interaction between people and technology in workplaces. C.f. for instance Pasmore (1988)
D2.2 WeGovNow Use Cases v.1
12
The Waterfall method has limited user involvement and establishes all the project
requirements at the beginning, analyses them, designs a solution, codes the solution and
carries out tests. Users are involved at the beginning and end of the process (i.e. during
requirements gathering and testing) Turner et al (2013). An advantage is that it provides the
big picture of the system up front but for medium or large projects a long list of
requirements is generated, which may not be read or even understood in any detail by the
developers (Cohn 2004).
The amount of user involvement in the Spirals and Rapid Application Development
approach is increased and goes some way to address some of the limitations of the
Waterfall method. The Spiral builds on the Waterfall method by adding risk analysis and
prototyping, which in turn leads to more frequent checks on progress and engagement with
stakeholders (Sharpe et al 2009). Unlike the previous approaches, Rapid Application
Development takes a user centred view to requirements gathering, and time-boxes
development into cycles of six months each, with the goal of developing a working system at
the end of the cycle (Sharp et al 2009). Users and developers work on requirements in
intensive requirements gathering phases at the start of each cycle.
“AGILE project management is a style of project management that focuses on early delivery
of business value, continuous improvement of the projects product and processes, scope
flexibility, team input, and delivering well-tested products that reflect customer needs”
(Mark, 2012). Individuals and interactions are valued over processes and tools as are
delivery of working software over comprehensive documentation; customer collaboration
over contract negotiation and responding to change over following a plan (Sharp et al 2009).
Agile is characterised by frequent short design phases (Cohn 2004 and put utmost
importance on iterative and incremental development, where requirements and solutions
evolve through collaboration between self-organising, cross-functional teams. It promotes
adaptive planning, evolutionary development and delivery, a time-boxed iterative approach,
and encourages rapid and flexible response to change. Multiple methods exist within the
framework (see Annex I in Chapter 5 for further details) SCRUM is one of the common
methods applied in which the focus is on the importance of handling emergent
requirements and striking a good balance between flexibility and structure (ibid). SCRUM
projects progress through a series of 30-day iterations called sprints, at the outset of which
each team decides what is to be achieved. SCRUM processes do not allow any changes in
the sprint (Cohn, nd). The WeGovNow project strives to adopt an Agile development
approach that may however entail some adaption. The geographical distribution of
potentially self-organising, cross-functional teams – including end user’s interactions may,
for example determine the number of and length of sprint cycles possible.
A further set of practices and methods which place the user at centre of any design process;
i.e. for both digital or non-digital products (Norman, 1988) fall under the philosophy of User-
Centred Design (UCD). As it is the case with some of the previously mentioned approaches
to development, UCD includes various methods which enable user involvement at various
stages of the product development, from very early, which usually aim at understanding
D2.2 WeGovNow Use Cases v.1
13
user needs and defining requirements, to the very late stages where usability and User
Experience (UXP) evaluations take place. User involvement also varies from simple user
observation or user interviews which inform the design process to co-design approaches
where users are deeply involved, occasionally as partners, in the design process.
Gathering and Documenting Requirements
The aim of any requirements elicitation process is to determine what features the software
should have, with this activity being carried out recurrently through the requirements stage.
Each gathering activity includes preparation, execution and analysis (ibid). In other words, a
three-stage process can be identified.
Additionally, in any requirements gathering process, it is important to not only involve the
users but also to document the requirements in a format that allows them to be
communicated throughout the team in a consistent manner (Sharp et al 2009).
Requirements lists, which provide a detailed description of a full set of requirements for
software development, are traditionally associated with the Waterfall approach to
development. They involve three stages: information gathering, when requirements are
elicited from users, representation – modelling/documenting the requirements, and
verification – confirming the requirements with users (Brown and Rogich 2001).
Use Cases are traditionally associated with the Waterfall, Spiral and Rapid Application
Development approaches to software development. A use case is a generalised description
of a set of interactions between the system and one or more actors, where an actor is either
a user or another system (Cohn 2004). This can be written as free text or a structured
format (see Annex I in Chapter 5). They focus on user/system interaction rather than the
user’s task – the user is an actor and the focus is very much on the user, and captures the
actor’s goal in using the system.
Assumptions about the existence of technology to interact with and about the user interface
and type of interaction (Sharp et al 2009) present a disadvantage of the Use Case approach.
This is overcome, however, with Essential use cases. These are abstractions from scenarios
(described below) and consist of a name, a list of user actions and a list of system
responsibility that interlinks with the user actions list (ibid). They are associated with user
roles rather than actors (ibid).
Scenarios are commonly used in Agile development. A scenario is an informal narrative
description that describes human activities or tasks in a story that allows exploration and
discussion of contexts, need and requirements (Sharp et al 2009). The advantage of using
scenarios is that they can be created by a wide range of stakeholders and avoid the more
technical focus of the approaches described above and instead focuses on what the users
are trying to achieve (ibid). Scenarios can be generated during a workshop, interview or
brainstorming sessions, and can also be used to imagine potential users of a product (ibid).
Unlike Use Cases or Requirements List, scenarios are not intended to capture a full set of
requirements – instead they offer the perspective of one system user. They do however
obscure broader, organisational level, issues (Sharp et al 2009).
D2.2 WeGovNow Use Cases v.1
14
A user story is a written description of the concepts used for planning and has three
components (Jeffries 2001 cited in Cohn 2004) and are closely associated with the Agile XP
approach to development (although they can be adapted for SCRUM methodology if
required). They are based on the principle that “The best estimates really come from
developers who understand what they’re estimating” (Patton 2014). User stories are written
by users, and all the potential users of a system should be identified.
The story should identify what the user is trying to do, and missing stories can be identified
by asking ‘what is the user likely to do next’, ’what mistakes could the user make here’,
‘what could confuse the user at this point’, or ‘what additional information could the user
need’ (ibid). The user stories should include a high-level description – e.g. ‘A user can search
for jobs’ but also detail such as how they can search – by date, location, job title, skills
required, salary and so forth. Cohn (2004) notes the following advantages of the user story
approach:
They focus on verbal communication
They are comprehensible
They are the right size for planning
They work well for iterative development
They encourage deferring detail
They support opportunistic development
They encourage participatory design
However, non-functional requirements are not usually documented as part of user stories
(Cohn 2004) and as with scenarios they have the disadvantage that the big picture and
overall goal of the software development process can be lost. As user stories are written by
the users, there is also an additional, perhaps complex, process required to turn the user
stories into something that the technical team can work from (Turner et al 2013).
User-Centre Design (UCD) methods and techniques consider a wide spectrum of users in
terms of diversity (e.g. gender, age, disability), perspectives (e.g. citizens, council users etc)
as well as different cultural contexts (i.e. we work with stakeholders in both UK and Italy).
To address design issues for such a wide spectrum of users but more importantly to
communicate them with design and development teams is often a complicated task which
can be eased by using personas.
Persona is a popular UCD method used in the requirements elicitation stage as well as other
stages of the design and development lifecycle. Personas are detailed descriptions of
possible end users which communicate the main information and which can help designers,
developers and other people who work on a project to impersonate potential users. Usually
they include information about user’s skills, attitudes, tasks and environment.
The WeGovNow project aims to breach new territory in eGovernment product development
and service delivery and sets out to develop new collaborative ways of working within local
government. Existing methods do not enable coverage of the full spectrum of requirements
D2.2 WeGovNow Use Cases v.1
15
to be elicited through user interaction (service delivery process innovation & service
platform innovation) and as such a composite process has been adopted and will be applied
moving forward.
2.2 Methodological approach adopted
Based on the experiences gained during the initial stage of WP2 user engagement activities
and the methods review a blended approach is adopted for the purposes of WeGovNow use
case development. This can be viewed as a step-based approach, as graphically summarised
in Exhibit 1., that commenced with preliminary scoping workshops with representatives
from different government units to be involved in further use case development work.
The initial scoping workshops focused on a broad introduction to the project, its aims and
objectives and how these fit with the authority’s strategic development and broader
engagement policy. This was then followed by a discussion of work programmes across local
government units, their objectives and scope, potential ICT use, challenges and risks within
the context of the WeGovNow Platform development, organisational processes and citizen-
centred services delivery. A critical appraisal of an initial set of use case scenarios that were
based on a selection of identified work programmes and potential technology requirements
followed. These were consolidated in terms of illustrative personas (see Annex III in Chapter
7) and related user stories. Based on transcriptions from the initial scoping workshops an
initial set of user requirements was derived (see Annex II in Chapter 6).
Exhibit 1: WeGovNow use case development approach
Following the iterative approach a second phase of use case development, based on the
outputs from the initial scoping, resulted in a set of analytical service scenarios. These were
D2.2 WeGovNow Use Cases v.1
16
developed through a series of internal discussions and meetings with staff across local
government departments and project team members.
Based on the previous work steps the service scenarios defined will be used for further
analysis and iterative refinement by means of stakeholder / user workshops and key
informant interviews to be pursued throughout the remainder of the project’s use case
development phase (by project month 18). This involves different subsequent
methodological steps as follows.
2.2.1 Service scenario description
A service scenario is developed to illustrate the advantages of new participatory online
services to be developed and piloted in collaboration with the three pilot municipalities
that:
enables and/or improves the involvement of citizens and/or civil society organisations
and/or local businesses in public service delivery at municipal level;
relies on the use of the WeGovNow platform by municipal staff and/or citizens and/or
civil society organisations and/or local businesses in public service delivery at municipal
level.
The service scenario is designed to set the context within which the WeGovNow platform
will be applied in the pilot city. It serves to provide an informal narrative description that
describes human activities and tasks (or else use cases) in a story that allows exploration
and discussion of contexts, need and requirements (Sharp et al 2009). It is aimed to ensure
that stakeholders understand the requirements, with a focus on what the users are trying to
achieve (ibid).
2.2.2 Use cases derivation
For each of the service scenarios one or more use cases are to be specified. A use case
represents a particular task or problem a user wants to achieve/address according to the
service scenario developed earlier, and should refer to a specific user/system interaction
that captures the users’ goal.
Staff of the local employment service wanting to indicate a dedicated job vacancy on a map
accessible through the WeGovNow platform or a citizen wanting to indicate on this map a
broken street light in her/his neighbourhood may serve as examples here. For our purpose
we consider a “user” as an individual trying to achieve something with the help of the
WeGovNow platform. A user acts within a particular role at a given point in time as defined
earlier in the service scenario, e.g. as a representative of a public administration or as a
citizen. In reality, it may however be possible that a user acts in different roles at different
points in time (e.g. in her/his role of public staff in an occupational context and as a citizen
during leisure time.
D2.2 WeGovNow Use Cases v.1
17
2.2.3 Requirements elicitation
For each use case – i.e. a specific task or problems a user wants to address - functional and
non-functional requirements are to be derived. Functional requirements concern a
particular functionality the WeGovNow platform needs to provide in order to enable the
user to actually perform the desired task. Beyond functional requirement, the user may
however have requirements on the WeGovNow platform which do not necessarily relate to
a particular functionality, e.g. when it comes to the usability of a given functionality.
Beyond requirements imposed by the users (i.e. user requirements) on the new platform to
be developed and piloted, a range of other requirements may be derived from the service
scenario described earlier. There may for instance stem from relevant legislation/regulation,
ethical considerations and/or service quality standards to be adhered to. Beyond this,
preconditions should be identified in terms of any activities that must take place or any
conditions that must be true, before the use case can be started. Finally, postconditions
should describe the state of the system at the conclusion of the use case execution.
2.2.4 Legacy process analysis
This analytical step focuses on the identification of any requirements on WeGovNow
potentially stemming from historically grown legacy service processes and infrastructures
prevailing in the various pilot cities. Therefore, it aims at identifying organisational/service
interfaces and collaboration models existing prior to the implementation of the WeGovNow
service scenario. It is to be analysed in what way any of the challenges/problems addressed
in the use case have been dealt with until now, if at all. In particular, it should be described
whether any form of inter/intra-organizational cooperation between the parties involved
has existed up to now, and if so in what way.
2.2.5 Value case analysis
This analytical step focuses on identifying innovative aspects in relation to the participation
of stakeholders in service delivery within the new service scenario. It aims at documenting
in what way the use case is expected to help addressing current challenges/problems by the
participatory public service. Any impacts that are envisaged to be realised when compared
with the current situation should be described as concretely as possible. The sustainability
of the WeGovNow solutions to be developed within the project will not at least depend on
whether or not a clear “value case” will become apparent from the validation trials to be
implemented at a later stage in the overall project. This aspect deserves attention at an
early stage as outcomes initial stakeholder workshops suggest that currently existing
administrative practices may not yet be well-attuned to the mainstreaming of participatory
services.
D2.2 WeGovNow Use Cases v.1
18
2.2.6 Options for service scenario optimisation
A final analytical step focuses on identifying possible variants of the service scenario and
options for improvements potentially to be explored. Here we are interested in learning
whether possible variations or room for improvement the current service scenario can be
anticipated at this stage, albeit this may require further internal discussions and/or
clarifications. These may concern the service concept as such or just selected aspects.
3 Initial use cases
In the following subsections, a first version of use cases are presented which were derived
from an initial set of service scenarios are presented. In line with the multi-staged
methodology described above this starts with a brief summary of the service scenario
concerned (role naming tables & role description tables). Next, a set of use cases derived
from each service scenario is presented. Each use case is analysed according to a number of
dimensions, including:
The use case title should comprise a concise, goal-oriented name for the use case.
Name the primary role(s) that interacts with the system and performs the use case to
accomplish tasks.
A brief description of the goal and context of this use case. This is usually an expanded
version of what you entered in the “Title” field.
Preconditions list any activities that must take place or any conditions that must be true,
before the use case can be started.
Postconditions describe the state of the system at the conclusion of the use case
execution.
Functional requirements concern a particular functionality the WeGovNow platform
need to provide in order to enable the user to actually perform the desired task, so
describe what the system should do.
3.1 WeGovNow service scenario #1 (San Donà di Piave)
3.1.1 General Background
In San Donà di Piave there are currently around 1.000 citizens who can be considered as
“frail” or otherwise being in need of support. Today, one in ten inhabitants is aged 65 years
an above. Many of these experience loneliness and a lack of social relations, within their
families and the wider community. Also, there is a considerable number of older citizens
experiencing difficulties in remaining in their own homes because of architectural barriers.
There are also many instances where older people cannot afford their houses anymore after
having reached the retirements age. Others wish to move into a smaller flat as they get
older and their children may have moved away. There are several public services addressing
these people including the local health authority, the municipal social services and a social
D2.2 WeGovNow Use Cases v.1
19
housing organisation. WeGovNow is envisaged to stimulate and support new forms of
collaboration in addressing older people’s needs, thereby involving public services, civil
society organisations and individual volunteers.
3.1.2 Role Naming
Type Name
Local Authority/
Municipality
M01 - Municipality’s ICT department
M02 - Municipal social & housing service
M03 - Local health authority
M04 - Nursing home
Citizens C01 - Older person living in the community
C02 - Citizen looking after an older person in need of support (family
carer)
NGOs N01 - Older peoples’ association
Businesses B01 - Local touring coach operator
B02 - Local social enterprise
Other -
3.1.3 Role Descriptions
Type Name
Local Authority /
Municipality
M01 - Municipal IT department:
The ICT department maintains the new WeGovNow platform in
technological regard, and it is responsible for trouble shooting
concerning the technical operation of the platform. Also, the
department responds to any requests submitted by platform users in
relation to technical problems these may experience (e.g. a broken
link). The latter may be directed to IT unit staff through the
telephone help desk operated by the municipality or straight through
the WeGovNow platform in terms of a dedicated issue reporting
function. To this end, IT unit staff executes a pre-defined workflow
process, for instance requiring at least an initial response to an end
user request within three working days.
Beyond this, the department is responsible for the regular mapping
of information provided on the municipality’s existing web portal
(http://www.sandonadipiave.net/) such as news items, event
announcements, council resolutions and the like on the WeGovNow
platform. This concerns only those information items which are of
particular relevance to older people and/or those supporting them
formally/informally, and - at the same time - can be related to any
D2.2 WeGovNow Use Cases v.1
20
Type Name
geographic dimension in a meaningful way. Here again, the IT
department relies on a pre-specified workflow process agreed
internal to the municipal administration, requesting e.g. content
producers to specify the relevance of a given information item to a
particular WeGovNow target group and a related regional dimension
according to a dedicated and easy to use format. As far as any
relevant information is available in terms of open public data (e.g.
related council resolutions), these are linked to the mapping entries
by the ICT department as well.
Local Authority /
Municipality
M02 - Municipal social & housing service:
Geographic aspects of the services available from the municipal
social and housing authority are regularly mapped on the publicly
accessible WeGovNow platform according to a pre-specified format.
The latter may e.g. include general information on services being
delivered according to the authority’s public duty (e.g. the location of
flats available under a social housing scheme, eligibility criteria for
those applying for a flat, how-to-do guidance concerning the
application process and the like). Beyond this, more specific
information may be mapped, e.g. on particular events/activities
organised in the framework of public service delivery (e.g. social
events organised for older people living in the community). At the
same time, staff regularly monitors any feedback to it’s particular
entries provided by citizens, local NGOs and/or businesses on
through the public interface of the platform (e.g. in terms of
requests, suggestions or annotations entered on the WeGovNow
platform). A response is delivered by authorised staff according to a
pre-specified process (e.g. immediate message that a request has
been received and information on how the request will be further
handled internal to the public service).
In case any feedback is received suggesting further collaboration with
external parties – either directly or indirectly (e.g. individual
volunteers or NGOs such as the local association of active retirees) -
municipal staff approaches the party concerned on a case-by-case
basis in order to further discuss options for collaboration. If a general
agreement on further collaboration has been reached, authorised
staff opens up a dedicated “closed group” on the WeGovNow
platform and invites all external parties concerned to join the closed
group having access to protected interface within the platform. The
latter supports further collaboration on the particular topics under
discussions, e.g. in terms of exchanging messages and documents
supporting joined-up planning/conduction of events and activities.
D2.2 WeGovNow Use Cases v.1
21
Type Name
These may include standard materials/templates prepared by the
municipality (e.g. how-to-do-guidance on the
preparation/conduction of events/initiatives, related templates and
the like) and ad-hoc content generated by individual group members
on the on-the-fly (e.g. event/activity outlines, related schedules and
the like).
At the same time, staff regularly monitors entries made in the public
area of the WeGovNow platform by other parties (e.g. individual
citizens, local NGOs, businesses) in order to assesses whether or not
a dedicated collaboration or any form of support may be deemed
meaningful by the social services, e.g. when it comes to
initiatives/events announced/discussed by local elderly associations,
businesses and/or other units of the public administration. If so
authorised staff approaches the parties concerned and – if deemed
meaningful - again opens up a dedicated “closed group” on the
platform accessible by all parties concerned.
Local Authority /
Municipality
M01 - Local Health Authority
As in the case of the municipal social service, geographic aspects of
the services available from the local health authority are regularly
mapped on the publicly accessible WeGovNow platform according to
a pre-specified format. The latter may e.g. include general
information on services being delivered according to the health
authority’s duty (e.g. different service offerings available at the local
health centre). Beyond this, more specific information may be
mapped, e.g. on particular events/activities organised in the
framework of public service delivery (e.g. local events on health
prevention in old age). Again, staff regularly monitors any feedback
to its entries provided by citizens, local NGOs and/or businesses on
through the public interface of the platform (e.g. in terms of
requests, suggestions or annotations entered on the WeGovNow
platform). A response is delivered by authorised staff according to a
pre-specified process.
Beyond this, the health authority has set up a “closed group” on the
WeGovNow portal involving ten community nurses employed by the
health authority, four social workers employed by the municipality
and one representative of a local nursing home. Also, members of
two voluntary associations representing active retirees are involved.
Upon informed consent, the individual members of the “closed
group” map their clients on the WeGovNow platform, and any
interventions scheduled under a particular formalised care scheme
(i.e. formal health care, formal social care, and informal care). Also,
D2.2 WeGovNow Use Cases v.1
22
Type Name
the group members regularly look up all entries concerning their
clients, in order to check whether there might be a need for mutual
coordination with other parties (e.g. in case a social carer identifies a
need for an unplanned health intervention and vice versa). If so,
group members have the possibility to annotate relevant entries
made by other group members respectively or to submit a dedicated
massage to the parties concerned (e.g. in order to call for a
multilateral case conference to be held on-site or by telephone).
Also, all group members can publish calls for voluntary support
through the WeGovNow platform. These can be viewed by registered
volunteers who can respond through the platform as well. Beyond
this, those registered volunteers who have provided a mobile
telephone number receive an automatic text message altering them
that a new request for voluntary support has been published.
Local Authority /
Municipality
The local nursing home provides residential nursing care to older
people having significant difficulty in coping with activities of daily
living. The nursing home has adopted a so called “open house“
concept directed towards facilitating social contacts of the residents
with the surrounding community. In the framework of this strategy a
summer party is organised on an annual basis. The summer party is
announced through the WeGovNow platform well in advance in
conjunction with a call for voluntary support. Individual citizens, the
older people’s associations and local businesses respond to the call
and jointly organise the upcoming summer party. The
NGOs The members of two older peoples’ associations tag place in their
community according to their age-friendliness, for example their
accessibility to people with mobility or visual impairments. An older
person experiencing for example a bus stop or leisure facility as
particularly inaccessible can add a comment to the point of interest,
way or area on the map. This way, issues impacting on the age-
friendliness of the city space are reported. From time to time,
municipal staff monitors and analyses tagged places, and the
outcome is informally fed into budget planning activities internal to
the administration. Moreover, the older people’s organisations want
to arrive at a jointly agreed priority list of issues to be proposed to
the municipality for further consideration. They gather online feed
back by their members on perceived priorities and launch a final
voting on the three top priority issues to be proposed to the
municipality for further consideration.
Businesses tbc. : Local touring coach operator collaborated with volunteers in
organising day trips addressing “active” older people and those
D2.2 WeGovNow Use Cases v.1
23
Type Name
requiring accompaniment. tbc.: social enterprise managing social
housing facilities collaborates with municipal social care services and
volunteers to address people in need of support.
Other -
3.1.4 Related Use cases
Use case 1.1 (technology-related trouble shooting)
a) User role(s) concerned M01 - The municipality’s ICT department
b) Description of task to be performed / problem to be addressed by the user Staff regularly monitors incoming problem reports as submitted by the end
users according to a dedicated reporting format (e.g. an alert in conjunction
with a short running text specified by the end user). Staff analyses the problem
as reported by the end user in national / lay man’s language, initiates remedial
action (e.g. by contacting the consortium member hosting the relevant sub-
section of the overall platform or software application concerned) and briefly
responds to the user by means of a short text message.
c) Preconditions 1) Staff is authorized to monitor/address problem reports submitted by end
users.
2) Staff has the skills required to monitor/address problem reports submitted
by end users.
3) The parties responsible for maintaining individual platform components
have named a contact person to be approached in case of technical
problems
d) Postconditions 1) The problem reported by the citizen is addressed.
2) The citizen receives a response that the problem has been addressed.
3) If the problem reported by the citizen cannot be addressed or is due to a
user error the citizen receives an explanation.
e) Functional requirements 1) All platform users should be able to alter IT unit staff about technical
problems they encounter.
2) IT unit staff should be able to monitor and initially analyze incoming end
user alters and problem descriptions.
3) IT unit staff should be able to identify any further party in charge of
technically hosting / maintaining a particular subsection / application
software integrated into the overall platform.
D2.2 WeGovNow Use Cases v.1
24
4) IT unit staff should be able to easily alert/inform any responsible party
external to the municipality in case of a technical problem reported by the
end user
5) IT unit staff should be able to monitor progress of any remedial action
agreed with any external parties responsible for maintaining/hosting a
particular software application integrated into the overall platform.
6) IT unit staff should be able communicate back to the platform users who
has originally reported a technical platform.
f) Non-functional requirements 1) All users should be enabled to easily recognize the problem reporting
function when a technical problem occurs, i.e. independent which particular
sub-section of the overall platform they may be utilizing when a technical
problems occurs.
2) The reporting of any technical problems experienced by the end users
should be possible with few clicks.
3) The end user submitting a problem report should be immediately informed
about the further process of request/report handling internal to the
municipality.
4) Municipal IT staff should be enabled to overview, analyze, communicate
and track all problems reported by using a single interface rather than being
required to switch between different interfaces.
Use case 1.2 (mapping of municipal news items)
a) User role(s) concerned M01 - The municipality’s ICT department
b) Description of task to be performed / problem to be addressed by the user Prior to publishing on the municipality’s existing web portal, IT unit staff
receives a news items from the content producer internal to the public
administration (e.g. public relations unit staff). The content producers indicate
any geographic dimension relating to a given news item according to a pre-
specified format (e.g. location, date and time of an upcoming event, related
Open Data). IT staff maps all news items received in conjunction with relevant
information items on WeGovNow platform.
c) Preconditions 1) IT unit staff has received the news item from content producer according to
a commonly agreed format to be mapped onto WeGovNow, including an
indication of the geographic dimension concerned and related information
items.
2) IT unit staff is authorized to map new item on WeGovNow.
d) Postconditions
D2.2 WeGovNow Use Cases v.1
25
1) News item to be published on the Municipality’s existing web portal is
accessible to the all WeGovNow platform users, together with related
information item(s) of relevance to the platform users.
e) Functional requirements 1) IT unit staff should be able to map a particular news item in conjunction
with a potentially diverse range of associated information items (e.g.
date/time of an upcoming event, details of person to contact, registration
form and the like)
2) IT unit staff should be able to import Open Data available at the
municipality’s existing web portal (e.g. council decisions) for making these
available in conjunction with a news item to be mapped on the WeGovNow
platform.
f) Non-functional requirements
1) IT unit staff should be able to derive relevant information items from different sources (e.g. electronic documents, e-mails and data bases) without too much effort for being presented in conjunction with the news item to be mapped on the WeGovNow platform.
Use case 1.3 (Mapping of public service offerings)
a) User role(s) concerned M01 - Municipal social service
M02 - Local health authority
M04 – Nursing home
b) Description of task to be performed / problem to be addressed by the user Staff of various public service organization regularly maps service offerings (e.g.
regular opening hours of local health care centre, occasional events such as
social events for the elderly) on the WeGovNow platform in conjunction with
relevant information items (e.g. opening hours, event program, details on
person to contact, interactive and/or printable registration form) on
WeGovNow platform
c) Preconditions 1) Public service staff is authorized to map new item on WeGovNow
d) Postconditions 1) Information on various public service offerings is accessible to all
WeGovNow platform users
e) Functional requirements
1) Social service staff should be able to map a particular service offerings in conjunction with a potentially diverse range of associated information items
D2.2 WeGovNow Use Cases v.1
26
f) Non-functional requirements
1) Social service staff should be able to derive relevant information items to be associated with a particular service offering from different sources (e.g. electronic documents, e-mails and data bases) without too much effort.
Use case 1.4 (Responding to request on social service offerings)
a) User role(s) concerned M01 - Municipal social service
C01 - Older person living in the community
C02 – Person looking after an older person in need of support (family carer)
b) Description of task to be performed / problem to be addressed by the user
Public service staff regularly monitors incoming comments/requests concerning the service offerings mapped on the platform. Staff analyses the comments/requests received and responds to the users via the platform
c) Preconditions 1) Public service staff is authorized to map new item on WeGovNow
d) Postconditions 1) Information on social service permanent and occasional offerings is
accessible to all WeGovNow platform users
2) Staff responsible for a particular service offering and other WeGovNow
users communicate about a particular service offering can.
e) Functional requirements
1) Public service staff should be able to map a particular service offerings in conjunction with a potentially diverse range of associated information items (e.g. service opening hours, eligibility criteria, pre-produced documents such as leaflets, and the like)
2) Platform users should be able to exchange massages with public service staff responsible for administering/delivering a particular service offering through the platform.
3) Public service staff should be alerted if a user massage comes in relation to mapped service offerings they are responsible for.
f) Non-functional requirements
1) …?
Use case 1.5 (setting up a closed group of collaborators)
a) User role(s) concerned
M02 - Municipal social & housing service
D2.2 WeGovNow Use Cases v.1
27
M03 - Local health authority
C01 - Older person living in the community
C02 - Citizen looking after an older person in need of support (family carer)
N01 - Older peoples’ association
b) Description of task to be performed / problem to be addressed by the user
The municipal social service and the health authority coordinate service delivery to frail older people living in the community with family careers and voluntary supporters of two older people’ associations by means of a closed user group. To this end the care recipient’s home and name is mapped in WeGovNow. Any entries made /messages exchanged through the WeGovNow platform are only be displayed to registered groups members.
c) Preconditions 1) Public social/health service staff is authorized to coordinate delivery of
ambulatory services with informal care providers
2) Informal care providers/supporters have signed a code of conduct
stipulating basic rules/conditions for collaboration (e.g. liability, ethics, data
protection)
3) Individual users have registered to the closed user group
4) Informed consent is given by care recipients
d) Postconditions 1) Information on planned/delivered care interventions is visible to all parties
concerned
2) Staff responsible for a particular service offering and other WeGovNow
users communicate about a particular service offering can.
e) Functional requirements 1) Public service staff should be able to set up a closed user group and invite
dedicated users to join the group.
2) Public service staff should be able to verify which users have registered to
the group and whether the code of conduct has been signed.
3) Public service staff should be able to verify whether the care recipient has
given informed consent
4) Public service staff should be able to map name/address of care recipient in
the WeGovNow platform.
5) All closed group members should be able to maintain joined schedules in
relation to individual care recipients.
6) All closed group members should be able to exchange messages concerning
service planning/delivery in relation to individual care recipients.
7) All closed group member should be able to exchange documents (e.g. scan
of a hospital discharge letter) concerning service planning/delivery in
relation to individual care recipients.
D2.2 WeGovNow Use Cases v.1
28
Use case 1.6 (publishing a call for registered volunteer support of frail individuals)
f) User role(s) concerned
M02 - Municipal social & housing service
M03 - Local health authority
C01 - Older person living in the community
N01 - Older peoples’ association
g) Description of task to be performed / problem to be addressed by the user The municipal social service organization and/or the health authority seek
voluntary support in caring for an older person living in the community. To this
end they publish a call for support on the WeGovNow platform. WeGovNow
users respond to the call. Following registration to a volunteer data base they
join a closed user group to coordinate with other parties involved.
h) Preconditions 1) Public social/health service staff is authorized to publish a call for voluntary
2) Volunteers is willing to signs a code of conduct stipulating basic
rules/conditions for collaboration (e.g. liability, ethics, data protection)
3) Informed consent is given by care recipients
i) Postconditions 1) Call for support is published
2) Code of conduct is signed by volunteer
3) Volunteer as registered to volunteer data base
j) Functional requirements 1) Public service staff should be able to publish a call for support describing
type and volume of support envisaged.
2) WeGovNow platform users should be able to respond to the call and
indicate their general interest.
3) After signing of a code of conduct the volunteer should be able to register
to a closed user group respectively.
k) Non-functional requirements 1) The call should be immediately recognizable by platform users after
publication
Use case 1.7 (publishing of an open call for voluntary support of an upcoming event)
a) User role(s) concerned
M04 - Nursing home
M02 - Municipal social service
C02 - Citizen looking after an older person in need of support (family carer)
D2.2 WeGovNow Use Cases v.1
29
N01 - Older peoples’ association
B01 - Local touring coach operator
b) Description of task to be performed / problem to be addressed by the user The local nursing home announces the annual summer party well in advance in
conjunction with a call for voluntary support on the WeGovNow platform. A
number of citizens and an older people’s organization respond to the call and
indicate their interest in supporting the conduction of the event. They are
invited to a closed user group to coordinate further collaboration. Also, staff at
of municipal social service organization responds to the call for support in order
to find out whether frail older people receiving care services in the community
could attend the party, and if so how the municipal service could contribute to
the event respectively. All parties interested in supporting the summer party
are invited to a closed user group for coordinating further activities. During the
preparatory phase, a local bus coach operator is asked to sponsor the event by
organizing a minibus transfer for a number of frail older people receiving
municipal home care services. Following agreement, the bus coach operator is
invited to the closed user group as well.
c) Postconditions 1) Open call for support is published
2) Those WeGovNow users having indicated their interest register to a closed
user group
d) Functional requirements 1) Nursing home staff should be able to publish a call for voluntary support on
the WeGovNow platform
2) WeGovNow users should be able to respond to the call and indicate their
interest, thereby specifying any particular conditions for their support.
3) Nursing home staff should be able to exchange messages with those
WeGovNow users having indicated their general interest in supporting the
event.
4) Nursing home staff should be able to set up a closed user group and invite
dedicated users to join the group.
5) All closed group members should be able to maintain joined schedules in
relation preparatory work for the upcoming event.
6) All closed group members should be able to exchange messages concerning
event planning
7) All closed group member should be able to access documents related to the
upcoming event (e.g. electronic copies of advertising materials, receipts for
expenditures).
8) Authorized members of the closed user groups should be able to publish
selected information items on the WeGovNow platform (e.g. advertising
materials)
D2.2 WeGovNow Use Cases v.1
30
Use case 1.8 (tagging non-age friendly places)
a) User role(s) concerned
N01 - Older peoples’ associations
M05 – Town planning department
a) Description of task to be performed / problem to be addressed by the user Older people tag inaccessible places on the WeGovNow platform, indicating
particular deficits experienced. These are regularly looked up by staff of the
municipal town planning department.
b) Preconditions 1) Volunteers is willing to signs a code of conduct stipulating basic
rules/conditions for collaboration (e.g. liability, ethics, data protection)
2) Informed consent is given by care recipients
c) Postconditions 1) Call for support is published
2) Code of conduct is signed by volunteer
3) Volunteer as registered to volunteer data base
d) Functional requirements 1) Public service staff should be able to publish a call for support describing
type and volume of support envisaged.
2) WeGovNow platform users should be able to respond to the call and
indicate their general interest.
3) After signing of a code of conduct the volunteer should be able to register
to a closed user group respectively.
e) Non-functional requirements 1) The call should be immediately recognizable by platform users after
publication
3.2 WeGovNow service scenario #2 (Southwark)
3.2.1 General Background
Streets and spaces are the public face of Southwark with the potential to positively or
negatively affect quality of life and perceptions of the borough.
They are also where many vibrant social and cultural activities occur, from markets and
outdoor events to street play, casual encounters and time spent people watching from
pavement cafes. This makes them as important as the buildings and landmarks they provide
settings for.
D2.2 WeGovNow Use Cases v.1
31
Major streetscape improvement schemes on the highway are currently designed without
first conducting a scoping exercise with residents and businesses. Schemes are therefore
being delivered that do not necessarily address local issues or that fall short of the potential
improvements that could be made.
It is thought that advance on-line scoping exercises with residents and businesses will help inform design briefs for improvements schemes in terms of objectives and priorities. We think the tool could help make our design briefs more realistic and responsive to local concerns. The map can also show constraints so that contributors can make an informed decision
3.2.2 Role Naming
Type Name
Local Authority LA01 - Highways Division of the London Borough of Southwark
Citizens C01 - Local residents within the vicinity of the scheme (e.g. 250m
radius)
C02 - People using highway that may not be residents, such as:
o pedestrians,
o cyclists,
o parents of locals schools,
o users of public transport (buses),
o motorists that park in the street
NGOs N01 - Disability groups
N02 - Community groups
N03 - Housing association groups
N04 - Business improvement district groups
N05 - School groups
N06 - Friends of parks
Businesses B01 - Fast food shops
B02 – Pubs
B03 - Cafés
B04 - Off license
Other O01 – Elected Members
3.2.3 Role Descriptions
Type Name
Local Authority LA01 - Highways Division of the London Borough of Southwark:
The Highways team regularly uses the new WeGovNow services as
part of the process of developing design briefs for improvement
schemes. The department is responsible for managing the majority of
D2.2 WeGovNow Use Cases v.1
32
Type Name
streets in the borough including things such as the design, installation
and maintenance of streetlights and traffic signals, maintenance of
roads, including pavements and footways etc. Staff in the Highways
Team use the WeGovNow platform to initiate new scoping exercises
to engage the public and ascertain local priorities, ideas and areas of
concern that can inform their design briefs for area improvements
schemes. The map is used by staff to highlight the boundary of the
area under development which serves as a way to centre the map to
the area of interest on entry.
Staff will look at existing spatial data sets to assess which constraints
may be related to location and may therefore prevent certain
developments or ideas from being pursued and these would then be
imported as additional map layers to platform. They will decide on an
appropriate timescales for which the specific scoping exercises will
stay live to illicit input.
Staff use the various channels available in order to promote when a
new scoping exercise has gone live, prior to which they create relevant
publicity content (e.g. creating QR codes, printed material, Facebook
and Twitter posts, SMS texts…). On setting-up a new scoping exercise
within WeGovNow staff decide whether they want the social media
services linked to new suggestions added to the map are switched on
or off and also decide which Facebook and Twitter accounts should be
linked to the service if selected.
The Highway Team regularly monitor activity for any live scoping
exercises, via a daily digest and other statistics to see how many
people are contributing each week, which channels are being used to
access the map in order to assess whether further publicity or
promotion is required.
Once a scoping exercise has closed staff update the WeGovNow
service to ensure that people are aware the session has closed and
further submissions will be discarded. Team members carry out a
range of analyses to explore the suggestions submitted and the
support for or against these. Once the various submissions and
constraints have been considered feedback is given via the
WeGovNow service. The design briefs are then created based on the
results of the analysis and these are uploaded to the platform and
overlain on the map. Feedback on further actions, developments and
implementation are provided and the results then implemented.
Citizens C01 - Local residents within the vicinity of the scheme (e.g. 250m
radius)
D2.2 WeGovNow Use Cases v.1
33
Type Name
A local resident that uses a street falling within a current highways
scoping exercise goes on to the community council Facebook page and
sees that there is a scoping exercise in progress and clicks on the link
to access the interactive map. On finding the link they then share this
on Facebook with some neighbours and friends.
A housing resident sees a sign on their notice board and speaks to
their resident officer to let them know what they think so that the
resident officer can post something on their behalf as they are not
confident with the technology.
Residents that live nearby (250 m radius?) that may feel knock on
effects from works in the street. E.g. if lots of people request speed
humps there may be more traffic through adjacent streets.
C02 - People using highway that may not be residents
Pedestrians – walk through the area to go to work, take public
transport, visit friends and families. They are of all ages and ethnic
backgrounds, some may have disabilities or special needs. They have
varied use of technology from never using it to quite a lot. They may
see a sign about the scoping exercise and if they feel strongly about
any issues they will try and logon and drop some pins however there
are a range of issues that may prevent them from doing so like not
having access to a smart phone or laptop.
Cyclists – cycle through the area to go to work, visit friends and
families. They tend to be sporty and street smart and use technology.
They may see signs up and leave a comment on the map via a link they
see on a cycling group that they follow on social media.
Parents of local schools – they are concerned about their children’s
safety when dropping off and picking up their children. They see that a
scoping exercise is on and once at home they go on the council
website to try and find the link to the map.
Users of public transport – they travel along buses and may use local
bus stops to get on and off the bus. They may see a sign about the
scoping exercise with a QR code and drop some pins on the map while
waiting for their bus.
Motorists that park in the street – they may park to have access to
local businesses or to access public transport or complete their
journey by fold-up bike. On the way home from work one day they
decide to look up the map on their smart phone and drop a pin to
point out that there is a regular flooding issue that could be taken care
D2.2 WeGovNow Use Cases v.1
34
Type Name
of.
NGOs N01 - Disability groups
Disability groups – they advocate for the needs of people with
disabilities on the highway and use the map to represent views of
their members.
N02 - Community groups
Community groups – they are typically a group of local residents.
There may be a nominated member that contributes to the map on
behalf of the community group. They focus on creating a feeling of
community, reducing isolation and promoting integration and mixing
of various sectors of the community.
N03 - Housing association groups
Housing association groups – they represent the needs of residents
living in housing estates/associations and make suggestions on behalf
of residents.
N04 - Business improvement district groups
Business improvement district groups – they advocate for local
businesses focussing on issues that affect business and promote the
scoping exercise via a link to the map from their website. They also
make suggestions from the perspective of staff member who walk
through the areas in question (C02 ) and as representatives of local
businesses. They regularly check WeGovNow services for updates and
feedback to share with the local business community.
N05 - School groups
School groups – they are concerned about the impact of schemes on
children and their parents.
N06 - Friends of parks
Friends of parks – they would like to improve the amenity of the local
park, access to the park, and enhance biodiversity values and are
active in providing suggestions to the scoping exercise.
Businesses B01 - B04
Businesses within a 100m radius that are mainly fast food shops, pubs,
cafes, with some seating at the front of the premises, as well as off
licenses and betting shops. Shop owners are concerned about parking
as well the amount of traffic that goes through the street. A cafe in
the street receives a pamphlet about the scoping exercise and makes
comments about the lack of parking for customers and that it would
be nice to have some attractive planters by the seating area.
Other O01 – Elected Members
D2.2 WeGovNow Use Cases v.1
35
Type Name
Concerned about their image as an engaged politician, elected
members log into the WeGovNow platform to make sure they add
some comments about issues and opportunities for the current
scoping exercise underway.
3.2.4 Related Use cases
Use case 1: Setting up a new Scoping Exercise
a) User role(s) concerned LA01- Highways Team Member
b) Description of task to be performed / problem to be addressed by the user Staff member sets up the system to initiate a new scoping exercise which
includes defining the boundaries within which suggestions and proposals should
be made; adding relevant data owned by the council as layers that can be
viewed by users accessing the system (e.g. flood risk zones, gullies …); adding
and setting constraints to inform users about aspects that may preclude certain
features of a highway scheme design.
c) Preconditions
1) Staff member has a user account
2) Staff member is logged into system
d) Postconditions
1) A new scoping exercise is created on the system
e) Functional requirements
1) The system shall enable authentication of user to ensure they have appropriate admin rights
2) The system shall allow administrators to define the boundary of the area for which the scoping exercise is being undertaken
3) The system shall allow administrators to define thematic categories for which contributions are wanted (e.g. Traffic, Parking…)
4) The system shall allow administrators to define data entry fields for each theme
5) The system shall allow administrators to add data layers for information consumption (e.g. flood risk zones, gullies…)
6) The system shall allow administrators to set which layers are switched on, by default, when opening the map
7) The system shall allow administrators to set who can enter data
D2.2 WeGovNow Use Cases v.1
36
8) The system shall allow administrators to set whether contributions require moderation
f) Non-functional requirements
1) Staff should be able to set-up a new scoping exercise with ease and efficiency
2) The system should make it clear when the task has been successfully completed
3) The system should make it clear to users if and where required steps or information is missing
Use case 2: Adding a suggestion to a scoping Exercise
a) User role(s) concerned C01 - Local resident within the vicinity of the scheme (e.g. 250m radius)
b) Description of task to be performed / problem to be addressed by the user Local resident wants to propose increasing parking restrictions outside his
home and accesses the system to make a contribution about a scoping exercise
in his area of interest.
c) Preconditions
1) Citizen is logged into system
d) Postconditions
2) A new suggestion is displayed on the map for others to view A new contribution is added to the scoping exercise and can be viewed by everyone.
e) Functional requirements
1) The system shall allow users to upload photos to a suggestion being made
2) The system shall allow users to define a point, line or area to highlight the location for which the suggestion is being made
3) The system shall allow users to input text to describe the suggestion being made
4) The system shall allow users to save draft input for new contributions
5) The system should display the new suggestion on the map (for approval…?)
f) Non-functional requirements
1) The system should make it clear when the task has been successfully completed
2) The system should make it clear to users if and where required steps or information is missing
D2.2 WeGovNow Use Cases v.1
37
Use case 3: Agreeing on a suggestion made by someone
a) User role(s) concerned C02 - People using highway that may not be residents
b) Description of task to be performed / problem to be addressed by the user A cyclist who commutes through the area that currently has a scoping exercise
underway accesses the WeGovNow service to make a contribution to propose
segregating the cycle lane but sees that has already been suggested so instead
decides to agree on the existing suggestion.
c) Preconditions
1) Cyclist can view existing suggestions on the map
d) Postconditions
1) A user’s suggestion indicates that someone else agrees with their suggestion and can be viewed by everyone.
e) Functional requirements
1) The system shall allow users to select an existing contribution
2) The system shall provide a function to allow users to share their support for an existing contribution
3) The system shall provide a function to allow users to share their disagreement for an existing contribution
f) Non-functional requirements
1) The system should make it clear when the task has been successfully completed
2) The system should make it clear to users if and where required steps or information is missing
Use case 4: Editing the Location of a suggestion to a scoping Exercise
a) User role(s) concerned C02 - People using highway that may not be residents
b) Description of task to be performed / problem to be addressed by the user A parent who previously added a suggestion to introduce a new zebra crossing
in a current scoping exercise logs into to edit their original contribution by
moving it to a new location based on discussions with other parents.
c) Preconditions Citizen can view and access their original suggestion
d) Postconditions An existing contribution is sited in a new location and can be viewed by
everyone.
D2.2 WeGovNow Use Cases v.1
38
e) Functional requirements
1) Users can edit their pins that relate to their suggestions which would include the ability to move or delete, or change a comment they’ve made. (Then again what if other people have agreed/disagreed? Allow editing only at time of initial posting?
f) Non-functional requirements
1) The system should make it clear when the task has been successfully completed
2) The system should make it clear to users if and where required steps or information is missing
Use case 5: Sending a suggestion to a scoping exercise via a Tweet
a) User role(s) concerned C01-2 - Citizens
N01-N06- NGOs
B01-B04 Businesses
b) Description of task to be performed / problem to be addressed by the user End users use their mobile phones whilst passing through an area for which a
scoping exercise is under way and add a new suggestion to the WeGovNow
platform by sending a geo-referenced Tweet addresses to the linked Twitter
account for the scoping exercise.
Preconditions
1) End user has a Twitter account
2) End user’s Twitter account has enabled geolocated Tweets
3) A Twitter account has been linked to the scoping exercise map
c) Postconditions
1) A new contribution is added to the scoping exercise and can be viewed by everyone.
2) Any associated media linked to the tweet can be viewed.
d) Functional requirements
1) The system shall allow users to send a Tweet to a dedicated Twitter account to make a post to the WeGovNow platform.
2) The system shall allow georeferenced Tweets to be displayed on a map relating to a particular scoping exercise. This should include the display of any media associated with the Tweet (photos, hyperlinks etc.) and the originators Twitter handle.
e) Non-functional requirements
D2.2 WeGovNow Use Cases v.1
39
1) The system should make it clear when the task has been successfully completed
2) The system should make it clear to users if and where required steps or information is missing
Use case 6: Sending a suggestion to a scoping exercise via Instagram
a) User role(s) concerned C01-2 - Citizens
N01-N06- NGOs
B01-B04 Businesses
b) Description of task to be performed / problem to be addressed by the user End users use their mobile phones to add photos and videos they feel relevant
for a new scoping exercise on the WeGovNow platform, which may highlight
examples of best practice in urban design or specific problem areas that need
addressing.
Preconditions
1) End user has an Instagram account
2) End user’s Instagram account has enabled geotagging
3) A hashtag for the scoping exercise has been assigned
c) Postconditions
1) A new contribution is added to the scoping exercise and can be viewed by everyone.
2) Any associated media linked to the tweet can be viewed.
d) Functional requirements
1) The system shall allow users to share photos and videos uploaded via their Instagram account.
2) The system should enable council staff to set geographic boundaries to filter geotagged media accepted for display
3) The system shall map photos and videos relating to a particular scoping exercise by using a designated hashtag.
4) The system should enable end users to browse through photos and videos mapped.
e) Non-functional requirements
1) The system should make it clear when the task has been successfully completed
2) The system should make it clear to users if and where required steps or information is missing
D2.2 WeGovNow Use Cases v.1
40
3) The system should display images and videos in an aesthetically pleasing way
Use case 7: Searching for a suggestion to a scoping exercise on the map
a) User role(s) concerned All
b) Description of task to be performed / problem to be addressed by the user Suggestions that have been made to a new scoping exercise on the WeGovNow
platform should be searchable by anyone accessing the map to enable them to
seek for specific information, views or ideas.
Preconditions
1) The map has existing entries
c) Postconditions
1) The results from the search criteria are returned.
d) Functional requirements
1) The system shall enable users to type in search terms of their choice
2) The system shall display the result of any searched terms entered.
e) Non-functional requirements
1) The system should make it clear when the task has been successfully completed
2) The system should make it clear to users if and where required steps or information is missing
3) The results should be returned and displayed in a way that is easy to view and see where the entries contain the search terms entered.
3.3 WeGovNow service scenario #3 (Turin)
3.3.1 General Background
Recent regeneration to Dora Park has seen a small area of the pre-existing factory re-
designed to host big events (such as Ramadan, Kappa FuturFestival, etc.). Part of the
regeneration of this community space has also included the creation of sports facilities such
as a basketball field, football pitch and skate park. The skate park is managed by an
association of young people and involves a community of about one hundred young people.
The Public Green Department has budget for maintenance of the park and the creation of
new services and events. One of the goals is to involve local communities, associations and
stakeholders in designing areas within the park for teenagers and young people (with new
services and activities).
D2.2 WeGovNow Use Cases v.1
41
3.3.2 Role Naming
Type Name
Municipality M01 - Public Green and Municipal Buildings Department
M02 - Youth Department
M03 - Innovation and Smart City Department
M04 - Municipal IT department
Citizens C01 - Local residents within the vicinity of the park (e.g. 800m radius)
C02 - People using the park that may not be residents of the
immediate area, such as:
o pedestrians,
o cyclists,
o visitors,
NGOs N01 - Events Organisers
N01 - Disability groups
N02 - Community groups
N03 - Youth associations
N04 - Housing association groups
N05 – Cultural associations
N06 – Sports associations
N06 - Friends of parks
Businesses B01 – Local shops
B02 –Mall Management
B03 – Businesses providing services for park events
B04 – Businesses providing services for park infrastructure and
maintenance
Other O01 – Elected Officials
3.3.3 Role Descriptions
Type Name
Municipality M01 - Public Green and Municipal Buildings Department:
The Public Green and Municipal Buildings team has defined their
annual budget and plans to use the new WeGovNow services to
involve local communities, associations and other stakeholders in
designing an area of Parco Dora for teenagers and young people (with
new services and activities). The department is responsible for
managing green spaces in the city including things such as the
installation and maintenance of street furniture, pavements and
footways etc. and managing events that take place in the park. Staff in
the department use the WeGovNow platform to initiate new co-
D2.2 WeGovNow Use Cases v.1
42
Type Name
design exercises to ascertain local priorities, ideas and public opinions
for the development of youth based services and activities in the park.
The Public Green and Municipal Buildings team is also responsible for
the regular mapping and updating of municipality’s datasets on the
WeGovNow platform, such as playgrounds, park furniture etc. They
encourage local associations, small boutique design companies to
promote their businesses and best practice regarding the area’s street
furniture by sharing links to the map.
Staff log into the WeGovNow platform to initiate a new co-design
exercise and outline the specifics of the exercise. This includes
highlighting the geographic boundaries of the area involved; the
timeframe for which community input will be needed and the location
of contact points in the area where offline engagement activities will
be held. Where specific input on pre-defined topics is required
categories are added to a map asking questions such as “where would
you like to see park benches added?”, “where and what sport facilities
would you like to see?” Open categories can also be added and
categorised using tags.
The co-design exercise is set-up so that suggestions made which are
not bound by predetermined constraints that may prevent certain
developments or ideas from being pursued are added to the
deliberative WeGovNow service in which ideas can be discussed,
developed and refined in more detail.
Staff use the various channels available to promote new co-design
exercises, prior to which they create relevant publicity content (e.g.
creating QR codes, printed material, Facebook and Twitter posts, SMS
texts…). On setting-up a new co-design exercises within WeGovNow
staff decide whether they want the social media services linked to new
suggestions made to the platform switched on or off and decide which
Facebook and Twitter accounts should be linked to the service if
selected.
Team members regularly monitor activity on new co-design exercises
via a daily digest and other statistics to see how many people are
contributing each week, which channels are being used to access the
map in order to assess whether further publicity or promotion is
required.
Once a co-design exercise has closed staff update the WeGovNow
service to ensure that people are aware the session has closed and
further submissions will be discarded. Team members carry out a
range of analyses to explore the ideas and suggestions submitted, the
support for these and review the outcome of the deliberative process.
D2.2 WeGovNow Use Cases v.1
43
Type Name
Feedback is given via the WeGovNow service.
If a general agreement on specific services and activities has been
reached, authorised staff opens up a dedicated “closed group” on the
WeGovNow platform and invites all external parties concerned to join
the closed group having access to protected interface within the
platform. The latter supports further collaboration on the particular
topics under discussions, e.g. in terms of exchanging messages and
documents supporting joined-up planning/conduction of events and
activities. These may include standard materials/templates prepared
by the municipality (e.g. how-to-do-guidance on the
preparation/conduction of events/initiatives, related templates and
the like) and ad-hoc content generated by individual group members
on the on-the-fly (e.g. event/activity outlines, related schedules and
the like).
M04 - Municipal IT department:
The ICT department maintains the new WeGovNow platform in
technological regards, and it is responsible for trouble shooting
concerning the technical maintenance of the platform. Also, the
department responds to any technology-related requests submitted
by the end users in relation to any technical problems these may
experience (e.g. a broken link). The latter may be directed to them
either through the telephone help desk operated by the municipality
or straight through the WeGovNow platform in terms of a dedicated
issue reporting function. The department operates according to a
predefined workflow process, for instance requiring a response to a
dedicated end user request within three working days.
Citizens C01 - Local residents within the vicinity of the scheme (e.g. 800m
radius)
A local resident that lives in an apartment overlooking the park
regularly takes her 8-year old son to play basketball after school. She
is made aware of an opportunity to share her ideas on potential youth
services when walking past a contact point outside the park. She takes
one of the post-it notes and writes down a comment about building an
outdoor swimming pool in a section of the park and pins it to the map
on the wall. One of the Officers from the Youth Association who run
activities from the contact point takes a tablet device and shows the
resident how to transfer her comment directly to the WeGovNow
platform. He also shows her how to view events being held in the
area. When she returns home, the lady signs up to the WeGovNow
service to receive SMS text alerts about events for young people that
might be of interest to her son.
D2.2 WeGovNow Use Cases v.1
44
Type Name
C02 - People using the park that may not be residents of the
immediate area
A teenager living in the centre of town who goes to Parco Dora to
hangout with friends sees a Facebook post asking for ideas about the
development of Parco Dora. He decides to visit the WeGovNow
platform and suggests building an area for free running in an area of
the park. In addition, he proposes starting an annual free running
competition in the park, if his proposal is taking forward, which he
believes could attract people from across the country. With over 2K
Facebook friends and as an avid Instagram user he shares the idea on
Facebook and asks friends to join the discussion on the WeGovNow
platform. He also takes various pictures in sections of the park that he
thinks would be suitable to build a free running zone and uploads
them to the map via his Instagram account. For further inspiration, he
asks his Instagram followers to share videos from free running
locations and events from across the country that are added to the
media collection linked to his proposal on the platform.
NGOs N03 - Youth associations
The engagement team use WeGovNow to publish activities and events
being organised. They collaborate with other youth centred
organisations and volunteers to broaden and strengthen their service
office and also sent out requests for volunteers for events being run.
N06 – Sports associations
Volunteers organised through the Sports Association collaborate with
each other and with parents, and local business to get sponsorship for
new sports equipment for the football and basketball teams operating
in the park. The association initiates the idea on the WeGovNow
platform and sends out a request to businesses in the area for
support.
Businesses B04 – Businesses providing services for park infrastructure and
maintenance
A local business is looking to promote their handmade outdoor
furniture designs. They log into the WeGovNow platform to create a
profile and upload images of some of their furniture designs and
provide information about the materials used and where they are
sourced. After adding their business details, they go to the
WeGovNow home page and see that a co-design exercise is running.
When they click on the map to see where the area of focus is they see
some of the comments and ideas that have already been generated.
They click on a comment which suggests building an outdoor
swimming pool and realise that some of their designs could be
D2.2 WeGovNow Use Cases v.1
45
Type Name
potentially used if the pool were built. They decide to add a comment
and provide a link to some of their designs that could be implemented
if the pool were built. They also suggest that a ‘Parco Dora Pool’ group
be created to discuss potential design ideas.
B03 – Businesses providing services for park events
A social enterprise running a catering company that provides training
and employment for youth offenders receives an email alert about an
open tender for an upcoming event being held in the park. They click
on a link in the email which directs them to further details provided on
the WeGovNow platform about the services required. They see that
they can meet the criteria specified and submit their offer in the
protected area for submissions using the standard template provided.
They emphasise they fact they ‘re supporting young people and that
any surplus food will be posted on the map and made available to
local charities supporting homeless people and those in financial
difficulties in the hope that this sways the decision makers.
Having won the tender and provided the catering they access
WeGovNow to post a ‘food on offer’ call out whilst still at the park
venue detailing what’s available, where to collect it and how long it
will be on offer. On the way back to the office they receive an alert
informing them that a volunteer from the local soup kitchen will be
over to collect the food. They update their post to note that the offer
has been taken. Details of the transaction are removed from view on
the expiry date and time stipulated by the user but remain in the
WeGovNow archive.
Other
3.3.4 Related Use cases
Use case 1: Uploading Geospatial Datasets
a) User role(s) concerned M01 - Public Green and Municipal Buildings Department
M04 - The municipality’s ICT department
b) Description of task to be performed / problem to be addressed by the user Staff regularly upload existing spatial datasets to the WeGovNow platform that
may of relevant to specific co-design exercises (e.g. park furniture, playgrounds,
drinking water fountains etc.) or for other informative purposes Prior to
submission for upload, all data is formatted according to a pre-specified format
(e.g. lat, long coordinates, geometry, attribute description etc.
D2.2 WeGovNow Use Cases v.1
46
c) Preconditions
1) Staff has datasets appropriately formatted for importation into WeGovNow.
2) Staff have relevant authorisation to import data into WeGovNow
d) Postconditions
1) Spatial data is published on the WeGovNow platform and can be accessed by the appropriate end users via a map interface.
e) Functional requirements
1) The system shall allow authorised staff at the municipality to upload new spatial data to the WeGovNow platform including points, lines, and polygons.
2) The system shall allow authorised staff at the municipality to upload new spatial data that contributes to existing data already stored in the WeGovNow platform.
3) The system shall allow authorised staff to assign different access rights to spatial datasets uploaded to WeGovNow
4) The system shall allow authorised staff to assign thematic categories to spatial datasets uploaded to WeGovNow
5) The system shall alert users if data being imported is incorrectly formatted.
f) Non-functional requirements
1) The system should be efficient to use; i.e. user goals should be easy to accomplish quickly and with few or no user errors
Use case 2: Exporting Geospatial Datasets
a) User role(s) concerned M01 - Public Green and Municipal Buildings Department
M04 - The municipality’s ICT department
b) Description of task to be performed / problem to be addressed by the user Staff regularly needs to export spatial datasets from the WeGovNow platform
for analysis, reporting and other needs. Spatial data should be exportable in a
set of predefined formats for use with other software packages.
c) Preconditions
1) Staff has access to datasets in the WeGovNow platform.
2) Staff have relevant authorisation to export data from the WeGovNow platform
d) Postconditions
1) Staff have spatial datasets exported in a format that enables integration with other data sources that are used by the municipality
D2.2 WeGovNow Use Cases v.1
47
2) Staff have spatial datasets export in a format that enables use with other software applications used by the municipality
e) Functional requirements
1) The system shall allow authorised staff at the municipality to select subsets of spatial data held within the WeGovNow platform (e.g. data from a specific time range or geographical area) for exportation.
2) The system shall allow authorised staff at the municipality to export spatial data from the WeGovNow platform in a format that can be used by other software programs used by the municipality.
3) The system shall alert users if data being imported is incorrectly formatted.
f) Non-functional requirements
1) The system shall enable data exportation to be achieved in a few simple steps.
Use case 3: Adding Pre-defined map categories
a) User role(s) concerned M01 - Public Green and Municipal Buildings Department
b) Description of task to be performed / problem to be addressed by the user Staff setting up a new co-design exercise requires specific input from the public
on pre-defined topics. Map categories are added and appropriately named
along with fields for requested input, such as a category that is labelled “where
would you like to see park benches added?” or “where and what sport facilities
would you like to see?” The field types should be labelled and classified e.g. a
field called ‘Description’ as a text box. An appropriate icon should be selected
and displayed to represent the theme being added.
c) Preconditions
1) Staff have relevant authorisation to set-up new map categories on WeGovNow
2) Decisions have been made as to the format and information needed
d) Postconditions
1) New map categories are added to the WeGovNow platform
2) Map categories can be accessed by the appropriate end users via a map interface and contributions can be made to the fields provided.
e) Functional requirements
1) The system shall allow authorised staff at the municipality to create new map categories held within the WeGovNow platform (e.g. data from a specific time range or geographical area).
2) The system shall allow authorised staff at the municipality to assign icons
D2.2 WeGovNow Use Cases v.1
48
for specific map categories being created.
3) The system shall allow authorised staff at the municipality to add fields for data capture within a new map category
4) The system shall allow authorised staff at the municipality to select from a range of field types (such as text box, date, time, lookup etc.)
f) Non- functional requirements
1) The system should be efficient to use; i.e. user goals should be easy to accomplish quickly and with few or no user errors
Use case 4: Sharing a map entry with Facebook
a) User role(s) concerned C01 - C02 Citizens
N01 - N06 NGOs
b) Description of task to be performed / problem to be addressed by the user End users of the WeGovNow platform use Facebook to communicate with
friends, other organisations and on topics of interest. When an end user sees an
idea, suggestion or post on map entries within the WeGovNow platform they
want to share these via their existing social network on Facebook.
c) Preconditions End user has an existing Facebook account
d) Postconditions The suggestion or idea is available for viewing on a user’s Facebook timeline
e) Functional requirements
1) The system shall provide a function to enable end users to select a map contribution and share this via their personal Facebook account
2) The system shall provide a function to enable local authority staff to select whether a map theme/category has the Facebook sharing function activated.
f) Non- functional requirements
1) The system should make it easy to identify what can be shared via Facebook and should allow for it to be accomplished quickly and with few or no user errors
Use case 5: Linking a Map to a Twitter Account
a) User role(s) concerned M01 - Public Green and Municipal Buildings Department
M04 - The municipality’s ICT department
D2.2 WeGovNow Use Cases v.1
49
M02 - Youth Department
M03 - Innovation and Smart City Department
b) Description of task to be performed / problem to be addressed by the user Staff setting up a new co-design exercises want to maximize participation and
encourage discussion. Where a new map is created to elicit idea generation
staff want to connect new or existing municipal Twitter accounts to share the
ideas captured on the WeGovNow platform to the selected Twitter account.
This would enable any new suggestions and posts made to the WeGovNow
platform to be shared via Twitter and the followers of these accounts.
c) Preconditions 1) Municipality has identified Twitter account for integration
d) Postconditions 1) The suggestion or idea is available for viewing on a selected Twitter account
e) Functional requirements
1) The system shall provide a function to enable municipality staff to assign a specific Twitter account to a co-design exercise within the WeGovNow platform.
2) The system shall provide a function to enable new contributions to be converted into a format that can be used in Twitter
3) The system shall provide a function to send new contributions in real-time to a predefined Twitter account
f) Non- functional requirements
1) The system should make it easy to identify Tweets that have been posted from the WeGovNow platform.
2) New contributes should be posted on Twitter in a timely manner
3) The system should be efficient to use; i.e. user goals should be easy to accomplish quickly and with few or no user errors
3.4 Further service scenarios currently analysed
Beyond the service scenarios and related use cases presented above, further service scenarios has yet been identified, and these currently analysed according to the methodology described earlier in this document. These briefly surmised in the remainder of this section.
D2.2 WeGovNow Use Cases v.1
50
3.4.1 WeGovNow service scenario #4 (San Donà di Piave)
Revitalising abandoned public spaces – the barrack: The Municipality of San Donà di Piave is trying to revitalise an abandoned barrack less than 10 km far form the city centre. In the general idea this big space should host different requests coming from associations, profit and non profit organisations working in several domains. WeGovNow is envisaged to support collaborative strategy building on the further development of this public space and , later on, its management.
WeGovNow service scenario #5 (San Donà di Piave)
Regeneration of the City Centre: The local authority has already started to initiate a new governance structure for their city centre via the establishment of local groups involving key stakeholders and role players from the civil society and businesses. WeGovNow is envisaged to support city-wide inter-agency collaborative structures.
WeGovNow service scenario #6 (San Donà di Piave)
Schools empowerment: The Municipality of San Donà di Piave is member of a local network entitled “Orientation and territory”, a local network of 15 high school together representing more than 6.000 students. The aim of this network is to facilitate the transition of pupils into the labour job market. WeGovNow is envisaged to support collaborative self-governance of the network.
WeGovNow service scenario #7 (Southwark)
City Biking: Southwark Council seeks to extend current bike routes to the quieter areas by
keeping the local community involved in the planning process. Ideally the council would like
to engage residents and encourage them to raise awareness of any issues that might arise in
the future with the routes and increase citizen participation in the planning process.
WeGovNow is envisaged to support collaborative planning on the development of cycle
routes based on resident’s votes. The council would also like to engage community with a
tool for reporting any upcoming issues with the new routes.
WeGovNow service scenario #8 (Southwark)
Estate Regeneration: Southwark Council are committed to deliver new homes, including
refurbishing and infill, with some demolition. The estate has many existing residents, social
housing and leaseholders. The council want to engage with residents to develop options to
consult on. WeGovNow is envisaged to support collaborative planning and familiarising the
community with the changes that will be applied during the redevelopment process. Each
estate resident would get a chance to express their opinion, and add suggestions and
feedback that would feed in ideas for further stages of consultation and also in the design
process.
D2.2 WeGovNow Use Cases v.1
51
WeGovNow service scenario #9 (Southwark)
Designing Green Spaces: Southwark Council intend to develop part of Burgess Park and the
project would be delivered across different stages. The scenario focuses on one element of
the development, which is the addition of a pond in this area, and the council require a tool
to enable them to consult with the public about the re-design. WeGovNow is envisaged to
support collaborative planning.
WeGovNow service scenario #10 (Southwark)
Moving into Southwark: The council are seeking to increase the number of people engaging.
Southwark would like to inform the new residents about all their services and engage them
from the earliest stage of their residency, as well as find out about who they are and how
they might be encouraged to get involved in local action and groups such as the Community
Council. WeGovNow is envisaged to support the integration of new residents
WeGovNow service scenario #11(Southwark)
Borough Regeneration: The ongoing developments in the borough mean that in addition to
providing static information the council want to provide information on other elements,
such as areas prone to flood risk; recent flood damage; routes for travel as well as wanting
to keep people informed about upcoming disruptions along with other associated activities.
WeGovNow is envisaged to support notifications of upcoming disruptions, with the
potential for interaction coming back in terms of related incidents.
WeGovNow service scenario #12 (Southwark)
Cleaner Greener Safer: The council has a budget that it allocates on an annual basis to
community projects proposed by members of the local community. WeGovNow is
envisaged to support the process of ideas generation and sharing, voting and selection of
projects.
WeGovNow service scenario #13 (Southwark)
Ageing Well: The council plans to ask residents of all ages how it can become an "age-
friendly" place, as defined by the World Health Organisation. The feedback they receive will
be used to draft an action-plan and explore ways in which collaborative approaches and
support mechanisms can be developed.
D2.2 WeGovNow Use Cases v.1
52
WeGovNow service scenario #14 (Southwark)
Resident-led Services: Many residents feel council services could be improved. In
recognition of this the council is asking them how they would do it. A group of residents in
Camberwell & Peckham will be supported by the council to redesign the housing repairs
service from scratch. If successful, the pilot will be rolled out in other areas.
WeGovNow service scenario #15 (Turin)
Furniture co-design: The Dora Shopping Mall would like to design some furniture (especially benches: smart benches and/or sustainable benches, using recycled materials) to furnish the internal square of the shopping mall. WeGovNow is envisaged to support the design process and citizen involvement.
WeGovNow service scenario #16 (Turin)
Social Gardening in Dora Park: Innesto, in partnership with the City of Turin and the Dora Shopping Mall are seeking promote and raise awareness about the community gardens and building a sense of community; they also need support in the maintenance, so that the space is comfortable and can host events and activities. WeGovNow is envisaged to support the creation of a calendar of activities for Hortus Conclusus, provide opportunities to create new activities and co-ordinate volunteer support as well as support collaboration
WeGovNow service scenario #17 (Turin)
The City of Turin (Urban Regeneration Department) needs to collect data and information about a project centred on the regulation of common goods and co-management. Project monitoring and evaluation is required and the WeGovNow platform is envisaged to support the documentation of activities from photos to workshop reports.
4 Outlook
The revision of the originally envisaged methodological approach towards use case development and requirements elicitation (relying on the SCRUM methodology) has led to delayed submission of the current deliverable. It is however not envisaged that this will have negative knock-on effects on the schedule for finalisation of the WeGovNow use cases, to be documented in Deliverable 2.2 due in M18.
The work on service scenario development and related use case development is organised in terms of an iterative process enabling a stepwise evolution and prioritisation until the start of the piloting stage, i.e. until the new WeGovNow services are to be provided by the pilot municipalities under day-to-day conditions for piloting purposes. To this end, the service scenarios and use cases presented in this report will be further analysed and refined in an iterative manner, and new ones created, thereby involving all stakeholders / user groups concerned by means of subsequent workshops, interviews and prototype demonstrations/test by project month 18 as originally planned. In the weeks and months
D2.2 WeGovNow Use Cases v.1
53
after submission of this deliverable, use cases and RTD across WeGovNow will be integrated in an iterative process of agile development. This process will include:
Assessment of listed use cases in accordance with agreed criteria to enable the
prioritisation of use cases in close coordination with WP3;
Conversion of prioritised use cases to an extracted set of functional and non-functional
requirements;
Assigned task leaders with responsibility for specific WeGovNow platform components
coordinate development tasks and collaborate with pilot site managers.
D2.2 WeGovNow Use Cases v.1
54
ANNEXES
5 Annex I: Outcomes of method review
This section presents an overview of various theoretical approaches to user requirements
gathering, both in the context of traditional approaches and in the context of AGILE
development. It then describes how these methods have been combined and adapted to
the WeGovNow context, where two key factors mean that the standard approaches cannot
be applied ‘out of the box’, namely:
The wide geographical distribution of the end users of the system – where three
municipalities in two different countries are involved, and where final end users (e.g. the
general public) are not available for regular meetings, and may not speak the common
language of the project team (English).
The use of pre-existing software, which is to be adapted for WeGovNow, means that the
user requirements gathered must be adapted to the context of what can be achieved with
the tools provided, rather than taken in the context of a ‘clean sheet’ approach where tools
are to be developed from scratch. Within this context is absolutely essential to further
consider contextual factors that influence how users interact with proposed technologies
and how these contextual characteristics influence user needs and subsequent tasks for
user requirements.
5.1 Requirements
Requirements are “a statement about an intended product that specifies what it should do
or how it should perform” (Sharp et al 2009). They should be as specific and clear as possible
and should also be testable (to ensure that they have been implemented correctly) (ibid).
When designing ICT systems, there are two main types of requirements to be considered –
functional and non-functional. The former can be defined as “what the system should do”
and the latter describe how the system should behave and include system constraints (ibid).
Cohn (2004) lists non-functional requirement types that include performance, accuracy,
portability, reusability, maintainability, interoperability, availability, usability, and security,
while Sharp et al (2009) also add data requirements, the use context (e.g. where the
software will be used such as a noisy or dusty environment, indoors or outdoors) and user
characteristics to this list. It should be also clarified that user requirements are different
from system requirements with the users mainly shaping the former and the developers
shaping the latter.
5.2 Approaches to Development
A fundamental component of any requirements elicitation process is developing an
understanding of the users of the software system, and their capabilities, tasks and goals
D2.2 WeGovNow Use Cases v.1
55
(Sharp et al 2009). A number of different models or approaches to software development
have been developed over the years, which can be broadly characterised by the level to
which users are involved in the full software development cycle (requirements gathering,
requirements documentation, software development, testing, deployment). Involving users
in this process takes time; levels of involvement may vary from a situation where users form
a very active part of the design team throughout the process to one where the users are
only kept up to date via newsletters (ibid) (with this latter method being useful when
thousands of users are involved). It is acknowledged that poorly defined requirements often
lead to project failure (Brown and Rogich 2001).
5.2.1 Waterfall Method – Limited User Involvement
This approach to development establishes all the project requirements at the beginning,
analyzes them, designs a solution, codes the solution and carries out tests. Users are
involved at the beginning and end of the process (i.e. during requirements gathering and
testing) Turner et al (2013). It is a linear model, with each step of development being
completed before the next one starts (Sharp et al 2009) and has the advantage that it
provides the big picture of the system up front. Disadvantages include the fact that for
medium or large projects a long list of requirements is generated, which may not be read or
understood in detail by the developers (Cohn 2004). Additionally, is acknowledges that
requirements change over time (Sharp et al 2009).
5.2.2 Spirals and Rapid Application Development – Increasing User Involvement
These methods (first proposed in the late 1970s and 1980s and not much used in practice
today) were designed to overcome some of the limitations of the Waterfall method, and
reflect an evolving understanding in the software development community of the benefits
of increasing involvement of users in the development process. The Spiral builds on the
Waterfall method by adding risk analysis and prototyping, which in turn leads to more
frequent checks on progress and engagement with stakeholders (Sharpe et al 2009). Unlike
the previous approaches, Rapid Application Development takes a user centred view to
requirements gathering, and time-boxes development into cycles of six months each, with
the goal of developing a working system at the end of the cycle (Sharp et al 2009). Users and
developers work on requirements in intensive requirements gathering phases at the start of
each cycle.
5.2.3 Agile – Ongoing User Involvement
“AGILE project management is a style of project management that focuses on early delivery
of business value, continuous improvement of the projects product and processes, scope
flexibility, team input, and delivering well-tested products that reflect customer needs”
(Mark, 2012). One of the basic principles of AGILE is that “motivated and empowered
software developers relying on technical excellence and simple designs create business
value by delivering working software to users at regular short intervals” (Dingsøyr et al.,
D2.2 WeGovNow Use Cases v.1
56
2012). It involves members of the programming team carrying out extensive testing as part
of every development cycle and ongoing, regular feedback from end users. The Agile
Manifesto states (Sharp et al 2009):
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value: Individuals and interactions over processes and
tools; Working software over comprehensive documentation; Customer collaboration over
contract negotiation; Responding to change over following a plan”
Within Agile, there is no up-front design phase, as there is in the Waterfall approach – but
Agile is characterised by frequent short design phases (Cohn 2004). Multiple methods exist
within the framework. DSDM – dynamic systems development method- is based on Rapid
Application Development and involves users as a core requirement. It consists of 5 phases
which iterate between and within themselves, namely a feasibility study, business study,
functional model iteration, design and build interaction, implementation (Sharp et al 2009).
A second, method, which is perhaps the most well known, is eXtreme Programming (XP).
Here, the focus is on the importance of handling emergent requirements and striking a good
balance between flexibility and structure (ibid), with very short development cycles (of
around 15 days, Cohn nd). Similarly to XP, SCRUM projects progress through a series of 30-
day iterations called sprints, at the outset of which each team decides what is to be
achieved. A short daily review meeting is held which focuses on what the team achieved the
previous day, the plan for the current day and any issues that could impede progress (Cohn
2004), with the team consisting of 4 to 7 developers who may take multiple roles – e.g.
testing – as well as their core specialisation (ibid). Unlike XP, SCRUM processes do not allow
any changes in the sprint (Cohn, nd).
5.2.4 User-Centred Design
User-Centred Design (UCD) is a philosophy that includes a set of practices and methods
which place the user at centre of any design process; i.e. for both digital or non-digital
products (Norman, 1988). As it is the case with some of the previously mentioned
approaches to development, UCD includes various methods which enable user involvement
at various stages of the product development (e.g. Exhibit 2 below) from very early which
usually aim at understanding user needs and defining requirements to the very late stages
where usability and User Experience (UXP) evaluations take place. User involvement also
varies from simple user observation or user interviews which inform the design process to
co-design approaches where users are deeply involved, occasionally as partners, in the
design process.
D2.2 WeGovNow Use Cases v.1
57
Exhibit 2: User-centred design activities (Muller et al. 1993)
5.3 Users
A number of alternative definitions can be found for the “users” of a software product,
including (Sharp et al 2009):
“The people who interact directly with the product to achieve a task”
The people who manage the direct users;
Those who receive products from the system;
Those who test the system;
Those who make a purchasing decision.
A second, perhaps more useful, grouping looks at users in terms of the frequency with
which they will use the new system, with primary users using the system daily, secondary
users being occasional users and tertiary users being those who don’t use the system but
are somehow involved in, or affected by, its implementation (e.g. managers) (Sharp et al
2009). These three groups, when taken together, form the stakeholders” of the project, who
are the “people or organizations who will be affected by a system and who have a direct or
indirect influence on the system requirements” (ibid).
D2.2 WeGovNow Use Cases v.1
58
5.4 Gathering and Documenting Requirements
“The elicitation of requirements from users is a critical activity in systems development”
(Brown and Rogich 2001). Indeed, “A principal reason that systems do not meet user
expectations is the failure of the development process to yield a complete and accurate set
of requirements” (ibid).
The aim of any requirements elicitation process is to determine what features the software
should have, with this activity being carried out recurrently through the requirements stage
(the initial stage of software development if the Waterfall approach is taken, throughout the
project for Agile approaches) (Carizzo et al 2014). Each gathering activity includes
preparation, execution and analysis (ibid). In other words, a three-stage process can be
identified.
Interaction between users and developers can range from one-to-one meetings and
interviews to online questionnaires, with a number of different approaches to requirements
gathering are available to software engineers, with each being applicable to one or more
situations involving information exchange between end users and developers. Additionally,
in any requirements gathering process, it is important to not only involve the users but also
to document the requirements in a format that allows them to be communicated
throughout the team in a consistent manner (Sharp et al 2009). Two alternatives can be
identified, with some requirements gathering processes producing documentation as part of
the process and others requiring a post-meeting (offline) documentation task, with the
results of that being fed back to the users for verification. Additionally, although there is not
a one:one correspondence between requirements gathering methods and the approaches
to software development described above, certain methods lend themselves better to one
or other of the approaches, reflecting the expected level of user involvement through the
project.
5.4.1 Facilitating Interaction between Users and Developers
When considering any requirements gathering task, a key aim should be to engage with as
wide a spectrum of potential system users as possible. This means that multiple types of
user/developer interaction should be considered, the choice of which will depend on the
availability of the users and developers (are they in the same city, do they have time to
meet, do they speak the same language) but also on the stage of the development cycle and
how frequently the users and developers meet, as well as the overall approach to
development (e.g. Waterfall , Agile or UCD).
Potential interactions include (Sharp et al 2009):
Interviews – semi-structured or unstructured interviews are used early on to elicit
scenarios;
Focus groups / workshops – good at gaining a consensus view and also highlighting areas
of disagreement, as well as helping stakeholders meet designers;
D2.2 WeGovNow Use Cases v.1
59
Questionnaires – for getting initial responses to identify people to interview, or to get a
wider perspective on specific issues;
Direct Observation – helps with nature of the tasks and in particular the context;
Indirect observation – diaries and interaction logging – can provide information as to
how a task is done currently;
Studying documentation – good sources of data about steps involved in an activity;
Researching similar projects.
The methods can be combined if necessary.
Carizzo et al (2014) present a detailed review of the suitability of various elicitation
techniques for requirements gathering, focussing not only on the target – i.e. the users
(called informants) – but also on the skills of the elicitor, and the suitability of the approach
to the specific problem domain. They present a table of suitability, noting that focus groups
and joint application design workshops are particularly suitable at the start of a project and
result in a relatively low level of problem definition, whereas protocol analysis (where users
relate out loud what they are thinking when performing a specific task) and scenario or use
case development results in a high level of problem definition, although it is less suited for
the start of a project. All of these techniques are best carried out by people with elicitation
experience, scenario/use cases are suitable when the elicitors are not familiar with the
problem domain, whereas focus groups/JAD workshops require high familiarity. Scenarios
and protocol analysis – best suited for working with individuals and in all cases the
informant's interest and expertise in the project domain should be high (ibid).
5.4.2 Requirements Lists
Requirements lists, which provide a detailed description of a full set of requirements for
software development, are traditionally associated with the Waterfall approach to
development (although as will be seen they are also very important for interaction design).
They involve three stages: information gathering, when requirements are elicited from
users, representation – modelling/documenting the requirements, and verification –
confirming the requirements with users (Brown and Rogich 2001).
Brown and Rogich (2001) list the following potential approaches to requirements elicitation
for use during the requirements gathering phase of a project:
Scenario building;
Conditionalising – what does the project mean for the customer;
Elaborating with instances – illustrate a requirement by providing examples;
Hedging – what is the fallback position if your solution does not work;
Generating counter arguments – why might the system not work as well as you expect,
Generating arguments – can you think of analogies that will clarify what you are saying,
Feedback – on a copy of what the user has said,
Summarization – ask the user to summarize what they have said.
D2.2 WeGovNow Use Cases v.1
60
They also note that various approaches can be used to prompt users to provide information
– task prompts ask what the customers do would, why would they do this, what can be
done to overcome this issue, syntactic prompts focus on who uses the system, who is
affected by the system, who affects the system, and the what, where, when, why and how
for each of these groups, and semantic prompts focus on the goals of the system, and how
are they attained,
Depending on the specific interaction approach between users and developers, the data
resulting from the first phase can transcribed (if recorded), and then analyzed using both
quantitative methods (e.g. for closed questions or questionnaires) or qualitative approaches
(open interviews, observations) (Sharp et al 2009). Qualitative analysis firstly involves
gaining an overall impression of the data and examining it at high level for patterns and
trends, followed by a process of categorization, which can take place at multiple levels and,
importantly, should be replicable (ibid). Where the qualitative data is extensive (e.g. a full
recording of a workshop) critical incidents can be identified – i.e. facts that make a
significant contribution to the activity (ibid). It is also possible to make use of a taxonomy of
generic requirements – which is a set of categories of requirements that help code the
results of interviews, questionnaires, focus groups and so forth – these relate to
requirement groups including goal level, gap speciation , process level requirements,
difficulties and constraints, task level requirements, performance criteria and roles and
responsibilities among others (Brown and Rogich 2001). Ideally this coding would be carried
out by persons not familiar with the system (ibid).
Requirements documents are created by the development team, and then verified by the
users. This requires the developers to have a relatively good working knowledge of the end
users’ needs and working domain, which can be gained by spending a relatively extensive
amount of time interviewing, and observing, the end users. Brown and Rogich (2001) also
note that one problem with this approach is how to systematically encode requirements,
with a second being when to halt the requirements elicitation process – i.e. when have ‘all’
the requirements been gathered.
5.4.3 Use Cases
These are traditionally associated with the Waterfall, Spiral and Rapid Application
Development approaches to software development. A use case is a generalized description
of a set of interactions between the system and one or more actors, where an actor is either
a user or another system (Cohn 2004). This can be written as free text or structured in the
following headings (ibid):
Title;
Primary Actor;
Level;
Pre-Condition;
Success Guarantee;
D2.2 WeGovNow Use Cases v.1
61
Main Success Criteria – the steps that need to work for the use case to be implemented
successfully;
Extensions – additional steps that could be included.
They focus on user/system interaction rather than the user’s task – the user is an actor and
the focus is very much on the user, and captures the actor’s goal in using the system (a
scenario in this context represents one path through the use case – i.e. a same as above as
they represent one particular set of conditions) (ibid).
One disadvantage of the Use Case approach is that it contains assumptions about the
existence of technology to interact with and about the user interface and type of interaction
(Sharp et al 2009). Essential use cases have been developed to overcome this – these are
abstractions from scenarios (described below) and consist of a name, a list of user actions
and a list of system responsibility that interlinks with the user actions list (ibid). They are
associated with user roles rather than actors (ibid). A second disadvantage of Use Cases is
that they are documented by the developers on the team – as with the Requirements Lists
approaches, this requires the members of the development team to have a relatively good
knowledge of the working domain of the users.
5.4.4 Scenarios
A scenario is an informal narrative description that describes human activities or tasks in a
story that allows exploration and discussion of contexts, need and requirements (Sharp et al
2009). It can be created by stakeholders and is aimed to ensure that they understand the
requirements (rather than the more technical focus of the approaches described above),
with a focus on what the users are trying to achieve (ibid). Scenarios can be generated
during a workshop, interview or brainstorming sessions, and can also be used to imagine
potential users of a product (ibid).
Unlike Use Cases or Requirements List, scenarios are not intended to capture a full set of
requirements – instead they offer the perspective of one system user. While they do not
require developers to have such an in-depth understanding of the users’ domain, they do
obscure broader, organisational level, issues (Sharp et al 2009).
Given its focus on users’ understanding of requirements, the scenario approach is
associated primarily with Agile development. However, it is also important within the
context of interaction design, where scenarios have a slightly different focus – These are not
the same thing, with the interaction scenario typically being even larger than a use case, and
may have multiple actors (Cohn 2004).
5.4.5 User Stories
A user story is a written description of the concepts used for planning and has three
components (Jeffries 2001 cited in Cohn 2004) and are closely associated with the Agile XP
approach to development (although they can be adapted for SCRUM methodology if
required). They are based on the principle that “The best estimates really come from
D2.2 WeGovNow Use Cases v.1
62
developers who understand what they’re estimating” (Patton 2014). User stories are written
by users, and all the potential users of a system should be identified. Techniques can include
(Turner et al 2013):
User interviews;
Questionnaires;
Observing user interaction with existing software;
Story-writing workshops.
The story should identify what the user is really trying to do, and missing stories can be
identified by asking ‘what is the user likely to do next’, ‘what mistakes could the user make
here, what could confuse the user at this point, or ‘what additional information could the
user need’ (ibid).
The card (where all the details are written);
The conversation (the details that form the user story);
The confirmation (the tests that will be used to document the details of the project and
for validation).
The user stories should include a high level description – e.g. ‘A user can search for jobs’ but
also detail such as how they can search – by date, location, job title, skills required, salary
and so forth (Cohn 2004). Ideally, they should be able to be developed in 1-2 weeks by one
or two programmers (ibid) and should enable good short term planning (Turner et al 2013).
They should not focus on user interface details at all and should be testable, with the tests
being written by the end users and serving the purpose to provide more detail and context
to the user story (Cohn 2004). Cohn (2004) notes the following advantages of the user story
approach:
They focus on verbal communication
They are comprehensible
They are the right size for planning
They work well for iterative development
They encourage deferring detail
They support opportunistic development
They encourage participatory design
However, non functional requirements are not usually documented as part of users stories
(Cohn 2004) and as with scenarios they have the disadvantage that the big picture and
overall goal of the software development process can be lost. On a large project with many
stories it can be difficult to understand the relationships between the stories, they don’t
facilitate requirements traceability and they don’t scale up to extremely large teams or
distributed teams (ibid). As user stories are written by the users, there is also an additional,
perhaps complex, process required to turn the user stories into something that the technical
team can work from (Turner et al 2013).
D2.2 WeGovNow Use Cases v.1
63
5.4.6 Personas in UCD
One of the top aims of ‘WeGovNow’ is to better understand the technological as well as
non-technological drawbacks, subsequently overcome traditional e-government obstacles in
order to create and put in practice tools that enable civic engagement in an effective and
truly inclusive manner to achieve a paradigm shift from e-Government to We-Government.
To do so we place the user at the centre of the design and development processes by using
UCD methods and tools. In specific, we use UCD methods that further allow us to take into
account a wide spectrum of users in terms of diversity (e.g. gender, age, disability),
perspectives (e.g. citizens, council users etc) as well as different cultural contexts (i.e. we
work with stakeholders in both UK and Italy). To address design issues for such a wide
spectrum of users but more importantly to communicate them with a design and
development teams is often a complicated task which based in our experience we can easily
overcome using the method of personas.
Persona is a popular UCD method that it is used in the requirements elicitation stage as well
as other stages of the design and development lifecycle. Personas are detailed descriptions
of possible end users which communicate the main information and which can help
designers, developers and people who work in the same time to impersonate potential
users and empathise. Usually they include information about user’s skills, attitudes, tasks
and environment. Each persona comprises of a name, a photograph and personal details.
Some of the elements that make up a persona are imaginary. Personas are not just simple
descriptions e.g. “somebody is a competent sailor”. In fact, they include further information
e.g. the “sailor has a Day Skipper qualification and he has completed 100 hours of sailing”.
Examples of our WeGovNow Personas which were generated after a preliminary user
requirements elicitation are provided in Section 7.
5.4.7 Comparing User Stories with Other Approaches
As noted above, each approach to requirements gathering lends itself better to specific
development approaches (Waterfall, Agile) and also to different requirements gathering
contexts. A short comparison is provided here:
User Stories versus Requirements Lists
The User Story approach is designed to build a shared understanding, perhaps using words
and pictures, and has a focus on solving problems as well as developing agreements on what
to build (Patton 2014). The real goal is “shared understanding” (ibid). They are designed to
be developed by users, and discarded at each phase of the development (e.g. after each
sprint). This contrasts markedly with Requirements Lists, which are fixed at the outset of a
project with a formal change request/variation process in place for any subsequent changes.
User Stories have advantages including ongoing involvement of the users, focus on small
chunks of development with immediate feedback from the users, providing a good
approach to estimation inbuilt tests to validate the development tasks and the fact that the
user writes the stories, they are created in the language of the business. However, they
D2.2 WeGovNow Use Cases v.1
64
require intensive User Involvement required at all stages of development – which means
that users are taken away from their daily tasks and in extreme cases may lose touch with
the day to day realities of their colleagues. It is also difficult to see the ‘big picture’ and
hence perhaps develop common code modules that can be re-used. The customer writes
the stories in the language of the business, so the developers need to be familiar with the
business language to translate this into technical specifications
User Stories versus Use Cases versus Scenarios
Cohn (2004) notes that to a certain extent, Use Cases and User Stories are similar. Both User
Stories and Use Cases are described in terms useful to the organisation, although user
stories tend to be smaller in scope than Use Cases. He also notes that in fact the following
applies:
Use Case = User Story + Acceptance Tests
In other words, the User Story text corresponds to the main success criteria of a Use Case,
with the tests corresponding to the extensions (ibid).
Differences include (Cohn 2004):
Use Cases are permanent artefacts, where as User Stories only exist for the interaction
in which they are developed;
Use Cases also include details of the user interface, where as user stories do not;
Use Cases are there to document an agreement between the customers and the
development team, whereas User Stories are written to facilitate release and iteration
planning;
Use Cases are written as a result of analysis activity, User Stories are notes that can be
used to initiate analysis conversations (with the details of these conversations being
recorded as tests).
Additionally, Use Cases tend to be documented by the development team, which means
that there is no issue translating them into more technical development tasks, but there is a
requirement that the development team develop a more in depth understanding of the user
domain early in the project (with the User Story approach this is developed as the project
progresses).
Cohn (2004) notes that a Scenario is single path through a Use Case OR a detailed
description of user interaction with a computer. As with Use Cases and User Stories, the
primary difference between User Stories and Scenarios relates to scope and detail (ibid):
Scenarios contain a lot of detail (setting, actors, goals and objectives, actions and events)
and their scope usually covers multiple Stories.
Cohn (2004) suggests that a User Story is part of a single Scenario, many of which can be
used to make up a Use Case. Thus:
1 Use Case = Many Scenarios and 1 Scenario = Many User Stories
D2.2 WeGovNow Use Cases v.1
65
Leading to the suggestion that:
1 Use Case = Many User Stories
Story Mapping
A typical requirements-list based process concentrates on getting all the requirements right
at the beginning of the project (Cohn 2004). Even though the User Stories approach
acknowledges that this cannot be done, there is benefit in getting a broad range of stories
up front if possible – even if these are at high level and are refined later on. This allows the
team to get an overall feel for the size of an application prior to starting any development
(ibid). Story mapping, proposed by Patton (2014) is designed to overcome the issue that
User Stories lose the big picture. Patton suggest that the user and developer team starts
with stories that tell the big picture and break them down into smaller ones. The story cards
are laid out with the big picture stories forming a backbone of the layout and the details
below. Once the amp is complete, then a minimum viable product release can be created
(ibid). As with the development of an up-front requirements list, this story mapping process
can take quite a bit of time – perhaps a number of days.
5.4.8 Requirements Gathering and Interface/Interaction Design and Usability
There is a conflict between the long user studies required in a user centred design approach,
before any work is done, and the shorter time-scales of Agile development (Sharp et al
2009). Additionally, “Agile methods largely ignore the user interface” so there are risks
when pursuing a user-story based approach with a system that has a significant or
important user interface (Cohn 2004).
As an example, the User Story approach to requirements implicitly acknowledges that
there is a chance that some small amounts of re-work may be required as requirements
emerge – this is justified by the savings in not holding extensive requirements meetings
up front (Cohn 2004) . However, if the user interface is important, it should be thought
about from the beginning of the project – i.e. “Change the user interface as little as
possible once it is started” (ibid). Constantine and Lockwood (2002 in Cohn 2004)
propose the following process:
Perform user role modelling;
Trawl for high level user stories;
Prioritize stories;
Refine high and medium priority stories;
Organise stories into groups;
Create a paper prototype;
Refine the prototype;
Start programming.
D2.2 WeGovNow Use Cases v.1
66
(steps 1 - 5 above are overlapped with the user stories process). Similarly, Sharp et al (2009)
recommend the early identification of features that do not require much interaction input,
as a starting point for developers, while the user interface is designed in parallel. The user
interface can then be tested in a second phase of development, along with the developed
features, while the developers work on additional features. It could also be appropriate to
develop two separate user interfaces in order to keep a clear distinction between the user
interface and any other functionality (Cohn 2004).
5.5 Requirements Gathering and Software Design in WeGovNow
Many of the approaches described above have been developed in the context of a ‘green
field’ project – i.e. where, if software to perform a certain task does exist, it is to be
replaced, or (in particular in the case of the Waterfall approach) no software exists to
perform the tasks in question. However, this is not the case for WeGovNow, where the aim
is to test out a number of existing tools at various technology readiness levels, both in terms
of their utility to end users and in terms of how they can best be deployed within a
municipal setting.
As noted above, in an ideal situation real end users would form part of any development
team. As Cohn (2004) notes: “It is vital that a project include one or more real users on the
customer team. While others may be able to guess at how a user wants the software to
behave, only a real user knows”.
However, within projects such as WeGovNow, where the range of user roles is extensive
(and includes a large group of municipality staff with different roles, various staff members
of Non-Governmental Organisations, and members of the general public with widely varying
skills and backgrounds) this level of engagement is not possible. The fact that the
WeGovNow development teams are distributed in multiple countries, and the linguistic
barriers, further complicates this situation.
5.5.1 User Proxies
As can be imagined, however, the problems described above are not unique to WeGovNow,
and the concept of User Proxies has been developed within the software development
community to attempt to address this situation. These are not ideal at all but could include
(Cohn 2004):
The user’s manager;
A development manager;
Salespersons;
Domain experts;
Marketing group;
Customers;
D2.2 WeGovNow Use Cases v.1
67
Former users;
Trainers and technical support;
Business or systems analysts.
While user proxies can provide useful information they will not have the same perspective
as someone who performs a task every day (Sharp et al 2009). Ideally even if a user proxy is
used the team should work with real users as much as possible (Cohn 2004), but again in
WeGovNow this may not be possible as even the proxies have their own work to complete.
5.5.2 Best Practice Approach to Requirements Gathering
As well as making use of user proxies, the approach to requirements gathering within the
WeGovNow project (in common with many development projects) has been carefully
designed to maximise the benefit gained from the time where direct engagement with end
users is possible, while compensating for the distributed user groups and development
teams. Thus, best practices from both the Agile and Waterfall as well as UCD approaches
have been combined, reflecting the fact that while we will have more regular user
engagement than is traditionally the case with the Waterfall approach, this will not be at the
level required for true Agile development.
Also several studies have already demonstrated that both UCD and Agile approaches have
their strengths and weaknesses and a combined approach is particularly beneficial
especially with respect to the user requirements elicitation. These usually highlight that the
benefits of combining them are: a) UCD is helpful in terms of uncovering and understanding
the user needs and goals which inform the requirement elicitation process to result in
defining a set of clear and very precise user requirements as opposed to refining a set of
user/system requirements which is usually the outcome of the Agile process; b) UCD
ensures the focus remains on users and user interfaces and thus User Experience elements
are not neglected which is usually the case with Agile; c) As none of the Agile processes
focus explicitly on usability UCD is used to serve this purpose (Salah et al., 2014).
Additionally, and to reflect our WeGovNow approach, multiple approaches to requirements
documentation (User Stories, Personas, Requirements Lists) have been used, to ensure that
the developers have as much information about both the functional and non-functional
requirements of end users (e.g. context), and that WeGovNow is able to take into account
emerging requirements (as required by Agile) and involve the users in the design process in
great depth by asking them to create personas and user stories. However, it also gives
clarity on the bigger picture provided by the Waterfall method for situations where end
users and proxies are not immediately available. As noted above, this dual approach also
provides benefits to Interaction Designers (including the accessibility design required by the
project) who need a solid understanding of a relatively complete set of requirements from
the outset, and overcomes one of the known issues with Agile. To quote Patton (2014): “I
love Agile Development. Every few weeks we see more working software. But it feels like
I’ve lost the big picture”. While the Agile approach has proven to have better results for
development success (succeeding three times more often than Waterfall, Turner et al 2013)
D2.2 WeGovNow Use Cases v.1
68
it could be suggested that the Waterfall approach may be more suitable for WeGovNow as it
may be easier to facilitate an intensive one-off requirements gathering session at the start
of the project, with developers and users flying to meet in the same country.
The requirements gathering process for WeGovNow is also, to a certain extent, given an
advantage due to the pre-existing software as “if a product is a new invention it can be
difficult to identify users and tasks” (Sharp et al 2009) which is what makes using purely a
UCD approach a bit problematic. Stakeholders in ‘greenfield’ situations may not necessarily
know what is possible (ibid) which could potentially make the requirements gathering
process far longer while a basic understanding of the user needs and context is gathered
and in particular while the developers gain the required in-depth understanding of the
user’s work domain. Within WeGovNow, users are rather being asked how they could
employ the existing software to benefit their daily tasks, with the consequence that the
users are also required to make some effort to understand the developers’ domain (i.e. the
existing software) at the same time as the developers further their understanding of the
users’ domain (engagement with the public and the municipality context). However, we do
not exclude the users from discussions that may shape the overall User Experience and in
particular the usability of the proposed WeGovNow Platform.
Moving forward, it will be important to make sure that even though user involvement is
limited when compared with the almost daily involvement required by Agile and UCD, it is
sufficient that the project does not encounter the pitfalls identified as part of the Waterfall
method. This will involve regular workshops, interviews, focus groups and other meetings
with a wide variety of stakeholders. Expectation management is also important to ensure
that the expectations of a new product realistic (Sharp et al 2009) and this is achieved by
providing access to the software at an early stage in the project, either in the form of early
deployments and/or in the form of sandpits (where users can test out the systems in a
synthetic environment). As noted by Carizzo et al (2014) the expertise and experience of the
persons eliciting the requirements from the users (i.e. those conducting the workshops or
interviews) is also important in ensuring a successful outcome of the process. In
WeGovNow this expertise is not widely distributed, in particular within the Municipalities,
and the process may need to be adapted going forward to compensate for this, while also
taking into account the language differences between the team leading on this process
(from the UK) and two of the municipalities based in Italy.
6 Annex II: Generic User Requirements Derived From the Initial Scoping Exercise
6.1 Usability User Requirements (non-functional user requirements)
The WeGovNow Platform should be efficient to use; i.e. user goals should be easy to
accomplish quickly and with few or no user errors.
D2.2 WeGovNow Use Cases v.1
69
The WeGovNow Platform should be intuitive; i.e. the interface should easy to learn and
navigate; buttons, headings, and help/error messages are simple to understand.
The WeGovNow Platform has low perceived workload; i.e. the interface appears easy to
use, rather than intimidating, demanding and frustrating
The WeGovNow Platform should be fast.
The WeGovNow Platform should be fully responsive.
Steps Forward: The usability requirements will be extended and become more specific
during iterative co-design user sessions that will involve usability testing of our existing tools
and software.
6.2 Other Non-Functional User Requirements
The WeGovNow Platform should be trustworthy.
The WeGovNow Platform should be transparent.
The WeGovNow Platform should be reliable.
The WeGovNow Platform will be open source at the end of the project.
The WeGovNow Platform and tools should be optimised for mobile use
The WeGovNow Platform and tools should be fully responsive.
Steps Forward: Broad non-functional requirements like the ones above will be extended
and become more specific to capture relevant interface design elements and functionality
features provided during iterative co-design user sessions. Non-functional requirements will
be further evaluated using questionnaires when the prototype is developed.
6.3 Registration User Requirements
The WeGovNow Platform should include a user authentication where users must
identify themselves using a login name and password. Only users who are authorised in
this way will have access to specific parts of the system*.
WeGovNow registration and authentication will be used to provide users with
customised services.
The WeGovNow Platform should provide users with the option to find more about their
local area after they login.
Specific projects on the WeGovNow Platform should allow users to contribute data,
make comments and vote without authenticating themselves *.
WeGovNow registration should support registration with email or a social media
account (e.g. login using Facebook, Twitter).
WeGovNow registration should provide clear instructions to explain user benefits for
registering and this should be directly visible from the registration page.
WeGovNow registration process should comply with basic usability principles to avoid
alienating or confusing the user.
D2.2 WeGovNow Use Cases v.1
70
Steps Forward:
*the exact tasks that should be supported with and without authentication need further
investigation during iterative co-design user sessions where specific projects will be studied
in context.
**user information collected during the registration process will be further investigated
during iterative co-design sessions to ensure that data collected are useful to the council but
also ensuring that data collection do not cause any engagement barriers due to user privacy
concerns.
6.4 Data User Requirements
Mapping and spatial data
Southwark council emphasises on the importance of the mapping component and the user
contribution of spatial data from the very beginning of the workshop and prior to
introducing any of the WeGovNow tools and technologies:
“Just to bring it back to technology. My interest was usually in … geospatial data …
geospatial services. The beauty of geospatial data is all about mapping and interactive
mapping and that kind of thing … it can interact with and can dovetail with so many other
areas …A lamp post is there at a fixed placed … There is a new park that at fixed location. All
that becomes captured within geospatial data so we can use it and analyse it and make
decisions based on it.” (Southwark user comment)
“…it is the mapping element of the offerings that you are talking to us that are of interest”
(Southwark user comment)
The WeGovNow Platform should provide interactive maps (spatial interfaces).
The WeGovNow spatial interfaces should allow users to contribute spatial data (i.e.
points, lines, polygons).
The WeGovNow spatial interfaces should allow users to view spatial data that are
contributed by other users.
The WeGovNow spatial interfaces should allow users* to edit/add/delete data.
The WeGovNow spatial interfaces should support data filtering using a defined by the
user search address.
WeGovNow spatial data should be in a format that enables integration with other data
sources that are used by the council **
The WeGovNow Platform should enable users to import and export spatial data** on
WeGovNow Maps.
The WeGovNow Platform should allow users to add an event on the map (with or
without moderation).
D2.2 WeGovNow Use Cases v.1
71
The WeGovNow Platform should support the users to set an expiration date for the
event they add on the map. On the expiration date the event is automatically deleted
and it is removed from the map.
The WeGovNow Platform should enable users to rate data entries on the map using a
starts system.
The WeGovNow Platform should enable users to run queries for identifying pending
consultations in specific spatial areas of search (i.e. user defined radius around a specific
address).
Steps Forward: Iterative co-design user sessions to further investigate user requirements
about maps and spatial data.
*edit/add/delete and other data functions depend on user & project access rights.
Moderation will be required for this functionality.
**further investigation is needed to understand the data that councils and other
stakeholders are working with and this will be further investigated during the iterative co-
design sessions.
Other data
WeGovNow users should be able to contribute comments
The WeGovNow Platform should enable users to import and export data
WeGovNow data should be compatible with other data formats that are used by the
council.
The WeGovNow Platform should interact with the CRM database that it is used by the
Southwark council.
Steps Forward: Iterative co-design user sessions to further investigate user requirements
moderation is required as well as the data formats that should be supported.
6.5 Voting User Requirements
The WeGovNow Platform should enable users to vote for their preferred
option/decision with respect to a proposed site using two options; i.e. ‘Yes’ ‘No’.
“For example the council might have 3 or 4 offered up sites for a playground using
spectrospecial you can plot those 4 sites on the map and then you invite the residents to
click on particular sites and vote ‘yes’, vote ‘no’ and maybe give them the option to ‘ask a
question’”.
The WeGovNow Platform should enable users once they vote to see the outcome of the
voting process.
Steps Forward: Iterative co-design user sessions to further investigate requirements for
voting functionality as this is highly influenced by various contextual project characteristics
and needs.
D2.2 WeGovNow Use Cases v.1
72
6.6 Communication and other Social Interactions User Requirements
The WeGovNow Platform should support integration with social networking platforms
(i.e. Facebook and Twitter).
The WeGovNow Platform should support moderated conversations amongst its users.
The WeGovNow Platform should provide users with options for other forms of
engagement (i.e. receive information via email, participate in facet-to-face interviews).
The WeGovNow Platform should inform the participants that were engaged in a project
about the final decision/outcome.
The WeGovNow Platform should provide to users the option to opt in/out for receiving
newsletters/updates/notifications and other customised services.
Steps Forward: Iterative co-design user sessions to further investigate requirements for
additional functionality which will eventually support communication and social
interactions.
6.7 Uncategorised Technical User Requirements (functional and non-functional)
Integration of WeGovNow Platform should be such to allow users to use a different tool
from any location within the platform.
The WeGovNow Platform should enable users (i.e. citizens, communities and council) to
start a new project for any important issue.
The WeGovNow Platform should be aware of each user’s location (i.e. home address) to
send notifications each time there is a public event or a consultation taking place within
a user specified distance from his home address. This should be part of the
customisation services the platform provides to the users.
“every time that something happens within the next 300 meters you can choose
whether or not you can be part of it” (Southwark user comment)
The WeGovNow Platform should require moderation access rights to use specific
functions.
The WeGovNow Platform should support grouping registered users based on various
geodemographics.
Steps Forward: Iterative co-design user sessions to further investigate these specific
requirements in detail before they can be added into a specific group of requirements.
In order to facilitate the authentication of organized entities, the login screen should ask
to add the sector or the geographical area of reference (e.g. City of Turin - European
Funds Dep.; Ipercoop - Torino, via Livorno)
The WeGovNow Platform should enable all potential users/stakeholders to create a
“map of collaborations”: stakeholder with whom I have collaborated or I'm collaborating
D2.2 WeGovNow Use Cases v.1
73
The WeGovNow Platform should allow users to work at different levels/different scale
(neighbourhood needs, local needs, …). The reference area (geographic area or project
area) should be highlighted visually on the map
In order to collect better feedback/complaints/suggestions from citizens, the Platform
should give some examples of the different categories (i.e. road maintenance: broken
traffic lights, potholes, …)
The WeGovNow Platform should allow users/stakeholders to report what they want and
what is missing (i.e. we need a garden for children); and to report also positive
feedbacks
The WeGovNow Platform should allow users/stakeholders to contribute to a project
(with human and financial resources), perhaps adding a crowdfunding tool.
The feedback and suggestions provided by users on the WeGovNow platform should be
collected in a way that is meaningful for the council to analyse.
The WeGovNow platform should include a user authentication which is connected with
a social media accounts and should be able to be connected to all main social media, in
order to increase the users.
The WeGovNow Platform could integrate Google’s cookies to send push emails: i.e. if I
like theatre, the platform could suggest to users that there is a theatre close to Dora
Park, or an association which works in the cultural/theatre field.
The WeGovNow platform should use the same user authentication which is used to
access other services.2
2 SPID - http://www.spid.gov.it/ or TorinoFacile - https://servizi.torinofacile.it/
74
7 Annex III: Example of personas derived from the initial scoping exercise
In the preliminary stages of ‘WeGovNow’ we use the data collected from our meeting with
Southwark users to construct four personas, highlighting key user characteristics as these
were identified by the stakeholders in this authority (i.e. age, accessibility requirements,
education, Information Technology skills and literacy). For example, one user was a dyslectic
woman. This shows that the council has to keep users in mind who have special accessibility
needs. Another persona was a hipster cyclist who was rather an IT expert. In the UK, IT
literacy and broadband access are quite high in the UK in general. In other countries,
however, this is often not the case. Another persona was a woman who was moving into her
new flat with her husband. The couple needs information about the area provided by the
council. Another persona was a single-parent mother with four children, English was her
second language, as the council engages with many people who don’t have English as their
first language. We assume that the same four main types will be identified during the user
requirement workshops that are currently organised in the Italian municipalities. We will
extend the personas to include additional user types that capture, specific to this context,
user characteristics and key requirements.
Exhibit 3: Some examples of personas
75
76
8 Annex IV: Example of user stories derived from the initial scoping exercise
Main actors: Public green and Municipal buildings Department; Development, European Funds, Innovation and Smart City Department; Youth Department; local communities (Event Five Association; UISP; other association; citizens)
Issue 1: How to involve local communities, associations and stakeholder in designing an area
for teenagers and young people (with new services and activities)?
Solution 1: Providing a tool for opinion formation and decision making, which helps groups
to identify objectives, activities, location…
As a <Municipality> I need a tool to help stakeholder and citizens to cooperate with the
Municipality in designing new services and activities for teenagers and young people
Requirements: software for opinion formation and decision making
Issue 2: How to involve local associations or small boutique design companies in design,
production and/or maintenance of the area’s furniture?
77
Solution 2: Providing a tool to map local associations or small boutique design companies
and to map street furniture and playgrounds; provide a web site which can be used by local
associations or small boutique design companies to communicate and promote their best
practice actions regarding the area’s furniture.
As a <Municipality> I like to involve local associations or small boutique design companies
in design, production and maintenance of the area’s furniture.
Requirements: Visualised maps, web site, mailing/newsletter option
Issue 3: How to support local associations in the management of the area?
Solution 3: Providing a tool for decision making which allows local associations to coordinate
activities, to visualize all the activities that are scheduled in the area everyday, to collect
feedback and suggestions about the area, preferably on a map and using keywords
As a <Local association> I need support in the management of the area and a tool which
helps us in coordination activities
Requirements: Visualised maps, Shared calendar, mailing/newsletter option
Issue 4: How to promote the whole design process and how to provide information about
local community events and meetings, providing details and location, using a single website?
Solution 4: Providing a tool to map local community events/meetings, differentiating by
topics.
As a Municipality I need to promote and communicate the whole design process;
As a < Local association > I want to promote my activities and events and to find people
with similar interests in my local area
Requirements: Visualised maps, ability to use a smartphone for adding data,
mailing/newsletter option.
Main actors: Dora Shopping Mall; facilitators (other association; citizens)
Issue 1: How to involve local communities, associations and citizens in designing urban
furniture in order to furnish the internal square of the shopping mall?
Solution 1: Providing a tool for opinion formation and decision making, which helps groups
to identify objectives, activities, location…
As a <Shopping Mall> I need a tool to help stakeholder and citizens to cooperate with the
Municipality in designing new services and activities for teenagers and young people
78
Main actors: Innesto Association; MAcA; Urban Regeneration and Development
Department; Development, European Funds, Innovation and Smart City Department;
Shopping Center Parco Dora
Issue 1. How to report and document activities?
Solution 1: Providing a tool which allows us, Innesto association and MAcA to upload all
information (photos, videos, link, workshop’s reports, …)
As a <Municipality / Local association > I need a tool which allows us to upload different
types of information
Requirements: Tool which allows to add different type of information (photos, videos, link,
workshop’s reports, …), in order to report and document activities
Issue 2: How to monitor and evaluate the results of the project and the partnership in the
most effective way?
Solution 2: Providing a tool which can facilitate the collection of data (qualitative and
quantitative data)
As a <Municipality> I need a tool helping to collect data, in order to facilitate monitoring
and evaluation
Requirements: Tool which allows to add and collect different type of data, in order to
facilitate monitoring and evaluation
Issue 3: How to find volunteers for the management of the area?
Solution 3: Providing a tool to recruit volunteers and coordinate their activities.
As a < Association > I need volunteers to help us in things like first aid or stewarding
during major events
Requirements: App to manage volunteers’ recruitment and activities, ability to use a
smartphone for adding data, mailing option
Issue 4: How can I get some funds to better organize all the events?
Solution 4: Providing a tool to launch a successful Fundraising Campaign
As a < Director of the Environmental Museum > I need a tool to support the decision
making process and to launch a successful Fundraising Campaign
Requirements: Crowdfunding platform linked to WGN Platform
79
Issue: How to map the local bin collection points and provide the information to the local
community?
Solution: Providing a tool to map local bin collection points and visualise them in the area
provided.
As a <resident> I am keen to find out where the local bin collection points are in my area,
preferably on the map.
Requirements: Visualised maps (points).
Topic: Tube line extension disruptions
Issue: When I’m trying to get somewhere by tube from my home I need to know if there are
any potential disruptions linked to the ongoing tubeline extension taking place over the next
5 years?
Solution: Providing a tool to colour-map the disruptions within the area, allowing to filter
them based on time period selected.
As a <resident> I want to see all the new tube line extension potential disruptions for the
next 5 years on the map.
Requirements: Visualised maps (points, lines, areas), categories (to prioritise disruptions)
with possibility to choose colours for each of them, map filters based on a date range.
Topic: Local bin collection points
Issue: How can I find out where the various bin collection points that I close to my home?
Solution: Providing a tool to map local bin collection points and visualise them in the area
provided.
As a <resident> I am keen to find out where the local bin collection points are in my area,
preferably on the map.
Requirements: Visualised maps (points).
Topic: Unsafe areas
Issue: In the Community Safety team we want to know where people don’t feel safe in the
area and why?
Solution: Providing a tool, which is used to place data entries on the map and add comments on why they are not feeling safe in this specific area.
As a <Community Safety Officer> I want to see where in the borough people don’t feel
safe and preferably why they feel this way.
Requirements: Contributing points, lines and areas, allowing to provide detailed information
80
9 Annex V: Reporting template used for user scenario analysis
81
Towards We-Government: Collective and participative
approaches for addressing local policy challenges
Grant Agreement number: 693514
WWeeGGoovvNNooww sseerrvviiccee sscceennaarriioo && uussee ccaassee rreeppoorrttiinngg
tteemmppllaattee
Use case title: ........................................................................................................................
Use case ID: ........................................................................................................................
(Pilot site name & consecutive numbering
Date of preparation: ........................................................................................................................
82
A Introduction
A.1 Service scenario
A service scenario is to be developed to illustrate the advantages of new participatory
online services to be developed and piloted in collaboration with the three pilot
municipalities that:
a) enables and/or improves the involvement of citizens and/or civil society organisations and/or local businesses in public service delivery at municipal level
b) relies on the use of the WeGovNow platform (“Technical Assistive System”) by municipal staff and/or citizens and/or civil society organisations and/or local businesses in public service delivery at municipal level
The advantages of the new service[s] are to be illustrated by a specific flow of events, the
"day-in-the-life".
The service scenario is designed to set the context within which the WeGovNow platform
will be applied in the pilot city. It serves to provide an informal narrative description that
describes human activities and tasks (or else use cases) in a story that allows exploration
and discussion of contexts, need and requirements (Sharp et al 2009). It is aimed to ensure
that stakeholders understand the requirements, with a focus on what the users are trying to
achieve (ibid).
Essential roles in the use case are:
a) Staff of the municipality offering the new participatory service with help of the WeGovNow platform (Municipality)
b) Individual citizens to be involved in the new participatory services to be offered through the WeGovNow platform (Citizen)
c) Civil society organisations to be involved in the new participatory services to be offered through the WeGovNow platform (Local NGO)
d) Local businesses to be involved in the new participatory services to be offered through the WeGovNow platform (Local Business)
The service to be developed with help of the WeGovNow platform may not necessarily need
to involve the creation of entirely new organisations or processes. It may also be a
modification of current practices. In such cases, any new modifications should be elaborated
by way of a use case in which the main success criteria – the steps that need to work for the
use case to be implemented successfully - are identified. User Requirements (UR) and
subsequently the functional and non-functional requirements need to be derived from the
use cases for being fed into the technology development work strand of the project.
The work on service scenario development and related use case development is to be
organised in terms of an iterative process enabling a stepwise evolution (and possibly
prioritisation) until the start of the piloting stage, i.e. until the new WeGovNow services are
to be provided by the pilot municipalities under day-to-day conditions for piloting purposes.
83
A.2 Use cases
For each of the service scenarios one or more use cases are to be specified. A use case
represents a particular task or problem a user wants to achieve/address according to the
service scenario developed earlier, and should refer to a specific user/system interaction
that captures the users’ goal.
Staff of the local employment service wanting to indicate a dedicated job vacancy on a map
accessible through the WeGovNow platform or a citizen wanting to indicate on this map a
broken street light in her/his neighbourhood may serve as examples here. For our purpose
we consider a “user” as an individual trying to achieve something with the help of the
WeGovNow platform. A user acts within a particular role at a given point in time as defined
earlier in the service scenario, e.g. as a representative of a public administration or as a
citizen. In reality, it may however be possible that a user acts in different roles at different
points in time (e.g. in her/his role of public staff in an occupational context and as a citizen
during leisure time.
A.3 Functional and non-functional user requirements to be derived from each use case
For each use case – i.e. a specific task or problems a user wants to address - functional and
non-functional requirements are to be derived. Functional requirements concern a
particular functionality the WeGovNow platform need to provide in order to enable the user
to actually perform the desired task. Beyond functional requirement, the user may however
have the requirements on the WeGovNow platform which do not necessarily relate to a
particular functionality, e.g. when it comes to the usability of a given functionality. See
examples given in Section 2.2
A.4 Requirements on the WeGovNow platform not stemming from the users
Beyond requirements imposed by the users (i.e. user requirements) on the new platform to
be developed and piloted, other requirements may be derived from the service scenario
described earlier. There may for instance stem from relevant legislation/regulation, ethical
considerations and/or quality standards to be adhered to (e.g. an accessibility requirement).
B Structure of the service scenario template
This document is divided into two core parts. Part A focuses on a description of the service
scenario in terms of the overall background to the new service under consideration, the
identification and description of different roles involved and the technology to be utilised in
this context. This is then followed by a ‘day in a life’ description of how the anticipated
service would work in a typical day-to-day situation, thereby considering the different roles
previously identified.
84
The descriptive part is followed by a more analytical part in which specific use cases are
detailed and directed towards fleshing out the particular innovative aspects of the use case
when compared with the current service delivery situation. Also, this part aims at assessing
any positive and negative impacts that may be realized by the implementation of the use
case as well as organisational, technical and user related requirements on the new service
under consideration. Finally, the template leaves room for reflecting on possible variants or
improvements of the service scenario and associated use cases that have been hitherto
described.
B.1 Part A: Service scenario
Required end user support can usually not be delivered by ICT services alone but by socio-
technical systems which usually involve and are driven by professionals and other service
providers, i.e. by “people”. The approach to be adopted towards service specification,
implementation and validation of WeGovNow services therefore relies upon the concept of
“socio-technical systems”. In socio-technical systems, service delivery incorporates a
number of elements additional to ICT, in particular, specific roles played by a range of
actors.
This section aims at describing the “socio-technical assistive system” (STAS) through which
service delivery is to be achieved when it comes to the use case in question, thereby relying
on the description of different roles various actors have to play in the overall service
delivery/utilisation process. When it comes to describing in particular the ICT that is
envisaged to enable service delivery/utilisation the term ‘technological assistive system’
(TAS) is used throughout the remainder of this document.
B.1.1 General background to the new service under consideration
This section aims at putting the service scenario to be subsequently described into a wider
service context. Work at each pilot site is driven by demand from the municipality, whereby
collaborative involvement of citizens, third sector organisations and/or businesses is at the
core of the overall project. Against this background, this section aims at describing in a
generic manner the current service delivery situation at your pilot site, and any negative
impacts or problems that are to be addressed/overcome by means of the participatory
WeGovNow service(s) to be newly developed and piloted in the project. In this sense, this
section is to provide a concise description of the general background against which the
current service scenario and subsequent use cases have been developed.
B.1.2 Role naming
This subsection aims at identifying all local stakeholders that have a role to play in delivering
and using the WeGovNow service(s) when it comes to the service scenario and use case in
question. Different “sub-stakeholders” per stakeholder type (Municipality, Citizens, NGOs,
85
Businesses, Other) can also be included here. Use the following “coding scheme” for any
sub-stakeholders identified:
For instance there may be different departments/units at a given municipality having a
dedicated role to play in a given service scenario. These should be numbered respectively,
e.g. M01, M02, M03 and so on. “Sub-stakeholders” to other stakeholder types should be
numbered respectively, i.e. C01, C02 ..., NGO01 ..., B01 ... and O01...
According to the general scope of the project, different generic role categories should be
covered by the use case:
e) Staff / units of the municipality offering the new participatory service with help of the WeGovNow platform (Municipality)
f) Individual citizens to be involved in the new participatory services to be offered through the WeGovNow platform (Citizen)
g) Civil society organisations to be involved in the new participatory services to be offered through the WeGovNow platform (Local NGO)
h) Local businesses to be involved in the new participatory services to be offered through the WeGovNow platform (Local Business)
i) Other
Type Name
Local
Authority/Municipality
Citizens
NGOs
Businesses
Other
B.1.3 Role Description
This section aims at describing the key characteristics of the various stakeholders involved in
the socio-technical-system which needs to be established for implementing new
WeGovNow services, and their particular roles. This includes a description of dedicated
actions/activities carried out by the particular role holder with help of the technical
platform.
Type Name
Local Authority
Citizens
NGOs
86
Type Name
Businesses
Other
B.1.4 An illustrative ‘day in the life’ description of service utilization
This section aims at illustrating in a narrative manner how the anticipated service would
work in a typical day-to-day situation, thereby considering the different roles involved in the
STS as identified above. The description may focus on one given role, such as an external
service user or a municipality staff member, or may reflect multiple roles.
B.2 Part B: Analysis of service scenario, related use cases and user requirements
elicitation
The use case description aims at describing the specific task or problems a user wants to
address. It is documented in a structured format that allows for it to be used as ‘standalone’
tool for communication (i.e. for technical developers, for usability assessment and
evaluation purposes etc.):
The use case title should comprise a concise, goal-oriented name for the use case <withdraw money from an ATM>.
Name the primary role(s) that interacts with the system and performs the use case to accomplish tasks <Customer; ATM Technician; Bank>.
Provide a brief description of the goal and context of this use case. This is usually an expanded version of what you entered in the “Title” field <Bank customer inserts their debit card and enters a pin…information is sent to the bank…money is dispensed…>.
Preconditions should list any activities that must take place or any conditions that must be true, before the use case can be started <network connection is active; ATM has available cash…>.
Postconditions should describe the state of the system at the conclusion of the use case execution <money is dispensed to customer>.
Functional requirements concern a particular functionality the WeGovNow platform need to provide in order to enable the user to actually perform the desired task, so should describe what the system should do <Customer is validated; ATM displays actions available on ATM unit…>.
Beyond functional requirements, the user may however have requirements on the WeGovNow platform which do not necessarily relate to a particular functionality, such as the usability of a given functionality. Non-functional requirements describe how the system works <A PIN must be entered within 20 seconds; The user must enter the PIN correctly within 3 attempts…>
87
B.2.1 Use case description
Use case 1
a) User role(s) concerned
b) Description of task to be performed / problem to be addressed by the user
c) Preconditions
d) Postconditions
e) Functional requirements
f) Non-functional requirements
Use case 2
a) User role(s) concerned
b) Description of task to be performed / problem to be addressed by the user
c) Preconditions
d) Postconditions
e) Functional requirements
f) Non-functional requirements
Use case n (please paste in as many use cases as required)
a) User role(s) concerned
a) Description of task to be performed / problem to be addressed by the user
b) Preconditions
88
c) Postconditions
d) Functional requirements
e) Non-functional requirements
B.1.2 Organisational/service interfaces existing prior to the implementation of the
service scenario:
This section aims at describing in what way any of the challenges/problems addressed in the
use case have been dealt with until now, if at all. In particular, it should be described
whether any form of inter/intra-organizational cooperation between the parties involved
has existed up to now, and if so in what way.
B.1.3 Innovative aspects in relation to the participation of stakeholders in service
delivery within the new service scenario
This sections aims at documenting in what way the use case is expected to help addressing
current challenges/problems by the participatory public service. Any impacts that are
envisaged to be realised when compared with the current situation should be described as
concretely as possible. If at all possible it should also be described in what way such
improvements could potentially be monitored or measured within the project and/or
beyond.
Innovative aspect to the service scenario when compared with the current situation
Positive impacts / advantaged that can be envisaged when compared with the current
situation
Negative impacts / disadvantages that can be envisaged when compared with the
current situation
B.1.4 Anticipated options for adding value to the service scenario by means of open
public data
From existing sources of open public data
89
Open data that would need to be newly generated
B.1.5 Other requirements for service scenario implementation
This section aims at deriving requirements from the service scenario described earlier which
would need to be taken into consideration when practically implementing it. These may
concern aspects relating to the use cases identified earlier, but also to
organisational/services processes, the technology to be employed, legal/contractual aspects
or any other aspect. Here the intention is to elaborate on these requirements in your own
language, including a very brief reasoning for each of the requirements identified.
Description of organisational / process requirements
Requirements relating to the interoperability with existing ICT infrastructures (e.g.
integration with existing user authentication system)
Legal / contractual requirements (e.g. legal requirements required for a public
consultation)
Any other
B.1.6 Possible variants of the service scenario and options for improvements potentially
to be explored
Here we are interested in learning whether possible variations or room for improvement the
current service scenario can be anticipated at this stage, albeit this may require further
internal discussions and/or clarifications. These may concern the service concept as such or
just selected aspects.
90
10 References
Browne, G.J. and Rogich, M.B., 2001. An empirical investigation of user requirements
elicitation: Comparing the effectiveness of prompting techniques. Journal of
Management Information Systems, 17(4), pp. 223-249.
Carrizo, D., Dieste, O. and Juristo, N., 2014. Systematizing requirements elicitation technique
selection. Information and Software Technology, 56(6), pp. 644-669.
Cohn, M, N/D Differences between SCRUM and Extreme Programming, online available
from: https://www.mountaingoatsoftware.com/blog/differences-between-scrum-
and-extreme-programming [Accessed 20th July 2016]
Cohn, M, 2004, User Stories Applied for Agile Software Developmen, Pearson Education Inc
Dingsøyr, T., Nerur, S., Balijepally, V. and Moe, N.B., 2012. A decade of agile methodologies:
Towards explaining agile software development. Journal of Systems and Software,
85(6), pp. 1213-1221.
Mark, L., 2012. Agile Project Management For Dummies. Wiley.
Muller, M. J., Wildman, D. M. and White, E. A., 1993. Participatory Design. Communication
of ACM, 36(4), pp. 23-28.
Pasmore, W. A., 1988. Designing Effective Organizations: The Sociotechnical Systems
Perspective. Academic Press.
Patton J, 2014, User Story Mapping, O’Reilly
Sharp H, Rogers Y, Preece J, 2009, Interaction Design - Beyond Human Computer
Interaction, J Wiley and Sons
Turner M, Hurst S, Jordan R, 2013, User Stories Unleashed, Tire Swing 360