1
Project Reference No. 287119
Deliverable No. D 4.5
Relevant workpackage: WP 4
Nature: Report
Dissemination Level: Public
Document version: Final
Editor(s): Egils Ginters, Artis Aizstrauts, Maija Ablazevica
Contributors: Egils Ginters, Artis Aizstrauts, Girts Dreija, Maija Ablazevica, Sergey Stepucev, Inita Sakne, Mikelis Baltruks, Miquel Angel Piera Eroles, Roman Buil, Marjan Gusev, Goran Velkoski
Document description: The purpose of the deliverable is to describe the software requirements and software design for Skopje Mountain Recreation Activities planning simulator software prototype based on agent-based simulation model designed in RePast and Java environment. The simulator is aimed to recreational resources
occupancy analysis simulation. The beneficiaries of the deliverable will be Skopje municipality associates involved in activities and tourism objects planning. The Vodno Mountain Recreational Activities simulator software prototype will be maintained, modified and developed by the end of FUPOL project.
Intelligent Tools for Policy Design
Deliverable 4.5 – FUPOL Simulator Software
prototype (Vodno Mountain Recreation
2
History
Version Date Reason Prepared / Revised by
0.1 23-09-2013 Initial version. Concept. Discussion of user requirements in Skopje Municipality.
Egils Ginters, Artis Aizstrauts, Marjan Gusev, Mikelis Baltruks, Lovren Markic
0.2 07-10-2013 Occupancy analysis simulation model in RePast environment.
Miquel Angel Piera Eroles, Roman Buil, Artis Aizstrauts 1.0 07-10-2013 Vodno Mountain Simulator software
requirements specification by City of Skopje.
Marjan Gusev, Goran Velkoski
2.0 12-11-2013 Occupancy simulation model changes Miquel Angel Piera Eroles, Roman Buil, Artis Aizstrauts 3.0 15-11-2013 Software Designing Document Artis Aizstrauts, Egils
Ginters, Maija Ablazevica, Mikelis Baltruks
5.0 22-12-2014 Simulator software GUI validation. Artis Aizstrauts, Egils Ginters, Mikelis Baltruks, Marjan Gusev, Lovren Markic, Ana Guseva, Biljana Veselinovska
7.0 31-01-2014 Finalization Egils Ginters, Artis
Aizstrauts, Maija Ablazevica, Mikelis Baltruks
3 Table of Content
1 LIST OF ABBREVIATIONS ... 12
2 INTRODUCTION ... 14
2.1 Purpose of the Document ... 14
2.2 Target group ... 15
2.3 Benefits ... 15
2.4 Structure of the document ... 16
3 FUPOL VODNO MOUNTAIN SIMULATOR SOFTWARE PROTOTYPE REQUIREMENTS SPECIFICATION ... 16
3.1 Preface ... 16
3.1.1 Purpose ... 16
3.1.2 Scope of coverage ... 16
3.1.3 Abbreviations ... 17
3.1.4 Association with other documents ... 17
3.1.5 Document overview ... 17
3.1.6 Conventions ... 17
3.2 General description ... 18
3.2.1 Current situation ... 18
3.2.2 Beneficiaries requirements to Vodno Mountain simulator software prototype ... 18
3.2.2.1 Document Overview and Functionalities ... 18
3.2.2.2 Users and functional description ... 19
3.2.2.3 Basic functionalities ... 22
3.2.2.4 Basic visualization functionalities ... 25
3.2.2.5 User interface description ... 26
3.2.2.6 Simulation Configuration ... 32
4
3.2.2.8 Simulation ... 35
3.2.2.9 Visualization user interface ... 36
3.2.2.10 Simulation reporting ... 37 3.2.2.11 Ticketing system ... 39 3.2.3 Product outlook ... 41 3.2.4 Legal regulation ... 41 3.2.5 Technical limitations ... 41 3.2.6 Performance requirements ... 42 3.2.7 User characteristics ... 42 3.2.8 General description ... 42
3.3 Functional requirements: Vodno Mountain Activities simulator prototype software ... 43
3.3.1 Summary of functional requirements ... 43
3.3.2 Description of functional requirements ... 44
3.3.2.1 User authorization ... 44
3.3.2.2 User list ... 46
3.3.2.3 New user ... 47
3.3.2.4 Show user... 49
3.3.2.5 Edit user ... 50
3.3.2.6 User role list... 52
3.3.2.7 New user role... 53
3.3.2.8 Show user role ... 54
3.3.2.9 Edit user role ... 55
3.3.2.10 Simulation setting list ... 56
3.3.2.11 New simulation settings ... 58
3.3.2.12 Show simulation settings ... 59
3.3.2.13 Edit simulation settings ... 61
3.3.2.14 Simulation list (Simulation 1 and simulation 2) ... 62
3.3.2.15 Create new simulation ... 63
3.3.2.16 Simulation ticket list ... 64
3.3.2.17 Show simulation ticket ... 68
3.3.2.18 Edit simulation ticket ... 70
3.3.2.19 Ticket topic list ... 72
3.3.2.20 New ticket topic ... 72
5
3.3.2.22 Edit ticket topic ... 75
3.3.2.23 View simulation result ... 76
3.3.2.24 Object detailed information ... 82
3.3.2.25 Citizens activities ... 86
3.3.2.26 New simulation ... 87
3.4 Non-functional requirements ... 90
3.4.1 Summary of non-functional requirements ... 90
3.4.2 Performance requirements ... 91
3.4.2.1 Number of users ... 91
3.4.2.2 User interface performance ... 91
3.4.2.3 System accessibility ... 91
3.4.2.4 Allowable time of system inaccessibility ... 91
3.4.2.5 Data download ... 91
3.4.3 Security requirements ... 92
3.4.4 Maintenance requirements ... 93
3.4.4.1 Expandability of functionality... 93
3.4.4.2 Data integrity ... 93
3.5 Functional requirements traceability table ... 93
4 FUPOL VODNO MOUNTAIN RECREATIONAL ACTIVITIES SIMULATOR SOFTWARE PROTOTYPE DESIGN DOCUMENT ... 95
4.1 Preface ... 95
4.1.1 Purpose ... 95
4.1.2 Scope of coverage ... 95
4.1.3 Definitions, acronyms, and abbreviations ... 95
4.2 Decomposition Description ... 96 4.2.1 Module decomposition ... 96 4.2.1.1 Authorization ... 97 4.2.1.2 Login ... 97 4.2.1.3 Home ... 98 4.2.1.4 User list ... 98 4.2.1.5 Create user ... 98 4.2.1.6 Show user... 98 4.2.1.7 Edit user ... 99
6
4.2.1.8 Delete user ... 99
4.2.1.9 User role list... 99
4.2.1.10 Create user role ... 99
4.2.1.11 Show user role ... 100
4.2.1.12 Edit user role ... 100
4.2.1.13 Delete user role ... 100
4.2.1.14 Ticket topic list ... 100
4.2.1.15 Create ticket topic ... 101
4.2.1.16 Show ticket topic ... 101
4.2.1.17 Edit ticket topic ... 101
4.2.1.18 Delete ticket topic ... 101
4.2.1.19 Ticket list ... 101
4.2.1.20 Show ticket ... 102
4.2.1.21 Edit ticket ... 102
4.2.1.22 Delete ticket ... 102
4.2.1.23 Submit replay ... 102
4.2.1.24 Simulation setting list ... 102
4.2.1.25 Create simulation settings ... 103
4.2.1.26 Show simulation settings ... 103
4.2.1.27 Edit simulation settings ... 103
4.2.1.28 Delete simulation settings ... 103
4.2.1.29 Simulation list 1 (simulation list 2) ... 103
4.2.1.30 Create simulation 1 (create simulation 2) ... 104
4.2.1.31 Show simulation 1 ( show simulation 2) ... 104
4.2.1.32 Edit simulation 1 (edit simulation 2) ... 104
4.2.1.33 Delete simulation 1 (delete simulation 2) ... 104
4.2.1.34 View simulation result ... 105
4.2.1.35 Map ... 105
4.2.1.36 Player ... 105
4.2.1.37 Average mountain occupancy ... 105
4.2.1.38 Visitors configuration ... 106
4.2.1.39 Ticket ... 106
4.2.1.40 Create ticket ... 106
4.2.1.41 Submit ticket ... 106
4.2.1.42 Object detailed information ... 106
4.2.1.43 Object parameters ... 107
7
4.2.1.45 Average occupancy per hours to today ... 107
4.2.1.46 Object occupancy per month ... 107
4.2.1.47 Visitors total ... 107
4.2.1.48 Visitor groups using this object ... 108
4.2.1.49 Citizens activities ... 108
4.2.1.50 Confirmation window ... 108
4.2.1.51 New simulation ... 108
4.2.1.52 New simulation map ... 108
4.2.1.53 New simulation parameters ... 109
4.2.1.54 New simulation visitor group size ... 109
4.2.1.55 Start simulation ... 109
4.2.1.56 PostgreSQL data base ... 109
4.2.1.57 Model ... 109
4.2.1.58 Logout ... 110
4.2.2 Decomposition of simultaneous processes ... 110
4.2.2.1 Description of the first process ... 110
4.2.2.2 Description of the second process ... 110
4.2.2.3 Description of the third process ... 110
4.2.2.4 Description of the fourth process ... 111
4.2.3 Data decomposition ... 111 4.3 Dependency Description ... 112 4.3.1 Intermodule dependencies ... 112 4.3.1.1 GUI – PostgreSQL DB ... 112 4.3.2 Interprocess dependencies ... 112 4.3.3 Data dependencies ... 112 4.4 Interface Description ... 112 4.4.1 Module interface ... 112 4.4.2 Process interface ... 125 4.4.2.1 Login ... 125 4.4.2.2 Edit ... 125 4.4.2.3 Delete ... 125 4.4.2.4 Start simulation ... 125 4.4.2.5 Send ticket ... 125 4.4.2.6 Create ... 125 4.4.2.7 Cancel ... 125
8
4.5 Detailed design ... 126
4.5.1 Module detailed design ... 126
4.5.1.1 Authorization ... 126 4.5.1.2 Home ... 127 4.5.1.3 User list ... 128 4.5.1.4 Show user... 129 4.5.1.5 Edit user ... 129 4.5.1.6 Update user ... 130 4.5.1.7 Delete user ... 131 4.5.1.8 Create user ... 132
4.5.1.9 User role list ... 132
4.5.1.10 Show user role ... 133
4.5.1.11 Edit user role ... 134
4.5.1.12 Update user role ... 135
4.5.1.13 Delete user role ... 136
4.5.1.14 Create user role ... 136
4.5.1.15 Ticket topic list ... 137
4.5.1.16 Show ticket topic ... 138
4.5.1.17 Edit ticket topic ... 139
4.5.1.18 Update ticket topic ... 139
4.5.1.19 Delete ticket topic ... 140
4.5.1.20 Create ticket topic ... 141
4.5.1.21 Ticket list ... 142 4.5.1.22 Show ticket ... 142 4.5.1.23 Edit ticket ... 143 4.5.1.24 Update ticket ... 144 4.5.1.25 Delete ticket ... 145 4.5.1.26 Submit replay ... 146
4.5.1.27 Simulation settings list ... 147
4.5.1.28 Show simulation settings ... 147
4.5.1.29 Edit simulation settings ... 148
4.5.1.30 Update simulation settings ... 149
4.5.1.31 Delete simulation setting ... 150
4.5.1.32 Create simulation settings ... 151
4.5.1.33 Create simulation 1 ... 152
9
4.5.1.35 View simulations results ... 154
4.5.1.36 Description ... 154
4.5.1.37 Map ... 155
4.5.1.38 Object list ... 155
4.5.1.39 Parameters ... 156
4.5.1.40 Average mountain occupancy ... 157
4.5.1.41 Ticket ... 157
4.5.1.42 Submit replay ... 158
4.5.1.43 Visitors configuration ... 159
4.5.1.44 Object detailed information ... 159
4.5.1.45 Object parameters ... 160
4.5.1.46 Visitor occupaing using this object ... 160
4.5.1.47 Average occupancy per hours to today ... 161
4.5.1.48 Object occupancy per month ... 161
4.5.1.49 Visitors total ... 162
4.5.1.50 Visitor groups using this object ... 162
4.5.1.51 Citizens activities ... 163
4.5.1.52 New simulations ... 163
4.5.1.53 New simulation map ... 164
4.5.1.54 New simulation parameters ... 164
4.5.1.55 New simulation visitors group size ... 165
4.5.1.56 Start simulation ... 166
4.5.1.57 Model ... 167
4.5.2 Data detailed design ... 168
5 VODNO MOUNTAIN SIMULATOR SOFTWARE PROTOTYPE VERIFICATION AND VALIDATION ... 181
5.1 Changes management ... 181
5.2 Verification plan ... 181
5.3 Vodno Mountain Simulator Software protype validation ... 183
5.3.1 Validation plan ... 183
5.3.2 Performance validation ... 184
5.3.3 Vodno Mountain Simulator Software protype 1.0 expert validation ... 187
5.3.3.1 Document Overview and Functionalities ... 187
10
5.3.3.3 Basic functionalities ... 191
5.3.3.4 Basic visualisation functionalities ... 194
5.3.3.5 Modifications to the user interface description ... 196
5.3.3.6 Simulation Configuration ... 204
6 USER MANUAL: VODNO MOUNTAIN SIMULATOR SOFTWARE PROTOTYPE ... 205 6.1 General description ... 205 6.1.1 Preliminary information ... 205 6.1.2 Configuration ... 206 6.1.2.1 User data ... 206 6.1.2.2 Resources list ... 207 6.1.2.3 Activities list ... 207 6.1.2.4 Weather conditions ... 208
6.2 Users and roles ... 208
6.2.1 Administrator ... 208
6.2.2 Manager ... 209
6.2.3 Master ... 209
6.3 Tickets ... 209
6.4 Unautorized user options ... 210
6.4.1 New simulation ... 210
6.4.2 Time control ... 211
6.4.3 Results on map ... 211
6.4.4 Detailed information ... 212
6.4.5 Tickets ... 213
6.4.6 Overall simulation data ... 214
6.5 Registered user options ... 215
6.5.1 Administrator ... 216
6.5.1.1 Add new user ... 216
6.5.1.2 Manage existing user ... 217
6.5.2 Manager ... 217
6.5.2.1 Simulation tickets ... 217
11
6.5.3.1 Simulation ... 219
6.5.3.2 New Simulation ... 220
6.5.3.3 Simulation settings ... 221
6.5.3.4 Simulation tickets ... 223
6.5.3.5 Simulation ticket topics ... 223
7 CONCLUSIONS ... 224
12
1
List of Abbreviations
ABM Agent-based modelling
API Application programming interface BMP Bitmap image file
CPN Coloured Petri Networks
CSV File extension: Comma-separated values DEVS Discrete event systems
ECE Easy Communication Environment ESB Enterprise service bus
FCM Fuzzy cognitive maps
FP7 The Seventh Framework Programme for Research and Technological Development.
FUPOL Future policy modeling. Research project for developing advanced information and communication technology tools to support policy design and implementation. FUPOL aims at a completely new approach to traditional politics.
GIF Graphics Interchange Format GIS Geographic Information System GUI Graphical user interface
HTTP Hypertext Transfer Protocol Secure JAR Java archive file format
JAVA Programming language
JPG/JPEG Joint Photographic Experts Group (image file format) LUCC Land use and cover change
MAS Multi Agent System
OSM OpenStreetMap (a collaborative project to create a free editable map of the world)
13 PDF Portable Document Format
PNG Portable Network Graphics (a bitmap image file format) PostgreSQL Open-source object relational database management system Python Programming language
SD Systems dynamic simulation SDD Software design document SDMX Statistical data format
SRS Software Requirements Specification SVG Scalable Vector Graphics
TIFF Tagged Image File Format
WFS Web Feature Service (vector format) WMS Web Map Service (raster format)
XML Extensible Markup Language (markup language that defines a set of rules for encoding documents)
14
2
Introduction
2.1
Purpose of the Document
The purpose of the deliverable is to describe the software prototype requirements and software prototype design for Vodno Mountain Activities simulator (http://dev.fupol.lv:8080/skopje) and (http://dev.fupol.lv:8080/skopje/city) based on agent-based simulation model designed in RePast and Java environment (see Figure 2.1). The simulator is aimed to activities planning through potential occupancy analysis on the routes.
Figure 2.1: Vodno Mountain Simulator architecture
The occupancy analysis simulation model is based on statistical data (typical visitor and groups characteristics, capacity of resources, time of arrival, list of desirable activities and probability of their choice), profile distribution on weekdays, as well as wethear conditions. There are two types of simulation authorization: public or administrative access. Simulation allows creating a rough distribution of resources use as described in D2.8. It is possible to ascertain the number of visitors in each resource in the simulated time slot: hour, day, week and/or year.
15 Interoperability of WP4 and other FUPOL workpackages related with FUPOL Vodno Mountain simulator software prototype software designing and running was described in D3.1 and D4.2. Vodno Mountain simulator software prototype is implemented as OSS tool.
Deliverables of WP2 (D2.8 and other) are one of main sources of Vodno Mountain simulator software prototype requirements. However many additional requirements were added after WP2, WP4 and WP7 meeting with Skopje municipality representatives. Vodno Mountain simulator software prototype GUI validation has been done by Skopje municipality representatives on 22 December 2013. Maintenance of simulator software (modification, verification and validation) will be continued by the end of FUPOL project.
2.2
Target group
The current deliverable is provided for public use and especially for Skopje municipality representatives. The audience of deliverable are software engineers and systems analysts working in work packages: WP2 Policy Analysis and Modelling, WP3 Open Core platform, WP5 Advanced Visualisation and WP7 Large Scale Demonstrators. However the deliverable and approaches demonstrated for policy simulators designing would be useful for other developers and municipalities, because approach is unified and would be the same for designing of other recreational areas.
2.3
Benefits
This deliverable contributes to designing of policy decision making simulators useable for recreational activities resources planning. The deliverable facilitates integration and collaboration with ESB (WP3), pilots and municipalities (WP7) and simulation models designers (WP2). The document is the software prototype version of FUPOL Vodno Mountain simulator.
16
2.4
Structure of the document
The document consists of following parts. The first part is Vodno Mountain simulator software prototype requirements specification, but the second part is FUPOL Vodno Mountain simulator software prototype designing document. The deliverable is designed in conformity with IEEE software engineering standards (IEEE 830:1998, IEEE 1016:1998) as joined software requirements specification and software designing document. Verification and validation plans are described. User manual of simulator is added as part of deliverable. Deliverable D4.5 corresponds to prototype version of FUPOL Vodno Mountain simulator software, which will be maintained by the end of FUPOL project.
3
FUPOL Vodno Mountain simulator software prototype
requirements specification
3.1
Preface
3.1.1 Purpose
The purpose of this document is to summarize the requirements for developing a FUPOL Vodno Mountain simulator software prototype, which can simulate possible occupancy of recreational resources on Vodno Mountain area. The basis for the functional requirements and simulation model algorithm are beneficiaries’ requirements and D2.8.
The document is intended for software developers ans system analysts, however can be used also for municipality other associates involved in Vodno Mountain activities planning and management.
3.1.2 Scope of coverage
The developed Vodno Mountain simulator software prototype operates in the Internet environment. It is accessible to all FUPOL Core Platform customers and other predescribed users.
17
3.1.3 Abbreviations
Term Explanation
GeoServer GeoServer is a Java-based software server that allows users to view and edit geospatial data. Using open standards set forth by the Open
Geospatial Consortium (OGC), GeoServer allows for great flexibility in map creation and data sharing.
PostgreSQL Open-source relational database management system.
Others see on the main document „List of Abbreviations“.
3.1.4 Association with other documents
See “References”.
3.1.5 Document overview
The “Preface” section provides general information about the purpose of the document, scope of coverage, association with other documents and an overview of the document itself.
The “General description” section provides information about the current situation, product outlook, technical limitations and user characteristics.
The “Functional requirements” section describes all necessary functional requirements.
The “Non-functional requirements” section provides information about all non-functional requirements: performance, maintenance.
3.1.6 Conventions
Requirements listed in this document are constructed according to the following structure:
Requirement ID SRS-XXX-000
Requirement title Title of XXX-000 requirement Description
18 Call requirement
3.2
General description
3.2.1 Current situationThe current situation analysis was obtained by analysing the documents mentioned in “References” (especially D2.8 and D4.2) and from meetings with Skopje municipality associates.
However to discuss detailed beneficiaries requirements to Vodno Mountain simulator software prototype the meeting organized by WP2, WP4 and WP7 which was held in Skopje on 23nd September 2013.
3.2.2 Beneficiaries requirements to Vodno Mountain simulator software
prototype
Requirements were precised in meeting organized by WP2, WP4 and WP7 which was held in Skopje on 23nd September 2013 and involves more or less all the possible features that would be covered by Vodno Mountain simulator software prototype by the end of FUPOL project.
3.2.2.1 Document Overview and Functionalities 3.2.2.1.1 Document Purpose
This document specifies the user interface requirements of the Simulation of Vodno Mountain recreation Activities, as part of the FUPOL FP7 project for City of Skopje. These requirements are assembled to summarize previous work and conclusions of the meeting held in Skopje on 09/23/2013 where details were elaborated, discussed and defined more precisely.
19 The main objective of this project is the development of a software solution that will offer the City of Skopje a possibility to realize a better schedule of resources and plan of activities on Vodno Mountain. To its citizens it will offer the opportunity to simulate the occupancy of the recreational resources on Vodno Mountain and suggest new schedule, new ideas to the administration of City of Skopje. The system would help the Administration of City of Skopje in improving the scheduling and resource planning, initiation and creating new projects involving the recreational area at Vodno Mountain. The citizens of City of Skopje will also be involved in the decision making process by constant communication and expressing their opinion to the authorities, making the whole process more transparent and efficient.
3.2.2.2 Users and functional description 3.2.2.2.1 Simulation types
The purpose of the Simulation is to simulate resource occupancy and generate conflict reports for a given period of recreation activities on Vodno Mountain.
Two simulations are proposed in the system:
Simulation 1 – visualizing a one year period, intended for master users, where all weather conditions will be simulated based on typical behavior; and
Simulation 2 – visualizing a one week behavior in a selected month with selected weather, intended for both master users and citizens.
3.2.2.2.2 User roles
The users in the system are:
Administrator – creating and managing users.
Master User – setup (using import) of initial simulator configuration, change configuration, export configuration, and realize both simulation 1 and 2. Manager – can list ticket reports, view and answer tickets sent by users,
suggest new configuration and projects that will improve the recreation on Vodno Mountain.
Public user – can access the visual simulation interface for simulation 2. 3.2.2.2.3 Overall functional description
20 Figure 3.1: Core functionalities.
Additionally, the user roles and their functions are specified as in Table 3.1.
Table 3.1: User roles.
User Role Description Responsibilities
Administrator Responsible for user creation
and user management. Create User, Remove User.
Manager
Manager can oversee simulations and suggest simulations and projects.
Suggest Simulation, Simulation Reporting, Ticket Answering, Ticket Reporting.
Master User
Master user can manage simulation configurations, and run Simulation 1.
Import Simulation Configuration, Change Simulation 1 / 2
Configuration, Export Simulation Configuration, Simulation 1,
Simulation 2, Simulation Reporting, Ticket Answering.
Citizen Public user role for all citizens of City of Skopje.
Simulation 2, Change Simulation 2 Configuration, Ticket Sending, Ticket
21
User Role Description Responsibilities
Tracking.
A typical scenario of the system’s usage is presented next. The administrator creates master user and manager for the City of Skopje.
The created master user logs in to the system in order to activate the simulation by uploading configuration files for both simulations.
The master user is able to start the one-year simulation (Simulation 1). It is assumed that the initial configuration is edited and stored in excel format (.xls/.xlsx) and then it is uploaded using an uploading form (import simulation configuration) on the interface. After the initial configuration is uploaded the master user is able to click on the “Start Simulation” button. The output of the simulation should contain the occupancy of each resource specified in the initial configuration.
The master user can create, edit and change the parameters for one-week simulation (Simulation 2), using the map of the Vodno Mountain recreational center in a specified excel format (.xls/.xlsx). The configuration file can be uploaded using an uploading form.
Both the master user and citizens can start the Simulation 2. They can change the parameters explained later in this document through a web interface i.e. by clicking on the map, selecting the month for the simulation and choosing the weather conditions. The simulation is started by click on the “Simulate” button. The output of simulation 2 is the occupancy of the resources available on the Vodno Mountain recreational center based on the user input.
For both simulations the input is sent to the simulation service. The output of the service (resource occupancy) is displayed on a map of the Vodno Mountain recreational center for easier user interaction.
The master user can also choose to export or import a specific system configuration. The export configuration button must create an excel table that can be later used for importing the configuration. Changing the configuration of the system can be done directly through the configuration files (excel tables) by changing and adding rows in
22 the table or through a web interface where the same parameters can be changed (the parameters are discussed later in this document).
Citizens are anonymous users in the system. They can start the simulation and define their own parameters for simulation. If they would like to share their experience with the city of Skopje, or suggest a change in recreational schedule, propose to add a resource, or an activity, they can use the ticketing system i.e. create tickets with suggested schedules and/or send complains.
The manager of the system works with the ticketing system, with goal to receive all the user tickets and answer them. Reports of the ticketing system usage can be created and available to relevant users. The manager can suggest a configuration that is propagated to the master users for review.
All of the users of the system can review the simulation reports that are created from the simulation 1. Additionally the private configurations made using the simulation 2 can only be reviewed by the user that created the specific simulation. If the simulation configuration is sent than the simulation report for that configuration can be reviewed by managers and master users too.
3.2.2.3 Basic functionalities
Basic functionalities of the Vodno Mountain - FUPOL project are specified as in Table 3.2.
Table 3.2: Main functionalities.
Functionality Users Description Objective
User
administration Administrator
Create and remove users for the simulation system.
Input / remove master users in the system.
Simulation setup
import Master user
Main parameters for simulation will be defined by a specific excel table (.xls/.xlsx) and uploaded in the system.
Upload initial settings for the simulation system.
23
Functionality Users Description Objective
change the configuration is
proposed by the
administration of City of Skopje, the parameters and new settings for the simulation system will be uploaded.
configuration setup of the system.
Simulation setup
export Master user
The present simulation setup saving in a specific excel table (.xls/.xlsx) that can be later used for Simulation setup upload.
Export of the current simulation setup.
Simulate 1 Master user
Start simulation based on the setup configuration for one year period, all weather conditions will be simulated based on
typical behavior.
Create visual output in order to evaluate the resource occupation for period of 1 year.
Simulate 2 Master user, Citizen
Start simulation based on the setup configuration for one week behavior in a selected month with user selected weather.
Create visual output in order to evaluate the resource occupation for period of 1 week in the selected month.
Visualize simulation
Master user, citizen
Visual representation of the resource occupation (produced by the
simulation) on time temporal map.
Visual display of the resource occupation in different time.
24
Functionality Users Description Objective
interaction citizen simulation using its visual representation (change date & time, weather, occupancy numbers for user groups and
activities). using user experiences or proposing a new schedule. Simulation reporting Manager, master user, citizen Reporting on average resource utilization and number of conflicts produced by simulation.
Overview the simulation results.
Ticket sending &
tracking Citizen
User communication with the authorities of City of Skopje for user
suggestions.
Use ticketing system for better user communication and ticket status tracking. List tickets,
Ticket answering
Master user, manager
Method of communication for the authorities
through ticketing system.
Use ticketing system in order to answer the tickets sent by users.
Suggest new configuration and projects Manager Suggesting new simulation configurations and projects for the Vodno Mountain recreational region.
Provide a way for managers to suggest new simulation configurations and projects.
Ticket reporting Manager
Reporting about the ticketing service’s work. Reporting about number of sent, viewed and answered tickets.
Provide transparent review about the work of City of Skopje and it’s communication with the citizens
25 3.2.2.4 Basic visualization functionalities
The Visualization part of the simulation software is intended to realize a visual representation of the generated data within the simulation for the recreational center at Vodno Mountain. All data must be setup on a map of the region with clearly distinguishable resources and their locations.
Basic visualization functionalities of the project are specified as in Table 3.3.
Table 3.3: Basic visualization functionalities.
Functionality Users Description Objective
Map navigation Master user, citizen
Map navigation and zoom in and out on the visually represented resource occupation.
User friendly map navigation for users.
Resource placement
Master user, citizen
Visual representation of the resources placed on the map with icons and/or tracks.
Easy identification of resources on the map.
Resource selection
Master user, citizen
Resource selection is done by clicking on the resource icons and/or tracks
represented on the tracks. This action lists the user groups occupying this resource.
Easy resource
selection and resource occupying user group identification.
Activity placement
Master user, citizen
Visual representation of the activities by icons that
clearly indicate each activity. Adding more icons near a resource should indicate increased activity on
Easy identification of the activities on the map.
26
Functionality Users Description Objective
selected resource.
Activity selection Master user, citizen
Activity selection is done by clicking on the activity icons. This action lists the user groups participation in the selected activity
Easy activity selection and easy identification of the participating user groups. User group listing Master user, citizen
Visual listing of the user groups in a grid view after resource or activity
selection.
User friendly user group identification.
User group selection
Master user, citizen
User group selection is done by clicking on a specific row in the grid view. This action opens up the opportunity for changing the number of people in the selected user group.
Easy parameter change for user groups. Simulation visualization Master user, citizen Resource utilization description by using a pie chart near resources. Blinking circle means resource conflicts.
Easy tracking of the simulation results on the map. Simulation time parameter changing Master user, citizen
Time change on the map for simulation representation analysis in variable hour and day steps.
Tracking changes on the resource map when the time is changed.
3.2.2.5 User interface description 3.2.2.5.1 Main interface
27 The main system interface of the system will be drafted in this section. The draft design will target the most essential parts of the system such as: simulation 1 and 2, ticketing system, reporting etc.
3.2.2.5.2 Simulation
The draft design of the simulations is presented in this section. Figure 3.2 presents the Simulation 1 interface. There are 4 icons on the menu representing “new”, “open”, “save” and “ticket” and one slider for time change during a day. The blank container is where the map should be placed. The same structure is setup for the user interface of Simulation 2 (see Figure 3.3).
The functionalities of the buttons are described in Table 3.4.
28 Figure 3.3: Simulation 2 user interface.
The buttons and the actions they invoke are specified as in Table 3.4.
Table 3.4: Description of button functionalities.
Button Description
New
Cleans all data from the current simulation configuration. The original simulation configuration (Simulation 1 configuration) is loaded again.
Open Imports simulation configuration from uploaded excel table (.xls/.xlsx).
Save Exports the currently setup simulation configuration in an excel table (.xls/.xlsx).
Ticket Redirects the user to the ticket creation part of the application. Simulate Starts simulation 1 with the imported simulation configuration or
29
Button Description
Calendar Control Used to select date for simulation results display on the map. Select Month Dropdown for mouth selection for Simulation 2.
Select Weather Dropdown for weather selection. Possible values: Bright, Sunny, Cloudy, Rainy, Snowy, Storm.
Change Parameters
Opens up the view for changing the parameters for simulation 2. List of all activities (Figure 3.4: List of Activities.) from where users can access user groups attending each activity and change number of people in a user group.
View Report Redirects the user to report generated from the simulation.
Suggest Redirects the user to the ticket creation interface. The user who started a simulation and saved configuration files creates a ticket. 3.2.2.5.3 Activities and User Groups Window
The activities and user groups window is listing the user activities and user groups based on the resource selected on the map. These views are shown on Figure 3.4 and Figure 3.5 accordingly.
30 Figure 3.5: User groups for selected activity.
The List of activities is a simple grid view representation of the activities available on the Vodno Mountain recreational center. The user is redirected to the user groups participating in the activity by clicking on the row in this grid view. Changing next and previous page of activities is also available using the arrows bellow the grid view. The user groups’ list presented on Figure 3.5 allows the user to change parameters regarding the number of users in a specific user group and save that configuration for simulation. In the grid view there is a control for easy changing the number of people in a user group. The save button in this view redirects the user to the Simulation 2 interface where all the changed data can be used for the simulation. 3.2.2.5.4 Suggestion (Ticket) window
The ticket creation is done using the Create Ticket view (see Figure 3.6). The functionality of each part of this view is presented in Table 3.5.
31 Figure 3.6: Create and send ticket.
Table 3.5: Description of button functionalities for ticketing system.
Button Description
Ticket ID Auto generated ticket ID. The user will use this ID to check the status of the ticket.
Topic Dropdown list of predefined topics. There is a topic for each resource.
Title Title of the message that the user sends. Message The body of the message that the user sends. Attached
Configuration
Simulation configuration attachment. This attachment is only available through suggesting.
Send Ticket Button that sends the ticket.
Cancel Button to discard the ticket and redirect the user to the previous page
The user can track the status of the ticket using the interface presented on Figure 3.7. He inputs the ticket ID and can see the status indicator (icon representing the status of the ticket).
32 Figure 3.7: Ticket tracking.
The tickets are listed as presented on Figure 3.8. This view is available for master users and managers. They can from here filter and order the tickets. They can answer them by clicking on the action button in the action column of the grid view. Additionally the Generate Report button creates report for the ticketing system.
Figure 3.8: List of tickets. 3.2.2.6 Simulation Configuration
This is the part where the Master Users can load initial configuration for the simulator or change configuration for the simulator.
33 The simulation configuration web interface should include the basic configuration interface (map visualization). Additionally, options for configuration import and export should be available. A Button that redirects the user towards a web interface for simulation configuration changing should also be available. After the configuration is finished, an import button for starting the simulation should also be available.
3.2.2.7 Simulation configuration import / export
The system must provide an import and export functionality for the simulation configurations. The imported and exported file must be an excel table (.xls/.xlsx) with the required (by simulation) fields. These functionalities are available for both master users and citizens for both simulation 1 and simulation 2. Importing configuration is done using the “Open File” button (see Figure 3.2 and Figure 3.3). The user is then asked to browse file for upload and then upload it. Exporting configuration is done using the “Save” button (see Figure 3.2 and Figure 3.3). This action simply downloads the current simulation configuration.
3.2.2.7.1 Load initial simulation configuration
The initial configuration of the system must be configured by uploading excel table (.xls/.xlsx) with the required (by the simulation) fields i.e. importing the initial configuration.
3.2.2.7.2 Change simulation configuration
The setup for new or changed configuration can be done by using an excel table import form (.xls/.xlsx) with the fields that are required by the simulation itself. Additionally, the system must provide a web interface with tabs and data grid views (see Figure 3.4) where the Master Users can change the simulation configuration. In both scenarios, the user groups defined in the excel table should NOT be static i.e. in the new configurations the Master Users must be able to add new user groups. Additionally, the parameters for the user groups should NOT be static.
34 The parameters that the simulation uses are specified as in Table 3.6.
Table 3.6: Parameters used in the simulation.
Parameter Description
User Group
The user group that will use the resources on Vodno Mountain recreational center (example: Regular Hikers, Weekenders, Weekend family, Weekend sportists, etc.)
Activities The activities that will be used for simulation in the system (example: extreme biking, skiing, motor biking, picnic, etc.) Activities
incompatibility
Incompatibility matrix for activities. The matrix contains 0 or 1 for all activities when compared with each other (0 for
incompatible, 1 for compatible activities)
Resources Resources available at the Mountain Vodno recreational center with description and list of activities that use each resource. Persons The number of persons in a user group.
Group Size The exact value of people in user group, or number of the minimum and maximum number of people in the user group. Age Minimum and maximum age of people in the user group. Preference To indicate the preference between different sequences of
activities of the same user group and the same day. Days of the week Days in the week when the user groups are active. Seasons – Month
Parameter
There can be a parameter (from 0 to 1) for each season or they can be specified for each month.
Weather
The parameters are from 0 to 1 and they are used to decide if the users go to the mountain or not. It multiplies the
percentage of day of the week together with the season month parameter. Six types of weather are defined: Bright, Sunny, Cloudy, Rainy, Snowy and Storm.
Sequence of Activities
Sequence of the activities that the user groups are expected to do.
35 3.2.2.8 Simulation
This is the section where the types of simulations are defined. There are two types of simulations called Simulation 1 and Simulation 2. The simulation is realized by using a simulation agent that simulates a typical behavior of a person from a given user group. The agent behavior depends on the type of the simulation, with a specific input and output parameters. The simulation input and output parameters will be discussed in the next subsections.
3.2.2.8.1 Simulation 1
The Simulation 1 is initiated by the Master Users. This simulation spans through the period of 1 year. Only hourly average data obtained by simulation are recorded and available for visualization. Simulation runs with random selection of input parameters within a defined range, such as, simulation of a weather condition, or agent behavior. Initial setup is loaded via an excel table.
The input of this simulation is a complete simulation configuration. All parameters are simulated according to their behavior and range of defined values.
3.2.2.8.2 Simulation 2
Both Master Users and Citizens can initiate the Simulation 2. This simulation spans through a period of 1 week within a selected month. Only hourly average values obtained by the simulation are available for visualization. The initial predefined setup and simulation results are loaded via an excel table.
Users can change several parameters, such as desired weather, month selection, or number of persons in a certain user group. After simulation, the result data is available for visualization and users can see the effects of the changes. Simulation runs on simulating the typical behavior of agents from all user groups.
The predefined input parameters for this type of simulation are: number of Persons, Group Size, Age, Personality, Acceptability, Preference, Days of the Week, Weather and Sequence of Activity. Users can select a month, select a weather, and change number of persons in a given user group.
36 3.2.2.9 Visualization user interface
This part defines the visual representation of the simulation results i.e. the resource occupancy. The interface is a map representation (see Figure 3.9) of the recreational center on Vodno Mountain. A pie chart is associated to each resource with information about occupancy. Activities are presented by corresponding icons.
Figure 3.9: Map representation. 3.2.2.9.1 Map description
The map should place each resource on its location. Furthermore, each resource will be shown on the map with a pie chart besides as follows:
Empty transparent pie if no simulation is executed;
Colored pie based on resource occupancy parameter produced by the simulation (red for occupied resources, green for available resources);
Blinking red circle if the capacity is overused (conflict).
Since each resource can be used for a certain activity, icons representing the actives (walking, hiking, cycling, etc.) must be also placed (see Figure 3.9). Depending on
37 the resource occupation, more or less icons should be placed to represent the activities on selected resources.
3.2.2.9.2 Map functionality
The users must be able to navigate through the map and zoom in or out. Additionally, for the simulation, a month must be chosen from a drop down list. The simulation will calculate the occupancy of the resources within a week.
On the map sliders for hours within a day (arrow right for next hour and arrow left for previous hour) and days within a week (+ for next day and – for previous day) must be available as presented in Figure 3.10. When these sliders are used the map should change the resource occupancy based on the simulation for used resources changes tracking. Button for showing only the occurred conflicts on the map must also be available.
Figure 3.10: Time slider example.
When a user clicks on a resource, a window with a list of the activities occupying this resource (see Figure 3.4) is opened.
When a user clicks on an activity icon on the map or on the activity in the grid view previously described, a window with a list of the user groups participating in this activity is opened (see Figure 3.5). Тhe user can list user id, user description, and number of persons in each user group and he can change the number of users in a given user group and start a new simulation.
3.2.2.10 Simulation reporting
The system must provide a simulation reporting web interface. Each generated simulation should produce a report about the average usage of each resource and the occurred conflicts. The simulation reporting interface will be used for displaying
38 the generated reports of the simulations. On the first view there should be a grid view of all simulations with general information such as:
Simulation unique identification number Simulation name
Simulation description Date and time of simulation Average resource utilization Number of generated conflicts
When a specific simulation from the grid view is selected the whole simulation output (visual representation) should be available.
The reports besides being available with a grid view (see Figure 3.11) they should be available as charts for the average occupancy for each resource (see Figure 3.12) and the conflicts generated (see Figure 3.13) with the specific simulation configuration.
Figure 3.11: Simulation Report.
39 Figure 3.13: List of conflicts.
3.2.2.11 Ticketing system
In this part we will define how users can use the ticketing system. The involved users in this case are Citizen, Master User and Manager.
3.2.2.11.1 Ticket
A Ticket is a message from a Citizen that will have unique identification number (ID) for tracking the status of the ticket, message topic, and message title, message body, and simulation configuration input/output attachment (not required). The status of the ticket can be:
Sent – the public user sent the ticket but the ticket is not viewed;
Viewed – the ticket sent by the public user is viewed by the ticket manager but no answer is provided;
Answered – the ticket sent by the public user is answered.
3.2.2.11.2 Ticket creation
The Citizens must be able to create and send tickets through a web interface where all the ticket fields will be manually written (in this case the simulation configuration attachment is not available field). Additionally, the user can create a ticket by using the visual representation of the simulation (the map) by clicking on a resource with conflict (this generates ticket that the user can review, edit and send), or by submitting the whole configuration of the simulation (both input and output of the simulation) with a single click on a button for schedule suggestion. The automatically
40 created ticket must be available for user review and editing (the attachment must NOT be editable) before submitting.
3.2.2.11.3 Schedule suggestions
User suggestions are also available using the ticketing system. A suggestion is a ticket that have simulation configuration (input and output) attached (see Figure 3.6). The suggestions may also contain information for new suggested resource, user group, or activity.
3.2.2.11.4 Ticket submit and tracking
After the user confirms that the message is complete, they must submit the ticket using the ticketing system. The ticketing system must return unique identification number of the ticket for ticket status tracking.
The ticket status tracking should be available by a web interface where the public users can see the status of their ticket and if a complete answer has been given. This is done by entering the ticket unique identification number.
3.2.2.11.5 Ticket prioritization and answering
The ticketing managers must be able to log in to the ticketing system and see tickets sorted by priority. The initial priority should be according to the most popular ticket topic. The system should also do ticket filtering by one or more of the filters in a grid view:
Date and time of ticket submission
Most popular ticket topic – the ticket topic with the greater number of ticket (initial)
Tickets with or without simulation configuration attached
Tickets with the smallest number of conflicts (for tickets with simulation configuration attached)
When a ticket is opened (by clicking on the ticket row) by the ticket manager the ticket status must immediately change to “viewed”. This action opens the complete ticket including all ticket fields including the simulation input and output if provided.
41 For the viewed tickets the ticket manager must be able to reply by writing a message and clicking on a reply button. When a ticket is replied the ticket status must change to “answered” and the reply must be saved for the public user to view it by using the ticketing web interface.
3.2.2.11.6 Ticket reporting
The users must also be provided a report about the number of tickets that are sent, viewed and answered through a public ticket-reporting interface.
3.2.3 Product outlook
This deliverable contributes to a policy simulators designing providing new approaches in recreational activities planning. The deliverable gives insight into the Vodno Mountain Activities simulator prototype software architecture and collaboration with other software services and FUPOL Core platform ESB Simulator API. The document is the base for further FUPOL Simulators software development. 3.2.4 Legal regulation
Not applicable, the FUPOL Consortium Agreement has been respected. 3.2.5 Technical limitations
Spatial data storage would require GeoServer (non obligatory) – a Java-based software server that allows users to view and edit geospatial data. To provide full system functionality, an Internet browser is necessary.
Statistical data storage requires PostgreSQL - open-source object relational database management system support.
Autentification requires access rights and collaboration with ESB (Enterprise Service Bus) (Mule), however stand alone versions of Vodno Mountain Activities simulator prototype software can be used.
42 The following Internet environment standards must be considered in the use of the software:
HyperText Markup Language 4.01 Specification - http://www.w3.org/TR/html401;
Hypertext Transfer Protocol 1.1 - http://www.w3.org/Protocols.
Simple Object Access Protocol (SOAP) specification - http://www.w3.org/TR/soap/.
Cascading Style Sheets, level 1 - http://www.w3.org/TR/CSS1.
3.2.6 Performance requirements
To ensure adequate performance, the storage of spatial (cartographical) information must be anticipated when planning the scenario of simulation, however till this requirement is no actual, because high resolution spatial data are not requested and main reason influencing simulation performance is visitors amount. Largest delays of response cannot exceed 60-180 sec.
3.2.7 User characteristics
The document is provided mostly for Skopje municipality associates, WP4 (simulator software designing), WP2 (simulation model software designing) and WP7 (beneficiaries of simulator). However Vodno Mountain Activities simulator prototype software designing praxis can be used for other FUPOL Consortium technical workpackages (WP3, WP5). The target group are software engineers and system analysts of FUPOL Policy modelling (WP2), FUPOL Simulator software designing (WP4) and FUPOL Core platform (WP3), and elaborators of FUPOL Visualisation tools (WP5), as well WP7 work package for further GUI and simulator useability assessment.
3.2.8 General description
The Vodno Mountain is located close to Skopje city. It is expected that inhabitants of Skopje and other visitors will visit the mountain recreational zones. Skopje municipality has statistical forecasts about the possible number of visitors on weekdays and weekends. A typical visitor set a number of profiles has been
43 provided by WP2 (D2.8). The set of activities have been determined to be implementable in Vodno Mountain resources.
For each profile has been appointed several most typical activities. These priority activities have been determined with a certain probability for each profile. The most likely time slot for visiting the mountain has been provided for each profile. Result levelling can be observed visually but in keeping with classic methods it can be assumed that a 95% credible result can be achieved if the number of simulation cycles is 30 or more. All activities are distributed over the resorces on the Vodno Mountain.
The use of the Vodno Mountain Activities simulator prototype software allows to answer the following questions:
• What is the current situation on the mountain resources?
• Are some potential conflicts or contacts related with incompatible activities predicted?
3.3
Functional requirements: Vodno Mountain Activities
simulator prototype software
3.3.1 Summary of functional requirements
Summary of functional requirements (see Table 3.7)
Table 3.7: Summary of functional requirements
Requirement ID Description Implementation
SRS-SVMRA-01 User authorization Mandatory
SRS-SVMRA-02 User list Mandatory
SRS-SVMRA-03 New user Mandatory
SRS-SVMRA-04 Show user Mandatory
SRS-SVMRA-05 Edit user Mandatory
SRS-SVMRA-06 User roles list Mandatory
44
SRS-SVMRA-08 Show user role Mandatory
SRS-SVMRA-09 Edit user role Mandatory
SRS-SVMRA-10 Simulation setting list Mandatory
SRS-SVMRA-11 New simulations settings Mandatory
SRS-SVMRA-12 Show simulation settings Mandatory
SRS-SVMRA-13 Edit simulation settings Mandatory
SRS-SVMRA-14 Simulation list (simulation 1 and simulation2) Mandatory
SRS-SVMRA-15 Create new simulation Mandatory
SRS-SVMRA-16 Simulation ticket list Mandatory
SRS-SVMRA-17 Show simulation ticket Mandatory
SRS-SVMRA-18 Edit simulation ticket Mandatory
SRS-SVMRA-19 Ticket topic list Mandatory
SRS-SVMRA-20 New ticket topic Mandatory
SRS-SVMRA-21 Show ticket topic Mandatory
SRS-SVMRA-22 Edit ticket topic Mandatory
SRS-SVMRA-23 View simulation result Mandatory
SRS-SVMRA-24 Object detailed information Mandatory
SRS-SVMRA-25 Citizens activities Mandatory
SRS-SVMRA-26 New simulation Mandatory
3.3.2 Description of functional requirements
3.3.2.1 User authorization Requirement ID SRS-SVMRA-01 Requirement title User authorization Description
Only registered users will be able to use this program. Therefore, before starting to work with the system, every user goes through the authorization process by entering a
45 username and password (see Figure 3.14).
The entered username and password is verified. If a user does not exist, the system shows a message: `Sorry, we were not able to find a user with that username and password`. If a user exists, the user continues work with the program.
The users in the system are:
Administrator – creating and managing users;
Master User – setup of initial simulator configuration, change configuration, export configuration, and realizeboth simulation 1 and 2;
Manager – can list ticket reports, view and answer tickets sent by users, suggest new configuration and projects that will improve the recreation on Vodno Mountain;
Public user – can access the visual simulation interface for simulation 2 (call requirement ` Citizens activities (SRS-SVMRA-25)`)
If a user registers as a system administrator, after successful authorization, calls the ` User list (SRS-SVMRA-02)`requirement. If a user registers as a master or manager, after successful authorization, calls the `Simulation list (Simulation 1 and simulation 2) (SRS-SVMRA-14)`requirement.
Figure 3.14: Username and password screen prototype.
Description of screen prototype elements (see Table 3.8):
46
Nr. Title Type Description
1 Username Input field Enter username. 2 Password Input field Enter user password.
3 Message Output field Message: `Sorry, we were not able to find a user with that username and password`.
4 Login Button 4.1 Always active.
4.2 Possible actions after button press: 4.2.1 Data quality check.
4.2.2 If data quality is consistent, the system calls the requirements, according to user role. If not, element `Message` shows an
appropriate notification. Call requirement SRS-SVMRA-02, SRS-SVMRA-14 Users All 3.3.2.2 User list Requirement ID SRS-SVMRA-02 Requirement title User list
Description
The requirement is called by `User authorization (SRS-SVMRA-01) ` after successfully authorization (as administrator).
All user created profiles must be displayed in a list. Each can be viewed, deleted or edited. The new user can be added by clicking on `new user`- calls the `New user 03) ` requirement. Clicking on `user roles`- calls the `User role list (SRS-SVMRA-06) ` requirement.
The user can use the system if `account expired`=false and `account locked`=false and `Enabled` =true and `Password expired `=false.
47 Figure 3.15: User list screen prototype.
Description of user list elements (see Table 3.9):
Table 3.9: User list elements
Nr. Title Type Description
5 Username Output field -link
Username. Call requirement `Show user (SRS-SVMRA-04)`.
6 Account expired
Output field Possible value: `V`. If element value=true, element is black, otherwise – grey.
7 Account locked Output field Possible value: `V`. If element value=true, element is black, otherwise – grey.
8 Enabled Output field Possible value: `V`. If element value=true, element is black, otherwise – grey.
9 Password
expired Output field
Possible value: `V`. If element value=true, element is black, otherwise – grey.
Call requirement
SRS-SVMRA-03, SRS-SVMRA-04, SRS-SVMRA-06 Users
Administrator 3.3.2.3 New user
Requirement ID SRS-SVMRA-03 Requirement title New user Description
The requirement is called by `User list (SRS-SVMRA-02) `, if click on element `New user`. The requirement allows enter information about user:
48 password; account expired; account locked; enabled; password expired.
New user screen prototype (see Figure 3.16):
Figure 3.16: New user screen prototype. Description of new user elements (see Table 3.10):
Table 3.10: Description of new user elements
Nr. Title Type Description
10 Username Input field 10.1 Username. 10.2 Required field. 11 Password Input field 11.1 Password.
11.2 Required field.
12 Account expired Checkbox By default: not checked (false). 13 Account locked Checkbox By default: not checked (false). 14 Enabled Checkbox By default: not checked (false). 15 Password
expired
Checkbox By default: not checked (false).
16 Create Button 16.1 Always active.
16.2 Possible actions after button press: 16.2.1 Data quality check.
16.2.2 If data quality is consistent, the system calls the `User list (SRS-SVMRA-02) ` requirement. If not, shows an appropriate
49
notification `Enter value!`.
Call requirement SRS-SVMRA-02 User Administrator 3.3.2.4 Show user Requirement ID SRS-SVMRA-04 Requirement title Show user Description
The requirement is called by `User list (SRS-SVMRA-02)`, if click on element `username`. The new user can be added by clicking on `new user`- calls the `New user (SRS-SVMRA-03) ` requirement. The user can be edited by clicking on `edit`. The user can be deleted by clicking on `delete`.
Requirement shows user information(see Figure 3.17):
Figure 3.17: Show user screen prototype.
Description of show user screen prototype elements (see Table 3.11): Table 3.11: Description of show user screen prototype elements
Nr. Title Type Description
17 Username Output field Username.
50
19 Account locked Output field Possible values: true or false. 20 Enabled Output field Possible values: true or false. 21 Password
expired
Output field Possible values: true or false.
22
Edit Button 22.1 Always active.
22.2 Possible actions after button press:
Calls the `Edit user (SRS-SVMRA-05)` requirement. 23
Delete Button 23.1 Always active.
23.2 Possible actions after button press: 23.2.1 Deletes user.
23.2.2 Element `Notification` shows an appropriate notification; 23.2.3 Calls the `User list (SRS-SVMRA-02)` requirement. 24
Notification Output field Notification: ` [#username] has been deleted! `.
Call requirement
SRS-SVMRA-02, SRS-SVMRA-03, SRS-SVMRA-05 User
Administrator 3.3.2.5 Edit user
Requirement ID SRS-SVMRA-05 Requirement title Edit user Description
The requirement is called by `Show user (SRS-SVMRA-04)`, if click on element `edit`. The requirement allows the user to edit user profile. The new user can be added by clicking on `new user`- calls the `New user (SRS-SVMRA-03) ` requirement. Edit user screen prototype (see Figure 3.18):
51 Figure 3.18: Edit user screen prototype.
Description of edit user screen prototype elements (see Table 3.12): Table 3.12: Description of interface elements
Nr. Title Type Description
25 Username Input field By default: corresponding value.
26 Password Input field By default: corresponding value.
27 Account expired Checkbox By default: corresponding value. 28 Account locked Checkbox By default: corresponding value. 29 Enabled Checkbox By default: corresponding value. 30 Password
expired
Checkbox By default: corresponding value.
31 Update Button 31.1 Always active.
31.2 Possible actions after button press: 31.2.1 Data quality check.
31.2.2 If data quality is consistent, the system calls the `User list (SRS-SVMRA-02)` requirement. If not, shows notification. 32 Notification Output field 32.1 Notification.
32.1 Possible values:
52
32.1.2 [password] cannot be blank. 32.1.3 [username] updated.
Call requirement
SRS-SVMRA-02, SRS-SVMRA-03 Users
Administrator
3.3.2.6 User role list
Requirement ID SRS-SVMRA-06 Requirement title User role list Description
All user roles must be displayed in a list. Each can be viewed, deleted or edited. The new user role can be added by clicking on `new user role`- calls the `New user role (SRS-SVMRA-07) ` requirement. Clicking on `users`- calls the `User list (SRS-SVMRA-02) ` requirement.
The users in the system are:
Administrator – creating and managing users.
Master User –setup (using import)of initial simulator configuration, change configuration, export configuration, and realizeboth simulation 1 and 2.
Manager – can list ticket reports, view and answer tickets sent by users, suggest new configuration and projects that will improve the recreation on Vodno Mountain.
User role list screen prototype (see Figure 3.19):
Figure 3.19: User role list screen prototype Description of user role list elements (see Table 3.13):
53 Table 3.13: User list elements
Nr. Title Type Description
33 Role Output field
-link
Possible value: Role_Admin, Role_Manager, Role_Master. Call requirement `Show user role (SRS-SVMRA-08)`. 34 User Output field Username.
Call requirement
SRS-SVMRA-02, SRS-SVMRA-07, SRS-SVMRA-08 Users
Administrator
3.3.2.7 New user role
Requirement ID SRS-SVMRA-07 Requirement title New user role Description
The requirement is called by `User role list (SRS-SVMRA-06) `, if click on element `New user role`. The requirement allows the user to:
Choose user role; Choose user.
New user screen prototype (see Figure 3.20):
Figure 3.20: New user role screen prototype Description of new user role elements (see Table 3.14): Table 3.14: Description of new user role elements
54
35 Role List Possible value: Role_Admin, Role_Manager, Role_Master. By default: Role_Admin.
36 User List List of created users. By default: corresponding value. 37 Create Button 37.1 Always active.
37.2 Possible actions after button press: the system calls the `User role list (SRS-SVMRA-06)` requirement.
Call requirement SRS-SVMRA-06 User
Administrator
3.3.2.8 Show user role
Requirement ID SRS-SVMRA-08 Requirement title Show user role Description
The requirement is called by `User role list (SRS-SVMRA-06) `, if click on element `role`. The new user can be added by clicking on `new user`- calls the `New user role (SRS-SVMRA-07) ` requirement. The user role can be edited by clicking on `edit`. The user role can be deleted by clicking on `delete`.
Requirement shows user information (see Figure 3.21):
Figure 3.21: Show user role screen prototype
Description of show user screen prototype elements (see Table 3.15):
Table 3.15: Description of show user screen prototype elements
