Software Requirements Speci cation - Drexel CCIbrr52/website/docs/reqdoc.pdf · Software...

Software Requirements Specification

Team ArcDEx

Mark GolazeskiAdam MillerBrant Olsen

Ben RockstrohPatrick Smith

April 8, 2009Revision 1

Member Signature Approval Sheet

Mark Golazeski Date

Adam Miller Date

Brant Olsen Date

Ben Rockstroh Date

Patrick Smith Date

i

SRS Revisions

Date Description Revision Editor30 October, 2008 Initial LATEXfile. 0 Ben Rockstroh19 November, 2008 Various formatting and content

changes1 Patrick Smith

ii

Contents

1 Abstract 1

2 Introduction 12.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Definitions, Acronyms, Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4 Developer’s Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 General Description 23.1 Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3 User Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.4 General Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.5 General Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.6 Requirements Apportioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 Functional Requirements 44.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44.2 ArcGis Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.3 Data Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.4 Query Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.5 Search Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.6 Analysis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.7 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Non-Functional Requirements 215.1 Performance Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Server Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Software Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.4 Hardware Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.5 Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Activity Cases 236.1 Creating a new query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Zooming In on Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.3 Entering a new Resident using Data Entry Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 246.4 Editing existing Database entry using Data Entry Tool . . . . . . . . . . . . . . . . . . . . . . 256.5 Creating and saving a query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6 Saving and Loading the Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iii


1 Abstract

This document serves as a requirements specification for the development of a software system allowing usersto intuitively explore archaeological data. This requirements specification makes all attempts to conform toIEEE specifications 2.3 with minimal changes for clarity and brevity.

2 Introduction

2.1 Scope

This document is the sole description of the requirements of the system. It is meant for use by the develop-ment team and forms the basis of validation for evaluating the final delivered system. All changes made tothis document should go through a formal change approval process.

2.2 Definitions, Acronyms, Abbreviations

• Active Data - Data that is used in the system for queries and analysis.

• ArcGis - A geographical information server produced by ESRI. 2.3 Provides maps and geographiclocation information for those maps. We use this map along with our location data to place objects atcorrect positions on a map.

• Client - A machine consuming services from a server.

• Comma-separated Values (CSV) - A file used for storage of data structured in a table form.Each line in the CSV file corresponds to a row in the table. Within a line, fields are separated bycommas.

• Database - A piece of software, or collection of software designed to allow easy access and manage-ment of data.

• Dig - The work undertaken by the National Park Service during the excavation for the constructionof the National Constitution Center.

• Eclipse - A software system that provides software developers with an integrated development. Formore information see http://www.eclipse.org.

• HTTP - Hypertext Transfer Protocol.

• Inactive Data - Data that has ben flagged as deleted/removed instead of actually removed fromthe database.

• Lot - A section of the dig, often a foundation or a location of a house.

• Lot Lines - Lines indicating the boarder of Lots. house.

• Object - An artifact, person, or any such element related to the dig stored in the database.

• Off-Site - Location physically separated from the current location, so as to protect against physicalaccidents.

• Privy - A well, garbage, or sewage hole. This is where most artifacts are found.

• Wall - An inactive structure on the map that was once a wall to a building.

• Redundancy - A backup.

April 8, 2009 Team ArcDEx 1


• Remote Storage - Storage located Off-Site.

• Resident - The person who has some sort of relation to a lot, during a given time period.

• Server - A machine providing a service to other machines.

• Stakeholders - A person outside of the development that has a vested interest in the project.

• TCP/IP - Internet Protocol Suite used for networking.

• Unique Name - Unique names are those that do not contain the same sequence of letters or numbersfor the entire name. This means names would not be case sensitive.

• User - The person(s) that will be utilizing any part of the software.

• Web Service - A requested service on a web server that is used by a client.

2.3 References

• ArcDex Project Website

– http://www.cs.drexel.edu/~brr52/website/arcdex.html

• ArcGis Website

– http://www.esri.com/software/arcgis/

• IEEE Standard on Software Requirements Specifications

– http://www.cs.drexel.edu/~pjs482/arcdex/IEEE830-1998.pdf

2.4 Developer’s Responsibilities

Developers must:

• Report back on regular intervals to their team lead, who in turn will report bi-weekly to stakeholders.

• Design and implement the system to meet the requirements in the Functional Requirements section 4.

3 General Description

3.1 Current Status

Archaeologists with the National Park Service (NPS) are currently in the process of cataloging and analyzingdata from the excavation for the National Constitution Center (NCC). Their current tools consist of MicrosoftAccess, Microsoft Excel, and ArcGis. These tools have the following shortcomings:

• Overly complex query language.

• Poor multi-user support.

• Difficult to enforce data standards.

• Disperse data across multiple databases.

These shortcomings prevent effective cataloging and analysis of the artifacts and inhibit the identification oftrends in the gathered information. For these reasons, NPS has commissioned ArcDex to build a data man-agement and analysis tool that leverages the power of ArcGis in a more simplified manner, while managingthe large amounts of data cataloged.


http://www.cs.drexel.edu/~brr52/website/arcdex.html

http://www.esri.com/software/arcgis/

http://www.cs.drexel.edu/~pjs482/arcdex/IEEE830-1998.pdf


3.2 Project Scope

This application solves many of the issues archaeologists are currently having with data entry and analysis.Data is stored in a single relational database, for ease of maintenance and access. There are tools that allowfor current data contained in Excel spreadsheets to be mapped to fields in the database and imported as abatch import. Data that is not already cataloged can be input as an individual keyed entry, while limitingthe user to fields currently in the database. If the user wishes to add objects (2.2) that do not match thecurrent schema, they are able to create a new type and form new relations on the type. Tools are providedthat enable the simple creation of complex queries for analysis. Result sets from these queries are integratedwith a graphical map of the site, or graphed for easy analysis.

3.3 User Characteristics

3.3.1 Administrative Role

Most Users are archaeologists with limited technical knowledge. Developers should design assuming the useris a standard “MS Office” user with limited or no knowledge of database design.

3.3.2 General Role

This group consists of people with a diverse range of experience and backgrounds. Anyone from a MiddleSchool Student to a Retired History Buff, to the Teacher planning a trip. These users should not beconcidered technical experts, though it is safe to view them as standard users of Microsoft Word.

3.3.3 Developers

Users of the Web Services shall be comprised of developers of custom applications designed to consume thedata in our database.

3.4 General Constraints

Must interface with ArcGis map 4.2 and 5.4

3.5 General Assumptions and Dependencies

ArcGis provides a Java based interface for developers to build upon.

3.6 Requirements Apportioning

Priority Description1 Highest priority. All priority 1 requirements bearing this priority must be satisfied to the

fullest extent for the project to be considered a success.2 These requirements are not necessary for the system to function, but would greatly enhance

the usability of the system. They are to be considered of highest priority once the systemhas fulfilled all priority 1 requirements.

3 Requirements of this priority are not necessary for the system to function. Instead theserequirements would add new functionality that is not part of the origional system, but wouldbe more difficult to implement than all priority 2 requirements.

4 These requirements are not necessary for the system to function and are the most difficultand/or expensive to implement. Developers should keep these tasks in mind during design,but should not make any attempt to complete these tasks until all other requirements aremet.



Requirement Format: Requirement Number (Priority Level) Requirement DescriptionNote: If a section does not have a priority, the prior priority mentioned is assumed.

4 Functional Requirements

Figure 1: A high-level view of the system. The direction of the arrows represents the flow of data betweenparts of the system.

4.1 Database

The database will contain all information related to resident and artifact data that is consumed by ourprogram.

4.1.1 (1)

Shall be able to store resident information with the following fields.

4.1.1.1 Lot Identifier - A string containing at least 1 and up to 20 characters.

4.1.1.2 Address Pre-1854 - A string of 255 characters long.

4.1.1.3 Address Post-1854 - A string of 255 characters long.

4.1.1.4 Street - A string of up to 100 characters.



4.1.1.5 Occupant’s First Name - A string of up to 50 characters.

4.1.1.6 Occupant’s Last Name - A string of up to 50 characters.

4.1.1.7 Occupant - A String containing up to 100 characters.

4.1.1.8 Begin Date of occupancy - A string of up to 50 characters.

4.1.1.9 End Date of occupancy - A string of up to 50 characters.

4.1.1.10 Notes about occupant - Largest string for Database no less than 255 characters.

4.1.2 (1)

For any resident, the Lot Identifier field shall not be blank or invalid.

4.1.2.1 A valid Lot Identifier is any string containing at least 1 and up to 20 characters.

4.1.3 (1)

For any resident, any field, other than Lot Identifier, may be blank.

4.1.4 (1)

The database must be able to store object information with the following fields:

4.1.4.1 Feature Number - A non-null string of up to 24 characters.

4.1.4.2 Provenances - A non-null string of up to 20 characters.

4.1.4.3 Feature Type - A non-null string of up to 20 characters.

4.1.4.4 Lot Number - A string of up to 20 characters.

4.1.4.5 Center Point North (CPN) - A 20 character string.

4.1.4.6 Center Point East (CPE) - A 20 character string.

4.1.4.7 Center Point Elevation (fasl)(CP Elev) - A 20 character string.

4.1.4.8 Date - A string of up to 50 characters.

4.1.4.9 ID Keyword - A non-null string of up to 50 characters.

4.1.4.10 Description of object - Largest string for Database no less than 255 characters and non-blank.

4.1.4.11 Notes - Largest string for Database no less than 255 characters.

4.1.4.12 Status - A string of up to 24 characters.



4.1.5 (1)

The database shall accept new data relations.

4.1.6 (1)

The database shall accept new data types.

4.1.7 (1)

User cannot delete data from database, but shall use 4.1.8 and 4.1.9 to toggle an active flag for an audittrail.

4.1.8 (1)

User shall have the ability to turn on active flag for data.

4.1.9 (1)

User shall have the ability to turn off active flag for data.

4.1.10 (1)

The database shall not query inactive(2.2) data for analysis.

4.2 ArcGis Map

ArcGis must provide a map with the following capabilities in order to be a viable solution.

4.2.1 (1)

Toggle viewing of lot (2.2) lines on.

4.2.2 (1)

Toggle viewing of lot (2.2) lines off.

4.2.3 (1)

Toggle viewing of privies (2.2) on.

4.2.4 (1)

Toggle viewing of privies (2.2) off.

4.2.5 (1)

Toggle viewing of walls (2.2) on.

4.2.6 (1)

Toggle viewing of walls (2.2) off.

4.2.7 (1)

Display id for lots (2.2) when selected.



4.2.8 (1)

Display id for privies (2.2) when selected.

4.2.9 (1)

Provides views at multiple levels of clarity (zooming).

4.3 Data Entry

The data entry tool facilitates the entry and modification of data within the database. Users are given toolsfor creating new object types (tables) and relationships between objects.

4.3.1 (1)

User can add single entry, as shown in Figure 2.

Figure 2: Adding Single Keyed Element

4.3.2 (3)

User can import data from a Microsoft Excel spreadsheet, illustrated in Figure 3.



Figure 3: Import Excel Spreadsheet

4.3.3 (3)

User can modify specific column mapping for incoming data.

4.3.4 (1)

User can add new object.

4.3.5 (2)

User can add new object type.

4.3.6 (2)

User has the ability to add a field to an existing object type.

4.3.7 (2)

User has the ability to add relationships between two objects.



4.3.8 (2)

User can edit entries in the database, illustrated in Figure 4.

Figure 4: Editing Database Entries

4.3.9 (3)

User can mark entries as inactive(2.2).

4.3.10 (3)

User can mark entries as active(2.2).

4.3.11 (1)

Database is not modified until user clicks the submit button.

4.3.12 (4)

Before submit button is clicked, user can click undo to revert changes.



4.3.13 (4)

Before submit button is clicked, user can click redo to reapply undone changes.

4.4 Query Tool

4.4.1 (1)

User may select from one or more of the following fields to create a query.

• start time

• end time

• lot(2.2)

• privy(2.2)

• object(2.2)

• descriptive fields of prior selected object or objects

4.4.2 (1)

Users shall be able to create custom queries.

4.4.2.1 The user can create a new query by opening a new tab.

4.4.2.2 (3) Newly created queries are automatically added to the saved query panel.

4.4.2.3 (3) Any change to the query is immediately reflected in the saved query panel.

4.4.2.4 A new query is automatcally given a unique alphanumeric name.

4.4.3 (2)

Users shall be able to save queries.

4.4.3.1 A user can save a query with a unique alphanumeric name that may be different from thequery’s given name.

4.4.3.2 A user will be given a default location to save the query.

4.4.3.3 A user can specify a valid location to save the query.

4.4.3.4 If the user specifies a invalid location, the user will be prompted to select a new locaiton.

4.4.4 (2)

Users shall be able to load queries.

4.4.4.1 Queries can be loaded from a user specified location.

4.4.4.2 A user may load a query into a new tab.



4.4.4.3 A user may load a query into a the existing tab.

4.4.4.4 If a user loads a query into the existing tab, he or she is prompted with a dialog box askingif they want to replace the query, union the queries, or take the intersection of the queries.

4.4.4.5 If the query can not be loaded, the user will be prompted to try a different file to load.

4.4.5 (1)

A query can be activated by the user by clicking a “create query” button or pressing the “Enter” key whilethe query panel is selected.

4.4.6 (1)

The results of the activated query are passed to the selected display engine (Graph, Map, or CSV).

4.4.7 (3)

The result set contains only rows marked as active from the database.

4.4.8 (2)

The result set contains only the fields specfied by the user.

4.4.9 (3)

Users shall be able to merge multiple queries.

4.4.9.1 Users can merge two queries by dragging a tab with the first desired query onto the tab ofthe second desired query.

4.4.9.2 The user will be prompted with a dialog box asking them to do a union or intersection ofthe two queries, as illustrated in Figure 5.

Figure 5: Merging queries

4.4.9.3 The dialog box shall represent each operation by a Venn diagram, so basic users can under-stand the terminology.



4.4.9.4 Users can merge multiple queries by selecting an option from the main menu.

4.4.9.5 User selects from a list of all current queries.

4.4.9.6 User can specify for each query whether to do a union or an intersection.

4.4.10 (2)

A user can give a query a unique alphanumeric name.

4.4.11 (4)

User can define which fields are viewable when creating the query.

4.4.12 (4)

By default, all fields are viewable when creating a query.

4.4.13 (4)

Once the user defines which fields are viewable, they can save these to a user specified file.

4.4.14 (4)

The user may load these preferences from a user specified file.

4.4.15 (4)

The user can reset their preferences back to the default settings.

4.5 Search Tool

The search tool provides users with a quick and easy way to access information from the database withouthaving to go through the steps to generate a query.

4.5.1 (4)

Users have the ability to search the database in a Google like manner.

4.5.2 (4)

The search tool consists of a popup box that is launched from:

4.5.2.1 The Query Tool

4.5.2.2 An option in the menu bar

4.5.2.3 A two-key shortcut

4.5.3 (4)

The search is activated by entering the string and pressing enter.



4.5.4 (4)

The search is activated by clicking the “Search” button.

4.5.5 (4)

Upon activating the search, a tab will appear in the tab bar providing access to the result set of the search.

4.5.6 (4)

User can search through all fields from the database.

4.5.7 (4)

User can search through specific selected fields from the database.

4.5.8 (4)

User can search through all object types in the database.

4.5.9 (4)

User can search through specific selected object types from the database.

4.5.10 (4)

The search field predicts search strings for the user based off of:

4.5.10.1 Previous searches

4.5.10.2 Common fields and entries in the database

4.6 Analysis Tool

The analysis tool allows archaeologists to compare and contrast data gathered.

4.6.1 (1)

The analysis tool consumes a result set generated from the query tool.

4.6.2 (1)

The results of a query are displayed on ArcGis Map at the locations they were discovered.

4.6.3 (2)

The User can zoom in on the map by:

4.6.3.1 Clicking a magnifying glass.

4.6.3.1.1 Zooming is done on increments of 10% at a time.

4.6.3.2 Clicking and dragging over an area of the map.



4.6.3.3 Right-clicking and selecting “Zoom in on”.

4.6.4 (2)

The User can zoom out of map by:

4.6.4.1 Clicking a magnifying glass.

4.6.4.1.1 Zooming is done on increments of 10% at a time.

4.6.4.2 Right-clicking and selecting “zoom out”.

4.6.5 (2)

The User shall be able to click on a play button that:

4.6.5.1 Hides all results of query.

4.6.5.2 Shows the results as time progresses from start to end.

4.6.6 (4)

The analysis tool shall allow the following types of graphs:

4.6.6.1 Line graph

4.6.6.2 Bar graph

4.6.7 (4)

The analysis tool shall allow the user to specify the following:

4.6.7.1 What range of result set is x-axis.

4.6.7.2 What range of result set is y-axis.

4.6.7.3 The scale used in the analysis.

4.6.8 (4)

If the user does not specify the scale used for analysis, a default value shall be used.

4.6.9 (3)

The analysis tool shall allow the User to view a heat map indicating the concentration of objects at a certaintime and place.

4.6.10 (3)

The density of objects on the heat map shall be displayed by the shade of the color.

4.6.10.1 A darker shade shall indicate higher density.



4.6.10.2 Users can define colors for multiple types of objects.

4.6.11 (3)

The analysis tool shall display a legend for reference.

4.6.11.1 If a line graph or bar graph is currently displayed, the legend shall display the following:

4.6.11.1.1 x-axis

4.6.11.1.2 y-axis

4.6.11.1.3 scale

4.6.11.2 If a heat map is currently displayed, the legend shall display the following:

4.6.11.2.1 colors for weights

4.6.12 (3)

The User shall be able to save a graph or heat map in the following file formats:

4.6.12.1 JPEG

4.6.13 (2)

The User shall be able to save a result set in the following file formats:

4.6.13.1 CSV

4.6.14 (2)

The User shall be able to open a saved result set. When the result set is opened, the system shall:

4.6.14.1 Inform the user when result set was made.

4.7 User Interface

The user interface will allow users to graphically manipulate all of the data contained in the external databasesand ArcGIS. The user interface will allow the user to create custom made queries in simple, non-technicalways. It allows the user to combine queries to create graphs for data analysis. The general look and feel ofthis will be a that of Eclipse (2.2), as shown in Figure 6.

4.7.1 (3)

Any process that takes more than 1 sec will have a progress bar or process working screen.

4.7.2 (3)

The user shall have the ability to hide the object tree.



Figure 6: An example of the User Interface with tabs, a tree view of the query and a timeline.

4.7.3 (3)

The user shall have the ability to hide the timeline.

4.7.4 (2)

The ArcGis map shall allow the following operations:

4.7.4.1 Toggle lot lines on and off.

4.7.4.2 Toggle privies on and off.

4.7.4.3 Toggle walls on and off.

4.7.4.4 Click to drill down on specific lots.

4.7.4.5 Click to drill down on specific privies.

4.7.4.6 Select by dragging on screen.

4.7.4.7 Return id for lots.



Figure 7: The main panel of the user interface

4.7.4.8 Returns id for privies.

4.7.5 (3)

Clicking on an object in the map displays a pop-up window that gives all information in the database onthat object.

4.7.6 (3)

The pop-up shall disable interaction with the rest of the program as long as the pop-up remains open.

4.7.7 (3)

If a click on the map can represent more than one object:

4.7.7.1 The User is given a list of the objects that can be represented by the click in a new window.

4.7.7.2 The User can select one or all of the items in the list to be the subject of a pop-up.

4.7.8 (3)

Clicking on the information in the pop-up window (lot for instance) should allow you to view the informationfrom the lot in another tab.

4.7.9 (3)

Pop-ups can be closed with a button in the top right corner of the pop-up.



4.7.10 (3)

The following shall be displayed with the object information:

4.7.10.1 Documents related to object.

4.7.10.2 Pictures related to object.

4.7.11 (4)

The User shall be able to generate the following types of graphs from the query:

4.7.11.1 Line graph.

4.7.11.2 Bar graph.

4.7.12 (1)

The interface shall contain a timeline as shown in Figure 8.

Figure 8: Timeline in Query tool Interface

4.7.13 (1)

The timeline shall allow the user to:

4.7.13.1 Select start time of query

4.7.13.2 Select end time for query

4.7.13.3 Select no time. Query does not consider time.

4.7.13.4 Incrementally show results of query based on time.

4.7.13.5 Specify increments of time for playback.

4.7.13.6 Hide the timeline from view.

4.7.14 (2)

The timeline shall be adjusted whenever a query is loaded to match the start and end criteria in the query.

4.7.15 (1)

The interface shall contain a query builder as shown in Figure 9.



Figure 9: Tree used to build Queries

4.7.16 (1)

The query builder shall:

4.7.16.1 Provide a traversable list of lots.

4.7.16.2 Provide a traversable list of objects contained in lots.

4.7.16.3 Provide a traversable list of properties of objects contained in lots.

4.7.16.4 Allow the User to create query from selections.

4.7.16.5 Allow the User to display the Result Set in the current tab.

4.7.16.6 Allow the User to display the Result Set in a new tab.

4.7.16.7 Automatically add the query to saved query panel.

4.7.17 (3)

The interface shall contain a saved queries panel as shown in Figure 10.

4.7.18 (3)

The saved query panel shall:

4.7.18.1 Displays all queries that have been loaded or created this session.



Figure 10: Selection of saved Queries

4.7.18.2 Allow the User to hide queries from this list.

4.7.18.3 Allow the User to add queries to list.

4.7.18.4 Allow the User to toggle multiple queries on.

4.7.18.5 Allow the User to toggle multiple queries off.

4.7.18.6 Give the User the option to show changes to result on Map.

4.7.18.7 Inform the User after toggling queries that they should update their result set on map.

4.7.19 (2)

The interface shall allow the user to utilize multiple tabs as shown in Figure 11.

Figure 11: An example of multiple tabs..

4.7.20 (2)

A tab shall satisfy the following:

4.7.20.1 A single tab contains all panels.

4.7.20.2 If this tab represents a query, the tab contains all specific settings to the query.

4.7.20.3 If this tab represents a analysis, the tab contains all specific settings to the analysis.

4.7.20.4 User can have any number of tabs open at one time.

4.7.20.5 User can only see up to six different names of tabs at one time.

4.7.20.6 Tabs after six tabs are displayed in a drop down list.

4.7.20.7 Users can give a tab a specific unique name.



4.7.20.8 Tabs are automatically given a unique name at creation.

4.7.20.9 Tabs can be saved with an Unique Name. This saves:

4.7.20.9.1 The query from this tab.

4.7.20.9.2 The analysis from this tab.

4.7.20.10 Tabs can be loaded.

4.7.20.11 Tabs are always opened in same window.

4.7.20.12 Tabs are always opened to right of existing tabs.

4.7.20.13 User can close single tabs.

4.7.20.14 User can close all tabs at once.

4.7.20.15 User can close all tabs, other than the currently selected tab, at once.

5 Non-Functional Requirements

5.1 Performance Constraints

The system must satisfy the following performance constraints:

• Any database query on a table of 1 million indexed rows with 10 columns of type varchar should finishin 2 seconds or less on minimum hardware.

• The application will load in no more than 5 seconds with no other applications running on a machinewith minimum hardware.

5.2 Server Constraints

5.2.1 Database Server

The database server must have at least the following software:

• SQL server Express

• SQL server Express can not work with database files larger than 4G

5.3 Software Constraints

The system shall run on any machine that has at least the following software:

• Java Virtual Machine 1.6



5.4 Hardware Constraints

The system shall run on any machine meeting or exceeding all the following criteria:

• 50MB of free hard drive space

• 1GB of available memory

• 100kbps network connection

• Keyboard and Mouse

• Monitor

• 1Ghz processor

• 64MB Video Card

• 1024x768 screen resolution

• A pointing device such as a mouse.

• A keyboard.

5.5 Acceptance Criteria

Before accepting the system the developer(s) must show that the system works and passes the User Accep-tance test plan.



6 Activity Cases

6.1 Creating a new query.

Figure 12: Where are all of the chinese plates?

6.1.1

Users create queries by utilizing the query builder on the right side of the application. The user selectsthe fields and their values that he or she desires. Then, the user hits submit to finalize the query. Theapplication will then retrieve the data and update the map with a heatmap showing the locations of theobjects returned. The user has the ability to then drill down further on the objects by clicking on a sectionof the map and selecting an object from the popup box.

6.2 Zooming In on Map

6.2.1 Zoom Tool

Either select with right click menu or shortcut icon.

Figure 13: Process of useing zoom tool



6.2.2 Click and Drag

Clicking and dragging over a section.

Figure 14: Process of clicking and dragging to zoom in

6.3 Entering a new Resident using Data Entry Tool

��

��

��

��

��

��

��

��

��

Figure 15: Process of adding a new Resident to the database using the Data Entry Tool



6.4 Editing existing Database entry using Data Entry Tool

��

��

��

��

��

��

��

��

��

��

��

��

Figure 16: Process of editing existing data using the Data Entry Tool

6.5 Creating and saving a query

6.5.1

The creation and saving of queries is the core of what allows users to interact with data in the database.The options for the query are loaded in, and then they are selectable to the user. Selecting various fieldsnarrows down the number of results that will be returned from the database. Once the user builds theirquery, the results are shown on the map and selectable. Queries are savable to a user specified file so thatthey may be stored and accessed at a later time.

6.6 Saving and Loading the Program

6.6.1

Users have the option to save their current program session and load it at a later point in time. This willsuccessfully save their current tabs, queries, and anayleses. This allows the user to quickly jump back in totheir current work.



Figure 17: Process of creating and saving a query



Figure 18: Process of saving and loading


Software Requirements Speci cation - Drexel CCIbrr52/website/docs/reqdoc.pdf · Software...

Documents

Transcript of Software Requirements Speci cation - Drexel CCIbrr52/website/docs/reqdoc.pdf · Software...