EasySDI OWS Builder SRS - BFHstatic.sws.bfh.ch/download/MAS-07-01-05-spec.pdfDownload services, ... Billing: an online payment ... urban planners, and geologist), infrastructure providers

Master Thesis MAS-07-01.05

Software requirements & specifications

Berner Fachhochschule

Technik und Informatik

Software-Schule Schweiz

Antoine Elbel & Rémy Baud

page 1 sur 45

Change Management

Document & source repository

Automation of Geoservice creation


Antoine Elbel Author [email protected]

Rémy Baud Author [email protected]

Bruno Magoni / Depth SA Technical expert [email protected]

Xavier Mérour Customer [email protected]

Beatrice Amrhein BFH-Expert [email protected]

Date Version Reason of changes Person

16.03.09 0.1 Structure of the document AE/RB

06.04.09 0.2 Submitted for Review to B. Amrhein AE/RB

13.04.09 0.3 Submitted for Review to X. Merour and B.Magoni AE

23.04.09 1.0 First release AE/RB

06.05.09 1.1 2nd Upload on the SWS portal AE/RB

Type Software Location

Version control system SVN svn://asitvd.ch/master

Forge Redmine http://projets.asitvd.ch:3000/projects/show/master-project

EasySDI Publish







page 2 sur 45

Table of content

1. Introduction ......................................................................................................................................................... 4 1.1 Goal, scope of this document ................................................................................................................................ 4 1.1.1 Global context ....................................................................................................................................................... 4 1.2 Product scope ....................................................................................................................................................... 9 1.2.1 Product context ..................................................................................................................................................... 9 1.2.2 Foreseen Application Architecture ...................................................................................................................... 11 1.2.3 Recommended Reading...................................................................................................................................... 11 1.3 Used definitions, acronyms, Glossary ................................................................................................................. 12 1.3.1 Definitions / Glossary .......................................................................................................................................... 12 1.3.2 Acronyms ............................................................................................................................................................ 12 1.4 Referenced Documents....................................................................................................................................... 12 1.5 Competitive products, existing market ................................................................................................................ 13 1.6 Stakeholder definition .......................................................................................................................................... 13 1.6.1 Stakeholder profile .............................................................................................................................................. 13 1.6.2 User profile .......................................................................................................................................................... 13 1.7 Licensing & legal notice....................................................................................................................................... 14

2. General Overview .............................................................................................................................................. 15 2.1 Product functionalities ......................................................................................................................................... 15 2.1.1 Overview ............................................................................................................................................................. 15 2.1.2 Business use cases............................................................................................................................................. 15

3. Requirement / functionality .............................................................................................................................. 19 3.1 Conventions ........................................................................................................................................................ 19 3.1.1 Requirement template ......................................................................................................................................... 19 3.1.2 Description .......................................................................................................................................................... 19 3.1.3 Naming ................................................................................................................................................................ 19 3.1.4 Type .................................................................................................................................................................... 19 3.1.5 Version V ............................................................................................................................................................. 20 3.1.6 Priority P .............................................................................................................................................................. 20 3.2 Subsystems ......................................................................................................................................................... 20 3.3 Use cases ........................................................................................................................................................... 21 3.3.1 UsUC01 “Create Service” .................................................................................................................................... 21 3.3.2 UsUC02 “Update Geoservice” ............................................................................................................................. 24 3.3.3 UsUC03 “List Created geoservices” .................................................................................................................... 26 3.3.4 UsUC04 “Delete Geoservice” .............................................................................................................................. 26 3.3.5 UsUC05 “Quick-View” ......................................................................................................................................... 27 3.3.6 UsUC06 “Upload Dataset” ................................................................................................................................... 28 3.3.7 UsUC07 “Transform Dataset”, UsUC08 “Store Dataset” ..................................................................................... 29 3.3.8 UsUC09 “Handle geoservice” .............................................................................................................................. 30 3.3.9 UsUC10 “Publish geoservice” ............................................................................................................................. 31 3.3.10 AdUC01 “Configure OWS” .................................................................................................................................. 31 3.4 Other non-functional requirements ...................................................................................................................... 33 3.5 Specific location requirement .............................................................................................................................. 33







page 3 sur 45

4. Documentation .................................................................................................................................................. 35 4.1 User’s guide ........................................................................................................................................................ 35 4.2 Online Help ......................................................................................................................................................... 35 4.3 Administrator’s guide ........................................................................................................................................... 35

5. Test concept ...................................................................................................................................................... 36 5.1 Goal of testing ..................................................................................................................................................... 36 5.2 Overview of planned tests ................................................................................................................................... 36 5.2.1 Smoke testing ..................................................................................................................................................... 36 5.2.2 Acceptance test ................................................................................................................................................... 36 5.2.3 System test ......................................................................................................................................................... 36 5.2.4 Integration Tests ................................................................................................................................................. 37

6. Project activity ................................................................................................................................................... 38 6.1 Project plan ......................................................................................................................................................... 38 6.2 Effort estimation .................................................................................................................................................. 38 6.3 Resource Plan ..................................................................................................................................................... 40

7. Risk Management .............................................................................................................................................. 42

8. Annex ................................................................................................................................................................. 45 8.1 Table of figures ................................................................................................................................................... 45







page 4 sur 45

1. Introduction

1.1 Goal, scope of this document

This document shall support the development process of EasySDI Publish. All requirements and agreements shall be

formulated as precise, complete, traceable and unambiguous as possible. Because a good picture is better than a

thousand words, this document should avoid following situations:

Figure 1: Communication problems in product development.

1.1.1 Global context

In order to describe the environment in which EasySDI Publish belongs, a general overview of its domain is presented

using a top-down approach.

1.1.1.1 The INSPIRE directive as root motivation.

“INSPIRE stands as the directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007

establishing an Infrastructure for Spatial Information in the European Community (INSPIRE). The general situation on







page 5 sur 45

spatial information in Europe is one of fragmentation of datasets and sources, gaps in availability, lack of

harmonisation between datasets at different geographical scales and duplication of information collection. These

problems make it difficult to identify access and use data that is available.

To counter this actual state, the initiative intends to trigger the creation of a European spatial information infrastructure

that delivers to the users integrated spatial information services. These services should allow the users to identify and

access spatial or geographical information from a wide range of sources, from the local level to the global level, in an

inter-operable way for a variety of uses. The target users of INSPIRE include policy-makers, planners and managers at

European, national and local level and the citizens and their organisations. Possible services available in a spatial data

infrastructure (SDI) are:

Discovery services making it possible to search for spatial datasets and spatial data services.

Catalogue services, making it possible to search, browse metadata that describe datasets.

View services making it possible to display, overlay spatial datasets and to display legend information.

Download services, enabling copies of spatial datasets to be downloaded.

Transformation services, enabling spatial datasets to be transformed.

“Invoke spatial data services” services, enabling data services to be invoked, for spatial-analysis purpose.

Further guidelines ensure that:

Infrastructures should make it possible that spatial data are stored, made available and maintained at the

most appropriate level.

It is possible to combine spatial data from different sources across the Community in a consistent way and

share them between several users and applications.

It is possible for spatial data collected at one level of public authority to be shared between all the different

levels of public authorities.

Spatial data are made available under conditions that do not unduly restrict their extensive use.

That it is easy to discover available spatial data, to evaluate their fitness for purpose and to know the

conditions applicable to their use.”

(Source: INSPIRE directive)

Figure 2: Inspire architecture

Services are built on datasets which users and applications access via a standardized and interoperable way (mostly

ISO and OGC standards). Queries are granted and filtered by the right management layer, which restricts request

possibilities and accessible contents to user rights.

The Inspire directive applies to the European Union member states, but its concept and vision may be extended to a

larger scope of organisations which deal with spatial data infrastructure.







page 6 sur 45

1.1.1.2 The OGC standards

While ISO provides standards for a wide array of components, as in our case for data structures and models, OGC

deals with standardization of geospatial content and services, data processing and sharing. There are currently 28

standards in the baseline, including:

WMS: Web Map Service: Service used to request and retrieve an image representation of an underlying

image or vector dataset.

Figure 3: A WMS sample from NASA server

The request supplied to retrieve this image was:

http://wms.jpl.nasa.gov/wms.cgi?REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&LAYERS=global_

mosaic&STYLES=pseudo&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&SRS=E

PSG:4326&BBOX=-

9.20332936979787,27.7825531860746,21.1890606420927,61.2828451492405&WIDTH=841&HEIGHT=927

WFS: Web Feature Service: Service used to request and retrieve a subset of vector data and related

attributes, encapsulated into the open GML format.

CSW: Service making it possible to access dataset metadata catalogue.

WPS: Web Processing Service: Service enabling analyses and calculations on datasets.

Most services use the remote procedure call principle based on HTTP, accepting both post and get methods.

They also support SOAP and some services even comply with the REST principle.

For instance, all services must implement a GetCapabilities method which returns the service capabilities

(methods, parameters, content) as an xml description. Furthermore, other methods are mandatory depending on

the type of the service (GetMap to retrieve an image from a WMS).







page 7 sur 45

1.1.1.3 The EasySDI project

EasySDI aims to implement the INSPIRE directive. It enables the realization of a geoportal based on a spatial data

infrastructure which allows spatial data sharing in a standardized way across several providers and consumers, without

imposing any specific tool or technology.

Figure 4: EasySDI’s concept

Providers can enter products or metadata based on their available datasets. The portal enables the consumer to

browse, query and view metadata, as well as order related products. The portal’s services are accessible through a

web-browser connecting to the website (Content Management System) or through a GIS software. In both cases the

access request goes through the right management layer represented by the proxy.

The CMS contains web-based features, so called “Joomla! Components”, that perform specialized business tasks.

These are described in the picture below.







page 8 sur 45

Figure 5: EasySDI stack and EasySDI Publish place.

Existing features:

Proxy: encryption, authentication and content filtering on OGC Web services (right management level).

Shop: online order of datasets from multiple providers.

Catalogue: online browsable metadata repository for datasets.

Core: user, role and right definition over EasySDI and implements common features.

Future or actual developments:

Map: a cartographic website where datasets can be viewed, searched and queried.

Billing: an online payment facility, billing upon geoservice consumption.

Geoservice monitoring: a remote geoservice watching, uptime reports, alarms, actions and notifications in

case of service failures.

Report: reporting and statistics of accessed and used data.

Installing the core component is mandatory, the other ones are optional.

1.1.1.4 The customer

EasySDI Publish is developed to match the needs of the ASIT-VD (Association pour le system d’information du

territoire Vaudois -- Association for the geographic information system in the canton of Vaud). The main goal of this

organization is to provide services for promoting geodata exchange and visibility for the interested partner inside the

state of "Vaud". It provides an entry point, from which it is possible to get information about all geodata and services

available for this canton. The ASIT-VD affiliates about 300 partners which are city-councils, cantons, the state,







page 9 sur 45

engineering firms (geometers, architects, urban planners, and geologist), infrastructure providers (gas, electricity, and

public transportation), specialized and federal institutes, software development firms, and private people.

To accomplish this task of promotion, the association already provides a searchable catalogue through a web portal for

browsing and ordering geodata of its partner community. Each member who wants to make public its data can fill in the

catalogue online, and then interested people may browse and order datasets.

1.2 Product scope

EasySDI Publish main goals:

Facilitate datasets distribution upon standardized geoservices (WMS/WFS) for a large, inexperienced public.

Share an infrastructure for datasets diffusion through geoservices.

This shall bring the following benefits:

Decrease the complexity of creating such geoservices by offering:

o Simple creation and configuration, comparable to ordering a book from an online store.

o Only most relevant data to be configured.

By sharing a diffusion infrastructure, no need of additional IT knowledge, no server cost and maintenance by

the end user will be required.

Promote significantly datasets exchange and in consequence, value-added services upon these datasets

(downloading, querying, analysing, combining them).

EasySDI Publish innovates with the creation of geoservice based on datasets, allowing first to transform their format

and reshape their model.

Datasets format needs to be transformed. Datasets have to be stored in a consistent way in database to meet

optimal diffusion performance, service maintainability, backups. Therefore EasySDI Publish must be able to transform

various datasets into a specified DB format (like PostGIS).

Datasets model needs to be reshaped. In a first approach, it might be sufficient to make only the transformation step.

It would work with certainty for well-designed datasets that come from GIS applications. On the other hand, the

application might have to deal with less structured datasets such as those coming from Computer-Aided Design (CAD),

which provides no topological rules, no themed structure and no real data model. Because it is not possible to publish

such data on a geoservice, it may be possible to reshape their structure before publishing them.

1.2.1 Product context

The extended EasySDI stack diagram points out what the EasySDI Publish functionalities are:







page 10 sur 45

Figure 6: Easy SDI Publish business functionalities

The scope of EasySDI Publish is to provide to a publisher the ability to create WMS or WFS geoservice on his dataset

and therefore, it DOES provide:

Dataset upload, format and model transformation, data storage.

WFS / WMS deployment on dataset.

Service configuration (end-point name, layer name, style).

Update or delete a created geoservice.

Preview a created service.

System configuration for the administrator.

Because the following functionalities are already usable or in development phase in EasySDI, EasySDI Publish DOES

NOT provide:

User administration.

Geoservice authentication and encryption.

Geoservice discovery and cataloguing.

Usage reporting, consumption statistic for billing purpose.

Service monitoring.







page 11 sur 45

1.2.2 Foreseen Application Architecture

This paragraph lists the used technologies in EasySDI and where EasySDI Publish is positioned:

Figure 7: EasySDI used technologies overview

User interface: JOOMLA! 1.5 is used as content management system, it requires

o PHP.

o MySQL.

Business tier:

o Java and PHP.

o Servlet container: Default is Tomcat, but other ones are supported.

o Of course, any needed technology that supports OGC standards.

Data tier:

o No condition, because a MySQL database is required to run Joomla, EasySDI Publish may use this

database for its own needs.

The exact technology choice is not in the scope of the requirements, and the diagram above is non-committing.

1.2.3 Recommended Reading

As mentioned previously, the specification assumes that the reader has some background knowledge on the domain of

problems common to the world of Geographical Information System, and the common solutions to these problems.

Useful URLs that the reader might be interested to look at are:

INSPIRE directive

INSPIRE implementing rules

OGC’s WMS

OGC’s WFS

OGC’s WPS

Joomla

http://inspire.jrc.ec.europa.eu/directive.cfm

http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/network/D3_5_INSPIRE_NS_Architecture_v3-0.pdf

http://www.opengeospatial.org/standards/wms

http://www.opengeospatial.org/standards/wfs

http://www.opengeospatial.org/standards/wps

http://en.wikipedia.org/wiki/Joomla







page 12 sur 45

EasySDI

Fme

PostGIS

geotools

geoserver

1.3 Used definitions, acronyms, Glossary

1.3.1 Definitions / Glossary

Authentication Identification process performed with user name and password.

Encryption Use of SSL transport layer.

Dataset Data which has a geographic content or not.

Geodata Data which has a geographic content.

Geoservice A generic term to design an OGC's web service.

Shape (ESRI) Pseudo-standard format for GIS application data.

DXF Drawing eXchange format. Pseudo-standard format for CAD application data.

KML Keyhole Markup Language. Google’s geodata format.

1.3.2 Acronyms

ASIT-VD Association pour le Système d’Information du territoire Vaudois.

GUI Graphical User Interface.

WMS Web Mapping Service.

WFS Web Feature Service.

OGC Open Geospatial Consortium.

EPSG European Petroleum Survey Group.

INSPIRE Infrastructure for SPatial InfoRmation in Europe.

SDI Spatial Data Infrastructure.

OWS OGC Web Service.

SOAP Web Service Messaging Framework (historically Simple Object Access Protocol).

WPS Web Processing Service.

REST REpresentational State Transfer.

ESRI GIS software development company

1.4 Referenced Documents

[1] EasySDI Presentation http://www.easysdi.org/attachments/download/6

[2] INSPIRE technical note http://www.cirb.irisnet.be/site/fr/departements/coordsup/E-

Government/Files/inspire_technical_architecture

[3] INSPIRE directive http://inspire.jrc.ec.europa.eu/proposal/EN.pdf

[4] OGC Web Mapping Service specifications http://www.opengeospatial.org/standards/wms

[5] OGC Web Feature Service specifications http://www.opengeospatial.org/standards/wfs

http://www.easysdi.org/

http://en.wikipedia.org/wiki/Feature_Manipulation_Engine

http://postgis.refractions.net/

http://en.wikipedia.org/wiki/GeoTools

http://geoserver.org/display/GEOS/Welcome







page 13 sur 45

[6] OGC Web Processing Service specifications http://www.opengeospatial.org/standards/wps

1.5 Competitive products, existing market

Solutions, open source or proprietary, that exist to implement fully or partially a spatial data infrastructure are

numerous. Most relevant are:

Proprietary software:

ESRI’s ArcGIS publisher for geoservices.

Conterra.de for an SDI suite.

Open source software:

“Degree” for a decentralised data infrastructure.

Proprietary software may fit customers that have a big structure and financial resources. In some cases, experiments

turned into really good realisations, for example in the canton of Geneva. On the other hand, standards have been

sometimes loosely interpreted or only partially integrated. Proprietary solutions have sometime restrictions on data

conversion possibilities and support. Hence the user is dependent on a manufacturer and may pay for something that

finally doesn’t really “belong” to him. The user can’t extend the product the way he wants.

In the case of Open-Source software, almost only the Degree project implements partially the INSPIRE stack. It is

already possible to create geoservices from a web frontend with a simple tool, but until now only proprietary solutions

are available.

1.6 Stakeholder definition

1.6.1 Stakeholder profile

Type Spokesperson Designation / Responsibilities

Customer Xavier Mérour Defines the feature to bring in the software.

ASIT-Vd’s member Find some muppet Gives feedback about the application’s usability.

EasySDI’s steering

community

Bruno Magoni /

Depth consultant

Checks the project orientation to match optimal EasySDI project

integration.

ASIT-Vd Xavier Mérour Checks the project orientation to match optimal association’s

goals.

EasySDI Maintainer Bruno Magoni Represents Depth SA’s interests.

1.6.2 User profile

Type Designation / Responsibilities

Administrator Manages and monitors the system. Does maintenance tasks.







page 14 sur 45

Geoservice creator Prepares datasets for exposure to the service and creates the geoservice.

Geoservice operator Publishes the geoservice and manages the service policies (right management layer).

Geoservice consumer Consumes geoservice data with a web client or a heavy client (GIS application).

1.7 Licensing & legal notice

As part of the EasySDI project and towards the possible future project incubation, EasySDI Publish must be licensed –

without further restriction - under the GNU GPL V.3 license. Terms and conditions are available under:

http://www.gnu.org/licenses/gpl-3.0.html

http://www.gnu.org/licenses/gpl-3.0.html







page 15 sur 45

2. General Overview

2.1 Product functionalities

2.1.1 Overview

Figure 8: The EasySDI Framework and product functionalities overview.

2.1.2 Business use cases

2.1.2.1 User profile and actor mappings

User profile Actor in use cases

Administrator Administrator.

Geoservice creator Publisher (distinction is made in requirement description).

Geoservice operator Publisher (distinction is made in requirement description).

Geoservice consumer Consumer.

Existing features

Publisher

Features on wish list

Administrator







page 16 sur 45

2.1.2.2 Publisher

Figure 9: Publisher’s use cases.







page 17 sur 45

2.1.2.3 Administrator

Figure 10: Administrator’s use cases.

2.1.2.4 Consumer

Figure 11: Consumer Use Case

Because this project aims to publish geoservices, the consumer part is not part of the work and won’t be handled.







page 18 sur 45

CAD, GIS tools and existing map viewers will be able to access the dataset using the OGC standardized interface (the

geoservice) that Easy SDI Publish has built after the creation process. This use case is drawn in order to display the

complete life cycle of the geodata.







page 19 sur 45

3. Requirement / functionality

3.1 Conventions

3.1.1 Description

Requirement descriptions follow a template.

The structure of this template is:

3.1.2 Requirement template

Name Description Type V P

[T]UC[a]

3.1.3 Naming

Notation Description

[T]UC[a]FR[x] UC: Use case of partial system T.

[a] counter for the use case.

FR: Functional Requirement.

[x]counter for the requirement.

GUI-NF01 Non-functional requirement that are more general and not described in the use cases.

They are classified regarding the system component: (SYStem, GUI, COMmunication,

SOFTware interfaces).

3.1.4 Type


Product All requirements for the product.

GUI All requirements for the GUI.

EasySDI All requirements for the framework (extension).







page 20 sur 45

3.1.5 Version V


1.0 Features of the first version, implemented in this work.

2.0 Features wished.

3.1.6 Priority P


1 Implementation of the Must point (shall), basis functionality.

2 Wish point (should).

3 Proposition (can).

4 Intention (will).

3.2 Subsystems


Us All requirements for the Publish User.

Ad All requirements for the Publish Administrator.







page 21 sur 45

3.3 Use cases

3.3.1 UsUC01 “Create Service”

Description: The publisher wants to create a geoservice.

Actor: The publisher.

Pre-condition:

The publisher is logged in.

The publisher disposes of sufficient rights.

Event-Flow:

Post-condition:

A geoservice is created


UsUC01 FR1 The system shall handle the upload of one dataset, contained into one file for Product 1.0 1







page 22 sur 45

the new service. The publisher shall provide the format name and projection

code, in which its data are described.

UsUC01 FR2 The system shall provide the ability to create the new geoservice with

following configuration elements:

Geoservice end-point name.

Geoservice type (WFS OR WMS).

Fields layer's attribute name and layer name (mapping between

database field and human readable name presented in the service).

Contact info + address for the responsible manager of the service.

A username and password to access the service end-point.

Map Default Colour.

Layer colours and line, point, fill colour and patterns.

Product

Product

1.0

1.0

1

2

UsUC01 FR3 The system shall provide the ability to upload vector-based dataset in various

formats for the WFS or WMS data source. Mandatory formats are:

ESRI shape.

Autodesk DXF.

Google's KML.

Product 1.0 1

UsUC01 FR4 The system can provide the ability to upload an image-based dataset in

various formats for the WMS data source. The wished formats are:

Erdas ECW.

GeoTIF.

MrSid.

JPEG2000.

Product 1.0 3

UsUC01 FR5 The system shall be able to support the following projections for WMS/WFS

rendering:

EPSG 21781 (CH1903 / LandVermessung 03).

EPSG 2056 (CH1903+ / LandVermessung 95).

EPSG 4326 (WGS 84).

EPSG 3785 (900913) (Google’s Web Mercator, used in Google

Maps).

Product 1.0 1

UsUC01 FR6 The system shall be able to return detailed messages in case of a

configuration error, leading the publisher to correct them.

Product 1.0 1

UsUC01 FR7 The system can provide the ability to set basic security policies and

authentication in the EasySDI proxy for the created service.

This includes:

Access restriction with user name and password.

Geographic Boundary limitations.

Geoservice operator and Data operator roles can be differentiated:

o Geoservice operator: Opens the service and manages

the right management.

o Data operator: Prepares data and service.

EasySDI –

Proxy

1.0 3







page 23 sur 45

UsUC01 FR8 If there is no configuration available, the system creates a default

configuration where the dataset field names are copied into the configuration

field.

Product 1.0 1







page 24 sur 45

3.3.2 UsUC02 “Update Geoservice”

Description: The publisher changes some properties of an already existing geoservice or the publisher updates

service’s dataset.


Pre-condition:

Publisher is logged in.

A service exists.

Publisher owns sufficient right on this service.

Event-Flow:

Post-condition:

The geoservice is updated.








page 25 sur 45

UsUC02 FR1 The system shall provide the possibility to update the configurable elements

of a geoservice as describe in UsUC01 FR2.

Product 1.0 2

UsUC02 FR2 The System shall provide the ability to update the data source of a geoservice

and shall perform checks to determine if the new data source is compatible

with the current geoservice configuration and accordingly display appropriate

error messages accordingly.

If the new data source is not compatible, the system shall provide

the choice to keep the existing data source and configuration OR to

keep the new data source and fill the configuration with default

values.

Product 1.0 2

UsUC02 FR3 By editing a geoservice, the system shall provide the possibility to EITHER

configure the geoservice OR upload a new data source.

Product 1.0 2

UsUC02 FR4 The system should be able to manage different roles, for creating the

geoservice (data operator) and for publishing, and securing the geoservice

(geoservice operator).

Product

1.0

3







page 26 sur 45

3.3.3 UsUC03 “List Created geoservices”

Description: The publisher requests a list of the services currently published.


Pre-condition: Publisher is logged in.

Event-Flow:

The System displays a list of published geoservices.

Post-condition:

If one or more services are available, a list is displayed.


UsUC03 FR1 The system shall provide the possibility to display a list of all geoservices

managed by the publisher.

The list shall contain at least:

Service name.

Service end point.

Date of creation.

Date of last dataset update.

Date of last changes in the configuration.

Product 1.0 1

UsUC03 FR2 The system should provide the possibility to view a list of all published

geoservices.

From this view, the system shall provide the possibility to turn a service online

and offline.

Product

Product

1.0

1.0

2

3

UsUC03 FR3 Search and filter functionalities should be available for sorting purpose. Product 1.0 2

3.3.4 UsUC04 “Delete Geoservice”

Description: A publisher erases a service that had been previously created by him.


Pre-condition:

At least one service must exist.

The publisher is logged in.

Event-Flow:

(include UsUC03) System displays a list of geoservices.

The publisher chooses the geoservice he wants to delete in the list.

(extend UsUC11) Delete the dataset if no other service references this dataset.

Post-condition:

The geoservice is deleted.








page 27 sur 45

UsUC04 FR1 The system should provide a mean to delete an already created geoservice.

If no geoservice references the dataset the latter shall also be deleted.

Product 1.0 1

UsUC04 FR2 The system shall delete all the fields corresponding to this service and

configuration elements. It shall emit a warning before deletion.

Product 1.0 1

3.3.5 UsUC05 “Quick-View”

Description: The publisher visualizes the created service on a map within the browser window.


Pre-condition:

At least a service is available.

Event-Flow:

(include UsUC03) System displays a list of geoservices.

Publisher chooses the geoservice he wants to visualize.

Post-condition:

A map displays the geoservice.


UsUC05 FR1 The system shall provide a map with the following navigation elements:

Zoom In.

Zoom Out.

Pan (move the visible map extends).

Zoom to full extent.

Product 1.0 3

UsUC05 FR2 A background image shall be displayed. A possible data source for this image

could be googlemap or yahoo maps service.

Product 1.0 3







page 28 sur 45

3.3.6 UsUC06 “Upload Dataset”

Description: The system transfers a dataset.

Actor: The system.

Pre-condition:

UsUC01 (service being created) and UsUC02 (service being updated).

Event-Flow:

N/A.

Post-condition:

A dataset is uploaded, and stands ready for transformation (UsUC07).


UsUC06 FR1 The system shall provide a mean to transfer a file from the local machine to

the server where EasySDI Publish resides.

Product 1.0 1

UsUC06 FR2 The system can provide a mean to synchronise a dataset automatically with a

configurable time interval.

Product 2.0 4

UsUC06 FR3 The system shall check the restrictions defined by the administrator, in

accordance with use case AdUC01.

Product 1.0 1







page 29 sur 45

3.3.7 UsUC07 “Transform Dataset”, UsUC08 “Store Dataset”

Description: A dataset is transformed and stored in a database.

Actor: The system.

Pre-condition:

A dataset is uploaded successfully.

Event-Flow:

The system detects that a new dataset is ready.

The system transforms the dataset.

The system stores the dataset in a database.

Post-condition:

The dataset is successfully stored in the database.


UsUC07(8) FR1 The system shall provide a mean to perform format-based conversion of the

dataset in the database:

Shape -> PostGIS.

Product 1.0 1

UsUC07(8) FR2 The system should provide a mean to perform model-based conversion of the

dataset, before storing it in the database:

Dxf -> PostGIS.

Product 1.0 2







page 30 sur 45

3.3.8 UsUC09 “Handle geoservice”

Description: The system checks and stores the configuration of the geoservice.

Actor: The system.

Pre-condition:

A new geoservice is being created, or an existing geoservice is being updated.

Event-Flow:

Post-condition:

The geoservice configuration is stored.








page 31 sur 45

UsUC09 FR1 The system shall store the configuration elements described in UsUC01 FR5.

Product 1.0 1

UsUC09 FR2 The system shall check the coherence between the dataset and the

geoservice configuration.

If incoherence is detected an error shall be thrown, and no modification shall

be stored.

Product 1.0 1

3.3.9 UsUC10 “Publish geoservice”

Description: The system finalizes the geoservice publication.

Actor: The system.

Pre-condition:

A modified dataset and/or configuration are available.

Event-Flow:

Data are transferred on the publication server.

Post-condition:

Geoservice is online.


UsUC10 FR1 The system shall copy the data to the underlying publication server Product 1.0 1

UsUC10 FR2 The system configures the geoservice on the underlying publication

server.

Product 1.0 1

3.3.10 AdUC01 “Configure OWS”

Description: The administrator performs system management tasks.

Actor: The administrator.







page 32 sur 45

Pre-condition:

Administrator is logged in.

Event-Flow:

Configuration available over a browser page.

Post-condition:

The system is configured.


AdUC01 FR1 Following elements shall be made configurable:

Upload file size limitation.

Upload file type limitation.

Max services per publisher.

And following elements in conformance with UsUC02 FR4:

Role defined through allowed actions.

User's role.

Product

Product

1.0

1.0

1

3

AdUC01 FR2 The system shall provide to the administrator the ability to display a list of all

available geoservices.

Product 1.0 1

AdUC01 FR3 Search and filter functionalities should be available for sorting purpose. Product 1.0 1

AdUC01 FR4 The system can report on uptime, usage statistics can alert, restart server, …

(This would belong to a monitoring component)

EasySDI 2.0 2







page 33 sur 45

3.4 Other non-functional requirements


SYS-NF01 Joomla Concepts of module/plug-in/component shall be used. Product 1.0 1

SYS-NF02 The configuration’s serialization and storage shall be done in the Joomla!

Database.

Product 1.0 1

SYS-NF03 The system shall use the EasySDI framework for the user authentication.

Therefore the installation of the EasySDI core component is a

prerequisite.

Product 1.0 1

SYS-NF04 EasySDI Publish shall support the following web browsers:

Firefox 3.0.

Internet Explorer 7.0.

Product

Product

1.0

1.0

1

2

GUI-NF01 Defined localization strings shall be used. Localization strings are stored in

a separate file.

Product 1.0 1

SOFT-NF02

The system shall be designed independently from a particular WMS/WFS

publication server.

Geoserver shall be supported as a publication server.

Product 1.0 1

SOFT-NF03

The system should be able to support many dataset transformation tools

(for example FME or geotools).

Product 1.0 2

COM-NF01 The system shall use only one publication server that is physically on the

same machine as EasySDI publish.

The system can use one or many WMS-WFS publication servers.

Product

Product

1.0

1.0

1

3

COM-NF02

The geoservice creation process shall be implemented as an OGC’s WPS

(Web Processing Service).

Access to this service shall be done over SSL and shall be protected with

a login.

Access to this service shall be done through the EasySDI-Proxy, which

provides encryption and authentication.

Product

Product

EasySDI-

Proxy

1.0

1.0

2.0

1

2

2

COM-NF03 In addition to the authentication for accessing a service end-point (the

created geoservice), as described in UsUC01 FR2, the transport layer for

accessing the service end-point should be encrypted with SSL.

Product 1.0 2

3.5 Specific location requirement

In addition to the EasySDI requirement, it shall be taken into account that:

Servers are Linux based.







page 34 sur 45

The ASIT-VD has no intention to compete with a service provider, which may be a partner. The former aims

to provide a service that no one else offers. For instance, there are firms who already provide geoservices

diffusion hosting, but do not provide a simple way for the creation process and configuration. These two

different tasks shall be separated and it should be possible to run them on different servers, where the

association provides a way to create the service. A third firm may provide the service storage and diffusion.







page 35 sur 45

4. Documentation

4.1 User’s guide

The goal of the application is to be intuitive in the way it is presented to the user, by using GUI ergonomics best

practices.

Hence, a user guide is not planned.

4.2 Online Help

docUC1.1FR1

Help on the full process of the geoservice creation, embedded into a

GUI.

Product 1.0 1

4.3 Administrator’s guide

docUC1.1FR2

The following documents are foreseen:

An EasySDI Publish installation guide.

A components configuration guide.

An administrative tasks guide.

Product 1.0 1







page 36 sur 45

5. Test concept

5.1 Goal of testing

The test plan goal is to consistently check the different views of the finished product:

The acceptance tests will verify the user requirements.

The system tests will verify the system requirements.

The integration tests will confront the system design.

And the unit tests will check the implementation as much as possible.

5.2 Overview of planned tests

At this stage of the project only the acceptance and system tests can be formalised because they directly depend on

the content of the present document. To the contrary, the other tests depend on the design and the implementation.

5.2.1 Smoke testing

As part of the development process, Smoke Tests will have to be run successfully by each developer before checking

changes in the subversion source control server.

5.2.2 Acceptance test

Acceptance tests aim to minimize the risk that the user ends up with a product different to the one he opted for. To

avoid this scenario, following elements may be tested with the involvement of both a representative user and ASIT-VD

contractor.

Test Object: Test Description:

GUI Interface Present a prototype to a user and to the expert.

Administrator Tasks Interface Present a prototype to the ASIT-VD contractor.

5.2.3 System test

Test Object: Test Description

UsUC01 “Create Service” Dedicated test scenario.

UsUC02 “Update Geoservice” Dedicated test scenario.

UsUC03 “List Created geoservices” Dedicated test scenario.

UsUC04 “Delete Geoservice” Dedicated test scenario.

UsUC05 “Quick-View” Dedicated test scenario.

UsUC06 “Upload Dataset” Dedicated test scenario.

UsUC07 “Transform Dataset” Unit Test.

UsUC08 “Store Dataset” Unit Test.

UsUC09 “Handle geoservice” Dedicated test scenario.

http://en.wikipedia.org/wiki/Smoke_testing







page 37 sur 45

UsUC10 “Publish geoservice” A useful mean for testing the WFS service at system level is

provided by the online client at:

http://webservices.ionicsoft.com/ionicweb/wfstester/index.html

AdUC01 “Configure OWS” Dedicated test scenario.

5.2.4 Integration Tests

These tests directly depend on the chosen design. Therefore integration tests planning will be made at a later stage of

the project. It is however reasonable to think that reviews and unit tests are the two methods that will be used to cover

them.

http://webservices.ionicsoft.com/ionicweb/wfstester/index.html







page 38 sur 45

6. Project activity

6.1 Project plan

The next picture describes with coarse granularity the time that will be spent on the main milestones. Project reviews,

documentation and testing are taken into account and are merged into the different tasks.

Milestones are defined, each with a set of deliverables:

Requirement phase: deliverable: Requirement and specification document

De-risking phase: deliverable: A chapter of the master thesis final report dealing with the prototypes that were

elaborated and the role they played in the overall proof of concept.

Design phase: deliverable: A chapter of the master thesis final report dealing within the concept and

reasoning behind the design decision.

Implementations: deliverable: The EasySDI Publish itself

Testing phase: deliverable: Successfully Executed test cases

Documentation: deliverable: Final Report

Presentation

Figure 12: Project planning overview

6.2 Effort estimation

The effort estimation is based on a PERT analysis that takes the previous milestones and describes them more in

depth. To convert the duration from day to hour the following formula is used:

1 working day = 2 persons that work 8h = 16 hours

Non-functional requirements do not appear in the PERT analysis, because they are implicitly included in the

implementation of the functional requirements.







page 39 sur 45

Figure 13: Effort Estimation







page 40 sur 45

6.3 Resource Plan

Since the project is run within the frame of a Master Thesis, the workload should be planned around fixed resources of

approximately 720 hours. This time quantum is distributed according to the following figure:

Figure 14: Resource Plan per person, day count







page 41 sur 45

Figure 15: Ressource Plan, Calendar View







page 42 sur 45

7. Risk Management

A successful project involves the realisation of a task within a given time and costs limit. Therefore it is important to

define a contingency plan to make sure that the work described in this document is feasible within the limited time and

costs. Major risks have been identified and are presented in the tables below, along with a solution.

Probability High Impact High

Description:

Learning Curve of the geoservice diffusion technology is too steep.

Objectives:

Avoid losing time because of choosing an inadequate technology.

Approach:

Make sure the technical needs for this project are understood.

Plan enough time for a proof of concept prototype where the critical parts of the server API are used.

Responsibilities:

Organize the knowledge acquisition by splitting areas of expertise between the team members and presentations to

spread it.

Contingency Plan and Trigger:

Trigger: More than 16 hours to get a service running.

Plan: Use hours from the end buffer to get it running at all costs.

Probability Medium Impact High

Description:

Learning Curve of the CMS Joomla and its programming environment is too steep.

Objectives:

Avoid losing time.

Approach:

Plan teaching hours from one project team member who masters this technology to the other.

Responsibilities:

Rémi to teach Antoine basic programming concepts in JOOMLA.


Trigger: Sleepless Night

Plan: Use hours from the end buffer to get it running at all costs.


Description:

Project implementation eating over documentation time.

Objectives:

Avoid hurrying over the final report.

Approach:







page 43 sur 45

Start early with the final report, by agreeing on a structure as soon as possible.

Responsibilities:

Antoine to propose a final report structure.


Trigger: Half of the planned hour spent without a line in the documentation and the final report.

Plan: work overtime

Probability Low Impact High

Description:

Daytime job putting the project resources under pressure.

Objectives:

Avoid having to face tight deadline both in the master thesis and in the professional employment sphere.

Approach:

Agree with employer on free time, early on in the project.

Responsibilities:

Antoine to propose a clear calendar and schedule to the end of the project.


Trigger: Unplanned emergency in the daytime job.

Plan: 3 days of buffer planned at the end of the project.

Status:

Agreement with School-Expert and Employer on a time

plan.

(cf sheet diplom_arbeit.xls)

Date:

20/03/09


Description:

Wrong technical decision in the choice of the geographical data format transformation.

Objectives:

Avoid losing time because of choosing a not adequate technology.

Approach:

Agree with the customer to support only a limited number of transformation types, but structuring the design to allow

easy future extensions.

Early prototype to understand better the data transformation problem domain.

Responsibilities:

Rémi to investigate for the available tools in the proprietary and open-source world.


Trigger: Technology workflow not understood at the beginning of the implementation phase.

Plan: work overtime


Description:

Learning Curve of the PostGIS database is too steep.







page 44 sur 45

Objectives:

Avoid losing time because of the technology intricacies.

Approach:

Early prototype to understand better the geographical database concepts.

Responsibilities:

One team member to devise an exercise and explain the solution to the other.


Trigger: Not understanding it quickly enough.

Plan: Work Overtime.







page 45 sur 45

8. Annex

8.1 Table of figures

Figure 1: Communication problems in product development. ....................................................................................................................... 4 Figure 2: Inspire architecture ........................................................................................................................................................................... 5 Figure 3: A WMS sample from NASA server ................................................................................................................................................. 6 Figure 4: EasySDI’s concept ........................................................................................................................................................................... 7 Figure 5: EasySDI stack and EasySDI Publish place. ................................................................................................................................... 8 Figure 6: Easy SDI Publish business functionalities..................................................................................................................................... 10 Figure 7: EasySDI used technologies overview ........................................................................................................................................... 11 Figure 8: EasySDI Framework and product functionalities overview. ......................................................................................................... 15 Figure 9: Provider’s use cases. ..................................................................................................................................................................... 16 Figure 10: Administrator’s use cases. ........................................................................................................................................................... 17 Figure 11: Consumer Use Case .................................................................................................................................................................... 17 Figure 12: Project planning overview ............................................................................................................................................................ 38 Figure 13: Effort Estimation ........................................................................................................................................................................... 39 Figure 14: Resource Plan per person, day count ......................................................................................................................................... 40 Figure 15: Ressource Plan, Calendar View ................................................................................................................................................ 41