IT 314 - Software Engineering

Geographic Information Access Services

System Requirements Specification
First Release

Organization and Stakeholders

Team 16, UG 2003, DA-IICT
Version History

First Release
25th February, 2006
Dhara Dave, Mohit Gupta, Venkat Krishna, Parag Kulkarni

Reviewed by Ashish Ladha

GIAS
System Requirements Specification Document First Release 2 3/10/06
Table of Contents

1. Introduction
1.1 Purpose and Scope

1.2 Product and Environment

1.3 References

2. General description
2.1 Product Perspective.

2.2 Product Functions.

2.3 User Characteristics.

3. Data and databases

3.1 MySQL Database.

3.2 Google Desktop Search Index.

3.3 File System.

4. Functional requirements
4.1 Map viewing.
4.2 Addition of new points of interest.
4.3 Data entry.
4.4 Searching.

5. Interfaces
5.1 System Interfaces.

5.2 Hardware Interfaces.

5.3 Software Interfaces.

5.4 Communications Interfaces.

GIAS
System Requirements Specification Document First Release 3 3/10/06
 5.5 Operational Interfaces.

6. Other requirements
6.1 Performance.

6.2 Security, Recovery and Usability.

6.3 Maintainability.

6.4 Operator's task Requirements.

7. Design constrains
7.1 Standards.

7.2 Hardware Constrains.

7.3 Software Constrains.

7.4 Other Constrains.

8. Ideas for further development

GIAS
System Requirements Specification Document First Release 4 3/10/06
Introduction

The Software Requirements Specification(SRS) is the official statement of what the system developers
should implement and it helps provide an organized way to collect all requirements surrounding a software
intensive project at the feature level into one document.

Purpose and Scope

The SRS includes user requirements for a system (functional and non-functional) in a language, end users
understand without much technical knowledge. It also contains the system requirements (as expanded
version of the user requirements) that can be used by software developers as a starting point for the system
design. In our project we make use of Requisite Pro of Rational Laboratories and our traditional
documentation to document and trace the Software Requirement Specifications.

The GIAS project seeks to provide a repository of geographically organized information that is usable for
tourists, locals and researchers. The group was divided to create personas for each of the target group
aforementioned so as to enlist all current systems that are used by these groups to access information that
falls under the scope of our project. The group brainstormed at various levels to list user requirements that
were instrumental in guideing the functionalities that are provided in this document.

The SRS documentation, together with the Use-Case modeling, takes care of coherence and dependability
in the project. The following in specific cases use the SRS:

• The system analyst creates and maintains the vision, use-case model overview and supplementary
specifications, which serve as input to the SRS. The specification is a communication medium
between the system analyst, the customer, and other developers.

• Designers use the SRS as a reference when defining responsibilities, operations, and attributes on
classes, and when adjusting classes to the implementation environment.

• Developers refer to the SRS at various stages to keep in touch of the original expectations from the
project. Also it makes possible for a collective vision while developing the system.

• The project manager refers to the SRS for input when planning iterations.

• The testers use the SRS to verify system compliance.

GIAS
System Requirements Specification Document First Release 5 3/10/06
 Product and Environment

Geographical Information Access Services (GIAS)

Information about local services/events currently is available as disconnected and non-cohesive media,
leading to a gap between the information and those who want it. It is exactly this gap that our application
plans to bridge. Access to information as it happens and where it happens is essential in today’s world.
Today’s Information Systems need to be more interactive and user-friendly and provide content that has
semantic value to users.

Distribution of information about local services is not available as a composite and does not lend itself
well to consumption by the average user. The interfaces of maps or newspapers that distribute such
information are not user-friendly and do not allow users to view/manipulate and even update data in the
way they want or are comfortable with. This application would allow the user to view/search/update/edit
and add information about locations via a map-based interface.

The project envisages developing software that can be used by tourists, locals and researchers for
information pertaining to a geographical location. The service can be used by installing the client
application on all the end-user machines and installing the web service on a central server. The service can
be utilized by use of facilities provided in the client application or by writing applications that consume
web methods exposed, bringing the information about a geographical location just a mouse click away.

References

The Rational Suite Documentation: for details about SRS

Wikipedia.com: for understanding of various concepts and terminologies of SRS

Google Earth: Google Blog and Google Research Outlines

Microsoft MapPoint Services
Yahoo UI Blog for Design Patterns
Yahoo Maps Blog

Demos Group, UK: demos.co.uk for open source methodologies

The Lonely Planet Project
Eeicher City Maps

GIAS
System Requirements Specification Document First Release 6 3/10/06
2. General description

In the process of building the system, developing the software, we anticipate to apply the Software
Engineering Principles & Techniques we acquire during the course while also adhering to deliver the
product within the stipulated time period and estimated cost(effort). The product envisages to bridge
the gap between the end-users and the information pertaining to a geographical location, keeping in
mind the target users namely; tourists, locals and researchers.

2.1 Product Perspective

The product shall be an independent entity in itself and would not be connected or part of or be a
subsystem to any other software or larger software.

2.2 Product Functions

The basic functions of the Products would be:
a) Map Viewing.
b) Addition of new points of interest.
c) Data Entry.
d) Searching.
2.3 User Characteristics

Guest Account
A guest account can access all information that is contained in the project but with no permissions to
edit, add or delete material. This is the default profile when somebody accesses the system using the
client-application.

Standard User Account

Standard users are permitted to edit, add and delete information pertaining to points-of-interest on
the map.

Enhanced User Account

An enhanced user account has priviliges to create new schemas for entering information relating to
points of interest. Based on specific needs the format of data entry can be changed by enhanced users.

Developer Account
Certain web methods exposed by the web service will be required only by developers who are creating
new clients that consume its services. Add new map, change default schema and certain test services
form a part of functionalities used by a developer account.

GIAS
System Requirements Specification Document First Release 7 3/10/06
3. Data and databases

GAIS Information Storage System

Data storage is not dependent on a single storage structure; it works as a composite using Windows file system,
Google Desktop Search, XML files and MySQL database. All these services are accessed by the GAIS server
that manages interaction between them and provides fast and efficient contextual search to the user while
allowing for an evolutionary growth in data structures.

MySQL Database:

The database structures primarily aim to provide details about relationships of data stored in the file
system and information required to limit the search set for Google desktop search.

Data Structures:

Points-of-Interest
• Points of Interest ID
• Point of Interest name
• Location on Map
• Filename
• Primary tag

GIAS
System Requirements Specification Document First Release 8 3/10/06
 Points-of-Interest Further Entries
• Points of Interest Entry Number
• Points of Interest ID
• Filename
Tags
• Tag ID
• Tag name
• Tag detail
Map Details
• Map ID
• Map name
• Map detail Level
• Filename
XML Schemas
• Schema ID
• Schema name
• Schema details
Filename Keys [virtual]
• Specification that is represented in filename (eg: Tags, map detail etc)
• Code that is used in file name

Google Desktop Search Index

GDS is used to search the files stored containing data entered by users. It is used as google search
algorithms are proven widely to be the best. The files to be searched are taken as an input from the
database.

File System

The windows file system is used to store data entered by the user for particular points-of-interest.
Files are stored in XML format that is validated against Schemas that can be user specified or the
default that is provided. The filenames form an important part in the search process as it contains
information that links DB results to GDS Search criteria.
Syntax of file name:
point-of-interest_ID.Entry_Number.TAG1_TagCode.TAG2_TagCode.Schema_Code

GIAS
System Requirements Specification Document First Release 9 3/10/06
4. Functional requirements

Functional requirements are a listing of what the system must establish, without going into the detail of how it
is established. For every module/requirement the user interface should be easy to use and intuitive and the
perceived execution time in all the modules should also be acceptably low. The success and spread of the
application would depend heavily on these two criteria. These detailed functional requirements are enumerated
below-

1. Map viewing

• Description: allow the user to view the map of a particular geographical region, allowing for
zoom up to a pre-determined level of granularity as well as being able to scroll and view the
entire map.

• Criticality: high. This module/functionality is placed in the bracket of most critical

functionalities, because most other modules and hence the application as a whole would not
be able to run without it.

• Technical issues: the requested parts of the map/image will have to be sent by the web-
service either by converting it to bytes and sending the image as an array of bytes or by
sending a dime attachment. Dime is a technology that is used to send binary attachments in
xml.

• Dependence with other requirements- all other modules/functionalities are dependent on

this module. This is the base module, and hence of highest importance.

2. Addition of new points of interest

• Description: this would allow the user to add new points of interest on the geographical map
provided. These “points of interest” are referred to as data-points or objects on the map.
Each of these data points has associated with it various tags. (described in requirement 3 -
data entry)

• Criticality: high. This module/functionality is placed in the bracket of most critical

functionalities, because without this the user would not be able to add/edit data about points

GIAS
System Requirements Specification Document First Release 10 3/10/06
 of interest.

• Technical issues: the superimposition of two layers or two images to make one single image
should be possible. The lower layer would contain just the geographical map whereas the
second layer would contain these points of interest.

• Dependence with other requirements- this module depends on the first module, because all
these data points will be placed at certain geographical locations on the map. The data entry
and search modules (enumerated below) are dependent on this module.

3. Data entry

• Description: this module would deal with user input. The user will have to enter the data in a
specified format to help achieve semantic meaning in data. This data is the target set for
searches.

• Criticality: moderate. Ease of use is essential in the user-interface for this functionality.

• Technical issues: carefully design and implementation of data-structures and schemas for
data entered is critical since it directly affects the user perceived response time during search.
The user entered data is required to be searched using gds and also to be transmitted over
the internet for storage at server design of proper xml schemas is critical.

• Dependence with other requirements - this module depends on module two. The searching
and database storage module is dependent on this.

4. Searching

• Description: searching of user entered data in two ways

ƒ User selection of a 'point of interest' - and relevant data about that point is
displayed.

ƒ User enters search criteria- and relevant data points should be

displayed/highlighted.

• Criticality: high. This module/functionality is placed in the bracket of most critical

GIAS
System Requirements Specification Document First Release 11 3/10/06
 functionalities, because this is the most useful feature of the application- allowing the
user to find geographically spread data.

• Technical issues: would require the linking of a database (which would prove relational
context to the file structure) and Google desktop search (which would search these
files). This linking of the two would be done using c# code running on the server.

• Dependence with other requirements - this module depends on the addition of points
of interest module. The searching and database storage module is dependent on this.

GIAS
System Requirements Specification Document First Release 12 3/10/06
5. Interfaces

5.1 System Interfaces

The central and most important part of the project is to expose a web-service that will have a clean
interface, so that many applications may use the basic functionalities in whichever way they please.
The detailed API's that designers will need to use are enumerated in Web-ServiceAPI.doc. Even
though a user is free to consume the web-service in the way he deems fit, a client side shall still be
provided that makes optimal utilization of the Web-Service.

5.2 Hardware Interfaces

The application interacts with and controls only those hardware devices that are part of a regular
PC. There are no special hardware interface requirements.

5.3 Software Interfaces

• If a user decides to write his own client application to consume the exposed web-service
API, then he would have to follow the guidelines of SOAP, XML and WSDL specified
for the web-service. The user application would have to confirm to the API's as
mentioned in Web-ServiceAPI.doc.
• At the Server Side/Backend the web service interfaces with MySQL database and
Google Desktop Search.
• It will require a background Operating Systems (Windows, Linux or Solaris) to run.

5.4 Communications Interfaces

The web service is used transparently by the client application to be developed by us. However, if
the customer wants to consume the web service using his own application, he could choose to
communicate with the client using any protocol, HTTP being the standard protocol.

5.5 Operational Interface

There are no special modes of operation, other than those specified in the User Characteristics
Section 2.3. Standard backup and recovery operations of data will be carried out at the server.

GIAS
System Requirements Specification Document First Release 13 3/10/06
6. Other Requirements

6.1 Performance

The performance of the system is primarily dictated by server performance. Maximum simultaneous
connections to the server will be limited by file access speeds on the server hardware with some
dependency on available memory. System performance will be graded during testing to hint at
appropriate hardware requirement for a specified load. Bandwidth constraints will dictate user access
speeds to the server and the server uses JPEG compression techniques to minimize file transfer sizes.

6.2 Security and Recovery

The system follows Microsoft .NET application design patterns for persistence and transaction
control to provide for data security. The project does not internally perform recovery tasks and it is
therefore required standard backup procedures are followed to allow for recovery of file system and
database.

6.3 Maintainability

There are no specific maintenance concerns other than standard file system and database maintenance
such as DB tuning and file system de-fragmentation etc.

6.4 Operator’s Task Requirement

The web server will run as part of the Microsoft Application Server and require no specific tasks on a
day-to-day basis apart from the aforementioned backup and maintenance tasks

GIAS
System Requirements Specification Document First Release 14 3/10/06
7. Design constraints

7.1 Standards

Templates have been provided by the authorities for reference as guidelines to create documents such as the
SRS, project plan and feasibility study. The Rational Suite was used to maintain standards as provided in the
Rational Unified Process.

7.2 Hardware Constraints

Minimum and recommended hardware requirements:

Server
• A computer with display monitor, mouse and a keyboard.
• CPU – 1.6 GHz onwards, 128 MB RAM and about 10 GB of HDD
Client
• Client should meet hardware requirements as required by Windows XP
• A minimum 2.8 Kbps connection (Broadband recommended)

7.3 Software constraints

The design phase requires complete Rational Suite Enterprise for developing test cases as well as
documentation.

Implementation

• Windows XP
• Microsoft .NET 2003 Architecture 1.1
• MySQL Server and ADO.NET to create, manage and access databases
• Google Desktop API as part of the server search module
• Visual Studio .NET 2003 as the primary development environment

Deployment

Server
• Windows XP or later with .NET 1.1 Architecture
• MySQL Server

GIAS
System Requirements Specification Document First Release 15 3/10/06
 • Google Desktop Application with indexing set only to GIA Storage Directory
Client
• Windows XP or later with .NET 1.1 Architecture

More constraints are expected to come to light as the project progresses.

7.4 Other constraints

Data / Information Constraints

• Map Constraints
Availability of satellite maps in India is limited and therefore the system will have to rely on
low detail cartographs that would constrain user experience.
• Location or ‘points-of-interest’ details
There is no easily accessible information regarding interesting locations in India that is non-
proprietary. The data density in maps will be very low the in the early phases of project
deployment which will limit the uses of the application or require for purchase or research to
gather enough data to make the service usable.

Client-side Constraints

• Limited Connectivity
Limited and low bandwidth connections would limit the scope and usage of the product.
• .NET is not packaged with Windows XP
The .NET architecture required for the client API is not standard on Windows XP. This
would require for specific installation of the same or inclusion with the installation package
for GIAS.

Development Constraints

• Web Service development constraints in .NET

Many API’s such as image manipulation, graphics, etc are not available when developing a
web service which limits development speed and requires developing separate windows
applications to handle such tasks effectively. Such architecture adversely affects system
performance and increases chances of error.

• Limited Test Capabilities of .NET Web Services Model

.NET web service model does not allow for independent tests of web methods which

GIAS
System Requirements Specification Document First Release 16 3/10/06
 interact using complex data types. This would require for development of small applications
to test web methods further increasing development and test time.

• Limited Client RAM

It has been observed that our target market has needs 256-512M of RAM; therefore the
design footprint should not exceed 256M.

8. Ideas for further development

Plug-in
A Mozilla Firefox plug-in that will monitor the content of the current user page and prompt the user by
sending queries transparently to the service. It will be‘crawler’ software which will constantly monitor
current state of the user and provide features to link web page URL’s to points-of-interest.

GAIS aggregator
An additional module in the client which will use ‘point-of-interest’ information to search for similar
content on the Internet. This content would primarily contain news-feeds, blog entries and other feed
based information relating to search parameters entered by user or location currently being viewed.

GIAS
System Requirements Specification Document First Release 17 3/10/06