Agility in software and service engineering usually needs to encompass the requirements analysis phase. The reason is that, only in rare cases, the requirements are fully available and fixed when software design and developments starts. In contrary, especially in the domain of environmental information systems, requirements analysis is an agile process including a multi-step dialogue between the user(s), the stakeholders and the software architects who know about the technological capabilities and constraints, and who may also estimate the effort to realize the expectations of the user. The resulting discussion often leads to reconsiderations and/or refinements of the user requirements. If multiple users of one or even multiple organizations are involved, such dialogues are usually carried out during requirements analysis workshops facilitated by experienced systems analysts or architects. The crucial aspects are a solid methodology underpinning this process as well as an associated flexible documentation of the requirements during this process, also taking into account capabilities and constraints of underlying geospatial architectures [9]. This paper presents a Web-based collaborative tool that supports the documentation according to the SERVUS design methodology [1].
The paper is structured as follows: Section 2 provides an overview about the SERVUS Design Methodology, before the structure of the use case model, i.e. its metamodel, is presented in section 3. The architecture of the tool supporting the methodology in form of a so-called use case server is described in section 4. As an illustrative example, section 5 explains how it is used in the ENVIROFI project, before the paper concludes with references to other tool applications and ideas about future developments.
The SERVUS design methodology [1] describes individual design activities interconnected by a common modelling environment that is common to the Enterprise, Information and Service Viewpoint of geospatial architectural frameworks [4]. The common modelling environment follows a resource-oriented approach according to the Representational State Transfer (REST) architectural style [5]. Hereby, a resource is considered to be an information object that is uniquely identified, may be represented in one or more representational forms (e.g. as a diagram, XML document or a map layer) and support resource methods that are taken from a limited set of operations whose semantics are well-known (uniform interface). A resource has own characteristics (attributes) and is linked to other resources forming a resource network. Furthermore, resource descriptions may refer to concepts of the domain model (design ontology) using the principle of semantic annotation, yielding so-called semantic resources SERVUS considers requirement analysis to be part of the Enterprise Viewpoint. It results in use case models that describe the behavior of a system [6] whereby "a use case is a sequence of actions performed by the system to yield an observable result that is typically of value for one or more actors or other stakeholders of the system".
When designing an (environmental information) system, a use case expresses the functional, informational and qualitative requirements of a user (i.e. an actor or a stakeholder) with respect to the system. Usually, use cases do not describe the user interactions themselves. The requirements for the user interface, i.e. a description of how the system functions are accessed by and presented to the user depending on his end-user device, may be captured in separate task models and then mapped to use cases [10]. It is essential for the use case description that the level of abstraction, the type of formalism as well as the language should be such that it is adequate to the domain of expertise of the users. In order to serve as a kind of contract with the user, a use case shall be both understandable to the user but also precise enough. Very often this means that use cases shall be specified in a non-technical way, normally achieved using plain text in natural language. However, in order to reduce the ambiguities and impreciseness of descriptions in natural language, structured textual descriptions are preferred. This means that use case descriptions are structured according to a given template, e.g. an application form comprising identifier and description fields or thematic domain references associated with code lists.
The SERVUS design methodology recommends a semi-formal description of use cases, e.g. according to the template proposed by Cockburn [8], but extends it in order to include references to requested resources, e.g. a time-series of water gauge values represented as a diagram. Optionally, it may be accompanied by a UML use case diagram. The templates of the ENVIROFI project are contained in [3].
The use case meta-model describes all the element types in a use case model and its relationships to each other. In addition to use cases as main element types, the SERVUS use case meta-model comprises the following element types:
actors: describes the roles of users that initiate use cases. test cases: describes a possible instantiation of a use case that is decisive for the system test with respect to this use case. requirements: describe functions of the system under design that may support the execution of a use case. In the ENVIROFI project also called enablers (see below). information resources: describes the information elements including its basic operations (create, read, update, delete) that are required to carry out the use case (see the resource-oriented approach of SERVUS introduced in section 2). Note that the early identification and linkage to information resource is the key idea that aims at reducing the gap between thematic experts as users and software architects. Hence, it distinguishes SERVUS from other use case-based approaches.
Each element type has its own structure and template, i.e. its own set of text elements. There are the following relations between these element types: use cases (UC) are linked to actors, to other use cases, to test cases (TC), to requirements (REQ) and information resources (IR). These relations are illustrated in Fig. 1 and will be explained below.
performs (inverse relation: is performed by): a UC is initiated and performed by an actor.
includes (inverse relation: is included in): one UC is included in another UC, i.e. one UC is included as a whole in the main success scenario, extension or alternate path of another UC.
refines (inverse relation: abstracted from): one UC is a refinement of another UC, e.g. it provides more details in its main success scenario, adds an extension or interprets a more abstract UC in the context of a thematic domain.
Note: The relation type <<refine>> corresponds to the relation type <<extend>> that is typically used in conventional UML use case diagrams.
is tested by (inverse relation: tests): one UC may be tested by one or more test cases.
Note: As use cases may be included in other use cases, one test case may also be linked to several use cases (which are then included in each other).
maps to (inverse relation: is derived from): a UC is mapped to one or more requirements. This means that the system under design should provide function (may be in terms of a Web service) that fulfills each requirement..
related to (bijective relation): one REQ is related to another REQ, i.e. there is some relationship between the requirements. This relation has to be better qualified in the future. It could be a unilateral or bilateral dependency but also some similarity in terms of concepts, design pattern or technology.
requests (inverse relation: is requested by): a UC requests an information resource in a defined access mode (create, read, update, delete).
refines (inverse relation: abstracted from): an information resource is a refinement of another information resource (in the sense of inheriting all properties of the more abstract information resource). related to (bijective relation): an information resource is related to another information resource. The meaning of the relation may be defined during the information modelling design step
Non-trivial projects and related system analysis and design activities require a tool that supports the edition and documentation of the use cases. For the SERVUS design methodology a dedicated tool has been implemented that allows the users to work in a collaborative and distributed manner. Furthermore, it supports an agile approach, i.e. use cases and the other elements in the model may be iteratively specified which allows the users to refine and change them according to the knowledge that is typically gained in the analysis and design process.
The architecture of the SERVUS Use Case Server is illustrated in Fig. 2. There are the following basic architectural decisions and characteristics of the SERVUS Use Case Server:
The server is realized as an application of the Fraunhofer IOSB WebGenesis ® content and community management framework that supports the implementation of Web-based collaborative applications by rich generic functions. Use cases and all other elements following the meta-model (e.g. test cases, information resources) are persistently stored in a relational database as WebGenesis ® entries. This enables the immediate use of built-in search functions for use cases and the other elements. The database structure is organized according to the use case meta-model which acts in this case as an ontology. Due to the built-in ontology support of WebGenesis ® this design decision increases the flexibility of the system and facilitates the linkage of these core elements to ontologies representing thematic domains.
At any time, there is the possibility to generate document reports out of the content of the use case server. In most projects, there is a need to deliver written use case specifications as soon as a given milestone has been reached. By using LATEX as document generation tool, the structure and the layout of the report may be easily changed and adapted to the requirements of a given project (e.g., addition of project or company logos or compliance with corporate designs). The face to the thematic expert as one of the user roles is the Web browser, hence, no installation on the user site is necessary. Furthermore, due to WebGenesis ® as underlying framework, the layout of the Web-based application may be tailored to the corporate or project design constraints. Furthermore, user management and collaboration utilities between users (e.g. calendar functions, etc) are already available, and may be easily integrated in order to support the analysis process within and across organizational boundaries. On the other side of the user role spectrum there is the system architect whose objective is to formalize the requirements as UML use case diagrams (e.g. using a UML tool such as the Enterprise Architect) and map the use case scenarios to call sequences of interfaces and services, possibly also specified in UML. The system analyst has to mediate between both communities: On the one hand, he/she shall facilitate the requirements analysis process within the community of the thematic experts aiming at getting consolidated semi-structured use case models. On the other hand, he/she shall guarantee the consistency with the UML models required for the system design activities led by the system architect. For this purpose the SERVUS use case server provides a mediator tool that, among others, extracts UML use case diagrams from the Enterprise Architect and feeds them as associated figures into the use case models.
The European Commission (EC) launched the Future Internet Public-Private Partnership programme (FI-PPP) with the idea of enabling a broad range of Internet applications, including those of the environmental knowledge domain. The FI-PPP programme shall advance a shared vision for common pan-European technology platforms and their implementation, as well as the integration and harmonization of the relevant policy, legal, and regulatory frameworks.
As illustrated in Fig. 3 the FI-WARE platform is an ICT platform based on generic functional building blocks: the so-called Generic Enablers (GE). These are used by the usage area projects in order to validate and demonstrate the new generation FI enabled environmental applications. ENVIROFI represents the environmental usage area within phase 1 of FI-PPP (see http://www.envirofi.eu/). It explores the so-called environmental enablers, i.e. reusable building blocks for collecting and processing environmental data, and provides environmental sector requirements to FI-WARE [7]. Thus, ENVIROFI lays the foundation for an FI-enabled Environmental Observation Web, which will help Europe to tackle the grand challenges of climate change, socio-economic pressures on the environment and sustainable development.
ENVIROFI's vision is to establish an Environmental Observation Web in which all environmental data from sensors, citizens and models become available through the Internet in a standardized and usable format [13]. ENVIROFI specifically works on three environmental application areas: biodiversity, personalized atmospheric data and marine assets.
The setting of the FI-PPP encompassing both usage area projects collecting requirements and a core platform project providing a capability platform under development requires a sophisticated and transparent analysis and design process. The ENVIROFI project has selected the SERVUS methodology including its tool support. The SERVUS use case meta-model has been interpreted such that the entry category of "requirements" represents requirements for FI-PPP generic or specific enablers, hence, generic functions to be integrated as reusable components into the platform with a welldefined, if possible, standard interface [3].
Fig. 4 shows a screenshot of the use case server as it was applied and configured in the ENVIROFI project. It illustrates on the left side a list of requirements for specific enablers and in the middle the list of those use case entries from which a selected requirement was derived. These links are realized as bijective hyperlinks in the use case server, hence, the user can browse through the entries in both directions and therefore get full transparency.
In addition to European research projects such as ENVIROFI, the SERVUS methodology and its use case server is used in the following environmental projects in Germany: WIBAS 5.0 -Architectural Re-Engineering of the Integrated Environmental Information System WIBAS [11]. In this project, user requirements for a functional upgrade in the context of a new virtually centralized system architecture in the German Federal State of Baden-Württemberg have to be collected among several dozens of multi-disciplinary experts of regional environmental authorities. FLIWAS 3.0: Requirements analysis of the German-Dutch Flood Information and Warning System along the Rhine river basin. FLIWAS is a Web-based flood information and warning system for local and regional decision support [12]. Originally developed and installed as a central database application for the German Federal State of Baden-Württemberg it will now undergo an essential architectural and functional upgrade along the Rhine river basin encompassing other German federal states and cities (e.g. the city of Cologne) as well as water authorities in the Netherlands.
For this new analysis process, the SERVUS methodology is used. Hence, one of the utmost new functions in the SERVUS use case server will be a multi-lingual support of the use case edition and documentation process.
All these example projects demonstrate that an agile requirements analysis methodology urgently needs a powerful software tool to support its edition and documentation. However, beyond technical tool support, there is also a confirmation that requirements analysis is a social process and needs didactical and facilitation skills, especially for the system analyst as the "man or the woman in the middle". Further developments will focus on investigations how to enrich the SERVUS use case server to better support such group facilitation techniques.