s04-f04 srs v0.91

CS 4311 Fall 2004

A Virtual Supermarket for Remote Sensing Data and Images

Version <0.91>4/10/2023

©2004 Software Engineering II CS 42311 Fall 2004

Software Requirements Specification

Document Control

ApprovalThe Guidance Team and the customer shall approve this document.

Document Change ControlInitial Release: 0.1

Current Release: 0.91Indicator of Last Page in Document: #

Date of Last Review: 08/28/04Date of Next Review: 08/31/04

Target Date for Next Update: 09/05/04

Distribution ListThis following list of people shall receive a copy of this document every time a new version of this document becomes available:

Guidance Team Members:Dr. Steve RoachDr. Ann GatesDr. Yoonsik CheonOmar Ochoa

Customer: Dr. G. Randy KellerPan-American Center for Earth and Environmental Studies

Software Team Members:All-Programmatic StarsCSTSputnik

Change SummaryThe following table details changes made between versions of this document

Version Date Modifier Description0.1 05/25/2004 Omar Ochoa Merging of Documents0.2 07/06/2004 Steve Roach Sections 1 and 2 revised0.3 07/12/2004 Omar Ochoa Changed Definitions and Section 20.4 08/01/2004 Omar Ochoa Revised Section 20.5 08/16/2004 Omar Ochoa Section 30.6 08/20/2004 Steve Roach Section 30.7 08/25/2004 Steve Roach Section 3, Appendices0.8 08/27/2004 Omar Ochoa Use Case Diagram, Appendices, Section 30.9 08/31/2004 Omar Ochoa/Steve

RoachUse Cases, Section 3, Appendices

0.91 09/02/2004 Omar Ochoa Appendices

Software Engineering II CS 4311 Fall 2004 Date

4/10/2023 6:33 PM

Page

ii


TABLE OF CONTENTS

DOCUMENT CONTROL............................................................................................................................II

APPROVAL.......................................................................................................IIDOCUMENT CHANGE CONTROL.......................................................................IIDISTRIBUTION LIST..........................................................................................IICHANGE SUMMARY.........................................................................................II1. INTRODUCTION..................................................................................................................................6

1.1. PURPOSE AND INTENDED AUDIENCE....................................................61.2. SCOPE OF PRODUCT..............................................................................61.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS................................7

1.3.1. Definitions.................................................................................................................................71.3.2. Acronyms and Abbreviations....................................................................................................9

1.4. OVERVIEW............................................................................................91.5. REFERENCES.......................................................................................102. GENERAL DESCRIPTION................................................................................................................11

2.1. PRODUCT PERSPECTIVE......................................................................112.2. USER CHARACTERISTICS....................................................................11

2.2.1. Actors......................................................................................................................................112.2.1.1. Visitor.................................................................................................................................................112.2.1.2. Provider...............................................................................................................................................122.2.1.3. Validator.............................................................................................................................................122.2.1.4. Database..............................................................................................................................................12

2.3. PRODUCT FEATURES..........................................................................122.3.1. Use Case Description.............................................................................................................13

2.3.1.1. Use Case 1: Search for Data...............................................................................................................132.3.1.2. Use Case 2: Register...........................................................................................................................162.3.1.3. Use Case 3: Login...............................................................................................................................172.3.1.4. Use Case 4: Provide Data...................................................................................................................182.3.1.5. Use Case 5: Validate Data..................................................................................................................20

2.4. GENERAL CONSTRAINTS....................................................................222.5. ASSUMPTIONS AND DEPENDENCIES...................................................223. SPECIFIC REQUIREMENTS............................................................................................................23

3.1. EXTERNAL INTERFACE REQUIREMENTS.............................................233.1.1. Hardware Interfaces...............................................................................................................233.1.2. Software Interfaces.................................................................................................................23

3.1.2.1. General Interface Requirements.........................................................................................................233.1.2.2. Visitor Pages.......................................................................................................................................233.1.2.3. Provider Pages....................................................................................................................................243.1.2.4. Validator Pages...................................................................................................................................25

3.2. COMMUNICATIONS INTERFACES.........................................................253.3. BEHAVIORAL REQUIREMENTS............................................................25

3.3.1. Same Class of User.................................................................................................................253.3.1.1. Visitor.................................................................................................................................................253.3.1.2. Provider...............................................................................................................................................263.3.1.3. Validator.............................................................................................................................................26

3.3.2. Related Real-world Objects....................................................................................................26


4/10/2023 6:33 PM

Page

iii


3.3.3. Stimulus...................................................................................................................................263.3.3.1. Visitor Stimulus..................................................................................................................................263.3.3.2. Provider Stimulus...............................................................................................................................273.3.3.3. Validator Stimulus..............................................................................................................................28

3.3.4. Related Features.....................................................................................................................283.3.4.1. Querying.............................................................................................................................................283.3.4.2. Automated Data Collection................................................................................................................283.3.4.3. Creating Administrative Reports........................................................................................................29

3.3.5. Functional...............................................................................................................................29

3.4. NON-BEHAVIORAL REQUIREMENTS....................................................293.4.1. Performance Requirements....................................................................................................293.4.2. Qualitative Requirements.......................................................................................................29

3.4.2.1. Availability.........................................................................................................................................293.4.2.2. Security...............................................................................................................................................293.4.2.3. Maintainability....................................................................................................................................293.4.2.4. Portability............................................................................................................................................29

3.4.3. Design and Implementation Constraints................................................................................29

3.5. OTHER REQUIREMENTS......................................................................303.5.1. Database.................................................................................................................................303.5.2. Operations..............................................................................................................................303.5.3. Site Adaptation........................................................................................................................30

4. APPENDIX A: WEB PAGE TRANSITIONS...................................................................................31

5. APPENDIX B: DATABASE FIELDS................................................................................................33

6. APPENDIX C: AVS SYSTEM CLASS DIAGRAM.........................................................................35

7. APPENDIX D: AVS SYSTEM DATA FLOW DIAGRAM.............................................................36

8. Appendix E: AVS System Prototype......................................................................................................38


4/10/2023 6:33 PM

Page

iv


TABLES

Table 1: Definitions.................................................................................................................................................7Table 2: Acronyms and Abbreviations....................................................................................................................9Table 3: Account Information...............................................................................................................................33Table 4: Metadata..................................................................................................................................................33Table 5: Instrument Information............................................................................................................................33Table 6: Glossary information...............................................................................................................................34Table 7: Link Center Data.....................................................................................................................................34

FiguresFigure 2-1: Use Case Diagram..............................................................................................................................12Figure 3-1: Home/Search Page..............................................................................................................................24Figure 4-1: Visitor Web Page Transition Diagram................................................................................................31Figure 4-1: Validator Web Page Transition Diagram............................................................................................32Figure 8-1: Change Provider Information.............................................................................................................38Figure 8-2: Advanced Search................................................................................................................................39Figure 8-3: Metadata Validation............................................................................................................................40Figure 8-4: Login...................................................................................................................................................41Figure 8-5: Provider Registration..........................................................................................................................41Figure 8-6: Submit Metadata.................................................................................................................................42Figure 8-7: Validator Homepage...........................................................................................................................43Figure 8-7: Guided Search.....................................................................................................................................43


4/10/2023 6:33 PM

Page

v


1. IntroductionThe Virtual Supermarket for Remote Sensing Data and Images (AVS) is a system under development at the University of Texas at El Paso (UTEP) Department of Computer Science. This document, the software requirements specification (SRS), describes the system in sufficient detail for its implementation. The SRS is divided into four sections. Section 1 describes the purpose and scope of the system and a glossary of terms used in the document. Section 2 describes the system in general terms. Section 3 contains the detailed requirements. The appendices provide additional information.

This section of the SRS contains a description of the Purpose and Intended Audience, the Scope of the Product, Abbreviations and Definitions and an overview of the document. This section of the SRS contains a description of the product and functionality provided by the product, main features of the product, a description of each type of user of the system, constraints on the development team, and factors that affect the requirements stated in the SRS. In order to describe what the system will do at a high-level, use case diagrams and scenarios are used in this section.

1.1. Purpose and Intended AudienceThe purpose of the SRS is to clearly and accurately define the requirements of the Virtual Supermarket for Remote Sensing Data and Images system being developed. The SRS documents and describes all functions that the final product should perform; thus, it serves as a developer reference for product design and implementation.

The SRS describes the system from the user perspective and then groups system requirements into two sections, behavioral and non-behavioral. Behavioral requirements define what the system does by examining inputs to the system, outputs from the system, and the relationships between these inputs and outputs. Non-behavioral requirements define the attributes of the system as it performs its job, including efficiency, reliability, security, maintainability, and portability.

The intended audience of this document is the client, Dr. G. Randy Keller of the Pan-American Center for Earth and Environmental Studies (PACES) at UTEP, the guidance team, and the software development team. The SRS is an agreement among these parties on requirements regarding the AVS system.

1.2. Scope of ProductRemote sensing is the science of acquiring, processing, and interpreting measurements acquired from a distance as with instruments borne on aircraft and satellites. Of particular concern here are data about Earth. Our client, PACES, specializes in the acquisition and distribution of Landsat data covering the Southwest United States and portions of Mexico.

Numerous remote sensing instruments are currently active in orbit around the Earth. Each instrument provides datasets to the instrument teams, who then make the data available to clients. In some cases, data acquired by clients can then be made available to other users. The result of current practices is that remote sensing data of various forms is available from a variety of data providers. Many data sets are available online, and much of it is free of charge. Scientists and the general public currently must use a variety of search engines that tend to favor commercial sites over non-commercial sites. PACES would like to facilitate locating various remote sensing data sets. Developing a centralized location and specialized search engine will facilitate locating datasets and will be greatly appreciated by the scientific community.

The AVS system will enable users to locate remote sensing datasets available online. It will maintain a list of data sets that are made available by a variety of remote sensing organizations. AVS will store, organize, search, and display links to commercial and non-commercial data sets that are available online. The software developed will provide a browser-based interface for users to search through an index of remote sensing data that various organizations make available. Data providers will use the software to make their data sets available to users by providing descriptions of the data that is available, including the location of the data, how the data was


4/10/2023 6:33 PM

Page

vi


obtained, and how the user can access the data. AVS will allow a user to search for data using a natural language query, and it will provide a list of relevant matches and links to the data. Descriptions of the data will also be provided to separate data into categories that can be used to narrow searches, such as date, price, and resolution. The software will offer “one stop shopping” for commercial and non-commercial remote sensing data located on various online websites.

1.3. Definitions, Acronyms, and AbbreviationsThis section provides the reader of the SRS with a list of definitions, acronyms and abbreviations that will be useful for the understanding of the terms used throughout this document.

1.3.1. DefinitionsTable 1 lists the definitions used in this document with respect to AVS. The definitions given below are specific to this document and may not be identical to definitions of these terms in common use. The purpose of this section is to assist the user in understanding the requirements for the system.

Table 1: Definitions

TERM DEFINITIONActor An external entity such as a user, a database, or application software that interacts with

the system.Administrator A person whose responsibility is to manage and maintain the infrastructure of the

system.Band A wavelength interval in the electromagnetic spectrum.Binary Data Any file format for digital data encoded as a sequence of bits but not consisting of a

sequence of printable characters (text). Class A set, collection, group, or configuration containing members regarded as having certain

attributes or traits in common; a kind or categoryClass Diagram A diagram consisting of a group of classes and interfaces reflecting important entities of

the domain of the system being modeled, and the relationships between these classes and interfaces.

Click through The process of selecting a hyperlink and transferring a browser’s display from the current site to the hyperlinked site.

Data Flow Diagram

A functional model of a software system that describes how outputs are derived from inputs. A diagram contains processes, data flows, actors and data stores.

Database A collection of data or information typically stored on a computer system and organized to facilitate retrieval and modification.

Database Management System

A software system that enables users to define, create, maintain, and control access to a database.

Download To transfer data or programs from a server or host computer to one's own computer or device.

Dynamic Model A model of a software system that describes the sequence events and states in the system.

Event An occurrence or happening of significance to a task or program, such as the completion of an asynchronous input/output operation.

External Program A program that interacts with the system to be built. An actor.Field An element of a database record in which one piece of information is stored.Footprint A rectangular or circular area that is the result of the projection of the field of view of an

instrument onto a surface or a selection of an area of an image or map.Foreign Key A set of fields in a relational data base table that is a primary key in a different table and

that is used to link the tables.Geo-referenced images

An image for which the image pixels have been assigned real-world coordinates (projection and datum) on the Earth.


4/10/2023 6:33 PM

Page

vii


Graphical User Interface

A user interface based on graphics (icons and pictures and menus) instead of text; uses a mouse as well as a keyboard as an input device.

Hit A request to a web server from a web browser or other client.Hover Placing the cursor over a GUI element without clicking on this element.Hyperlink An electronic link providing direct access from one hypertext document to another

either located in another area or in the same document.Image Pictorial representation of a scene recorded by a remote sensing system.Interactive Map A map displayed on a graphical display device that can detect mouse clicks and respond

using the location of the mouse click on the map to determine the action taken.Key Either a Primary Key or a Foreign Key.Landsat A series of earth orbiting NASA satellites that acquire multi-spectral images in various

visible and IR bands.Latitude Latitude is the Angular distance north or south from the earth’s equator measured

through 90 degrees.Link A hyperlink.Linux The operating system Linux, a Unix-like operating system available for most hardware

computing platforms.Login The process of gaining access to certain features of the AVS system.Longitude The angular distance measured on a great circle of reference from the intersection of the

adopted zero meridians with this reference circle to the similar intersection of the meridian passing through the object.

MacOS The Macintosh operating system features a graphical user interface (GUI) that utilizes windows, icons, and a mouse to make the computer simple to use.

Metadata Data describing the data contained in a database.Multi-spectral The use of two or more bands in remote sensing.Object An instance of a class used to describe real-world entities that have a counterpart within

the system. Object-Oriented A problem-solving paradigm that is based on abstracting real world entities including

their attributes and functions. Interactions between objects generate the functionality of programs.

Pixel A picture element. The smallest unit of information in an image.Precondition A condition that must be true prior to the execution of a piece of code.Primary Key A set of fields in a database table that is used to uniquely identify records in the table.Provider An organization or individual that will provide metadata for the AVS system.Query A user's request for information, generally as a formal request to a database.Radar An active form of remote sensing that operates in the microwave and radio wavelength

regions.Record A unique row in a table in a database consisting of a set of fields that describe a single

occurrence of some entity described by the table.Registered User A user of the AVS system that has an account, for example a validator, provider or an

administrator.Relational Database

A database where data is stored in tables, which contain records, which contain fields. Relationships between tables are defined by foreign keys.

Remote Sensing The measurement or acquisition of information about the Earth by a recording device that is not in physical contact with the Earth.

Resolution The fineness of detail that can be distinguished in an image. The real world size of the footprint of a pixel in a remote sensing image.

Scenarios Part of a use case consisting of a sequence of steps describing the interactions between a user and a system.

Search Engine A program that uses a search pattern to identify a set of web pages matching the search pattern.

Server A computer that provides services to other computers or to people.Spatial Resolution

The smallest object or feature detectable by the sensor. Also known as pixel size or resolution.


4/10/2023 6:33 PM

Page

viii


Spectral Resolution

The number and width (wavelength) of bands (meaningful portions) of electromagnetic energy detectable by a given sensor.

Table A collection of records in a relational database.Trigger Condition An event that leads to some consequence in the system either caused by an outside

entity, or a chain of events.Update The process of modifying, adding or removing existing data.Use Case Descriptions, from the user’s point of view, of the important operations that provide

value to a user. They describe the interactions between actors and the system.Use Case Diagram

A diagram that represents the use cases of the system, i.e., interaction among the system, external entities, and the principal users of the system.

Validator The actor who is responsible for verifying the accuracy of new or submitted data.Visitor The actor that is the main user of the system and who searches the system for data.Windows Operating System

A computer operating system by Microsoft that provides a graphical user interface (GUI), virtual memory management, multitasking, and support for many peripheral devices.

1.3.2. Acronyms and AbbreviationsTable 2 lists the acronyms and abbreviations used in this document with respect to AVS.

Table 2: Acronyms and Abbreviations

ACRONYMS MEANINGAVS A Virtual Supermarket for Remote Sensing Data and Images

DBMS Database Management System

DFD Data Flow Diagram

ESC Escape

GEON Geosciences Cyberinfrastructure Network

GIF Graphic Interchange Format

GIS Geographic Information System

GUI Graphical User Interface

JPEG Joint Photographic Experts Group (Image Format)

NASA National Aeronautics and Space Administration.

OS Operating System

PACES Pan American Center for Earth and Environmental Studies

SQL Structured Query Language

SRS Software Requirements Specification

STD State Transition Diagram

TIFF Tagged Image File Format

URL Universal Resource Locator.

UTEP University of Texas at El Paso

WWW World Wide Web

e.g. for example

RADAR Radio Detection And Ranging

i.e. that is


4/10/2023 6:33 PM

Page

ix


1.4. Overview The SRS is divided into four major sections: Introduction, General Description, Specific Requirements, and Appendices.

Section 2 (General Description) contains:

1) Product Perspective: description of the product and functionality provided by the product.

2) Product Features: main features of the product, including use cases

3) User Characteristics: description of each type of user of the system

4) General Constraints: constraints on the development team including organizational factors, hardware limitations, and security considerations.

5) Assumptions and Dependencies: factors that affect the requirements stated in the SRS.

Section 3 (Specific Requirements) contains:

1) External Interface Requirements: describes requirements for user, hardware, software, and communication interfaces.

2) Behavior Requirements: same class of user, related real-world objects, stimulus, related features, and functional requirements

3) Non-Behavioral Requirements: performance, qualitative, and design/implementation constraint requirements.

4) Other Requirements: database, operations, and site adaptation requirements.

Appendix A contains the AVS web page transition diagram.

Appendix B contains the AVS data base entries.

Appendix C contains the AVS class diagram.

Appendix D contains the AVS data flow diagram.

Appendix E contains the AVS prototype.

1.5. References[1] Roach, Steve. “Requirements Definition: Metadata for Earthbound Remote Sensing.” Jan 2004. [2] Keller, G. Randy. First Interview. 28 Jan 2004.[3] Keller, G. Randy. Second Interview. 05 March 2004.[4] Keller, G. Randy. Third Interview. 10 March 2004.[5] All-Programmatic Stars, CST, Sputnik. Interview Report. 06 February 2004.[6] Software Engineering I Class. Second Interview Transcript. 05 March 2004.[7] All-Programmatic Stars. Third Interview Transcript. 10 March 2004[8] All-Programmatic Stars, CST, Sputnik. Prototype Presentations. 10 March 2004.[9] All-Programmatic Stars, CST, Sputnik. Team SRS. 10 March 2004.[10] Roach, Steve. “Requirements” Email. 11 February 2004.[11] Roach, Steve. “Re: MEMO” Email. 04 April 2004.


4/10/2023 6:33 PM

Page

x


2. General DescriptionThis section of the SRS contains a description of the product and functionality provided by the product, main features of the product, a description of each type of user of the system, constraints on the development team, and factors that affect the requirements stated in the SRS. In order to describe what the system will do at a high-level Use Case diagrams and Scenarios are used in this section.

2.1. Product PerspectiveThe AVS system will serve as a search engine for remotely sensed data and it will allow scientists and the general public to search over a vast amount of remotely sensed data for sets of information. The system’s search interface will allow the user to specify various characteristics of the data in order to find data sets that match the given search criteria, e.g. spatial resolution, spectral resolution, geographical location, costs. The result of the queries will be links (URLs) to the location of the matching data. This system will also allow its users to provide data sets of their own which, after a validation process, will be supplied to the information repository in order to make it available to other users. This system is self-contained however, it is not independent given that its functionality relies on the database that PACES will provide, which will not be a part of the system.

AVS is a web-based software system that provides services for registered and non-registered users. Registered users, known as data providers, are able to store descriptions of their online remote sensing data sets. These data sets may include “pretty pictures”, geo-referenced images, and binary data. Providers add metadata to the system by providing a link to their data and a specific description of the data, including location, date, data type, longitude, and latitude. Non-registered users, known as visitors, can search and browse through the metadata. To maintain the security and integrity of the metadata, validators verify and data posted by data providers before it is available to visitors.

AVS is being developed for PACES. The technical mission of PACES is to contribute to NASA’s Earth and Science Enterprise by conducting research in several areas of the geological, physical and environmental sciences. Other search engines are available on the World Wide Web (WWW) to search for remotely sensed data however; these search engines are not unified as a common entity. The interfaces for each of these search engines vary, and the information they contain may not be as reliable as needed for scientific purposes. The AVS software system intends to merge all of the most important and dependable remotely sensed data sources into one entity that will provide this information for free to the general public, according to PACES mission statement.

2.2. User CharacteristicsThis section describes the actors of the system and gives a description of features and characteristics that influence the software system. The use case model consists of actors, use cases and relations among them.

2.2.1. ActorsThis section describes all of the users of the system and their different roles and general function in it. An actor is an outside entity that interacts with the proposed system. When an actor interacts with a system it performs a use case.

2.2.1.1. VisitorThis actor is a person who comes to the system to search for remotely sensed data. The visitor is a person who can either have a strong educational level or have no professional background, e.g. a Ph.D. and a high school student, respectively. The visitor may perform two types of search, a simple search by submitting a query to the search engine, or an advanced search, where the user is given a set of descriptions of type of data to be searched.


4/10/2023 6:33 PM

Page

xi


2.2.1.2. ProviderA provider is every entity that will provide descriptions and locations of remotely sensed data through our system. The perspective providers include research centers and commercial organizations which own remotely sense data.

2.2.1.3. ValidatorThis actor is the person in charge of reviewing and validating data for the system. Every time a set of data is proposed, it will be the responsibility of the validator to verify the content of the data and validate it, so it can be either accepted and uploaded into the system or rejected. The perspective validator is an administrative staff member from a research center.

2.2.1.4. DatabaseThe database will hold relations containing all the information that the system needs such as user’s profiles, metadata for both approved remotely sensed data and unapproved remotely sensed data and help topics.

2.3. Product FeaturesThe main features of this software system are:

The system provides an interface for searching for remotely sensed data that is available on-line.

The system provides an interface that enables data providers to describe the data sets they have available.

The system provides an interface that allows validators to accept or reject submitted metadata.

It is important to mention that the system will not manage actual pieces of remotely sensed data, but instead, it manages metadata that points to the actual location of remotely sensed data. Figure 1 contains the Use Case Diagram for the AVS system.

Figure 2-1: Use Case Diagram


4/10/2023 6:33 PM

Page

xii


2.3.1. Use Case DescriptionIn this section each use case of the system will be described. Use cases contain scenarios, which are the sequence of steps involved in the use case. Use cases are abstractions of the operations performed by the system that are valuable to the user. This modeling helps as a communication tool between developers and clients. The following is a description of each use case, its actors and the scenarios for that use case.

2.3.1.1. Use Case 1: Search for DataUse Case Description: A visitor uses a simple search for remote sensing data by entering a set of keywords or a more advanced search by entering parameters such as source, visual-infrared or radar, date and location. The system will display the results of the search.Actors: Visitor, Database.

2.3.1.1.1. Scenario 1: Simple Search

Preconditions: The visitor is viewing the Home Search Page as shown in Figure 3-5: Home/Search Page.Postconditions: The visitor is viewing the Search Results Page.1. The visitor enters a list of keywords describing the query.2. The visitor selects image (ALT 1).3. The visitor clicks the submit button.4. The system processes the visitor’s search query and constructs an SQL query.5. The system submits an SQL search query to the database.6. The database returns URLs and descriptions of metadata to the system.7. The system orders the results according to how well the metadata matches the query and how available the

site is.8. The system displays the ordered matches found, five results at a time. (ALT 2).9. The visitor scrolls forward through the list, five results per page.10. The visitor selects a search result (ALT 3).11. The system redirects the visitor to the URL associated with that metadata and records the visitors IP

address, the time, and the target of the click through.12. End of use case.

ALT 1: The visitor selects the dataset option.A1-1: The system continues with the Advanced Search, Use Case 1, Scenario 2.

ALT 2: The database returns no matches.A1-1: The system displays the message “No match found” on the Search Results Page. A1-2: End of use case.

ALT 3: The visitor refines his search query and enters a new list of keywords describing his query.A4-1: Return to Scenario 1, step number 2.

2.3.1.1.2. Scenario 2: Advanced Search

Preconditions: The visitor is viewing the Advanced Search Page as shown in Figure 2-2: Advanced Search Postconditions: The visitor is viewing the Search Results.1. The visitor enters a list of keywords describing his query.2. The visitor selects a source from the sources table (ALT 1, ALT 2).3. The visitor selects a footprint from the map of US & North America (ALT 1, ALT 3, ALT 4, ALT 5, ALT

6).4. The system displays the coordinates of the selected area.5. The visitor clicks the submit button.6. The system processes the visitor’s search query and constructs an SQL query.7. The system submits an SQL search query to the database.8. The database returns URLs and descriptions of metadata to the system.9. The system orders the results according to how well the metadata matches the query and how available the

site is.


4/10/2023 6:33 PM

Page

xiii


10. The system displays the ordered matches found, five results at a time. (ALT 7).11. The visitor scrolls forward through the list, five results per page.12. The visitor selects a search result (ALT 8, ALT 9, ALT 10).13. The system redirects the visitor to the URL associated with that metadata and records the visitors IP

address, the time, and the target of the click through.14. End of use case.

ALT 1: The visitor selects path and row option.A1-1: The visitor enters the path and row as search parameters.A1-2: Return to Scenario 2, step number 5.

ALT 2: The visitor clicks on the sensor guide link.A2-1: The system redirects the visitor to the Guided Sensor Search Page as shown in Figure 2-3: Guided

Sensor Search.A2-2: The visitor selects the free radio button.A2-3: The visitor selects a spectral resolution from the spectral resolution drop down list.A2-4: The visitor selects a spatial resolution from the spatial resolution drop down list.A2-5: The visitor clicks the submit button.A2-6: The system processes the visitor’s source search query and constructs an SQL query.A2-7: The system submits an SQL search query to the database.A2-8: The database returns the matching sensors.A2-9: The system redirects the visitor to the Advanced Search Page.A2-10: The system populates the sources table using the results of the matching sensors query.A2-11: Return to Scenario 2, step number 3.

ALT 3: The visitor selects coordinates option.A3-1: The visitor enters the longitude and latitude as search parameters.A3-2: Return to Scenario 2, step number 5.

ALT 4: The visitor selects another continent from the continent options.A4-1: The system displays a map for the selected continent.A4-2: The visitor selects an area from the selected map (ALT 1, ALT 2, ALT 3).A4-3: Return to Scenario 2, step number 4.

ALT 5: The visitor selects the option to zoom in.A5-1: The system changes the cursor pointer into a crosshair cursor.A5-2: The visitor left clicks on a point in the map.A5-3: The system refreshes the webpage displaying the zoomed map.A5-4: Return to Scenario 2, step number 3.

ALT 6: The visitor selects the option to zoom out.A6-1: The system changes the cursor pointer into a crosshair cursor.A6-2: The visitor left clicks on a point in the map.A6-3: The system refreshes the webpage displaying the zoomed map.A6-4: Return to Scenario 2, step number 3.

ALT 7: The database returns no matches.A7-1: The system displays a match not found message and an option to return to the Advanced Search Page.A7-2: The visitor selects the return option.A7-3: Return to Scenario 2, step number 1.

ALT 7: The visitor selects next page. A8-1: The system displays the results associated with the next page.A8-2: Return to Scenario 2, step number 11.


4/10/2023 6:33 PM

Page

xiv


ALT 9: The visitor selects the N page.A9-1: The system displays the results associated with the N page.A9-2: Return to Scenario 2, step number 11.

ALT 10: The visitor wishes to refine his search query and selects the advanced search option.A10-1: The system redirects the visitor to the Advanced Search Page. A10-2: Return to Scenario 2, step number 2.

2.3.1.1.3. Scenario 3: Help

Preconditions: The visitor is viewing the Home Search Page, or Advanced Search Page, or Search Results Page.Postconditions: The visitor is viewing the Search Help Page.1. The visitor selects the help option.2. The system redirects the visitor to the Search Help Page and to the section associated with the page from

which the visitor came from.3. End of use case.

2.3.1.1.4. Scenario 4: View Glossary

Preconditions: The visitor is viewing the Home Search Page, Advanced Search Page, or Search Results Page.Postconditions: The visitor is viewing the Glossary Page.1. The visitor selects the glossary option.2. The system redirects the visitor to the Glossary Page.3. End of use case.

2.3.1.1.5. Scenario 5: View Link Center

Preconditions: The visitor is viewing the Home Search Page, or Advanced Search Page, or Search Results Page.Postconditions: The visitor is viewing the Link Center Page.1. The visitor selects the link center option.2. The system redirects the visitor to the Link Center Page.3. The visitor selects a link from the list (ALT 1).4. The system redirects the visitor to the URL associated with that link.5. End of use case.

ALT 1: The visitor selects the option to return to the Home Search Page. A1-1: The system redirects the visitor to the Home Search Page. A1-2: End of use case.

2.3.1.1.6. Scenario 6: View Site Map

Preconditions: The visitor is viewing the Home Search Page, Advanced Search Page, or Search Results Page.Postconditions: The visitor is viewing the Site Map Page.1. The visitor selects the site map option.2. The system redirects the visitor to the Site Map Page.3. End of use case.

2.3.1.1.7. Scenario 7: View Contact Us

Preconditions: The visitor is viewing the Home Search Page, Advanced Search Page, or Search Results Page.Postconditions: The visitor is viewing the Contact Us Page.1. The visitor selects the contact us option.2. The system redirects the visitor to the Contact Us Page.3. The visitor selects the donate image option (ALT 1).4. The system redirects the user to the Paces Donation Webpage.5. End of use case.


4/10/2023 6:33 PM

Page

xv


ALT 1: The visitor selects the option to return to the Home Search Page. A1-1: The system redirects the visitor to the Home Search Page. A1-2: End of use case.

2.3.1.2. Use Case 2: RegisterUse Case Description: A prospective provider must register before s/he can make data available (Refer to Use Case 4). Registration is a one-time process after which the provider will be able to login.Actors: Provider, Database.

2.3.1.2.1. Scenario 1: First Time Provider

Preconditions: The provider is not registered. The provider is viewing the Provider Registration Page.Postconditions: The provider has successfully registered and an email with information has been sent to the provider.1. The system displays the Provider Registration Page. This page contains a form for the user to fill out with

the attributes listed below. The attributes marked with * are required.a. The provider’s first name. *b. The provider’s middle initial.c. The provider’s last name. *d. The provider’s email address. *e. The provider’s organization.f. The provider’s address.g. The provider’s category, i.e. commercial, government, educational or other.h. The provider’s login name. *i. The provider’s password. *j. The provider’s password verification. *

2. The provider fills out the form with the requested information and selects the option to submit (ALT 1).3. The system verifies that the required attributes are present, that the email address has a valid form, that the

login name does not exist in the database, and that the password and password verification are identical. (ALT 2, ALT 3).

4. The system displays a thank you page which contains instructions.5. The provider presses continue with login link option.6. The system displays the Login page (Refer to Use Case 3).7. End of use case.

ALT 1: The user selects the option to clear the form.A1-1: The system sets the webpage to its default state, without submitting any information.A1-2: System returns to Scenario 1, step number 1.

ALT 2: The system detects invalid registration information. Required fields are empty, email address does not have a valid format, the login name is already in use, or the passwords do not match.A2-1: The system displays the registration webpage.A2-2: The system informs that one or more of the required fields are incorrect (such as invalid login name, or

login name already exists), marks them in red, and includes description of appropriate corrective actions.

A2-3: The user corrects the marked fields and resubmits the information pressing the submit button (ALT 1).A2-4: System returns to Scenario 1, step number 3.


Preconditions: The provider is viewing the Provider Registration Page.Postconditions: The visitor is viewing the Provider Registration Page.1. The visitor selects the help option.2. The system redirects the visitor to the Search Help Page and to the section associated with the page from



4/10/2023 6:33 PM

Page

xvi


2.3.1.3. Use Case 3: LoginUse Case Description: A provider or validator must login with a valid login name and password in order to access restricted functions. These include providing data (Refer to Use Case 4) and validating data (Refer to Use Case 5). Actors: Provider, Validator, Database.

2.3.1.3.1. Scenario 1: Login

Preconditions: The Actor must be registered (Refer to Use Case 2). The Actor is viewing the Login Page.Postconditions: The Actor has successfully logged into the system.1. The system displays the Login Page.2. The Actor enters a login name, a password and selects the submit option (ALT 1).3. The system submits an SQL search query to the database using the login name.4. The database returns the encrypted password.5. The system encrypts the password entered and compares to the password returned by the database. The

passwords match (ALT 2). NOTE: The password is encrypted on the client side and compared on the server side. The server does not send an encrypted password to a client, and an unencrypted password is never transferred over the network.

6. The system redirects the Actor to the Actor Page.7. End of use case.

ALT 1: The Actor selects the cancel option.A1-1: The system returns to the Home Search Page.A1-2: End of use case.

ALT 2: The system detects invalid login name or password.A2-1: The system displays an error page.A2-2: The system waits 5 seconds.A2-3: System returns to Scenario 1, step number 1.

2.3.1.3.2. Scenario 2: Password Recovery

Preconditions: The Actor must be registered. The Actor is viewing the Login Page.Postconditions: The Actor has successfully received an email with his password.1. The system displays the Login Page.2. The Actor selects forgot password option.3. The system displays the Password Recovery Page.4. The Actor enters his log in name.5. The system submits an SQL search query to the database using the login name (ALT 1).6. The database returns the Actor’s email address.7. The system creates a new temporary password and emails it to the Actor.8. The system submits the new password to the database.9. The system sends the new password to the Actor’s email address.10. The system displays the Password Recovery Instructions Page with instructions.11. End of use case.

ALT 1: The Actor login name is not found.A1-1: The system displays a webpage indicating that the provider login name was not found.A1-2: The Actor hits the ok button.A1-3: The system redirects the Actor to the Provider Registration Page (Refer to Use Case 2).A1-2: End of use case.


Preconditions: The visitor is viewing the Login Page.Postconditions: The visitor is viewing the Login Help Page.1. The visitor selects the help option.


4/10/2023 6:33 PM

Page

xvii


2. The system redirects the visitor to the Login Help Page and to the section associated with the page from which the visitor came from.

3. End of use case.

2.3.1.4. Use Case 4: Provide DataUse Case Summary: The provider wants to submit a description of metadata for consideration; the proposed metadata must be validated before added to the system (Refer to Use Case 5).

Actors: Provider, Database.

2.3.1.4.1. Scenario 1: Submit Data

Preconditions: The provider must be logged in to the system (Refer to Use Case 3). The provider is viewing the Provider Page.Postconditions: Metadata has been successfully submitted.1. The provider selects the submit metadata option on the Provider Page.2. The system displays the Submit Metadata Page for data submission.3. The provider enters the following metadata:

a. A URL for the data set.b. A description which will not exceed 250 words describing the data set.c. Source of the data set.

4. The provider enters the coordinates of the data set which can be (ALT1, ALT2):a. Longitude and Latitude.b. Path and Row.

5. The provider selects the option to submit the data (ALT 3).6. The system informs provider that the information supplied has been stored into the database and will be

validated.7. The system returns the provider to the Provider Page. 8. End of use case.

ALT 1: The provider selects an area on the map of US & North AmericaA1-1: The system displays the coordinates entered.A1-2: Return to Scenario 1, step number 5.

ALT 2: The provider selects another continent.A2-1: The system displays the map for the selected continentA2-2: The provider selects an area on the selected map.A2-3: Return to Scenario 1, step number 5.

ALT 3: The provider selects the clear option.A3-1: The system clears all fields in the submission form.A3-2: Return to Scenario 1, step number 2.

2.3.1.4.2. Scenario 2: Submit Software Metadata

Preconditions: The provider must be logged in to the system (Refer to Use Case 2). The provider is viewing the Provider Page.Postconditions: Software Metadata has been successfully submitted.1. The provider selects the submit software metadata option on the Provider Page.2. The system displays the Submit Software Metadata Page for submission.3. The provider enters the following metadata:

a. A URL for the software.b. A description which will not exceed 250 words describing the data set.c. A number representing the cost of the software.


validated.


4/10/2023 6:33 PM

Page

xviii


6. The system returns the provider to the Provider Page. 7. End of use case.


2.3.1.4.3. Scenario 3: Submit Glossary Entry

Preconditions: The provider must be logged in to the system (Refer to Use Case 2). The provider is viewing the Provider Page.Postconditions: Glossary entry has been successfully submitted.1. The provider selects the submit glossary entry option on the Provider Page.2. The system displays the Submit Glossary Entry Page for submission.3. The provider enters the following metadata:

a. A term.b. A description which will not exceed 250 words describing the term.


validated.6. The system returns the provider to the Provider Page. 7. End of use case.


2.3.1.4.4. Scenario 4: Donate Data to PACES

Preconditions: The provider is viewing the Contact Us Page.Postconditions: The provider has been redirected to PACES.1. The provider selects the donate metadata option on the Contact Us Page.2. The system redirects the provider to the PACES donations web page.3. End of use case.

2.3.1.4.5. Scenario 5: Change Account Information

Preconditions: The provider must be logged in to the system (Refer to Use Case 3). The provider is viewing the Provider Page.Postconditions: The provider has changed his information.1. The provider selects the change account option on the Provider Page.2. The system submits an SQL search query to the database using the login name for the provider.3. The database returns all the account information associated with that provider login name.4. The system redirects the provider to the Change Provider Information Page.5. The system displays a form with all the attributes associated with that user.6. The provider changes a field.7. The provider selects submit changes (ALT1).8. The system sends the new information to the database.9. The system displays a message saying that the account has been updated.10. The system redirects the provider to the Provider Page.11. End of use case.

ALT 1: The provider selects the cancel option.A1-1: The system redirects the user to the Provider Page.A1-2: End of use case.



4/10/2023 6:33 PM

Page

xix


Preconditions: The visitor is viewing the Provider Page, Submit Metadata Page, Submit Software Metadata Page, Glossary Entry Page, and Change Provider Information Page.Postconditions: The visitor is viewing the Provider Help Page.1. The visitor selects the help option.2. The system redirects the visitor to the Provider Help Page and to the section associated with the page from


2.3.1.5. Use Case 5: Validate DataUse Case Description: The validator wants to review selected metadata in the database. After review, the data may be accepted or rejected. If the data is accepted, then it is added to the database and will be available for others; otherwise, it will not be added and a notification will be sent to the provider. The Validator web site is distinct from the Visitor/Provider site. This is to simplify the user interfaces.Actors: Validator, Database.

2.3.1.5.1. Scenario 1: Review Data

Preconditions: The validator must be logged in to the system (Refer to Use Case 3). The validator is viewing the Validator Page.Postconditions: Metadata has been reviewed.1. The validator selects the validate metadata option on the Validator Page.2. The system redirects the validator to the Metadata Validation Page.3. The validator selects the review metadata option associated with that dataset from the table (ALT 1).4. The system displays the data from the dataset.5. The validator approves the data (ALT 2).6. The system marks the dataset as reviewed and makes the metadata available for visitor searches (Refer to

Use Case 1). 7. The system sends an email to the provider indicating that the data set has been accepted.8. The system redirects the validator to the Validator Page.9. End of use case.

ALT 1: The validator selects the cancel option.A1-1: The system redirects the user to the Provider Page.A1-2: End of use case.

ALT 2: The validator selects the disapprove option.A2-1: The system marks the data as disapproved.A2-2: The system prompts the validator for an explanation.A2-3: The validator enters an explanation.A2-4: The validator selects the submit option.A2-5: The system sends an email to the provider indicating that the data has been rejected, including the

validator’s explanation.A2-6: The system redirects the validator to the Validator Page.A2-7: Return to Scenario 1, step number 1.

2.3.1.5.2. Scenario 2: Validate Software Metadata

Preconditions: The validator must be logged in to the system (Refer to Use Case 3). The validator is viewing the Validator Page.Postconditions: Software has been reviewed.1. The validator selects the validate software option.2. The system redirects the validator to the Software Validation Page.3. The validator selects the review software option associated with that dataset from the table (ALT 1).4. The system displays the software information from the list.5. The validator approves the data (ALT 2).


4/10/2023 6:33 PM

Page

xx


6. The system marks the dataset as reviewed and makes the metadata available for visitor searches (Refer to Use Case 1).

7. The system sends an email to the provider indicating that the data set has been accepted.8. The system redirects the validator to the Validator Page 9. End of use case.


ALT 2: The validator selects the disapprove option.A2-1: The system marks the data as disapproved.A2-2: The system prompts the validator for an explanation.A2-3: The validator enters an explanation.A2-4: The validator selects the submit option.A2-5: The system sends an email to the provider indicating that the data has been rejected, including the


2.3.1.5.3. Scenario 3: Submit Glossary Entry

Preconditions: The validator must be logged in to the system (Refer to Use Case 3). The provider is viewing the Validator Page.Postconditions: Glossary has been reviewed.1. The validator selects the validate glossary entry option.2. The system redirects the validator to the Glossary Term Validation Page.3. The validator selects the review glossary term option associated with that term from the table (ALT 1).4. The system displays the glossary term definition from the list.5. The validator approves the data (ALT 2).6. The system marks the glossary term as reviewed and makes the term available for visitor viewing the

glossary (Refer to Use Case 1). 7. The system sends an email to the provider indicating that the data set has been accepted.8. The system redirects the validator to the Validator Page 9. End of use case.


ALT 2: The validator clicks disapprove option.A2-1: The system marks the data as disapproved.A2-2: The system prompts the validator for an explanation.A2-3: The validator enters an explanation.A2-4: The validator selects the submit option.A2-5: The system sends an email to the provider indicating that the data has been rejected, including the


2.3.1.5.4. Scenario 4: Change Account Information

Preconditions: The validator must be logged in to the system (Refer to Use Case 3). The validator is viewing the Validator Page.Postconditions: The validator has changed his information.1. The validator selects the change account option on the Validator Page.2. The system submits an SQL search query to the database using the login name for the validator.


4/10/2023 6:33 PM

Page

xxi


3. The database returns all the account information associated with that validator.4. The system redirects the validator to the Change Validator Information Page.5. The system displays a form with all the attributes associated with the user.6. The validator changes a field.7. The validator selects submit changes (ALT1).8. The system sends the new information to the database.9. The system displays a message saying that the account has been updated.10. The system redirects the validator to the Validator Page.11. End of use case.

ALT 1: The validator selects the cancel option.A1-1: The system redirects the user to the Validator Page.A1-2: End of use case.


Preconditions: The visitor is viewing the Validator Page, Validate Metadata Page, Validate Software Page, Validate Glossary Entry Page, and Change Validator Information Page.Postconditions: The visitor is viewing the Validator Help Page.1. The visitor selects the help option.2. The system redirects the visitor to the Validator Help Page and to the section associated with the page from


2.4. General ConstraintsThe following constraints are recognized.

The database management system will be Oracle. The Oracle system will run on a server, and the user will access the server via the Internet.

The clients may change the database from Oracle to some other commercial product. The design should minimize the impact of this change.

The system will be completed by December 1, 2004. Developed with intent of integrating with GEON: use .NET platform

2.5. Assumptions and Dependencies A windows compatible version of all the External Programs will be made available. Examples of data sets will be made available prior to November 2004. The PACES server will be a HP Proliant DL380, Dual processor, Intel XEON 3.2 GHz with Windows

Server 2003, Enterprise Edition.


4/10/2023 6:33 PM

Page

xxii


3. Specific RequirementsThis section contains external interface requirements, behavioral requirements, and non-behavioral requirements.

3.1. External Interface RequirementsThis section contains the specification of requirements for interfaces among different components and their external capabilities, including all its users, both human and other systems.

3.1.1. Hardware Interfaces There are no hardware interface requirements for this system.

3.1.2. Software Interfaces

3.1.2.1. General Interface Requirements[SRSreq 01] The system shall have a web-based graphical user interface (GUI) constructed from standard

web-interface elements such radio buttons, text boxes, check boxes, drop down lists, tables, and URLs.

[SRSreq 02] The system’s web interface shall accept user input from the keyboard and from the mouse.

[SRSreq 03] The system shall have scroll bars for web pages displaying a more text than fits in the currently displayed window.

[SRSreq 04] The system shall present a confirmation prompt to the user with the options to continue or cancel the operation whenever a user selects an operation that may modify the contents of the database.

[SRSreq 05] The title for all the webpages on the system shall be composed of the text “Remote Sensing Supermarket” and the title of the specific page. Specific page names are given in the page transition map given in Appendix A: Web Page Transitions.

[SRSreq 06] Each webpage will display hyperlinks to adjacent pages as shown in Appendix A: Web Page Transitions.

[SRSreq 07] All webpages shall contain the logos from appropriate sponsors. These include, UTEP, PACES, NASA, and GEON. These logos shall be hyperlinked to the homepages of these organizations.

[SRSreq 08] Each web page that responds to user actions shall have an associated help page. Pages requiring help pages are shown in Appendix A: Web Page Transitions. Each help page shall contain instructions and explanations on how to use the webpage associated with it.

3.1.2.2. Visitor Pages[SRSreq 09] The Home/Search webpage shall contain a description of the motivation and purpose behind the

system being built, as shown Figure 3-5: Home/Search Page.

[SRSreq 10] The Glossary Page shall contain links to approved remote sensing glossaries available on line and a list of terms and definitions provided by the client and AVS users.

[SRSreq 11] When the length of the number of entries displayed in The Glossary Page exceeds two standard window lengths, the Glossary Page shall have hyperlinked shortcuts to each letter of the alphabet to facilitate faster searches.

[SRSreq 12] The Site Map Page shall contain a graphical representation of the layout of the system’s webpages.

[SRSreq 13] The Link Center shall display a table containing links to other sites of interest.

[SRSreq 14] The Contact Us Page shall display information on how to contact the persons responsible for the system and a link to the PACES donations webpage.

Software Engineering II CS 4311 Fall 2004 Date4/10/2023 6:33 PM

Page23


[SRSreq 15] The Advanced Search Page shall display table containing sensor sources and an interactive map as shown in Figure 3-4: Advanced Search.

[SRSreq 01] The Guided Sensor Search Page shall allow a visitor to describe a source and the system will search the database for matching sources as shown in Figure 3-8: Guided Source Search.

[SRSreq 02] The interactive map in the Advanced Search Page shall allow for zoom in, zoom out and placing footprints on the map.

[SRSreq 03] The Search Results Page shall contain the total number of results returned by the query, result descriptions, and links to the URL of the result.

[SRSreq 04] The Search Results Page shall contain a numeric sequence of links labeled with numbers that behave as follows:

o Only the next 5 pages shall be displayed at a time, for example “1 2 3 4 5 NEXT”o After the first 5 results the links label shall display “PREV 6 7 8 9 10 NEXT”o On the last 5 results the links label shall display “PREV 11 12 13 14 15” o Each number shall act as a link to that page in the order of how the matching pages were

sorted.

Figure 3-5: Home/Search Page

3.1.2.3. Provider Pages[SRSreq 05] The Login Page shall provide for the entry of a user’s login name and password. It will provide a

clickable button labeled “Logon”.

[SRSreq 06] The Password Recovery Page shall provide for the user entry of an email address. It shall provide a clickable button labeled “Submit.”

[SRSreq 07] The Register Page shall provide fields for users to enter the following text elements (the elements marked with “*” are required):

First Name* Middle Initial Last Name* Email Address* Organization


Page24


Address Organization Type Login Name* Password* Verify Password*

[SRSreq 08] The Change Provider Information Page shall provide an interface that displays all of the provider information obtained from the Register page and allows a user to modify the data.

[SRSreq 09] The Submit Metadata Page shall allow a provider to enter a URL, a text description of up to 250 words, a sensor source and the observed location of the metadata by either entering the coordinates or by drawing a footprint on a map. (A word is a maximum of 5 characters.)

[SRSreq 10] The Submit Software Metadata Page shall allow a provider to enter a URL, a text description of up to 250 words, and a cost. (A word is a maximum of 5 characters.)

[SRSreq 11] The Submit Glossary Term Page shall allow a provider to enter a term and a definition. The definition may contain up to 250 words. (A word is a maximum of 5 characters.)

3.1.2.4. Validator Pages[SRSreq 12] The validator interface shall be accessed through a different URL than the visitor and provider

URL.

[SRSreq 13] The Validate Software Metadata Page shall display the URL, description, metadata, and cost of metadata entries that have not yet been validated.

[SRSreq 14] The Validate Glossary Term Page shall display the term and description for each entry that has not yet been validated.

[SRSreq 15] The Change Validator Information Page shall provide an interface that displays all of the validator information and allows a user to modify the data.

3.2. Communications Interfaces PACES is currently involved in the development of the GEON grid, a cyberinfrastructure for the geological sciences. To this end, the AVS system’s functionality must be adaptable to grid services. The following requirements enable the system to be ported to grid services in the future.

[SRSreq 16] The AVS system shall provide all of the search functionality as Web Services.

3.3. Behavioral Requirements

3.3.1. Same Class of User[SRSreq 17] The primary system shall support two kinds of user: Visitors and Providers.

[SRSreq 18] A separate site shall support Validators. This site shall be accessed through a different URL than the URL of the primary system.

[SRSreq 19] The system shall allow a user to access the help page for any page to which the user has access.

3.3.1.1. Visitor[SRSreq 20] The system shall allow a visitor to search for images or datasets.

[SRSreq 21] The system shall allow a visitor to search by using a simple search or an advanced search.

[SRSreq 22] The system shall allow a visitor to view a glossary term.

[SRSreq 23] The system shall allow a visitor to read the help web pages.

[SRSreq 24] The system shall allow a visitor to view a site map.


Page25


[SRSreq 25] The system shall allow a visitor to read the contact information to the organization responsible for maintaining the system.

[SRSreq 26] The system shall allow a visitor to access the link center.

3.3.1.2. Provider[SRSreq 27] The system shall require a provider to login before allowing access to provider functions.

[SRSreq 28] The system shall allow a provider to submit remote sensing metadata into the system.

[SRSreq 29] The system shall allow a provider to submit software metadata into the system.

[SRSreq 30] The system shall allow a provider to submit glossary terms into the system.

[SRSreq 31] The system shall allow a provider to change his/her account information.

3.3.1.3. Validator[SRSreq 32] The system shall require a validator to login before allowing access to provider functions.

[SRSreq 33] The system shall allow a validator to validate remote sensing metadata.

[SRSreq 34] The system shall allow a validator to validate software metadata into the system.

[SRSreq 35] The system shall allow a validator to validate glossary terms into the system.

3.3.2. Related Real-world ObjectsNo further related real-world object requirements have been identified.

3.3.3. Stimulus[SRSreq 36] When the visitor selects a hyperlink on any of the system’s pages, the system shall redirect the

visitor’s browser to the link’s target page. Links internal to the system are described in Appendix A: Web Page Transitions.

3.3.3.1. Visitor Stimulus[SRSreq 37] When a visitor selects the Search option and no search criteria have been entered or selected, the

system shall ignore the selection and continue to display the current page.

[SRSreq 38] When a visitor selects the Search option and a search query has been entered on the Home Search page, the system shall scan the search query, extract key words, construct and submit an SQL query to the DBMS, and display the results in a Search Results page.

[SRSreq 39] When a visitor selects the submit option on the Advanced Search Page, the system shall construct an SQL query based on the visitor’s entries. The SQL query shall be sent to the database.

[SRSreq 40] When the system receives results from the database for a query, the system shall build and display the results dynamically.

[SRSreq 41] On the Advanced Search Page, upon the visitor clicking on another continent link the system shall switch the default map to that continent’s map.

[SRSreq 42] When the visitor clicks on the Footprint button the system shall change the cursor into a crosshair and enable drawing footprints on the map.

[SRSreq 43] When drawing footprints is enabled, if the visitor clicks and holds the left button of the mouse on the map the system shall start drawing a footprint.

[SRSreq 44] When drawing footprints is enabled and if the visitor is holding the left button of the mouse, if the visitor drags the mouse over an area a footprint shall be drawn on the map.

[SRSreq 45] When drawing footprints is enabled and if the visitor is holding the left button of the mouse, if the visitor releases the left button of the mouse the system shall disable drawing, change the crosshair cursor into a normal cursor and fill in the coordinates.


Page26


[SRSreq 46] When drawing footprints is enabled, and the user clicks on an area outside of the map the system shall disable footprint drawing and switch the crosshair cursor to the normal cursor.

[SRSreq 47] On the Guided Sensor Search Page upon the user answering at least one question, the system shall construct an SQL query based on options selected. The SQL query shall be sent to the database.

[SRSreq 48] When the system receives results from the database for a source search query, the system shall redirect the user to the Advanced Search Page and fill the dynamic table with the returned matches.

[SRSreq 49] On the Search Results Page, upon the visitor clicking on a URL link the system shall redirect the browser to that URL and capture the IP address of the visitor, the time, and the target URL.

[SRSreq 50] On the Search Results Page, upon the visitor clicking on the numeric link the system shall redirect the browser to the results of that page.

[SRSreq 51] On the Search Results Page, upon the visitor clicking on the PREV/NEXT link the system shall redirect the browser to the results of the previous/next page respectively.

3.3.3.2. Provider Stimulus[SRSreq 52] When a user selects the Submit option on the Register Page, the system shall validate the entry,

store the entry in the database, and send an email to the user.

[SRSreq 53] The system shall consider a registration entry to be valid if all the required fields have text, the password and verify password entries are identical and non-empty, the login name does not already exist in the user table of the database, and the email address consists of letters and digits, periods, and exactly one “@” symbol. The following fields are required:

o First Nameo Last Nameo Email Addresso Login Nameo Passwordo Verify Password

[SRSreq 54] When a user selects the Submit option on the Login Page, the system shall attempt to authenticate the user. The system shall create an SQL query, submit it to the database, and accept a response. The query will consist of the user login name and the password. The system must encrypt the login information prior to sending data across the internet.

[SRSreq 55] When the system authenticates a provider, the system shall display the Provider page.

[SRSreq 56] When the system fails to authenticate a provider, the system shall wait five seconds and then display the following error message “Incorrect password or incorrect user.”

[SRSreq 57] When the user selects the submit option on the Password Recovery page, the system shall construct an SQL query using the data entered in the email address input area. The query shall be sent to the database.

[SRSreq 58] If a password recovery query returns a match, an email containing a temporary password shall be sent to the email address. (This is actually a security hole.)

[SRSreq 59] If a password recovery query fails to return a match, the system shall display an error message.

[SRSreq 60] When a provider selects the logoff option on any provider page, the system shall log the user off the system and return to the Home Search Page.

[SRSreq 61] When a provider selects the submit option on the Submit Metadata, the Submit Software Metadata, or the Submit Glossary Term page, the system shall capture the input information and send a SQL query storing this information as unverified metadata.

[SRSreq 62] When the system displays the Change Provider Information page, the system will extract registration information from the database for the currently logged in provider. The page will


Page27


appear as the registration page does, except that the fields will be filled with the provider information.

[SRSreq 63] When a provider selects the submit option on the Change Provider Information page, the system shall validate the information in the same manner as for the Register User page.

[SRSreq 64] When a provider selects the submit option on the Change Provider Information page and the system validates the information, the system shall submit an SQL query to update the database with the new data.

3.3.3.3. Validator Stimulus[SRSreq 65] When the validator selects the accept option on a Validate Metadata Page, the system shall mark

the data as verified, update the database, and send an email to the provider notifying the provider that the metadata has been accepted.

[SRSreq 66] When the validator selects the reject option on a Validate Metadata Page the system shall open a dialog to allow the validator to enter an explanation for the rejection. When the validator has completed this and selects send, the system shall update the database and send an email to the provider including the explaination.

[SRSreq 67] When the validator selects the accept option on a Validate Glossary Page, the system shall mark the data as verified, update the database, and send an email to the provider notifying the provider that the glossary term has been accepted.

[SRSreq 68] When the validator selects the reject option on a Validate Glossary Page the system shall open a dialog to allow the validator to enter an explanation for the rejection. When the validator has completed this and selects send, the system shall update the database and send an email to the provider including the explaination.

[SRSreq 69] When the validator selects the accept option on a Validate Software Metadata Page, the system shall mark the data as verified, update the database, and send an email to the provider notifying the provider that the metadata has been accepted.

[SRSreq 70] When the validator selects the reject option on a Validate Software metadata Page the system shall open a dialog to allow the validator to enter an explanation for the rejection. When the validator has completed this and selects send, the system shall update the database and send an email to the provider including the explaination.

[SRSreq 71] When the system displays the Change Validator Information page, the system will extract registration information from the database for the currently logged in validator. The page will appear as the registration page does, except that the fields will be filled with the validator information.

[SRSreq 72] When a provider selects the submit option on the Change Validator Information page, the system shall validate the information in the same manner as for the Register User page.

[SRSreq 73] When a provider selects the submit option on the Change Validator Information page and the system validates the information, the system shall submit an SQL query to update the database with the new data.

3.3.4. Related Features

3.3.4.1. Querying [SRSreq 74] The input to searches shall be TBD???. The system shall TBD???

[SRSreq 75] The results of searches shall be ordered. The ordering shall be determined by the degree of match of the result to the query and the availability of the web page server for the target site. Given the same degree of match, a more available server shall appear above a less available one.


Page28


3.3.4.2. Automated Data Collection[SRSreq 76] The system shall test and record the availability of provider sites by checking the site four times

per day.

[SRSreq 77] The system shall detect and record the IP address of each visitor. The IP address, the date and time of the visit, and any site visited via click through shall be recorded.

3.3.4.3. Creating Administrative Reports[SRSreq 78] The system shall support the creation of the following reports: System Usage Report, Available

Link Report, and Pending Metadata Report.

[SRSreq 79] The System Usage Report shall contain data about the number of queries for a given time, the average queries by time of day, and the average queries per month. The reports shall contain tabular as well as graphical outputs.

[SRSreq 80] The Available Link Report shall display a summary of the availability of sites registered with the system.

[SRSreq 81] The Pending Metadata Report shall display a summary of metadata submitted by providers but not yet approved by validators.

3.3.5. FunctionalNo further functional requirements have been identified.

3.4. Non-behavioral Requirements

3.4.1. Performance Requirements[SRSreq 82] The system shall be able to service at least 100 hits per second.

[SRSreq 83] The system shall send an email with a password within 1 second of request.

[SRSreq 84] The system shall be able to process 20 queries per second with a response time of 1 second or less.

3.4.2. Qualitative Requirements

3.4.2.1. Availability No availability requirements have been identified.

3.4.2.2. Security[SRSreq 85] The system (server) shall restrict access to provider and validator functions by using a userid and

passwords.

[SRSreq 86] The system shall encrypt the passwords in the DBMS.

[SRSreq 87] The system shall never send an unencrypted password over the internet.

[SRSreq 88] Passwords shall always be encrypted using the .NET Encryption component.

3.4.2.3. MaintainabilityNo maintainability requirements have been identified.

3.4.2.4. Portability[SRSreq 89] The system shall be compatible with the following web browsers: Internet Explorer, Mozilla,

Opera, and Netscape. All input functions shall be tested under these systems.


Page29


3.4.3. Design and Implementation Constraints[SRSreq 90] The system design shall be an object-oriented design. This design shall be documented using the

CRC Design Assistant.

[SRSreq 91] The system shall be implemented using the .NET architecture. The system’s GUI shall be built as Web Applications.

3.5. Other Requirements

3.5.1. Database[SRSreq 92] The system shall interface with a DBMS described in Error: Reference source not found

[SRSreq 93] The database system on the server side shall be an Oracle database. The DBMS shall be provided by PACES.

[SRSreq 94] The database shall be factored into third normal form or Boyce-Codd normal form in order to avoid update and delete anomalies.

3.5.2. Operations[SRSreq 95] Operation of the system shall be handed over to the PACES staff upon delivery of the system.

3.5.3. Site AdaptationSince the system will be installed and will run on the PACES server, no additional site adaptation is necessary.


Page30


4. Appendix A: Web Page Transitions

Figure 4-6: Visitor Web Page Transition Diagram


Page31


Figure 4-7: Validator Web Page Transition Diagram


Page32


5. Appendix B: Database Fields The following tables describe the data and information required. It is organized by topic.

This table contains all the accounts for registered users.

Table 3: Account Information

Data Element DescriptionLogin name A user login name. This must be unique in the system (no two users can have

the same login name). The login name may be upto 32 characters long.E-mail Address A valid email address. Valid email addresses must have the following format:

<username> @ <hostname> <. Subdomain>+ . <domain>The username in the email does not need to match the login name.

Password A pass phrase used to access the system. Pass phrases must be at least 4 characters long, and they may be up to 256 characters. Spaces and special characters are allowed. Pass phrases are case sensitive.

Name The name (title, first, middle, and last) of the account holder.Contact information The physical mail address of the account holder. Work and fax phone numbers

(optional). Organization The name and location of the organization and department with which the

account holder is affiliated.Account Type The type of user: Visitor, Provider, Validator, Administrator.

This table contains all the metadata for the system.

Table 4: Metadata

Data Element DescriptionURL The internet location of the data described by this metadata entryTitle A brief (80 character) phrase used to identify the data set.

DescriptionA natural language description of the dataset described by this metadata entry. Descriptions can be up to 10,000 characters.

Organization The name and contact information for the organization sponsoring the URL.Source The sensor used to collect the data.Range The minimum and maximum latitudes and longitudes bounding the dataset.Validated A Boolean flag that when true, indicates the metadata has been validated and

is available to the general public.Validation entry User name of validator and the date and time of validation. Also, notes added

by validator such as justification for rejection.Metadata Type Software or Dataset

This table contains all the sensors and their respective attributes.

Table 5: Instrument Information

Data Element DescriptionInstrument title Instrument title, such as Landsat.Spectral ResolutionSpatial ResolutionCost Description of the cost structure. Description Natural language description of instrument, up to 10,000 characters.


Page33


This table contains glossary entries.

Table 6: Glossary information

Data Element DescriptionEntry Word or phrase to be defined.Definition Up to 2048 characters defining the entry.TypeVerified A Boolean flag that when true, indicates the metadata has been validated and

is available to the general public.Validation entry User name of validator and the date and time of validation. Also, notes added

by validator such as justification for rejection.

This table contains the links for the Link Center

Table 7: Link Center Data

Data Element DescriptionTitle Title to appear as the hyper link.Description Up to 10,000 characters describing the linkURL The target of the link


Page34


6. Appendix C: AVS System Class Diagram

Provider Validator

Help

SearchEngineResults

0..* 10..* 1

LinkCenter

MapGlossary

GUI

1..*1

1..*1

1

1

1

1

1..*1..*

1

1

1

1

1

1

1

1

Login

1..*1 1..*1

Account

11

Registered User

1

1..*

1

1..*

1

1

1

1

Database Interface

1

1

1

1

1

1..*

1

1..*

111

1

Figure 6-8: Class Diagram


Page35


7. Appendix D: AVS System Data Flow Diagram

Figure 7-9: Data Flow Diagram – Visitor

Figure 7-10: Data Flow Diagram – Provider


Page36


Figure 7-11: Data Flow Diagram – Validator


Page37


8. Appendix E: AVS System Prototype

Figure 8-12: Change Provider Information


Page38


Figure 8-13: Advanced Search


Page39


Figure 8-14: Metadata Validation


Page40


Figure 8-15: Login

Figure 8-16: Provider Registration


Page41


Figure 8-17: Submit Metadata


Page42


Figure 8-18: Validator Homepage

Figure 8-19: Guided Source Search

#


Page43