Schematizing Maps
Requirements Definition
Version:
0.2
Date: 2010-10-01
Schematic Maps
Requirements Definition
Version 0.2
Page 1
Doc. No.:
Schematizing Maps
Requirements Definition
Version:
0.2
Date: 2010-10-01
Revision History
Date
Version
Description
Author
2010-09-26
0.1
Initial Draft
Martin Vrkljan
2010-10-01
0.2
Updated section 2.5, 3.14-3.17, 4.3 and 5.4
Zhixiang Gao
Page 2
Schematizing Maps
Requirements Definition
Version:
0.2
Date: 2010-10-01
Table of Contents
1.
2.
3.
Introduction
4
1.1
1.2
1.3
1.4
Purpose of this document
Intended Audience
Scope
Definitions and acronyms
1.4.1 Definitions
1.4.2 Acronyms and abbreviations
1.5
References
4
4
4
4
4
4
5
Requirements Description
5
2.1
2.2
2.3
2.4
2.5
2.6
2.7
5
5
5
5
5
6
6
Use Case Models
3.1
4.
6
Use case model “User”
3.1.1 Use case “Load image of a geographical map”
3.1.2 Use case “Draw lines and stations”
3.1.3 Use case “Apply schematizing algorithm”
3.1.4 Use case “Save schematic map as an image”
3.1.5 Use case “Import MDM file”
3.1.6 Use case “Export MDM file”
3.1.7 Use case “Editing on existing schematic map”
6
7
7
7
8
8
8
9
Requirements Definition
4.1
4.2
4.3
5.
Introduction
General requirements
Business requirements
User requirements
Algorithm requirements
Functional requirements
Non-functional requirements
9
Requirement Group Definitions
Requirement Sources
Requirements definitions
4.3.1 Change Log
9
9
9
10
Future Development
11
5.1
5.2
5.3
5.4
11
11
11
11
General Overview
Input data import
Output data export
Extensibility
Page 3
1.
Introduction
1.1
Purpose of this document
The purpose of this document is to define the necessary requirements for the Schematizing
Maps project.
1.2
Intended Audience

DSD teachers and project supervisors

Project proposer and customers

Team members
1.3
Scope
This document concentrates on requirements and necessary software functionality
descriptions.
1.4
Definitions and acronyms
1.4.1
Definitions
Keyword
Schematizing Maps
Schematic map
Octilinear
1.4.2
Definitions
Project name and also team name.
A map displaying landmarks connected by routes which follow
certain esthetic constraints, organized to preserves geographical
relationships, but not necessarily the geographical distances. It
usually serves as a graphical representation of a mental map of
geographical locations.
An octilinear drawing of a graph is a drawing which constraints
edges to horizontal, vertical and diagonal orientation, resulting in
eight different directions.
Acronyms and abbreviations
Acronym or
abbreviation
API
FER
GIS
IDE
JDK
MDH
MDM
SVN
Definitions
Application Programming Interface
Fakultet elektrotehnike i računarstva (University of Zagreb,
Croatia)
Geographic Information System
Integrated Development Environment
Java Development Kit
Mälardalens Högskola (Malardalen University, Sweden)
Million Dollar Map, product own output file format
Subversion, an open source version control system
1.5
References

Project DSD home page
http://www.fer.hr/rasip/dsd/projects/schematizing_maps

Project Google group
http://groups.google.com/group/dsd-schematizing-maps
2.
Requirements Description
2.1
Introduction
The customer has asked for an application which could aid a map designer in creating schematic
maps. As a team, we have been given a lot of freedom in defining requirements. The customer gave us
certain guidelines within which those requirements should be made.
2.2
General requirements
We have decided to concentrate on the basic functionalities and create a simple, but robust
application, which could be used by amateurs and professionals alike. To describe what the application
is required to do in general, we can describe what the user should provide as an input, and what the
desired output would be.
On an abstract level, all that the application needs from the user are two sets of different entities:
the stations and the lines. The stations are fixed locations, while the lines connect those stations and
create different routes. On a more realistic level, those stations and lines can represent bus, tram or
metro stations and lines, or even possible guidelines for notable landmarks, bicycle routes, or any other
information that could be schematized in order to provide an more organized view of geographical
locations.
Once the user has defined the input data, the output should be a schematic map. A schematic
map is a special type of a map which is drawn with a particular set of constraints in mind. The purpose
of such a map is to offer a more organized view of geographical paths (routes, lines, etc.) which
contains the information of geographical relation of stations and lines, but not necessarily their
distance, as we will explain in the following sections.
2.3
Business requirements
Business requirements describe the need for building this application. In the next couple of lines
we will list which requirements should be met to satisfy the customer's (or potential user's) business.

The application should offer easy creation of schematic maps,

The application should produce a schematic map in a form that is printable, publishable on digital
media, and easily distributable to users of customer's business.
2.4
2.5
User requirements
User requirements describe the tasks that the user should be able to perform while using this
application. These tasks closely relate to the use case models.

The application should enable the user to easily create a schematic map based on his knowledge of
the network of stations and lines in question, regardless of his skill as a map designer,

The application should provide the user with a quality end result in form of a schematic map,
regardless of her knowledge or skill in mathematical algorithms, graph theory or graphical design.
Algorithm requirements
Algorithm requirements describe the expected behavior of schematizing algorithm and
constrains which the algorithm should comply.

The schematizing algorithm should roughly support the geographical relationships of stations. A station
which is located north from another station should not be positioned south of it on the schematic map.

The schematizing algorithm should respect the input topology of the user's drawing; if that drawing
represents the input graph, the embeddings of that graph must be preserved in the schematic map.
2.6
Functional requirements
Functional requirements define the expected behavior of the application and the operations it
can perform in order to enable the user to perform his tasks.

The application should enable the user to define the input data by drawing stations and lines that
connect them over an image of a geographical map.

The application should enable the user a certain amount of control over how the schematic map will
look. This should be handled by giving the user an option to work in a basic, fast mode with predefined
settings, and the option to work in an advanced mode with the ability to adjust certain settings.

The application should enable the user to save the input data and the output result for optional editing
in the future.

The application should enable the user to save the output result in a form that is printable and
publishable on a digital media.
2.7
Non-functional requirements
Non-functional requirements describe the constraints and contracts the application should
respect. Any requirements on the graphical interfaces, performances, implementation, standards and
similar should be listed here.

The application should be simple and easy to use, for amateurs and professionals alike,

The user interfaces should be simple and unobtrusive. The main use of each interface should be clearly
recognized, with only the necessary controls displayed and neatly organized,

The final output in form of a schematic map should adhere to certain constraints:
◦
Different lines should be displayed in different, contrasting colors. It must be clear which line
continues in which direction and through which stations,
◦
Line segments should be restricted to octilinear orientations: vertical, horizontal, and diagonal.
The degree of the diagonal orientation should be treated as an algorithm setting.
3.
Use Case Models
3.1
Use case model “User”
3.1.1
Use case “Load image of a geographical map”
Initiator:
User
Goal:
Have an image of a geographical map loaded and displayed.
Main Scenario:
1. A list of available images on the user's computer is displayed
2. The user selects the image file to be loaded and confirms his choice
3. The application loads the image file and display
Extensions:
- If the image fails to load, for whatever reason, the application notifies the user.
3.1.2
Use case “Draw lines and stations”
Initiator:
User
Goal:
Have a complete drawing of all the lines and stations displayed and ready to be
processed.
Main Scenario:
1.
2.
3.
4.
5.
Necessary controls for drawing lines and stations are displayed to the user
The user chooses and selects the object he wants to place on top of the
geographical map
The user places the selected object on top of the geographical map
The application displays every placed object with an appropriate visual
representation
Steps 2 – 4 are repeated until the user has defined all input data (that is, until
the user has drawn the network of lines and stations he wishes to schematize)
Extensions:
 If the user tries to perform an invalid placement of a certain object (for example, placing a station
on top of an existing station) the application will notify him.
3.1.3
Use case “Apply schematizing algorithm”
Initiator:
User
Goal:
Have the input data processed and the final result displayed in form of a schematic
map.
Main Scenario:
1.
2.
3.
The user clicks the “Generate” button
The application processes the input data by applying a schematizing algorithm
The application takes the final result and displays it in a form of a schematic
map
Extensions:
 The user can choose to generate the map in an advanced mode, in which case he can select
additional, custom settings:
 Custom angle for diagonal lines,
 Resolution of the grid the schematic map will conform to,
 Line colors,
 Possible additional settings
 If the algorithm cannot find a possible solution for the user's input, it notifies the user about the
problem.
3.1.4
Use case “Save schematic map as an image”
Initiator:
User
Goal:
Save the generated schematic map as an image file in file system.
Main Scenario:
1.
2.
The user clicks the “Save as…” button, then chooses saving directory of image,
The application generates the image of schematic map and stores it to user
chosen directory.
Extensions:
 The user can choose the format of output image (bmp, jpeg, png).
3.1.5
Use case “Import MDM file”
Initiator:
User
Goal:
Import MDM file from file system and display schematic map.
Main Scenario:
1.
2.
The user clicks the “Import” button, then chooses source MDM file from file
system,
The application reads source MDM file, then generates a schematic map
according to this MDM file.
Extensions:
 If an error occurs during importing, it notifies the user about the problem.
3.1.6
Use case “Export MDM file”
Initiator:
User
Goal:
Export generated schematic map to file system as a MDM file.
Main Scenario:
1.
2.
The user clicks the Export” button, then chooses destination directory,
The application generates a MDM file according to current schematic map and
stores it.
Extensions:
 If an error occurs during exporting, it notifies the user about the problem.
Use case “Editing on existing schematic map”
3.1.7
Initiator:
User
Goal:
Have the current schematic map edited and then regenerated.
Main Scenario:
1.
2.
The user edits on existing schematic map by changing colors, removing stations,
adjusting distance between stations and adjusting angle,
The application regenerates a schematic map according to user’s modification.
Extensions:
 Some operations of editing are limited by application according to the situation of current
schematic map.
 If application cannot find a possible solution for the user's modification, it notifies the user about
the problem.
4.
Requirements Definition
4.1
Requirement Group Definitions
Identification
IDD
SA
UI
FIO
4.2
Requirement Group
Rem.
Input Data Definition
Schematizing Algorithm
User Interface
File Input/Output
Requirement Sources
Source
Description
Customer (Michal Young) defined requirement
Required as a consequence of system design (contractor’s
requirement)
Developers suggestion
Ctm
Sys
Ds
4.3
Requirements definitions
Identity
IDD-1
Rem.
Sta
tus
Prio
rity
I
1
Description
Input Data Definition
Define underlying map
Source
Ds
IDD-1-1
IDD-2
IDD-2-1
IDD-2-2
IDD-2-2-1
I
I
I
I
I
1
1
1
1
2
I
SA-1
1
I
SA-2
2
I
SA-2
1
SA-3
SA-4
I
H
2
2
I
UI-1
1
I
UI-2
1
UI-3
I
1
UI-4
I
1
UI-5
I
1
UI-6
UI-7
UI-8
UI-9
I
I
I
I
1
1
2
2
FIO-1
I
1
Load image of a geographical map
Define input graph
Define route lines
Define stations
Define station labels
Schematizing Algorithm
Schematize input graph (basic)
- Geographical map
- User drawing stations
- User drawing lines
Schematize input graph (advanced)
- User defined angle
- User defined resolution
- User defined color
Adhere to schematic map constraints
- Octilinear orientations
- Distance between two stations
- Geographical relationships of stations
- User drawing topology
Define custom angle for diagonal line segments
Regenerating depends on edited schematic map
User Interface
Show basic drawing options
 Select line drawing
 Select station drawing
Show advanced options
 Select custom diagonal line segments angle
Show input graph details
 display underlying map
 display lines and stations
 display station labels
Call schematic map generation
Show output graph details
 Show schematized lines and stations
Open saved map file
Save map file
Rename station labels
Change route lines colors
File Input/Output
Define internal file format (MDM)
Requirement status:
I = initial (this requirement has been identified at the beginning of the project),
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = additional (this requirement was introduced during the project course).
4.3.1
Change Log
Identity
Acti
on
Date
Comments
Ds
Sys
Ctm
Ctm
Ds
Ctm
Ctm
Ctm
Ctm
Ds
Ds
Ds
Ds
Sys
Ctm
Ds
Ds
Ds
Ds
Sys
Requirement status:
D = dropped (this requirement has been deleted from the requirement definitions),
H = on hold (decision to be implemented or dropped will be made later),
A = added (this requirement was introduced during the project course).
R = resurrected (dropped or on hold requirement was reactivated)
5.
Future Development
5.1
General Overview
Future development of this project should go into extending existing features. The initial
application will be a simple one, with only the basic functionalities, but stable and robust, leaving room
for incremental improvement and upgrade modules.
5.2
Input data import
Importing data from other sources, thus enabling users who already have a set of defined station
networks in a different format (shape files, vector drawings, GIS databases, etc.) to use that data to
produce schematized maps quickly.
5.3
Output data export
Instead of just having a specific file format and a printable image, the output result could be
exported to different formats, such as vector graphics for an example. This would enable graphic and
map designers to create quality schematic maps by utilizing the functionality of our software and
graphic-manipulation functionalities of existing, professional software such as Adobe Illustrator.
5.4
Extensibility
Algorithm should developed in order to be able to reuse in other programs in the future. The
possibility of migrating to a web based application should be considered during the development.