Software Requirements Specification Document Rev 1.0 Drafted by: Di Simone Alessio 068/100005 Di Sorbo Alessandro 068/100254 Ragni Domenico 068/100006 Romano Enrico 068/100030 Serino Antonio 068/100061 Supervision by: Prof. Antoniol Giulio Approved by: Title Date Signature Prof. Antoniol Giulio Team Supervisor Romano Enrico Team Leader Di Simone Alessio Team Member Di Sorbo Alessandro Team Member Ragni Domenico Team Member Serino Antonio Team Member 3/15/02 SF.BART Grass P ost Software Requirements Specification Document
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Prof. Antoniol Giulio Team SupervisorRomano Enrico Team LeaderDi Simone Alessio Team MemberDi Sorbo Alessandro Team MemberRagni Domenico Team MemberSerino Antonio Team Member
2.1 Product Perspective.............................................................................................................72.2 Product Functions................................................................................................................72.3 User Charateristic.................................................................................................................82.4 Constraints.............................................................................................................................8
3 Specific Requirements...........................................................................................................................9
3.1 External interface requirements.......................................................................................93.2 Function Requirements.......................................................................................................9
3.2.1 Overview of DataBase Interaction............................................................................93.2.1.1 Create a DataBase with PostGIS extension Use Case.................................103.2.1.2 Drop a DataBase with PostGIS extension Use Case...................................11
3.2.2 Overview of PostGrass System Interaction..........................................................123.2.2.1 Open a connection on a PostGrass DataBase..............................................133.2.2.2 Perform a write line on the DataBase............................................................143.2.2.3 Perform a rewrite line on the DataBase........................................................153.2.2.4 Perform a read line on the DataBase.............................................................163.2.2.5 Perform a read next line on the DataBase...................................................173.2.2.6 Perform a rewind on the DataBase................................................................183.2.2.7 Close a connection to a PostGrass DataBase...............................................19
3.3 Design Constraints............................................................................................................203.4 Software System Attributes.............................................................................................20
1 IntroductionThis document is the first artifacts in the development life cycle of the product. It ’sa guideline for designers and developers about the functionalities performed and theproblems that the system solves.
1.1 Background
Project title: PostGrass GRASS extension to the PostGIS functionalities
Rapid overview on the project environment:
GRASS (Geographic Resources Analysis Support System) is a raster based GIS,vector GIS, image processing system, and graphics production system. GRASScontains over 200 programs and tools to render maps and images on monitor andpaper; manipulate raster, vector, and sites data; process multi−spectral image data;and create, manage, and store spatial data. GRASS uses both an intuitive windowsinterface as well as command line syntax for ease of operations. GRASS caninterface with commercial printers, plotters, digitizers, and databases to develop newdata as well as manage existing data.
GRASS is ideal for use in engineering and land planning applications. Like otherGIS packages, GRASS can display and manipulate vector data for roads, streams,boundaries, and other features. GRASS can also be used to keep maps updated withits integral digitizing functions. Another feature of GRASS is its ability to use raster,or cell, data. This is particularly important in spatial analysis and design. GRASSfunctions can convert between vector data to raster data for seamless integration.
GRASS’ strengths lie in several fields. The simple user interface makes it an idealplatform for those learning about GIS for the first time. GRASS is capable ofreading and writing maps and data to many popular commercial GIS packagesincluding ARC/Info and Idrisi. Users wishing to write their own code can do so byexamining existing source code, interfacing with the documented GIS libraries, andusing the GRASS Programmers Manual. This allows more sophisticatedfunctionality to be integrated in GRASS.
The ability to work with raster data gives GRASS the unique ability to function as asurface modeling system. GRASS contains more than 100 multi−function rasteranalysis and manipulation commands. Surface processes such as rainfall−runoffmodeling, flowline construction (as shown), slope stability analysis, and spatial data
analysis are just a few of the many applications of GRASS to engineering and landplanning. Since many of the raster tools are multi−functional, users can create theirown maps from GRASS data analysis.
In addition to standard two−dimensional analysis, GRASS allows users to view datain three−dimensions. Raster maps, vector maps, and sites data can be used forvisualization. Example applications of such capabilities include airspace analysis forairport planning (as shown), terrain analysis and flybys , and spatial trends. Tools inGRASS allow the user to animate any spatial data available with options to switchbetween data layers on−the−fly . Data used in 3−D visualization may also be savedas still pictures, or as mpeg movie files for later replay and analysis.
Accompanying its land planning and engineering applications, GRASS contains asuite of tools to aid in hydrologic modeling and analysis. Currently, tools are alsoavailable for performing such functions as watershed analysis, curve numbergeneration, flood analysis, and stream channel characteristics for comprehensivewatershed modeling. Other GRASS programs can generate graphs, statistics, andcharts of modeled and calibrated data. Additionally, GRASS can use field data formodel input or simulate parameters based on numerical data.
In addition to the traditional command line version of GRASS, a new user interface,based on Tcl/Tk has been written. This puts the power of spatial analysis andmodeling into an easy to use Graphical User Interface that is platform−independent.This intuitive user interface lets users quickly and easily view, manipulate, and usedata. Nearly all of the programs available in GRASS are available in the new GUI,with the standard command−line still available, giving users all of the functionalityof GRASS. [Refer to GRM for more information]
1.2 Purpose & Scope
A new GRASS vector format and library is under development (GRASS 5.1).Thenew vector support is based on flat files for geometry and RDBMS for attributes.This solution is suitable for many tasks but doesn’t allow simultaneous editing bymore users and all the other advantages available for RDBMS. The idea for GRASS5.1 is to support both flat files and RDBMS for geometry. This research shouldresult into working code applicable to future version of GRASS and discoverpotential problems.The aim is to write (modify) all the functions which writes and reads primitivesto/from PostGIS database tables.
FFunction A defined objective or characteristic action of a system or component. Asoftware module that performs a specific action, is invoked by the appearance of itsname in an expression, may receive input values and returns a single value.
G H
IInterface A connection between two devices or systems.
J K
LLibrary A controlled collection of software and related documentation designedto aid in software development, use or maintenance.
M
NNetwork Describes the physical hardware and software connections betweencomputers allowing information to be shared and electronic communications to takeplace.
O
PPatch A modification made directly to an object program without reassembling orrecompiling from the source program.Portability The ease with which a system or component can be transferred fromone hardware or software environment to another.Project The combined resources (people, machines, materials), processes, andactivities that are dedicated to building and delivering a product to a customer.
RRequirements The statement of needs by a user that triggers the development of aprogram, system, or project. May be called business functional requirements orrequirement specifications.
S T U V W X Y Z
1.4 Definitions, Acronyms and Abbreviations
GRASS Graphical Resources Analysis Support SystemSFRD or PSFRD PostGrass Software Feasibility Research Document SRS or PSRS PostGrass Software Requirement Specification DocumentSDD or PSDD PostGrass Software Design Description DocumentTVRRD or PTVRRD PostGrass Test or Validation Result Report DocumentUD or PUD PostGrass User DocumentationTBD To Be DeterminedCD Create a DataBase with PostGIS extension Use CaseDD Drop a DataBase with PostGIS extension Use CaseOCD Open a connection on a PostGrass DataBasePWD Perform a write line on the DataBasePRD Perform a rewrite line on the DataBasePRDD Perform a read line on the DataBasePRND Perform a read next line on the DataBasePRWD Perform a rewind on the DataBaseCCD Close a connection to a PostGrass DataBase
1.5 References
The following document are used as design and development requirements of thePostGrass system parts.
1.5.1 PostGrass Project Documents
Grass Reference Manual (GRM)PostGrass Software Feasibility Research Document (SFRD)
The product PostGrass is not a complete system, but it’s an integral part of theSoftware GRASS. This document will be useful during the development of futureproject tied to the functionalities implemented in the PostGrass project.
2.2 Product Functions
Create a DataBase with PostGis extension (PostGrass DataBase)
~
Drop a DataBase with PostGis extension (PostGrass DataBase)
A PostGrass User is the PostGis user which own the table defined in the frmt fileexample relative to a PostGrass DataBase as indicated in the Feasibility ResearchDocument (SFRD).Every User has reading permission on every table.
2.4 Constraints
Library must be reliable in multi user environment (for writing).Simultaneous write access by more clients must be available.Library should be optimized for speed.Binary cursors should be used, and geometry read directly from geometry structure.Solution must be platform independent, please pay attention to byte order issues.The solution must permit to handle:
Native vector on local machine.Native vector on NFS.PostGIS vector on a local server.PostGIS vector on a remote server (other machine in network).
The product satisfied the committent’ requirements when:
We develop a patch file for pgrass.The patched pgrass must be able to import/export ascii files (v.in/out.ascii grassmodule) to postgres and data created in postgres tables must be readable byPostGIS functions and identical with original ascii files.The functionality will be tested on ’mcat’ and ’multi’ from pgdata package inthe same way which can be seen in ’io’ script in pgdata. The simultaneous write access by more clients must be available. The short report about technical problems faced during the project and ideas forfuture development and improvements.