CS 4311 Fall 2004: A Virtual Supermarket For Remote Sensing Data and Images

CS 4311 Fall 2004
A Virtual Supermarket for Remote Sensing Data and Images

Version <0.91> 9/22/2011
2004 Software Engineering II
CS 42311 Fall 2004
Software Requirements Specification
Document Control
Approval
The Guidance Team and the customer shall approve this document.
Document Change Control

Initial Release: Current Release: Indicator of Last Page in Document: Date of Last Review: Date of Next Review: Target Date for Next Update: 0.1 0.91 # 08/28/04 08/31/04 09/05/04
Distribution List
This 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 Roach Dr. Ann Gates Dr. Yoonsik Cheon Omar Ochoa Customer: Dr. G. Randy Keller Pan-American Center for Earth and Environmental Studies
Software Team Members: All-Programmatic Stars CST Sputnik
Change Summary
The following table details changes made between versions of this document
Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.91 Date 05/25/2004 07/06/2004 07/12/2004 08/01/2004 08/16/2004 08/20/2004 08/25/2004 08/27/2004 08/31/2004 09/02/2004 Modifier Omar Ochoa Steve Roach Omar Ochoa Omar Ochoa Omar Ochoa Steve Roach Steve Roach Omar Ochoa Omar Ochoa/Steve Roach Omar Ochoa Description Merging of Documents Sections 1 and 2 revised Changed Definitions and Section 2 Revised Section 2 Section 3 Section 3 Section 3, Appendices Use Case Diagram, Appendices, Section 3 Use Cases, Section 3, Appendices Appendices
Software Engineering II
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page ii
TABLE OF CONTENTS
DOCUMENT CONTROL...........................................................................................................................II
APPROVAL.........................................................................................................II DOCUMENT CHANGE CONTROL.............................................................................II DISTRIBUTION LIST.............................................................................................II CHANGE SUMMARY.............................................................................................II

1. INTRODUCTION....................................................................................................................................VI
1.1. PURPOSE AND INTENDED AUDIENCE................................................................VI 1.2. SCOPE OF PRODUCT......................................................................................VI 1.3. DEFINITIONS, ACRONYMS, AND ABBREVIATIONS..............................................VII
1.3.1. Definitions....................................................................................................................................vii 1.3.2. Acronyms and Abbreviations.........................................................................................................ix
1.4. OVERVIEW .................................................................................................IX 1.5. REFERENCES.................................................................................................X

2. GENERAL DESCRIPTION...................................................................................................................XI
2.1. PRODUCT PERSPECTIVE.................................................................................XI 2.2. USER CHARACTERISTICS................................................................................XI

2.2.1. Actors.............................................................................................................................................xi
2.2.1.1. Visitor....................................................................................................................................................xi 2.2.1.2. Provider................................................................................................................................................xii 2.2.1.3. Validator...............................................................................................................................................xii 2.2.1.4. Database...............................................................................................................................................xii
2.3. PRODUCT FEATURES....................................................................................XII

2.3.1. Use Case Description..................................................................................................................xiii
2.3.1.1. Use Case 1: Search for Data................................................................................................................xiii 2.3.1.2. Use Case 2: Register...........................................................................................................................xvi 2.3.1.3. Use Case 3: Login.............................................................................................................................xvii 2.3.1.4. Use Case 4: Provide Data..................................................................................................................xviii 2.3.1.5. Use Case 5: Validate Data....................................................................................................................xx
2.4. GENERAL CONSTRAINTS.............................................................................XXII 2.5. ASSUMPTIONS AND DEPENDENCIES...............................................................XXII

3. SPECIFIC REQUIREMENTS................................................................................................................23
3.1. EXTERNAL INTERFACE REQUIREMENTS...........................................................23

3.1.1. Hardware Interfaces ...................................................................................................................23 3.1.2. Software Interfaces.......................................................................................................................23
3.1.2.1. General Interface Requirements............................................................................................................23 3.1.2.2. Visitor Pages.........................................................................................................................................23 3.1.2.3. Provider Pages......................................................................................................................................24 3.1.2.4. Validator Pages.....................................................................................................................................25
3.2. COMMUNICATIONS INTERFACES ....................................................................25 3.3. BEHAVIORAL REQUIREMENTS........................................................................25

3.3.1. Same Class of User......................................................................................................................25
3.3.1.1. Visitor...................................................................................................................................................25 3.3.1.2. Provider................................................................................................................................................26 3.3.1.3. Validator...............................................................................................................................................26
3.3.2. Related Real-world Objects.........................................................................................................26

Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page iii
3.3.3. Stimulus........................................................................................................................................26
3.3.3.1. Visitor Stimulus....................................................................................................................................26 3.3.3.2. Provider Stimulus.................................................................................................................................27 3.3.3.3. Validator Stimulus................................................................................................................................28
3.3.4. Related Features..........................................................................................................................28

3.3.4.1. Querying ..............................................................................................................................................28 3.3.4.2. Automated Data Collection...................................................................................................................29 3.3.4.3. Creating Administrative Reports...........................................................................................................29
3.3.5. Functional....................................................................................................................................29
3.4. NON-BEHAVIORAL REQUIREMENTS.................................................................29

3.4.1. Performance Requirements..........................................................................................................29 3.4.2. Qualitative Requirements.............................................................................................................29
3.4.2.1. Availability ..........................................................................................................................................29 3.4.2.2. Security.................................................................................................................................................29 3.4.2.3. Maintainability......................................................................................................................................29 3.4.2.4. Portability.............................................................................................................................................29
3.4.3. Design and Implementation Constraints......................................................................................30
3.5. OTHER REQUIREMENTS................................................................................30

3.5.1. Database.......................................................................................................................................30 3.5.2. Operations....................................................................................................................................30 3.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
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page iv
TABLES TABLE 1: DEFINITIONS.........................................................................................................................VII TABLE 2: ACRONYMS AND ABBREVIATIONS.................................................................................IX TABLE 3: ACCOUNT INFORMATION..................................................................................................33 TABLE 4: METADATA..............................................................................................................................33 TABLE 5: INSTRUMENT INFORMATION............................................................................................33 TABLE 6: GLOSSARY INFORMATION.................................................................................................34 TABLE 7: LINK CENTER DATA.............................................................................................................34 FIGURES TABLE 1: DEFINITIONS.........................................................................................................................VII TABLE 2: ACRONYMS AND ABBREVIATIONS.................................................................................IX FIGURE 2-1: USE CASE DIAGRAM......................................................................................................XII FIGURE 3-5: HOME/SEARCH PAGE......................................................................................................24 FIGURE 4-6: VISITOR WEB PAGE TRANSITION DIAGRAM.........................................................31 FIGURE 4-7: VALIDATOR WEB PAGE TRANSITION DIAGRAM..................................................32 TABLE 3: ACCOUNT INFORMATION..................................................................................................33 TABLE 4: METADATA..............................................................................................................................33 TABLE 5: INSTRUMENT INFORMATION............................................................................................33 TABLE 6: GLOSSARY INFORMATION.................................................................................................34 TABLE 7: LINK CENTER DATA.............................................................................................................34 FIGURE 6-8: CLASS DIAGRAM..............................................................................................................35 FIGURE 7-9: DATA FLOW DIAGRAM VISITOR..............................................................................36 FIGURE 7-10: DATA FLOW DIAGRAM PROVIDER.......................................................................36 FIGURE 7-11: DATA FLOW DIAGRAM VALIDATOR....................................................................37 FIGURE 8-12: CHANGE PROVIDER INFORMATION ......................................................................38 FIGURE 8-13: ADVANCED SEARCH......................................................................................................39 FIGURE 8-14: METADATA VALIDATION............................................................................................40 FIGURE 8-15: LOGIN.................................................................................................................................41 FIGURE 8-16: PROVIDER REGISTRATION.........................................................................................41 FIGURE 8-17: SUBMIT METADATA......................................................................................................42 FIGURE 8-18: VALIDATOR HOMEPAGE.............................................................................................43 FIGURE 8-19: GUIDED SOURCE SEARCH...........................................................................................43
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page v
1.
Introduction
The 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 Audience
The 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 Product
Remote 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
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 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 Abbreviations
This 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. Definitions
Table 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 Actor Administrator Band Binary Data Class Class Diagram Click through Data Flow Diagram Database Database Management System Download Dynamic Model Event External Program Field Footprint Foreign Key Geo-referenced images Graphical User Interface DEFINITION An external entity such as a user, a database, or application software that interacts with the system. A person whose responsibility is to manage and maintain the infrastructure of the system. A wavelength interval in the electromagnetic spectrum. Any file format for digital data encoded as a sequence of bits but not consisting of a sequence of printable characters (text). A set, collection, group, or configuration containing members regarded as having certain attributes or traits in common; a kind or category 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. The process of selecting a hyperlink and transferring a browsers display from the current site to the hyperlinked site. 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. A collection of data or information typically stored on a computer system and organized to facilitate retrieval and modification. A software system that enables users to define, create, maintain, and control access to a database. To transfer data or programs from a server or host computer to one's own computer or device. A model of a software system that describes the sequence events and states in the system. An occurrence or happening of significance to a task or program, such as the completion of an asynchronous input/output operation. A program that interacts with the system to be built. An actor. An element of a database record in which one piece of information is stored. 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. 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. An image for which the image pixels have been assigned real-world coordinates (projection and datum) on the Earth. 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.
CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page vii
Hit Hover Hyperlink Image Interactive Map Key Landsat Latitude Link Linux Login Longitude MacOS Metadata Multi-spectral Object Object-Oriented Pixel Precondition Primary Key Provider Query Radar Record Registered User Relational Database
Remote Sensing
Resolution Scenarios Search Engine Server Spatial Resolution Spectral Resolution
A request to a web server from a web browser or other client. Placing the cursor over a GUI element without clicking on this element. An electronic link providing direct access from one hypertext document to another either located in another area or in the same document. Pictorial representation of a scene recorded by a remote sensing system. 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. Either a Primary Key or a Foreign Key. A series of earth orbiting NASA satellites that acquire multi-spectral images in various visible and IR bands. Latitude is the Angular distance north or south from the earths equator measured through 90 degrees. A hyperlink. The operating system Linux, a Unix-like operating system available for most hardware computing platforms. The process of gaining access to certain features of the AVS system. 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. The Macintosh operating system features a graphical user interface (GUI) that utilizes windows, icons, and a mouse to make the computer simple to use. Data describing the data contained in a database. The use of two or more bands in remote sensing. An instance of a class used to describe real-world entities that have a counterpart within the system. 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. A picture element. The smallest unit of information in an image. A condition that must be true prior to the execution of a piece of code. A set of fields in a database table that is used to uniquely identify records in the table. An organization or individual that will provide metadata for the AVS system. A user's request for information, generally as a formal request to a database. An active form of remote sensing that operates in the microwave and radio wavelength regions. 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. A user of the AVS system that has an account, for example a validator, provider or an administrator. A database where data is stored in tables, which contain records, which contain fields. Relationships between tables are defined by foreign keys. The measurement or acquisition of information about the Earth by a recording device that is not in physical contact with the Earth. 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. Part of a use case consisting of a sequence of steps describing the interactions between a user and a system. A program that uses a search pattern to identify a set of web pages matching the search pattern. A computer that provides services to other computers or to people. The smallest object or feature detectable by the sensor. Also known as pixel size or resolution. The number and width (wavelength) of bands (meaningful portions) of electromagnetic energy detectable by a given sensor.
CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page viii
Table Trigger Condition Update Use Case Use Case Diagram Validator Visitor Windows Operating System
A collection of records in a relational database. An event that leads to some consequence in the system either caused by an outside entity, or a chain of events. The process of modifying, adding or removing existing data. Descriptions, from the users point of view, of the important operations that provide value to a user. They describe the interactions between actors and the system. 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. The actor who is responsible for verifying the accuracy of new or submitted data. The actor that is the main user of the system and who searches the system for data. 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 Abbreviations

Table 2 lists the acronyms and abbreviations used in this document with respect to AVS. Table 2: Acronyms and Abbreviations ACRONYMS AVS DBMS DFD ESC GEON GIF GIS GUI JPEG NASA OS PACES SQL SRS STD TIFF URL UTEP WWW e.g. RADAR i.e. MEANING A Virtual Supermarket for Remote Sensing Data and Images Database Management System Data Flow Diagram Escape Geosciences Cyberinfrastructure Network Graphic Interchange Format Geographic Information System Graphical User Interface Joint Photographic Experts Group (Image Format) National Aeronautics and Space Administration. Operating System Pan American Center for Earth and Environmental Studies Structured Query Language Software Requirements Specification State Transition Diagram Tagged Image File Format Universal Resource Locator. University of Texas at El Paso World Wide Web for example Radio Detection And Ranging that is
1.4.
Overview
The SRS is divided into four major sections: Introduction, General Description, Specific Requirements, and Appendices.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page ix
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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page x
2.
General Description
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.
2.1.
Product Perspective
The 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 systems 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 NASAs 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 Characteristics
This 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. Actors
This 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. Visitor
This 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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page xi
2.2.1.2. Provider
A 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. Validator
This 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. Database
The database will hold relations containing all the information that the system needs such as users profiles, metadata for both approved remotely sensed data and unapproved remotely sensed data and help topics.
2.3.

Product Features
The 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
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page xii
2.3.1. Use Case Description

In 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 Data

Use 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 visitors 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 visitors 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.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xiii
10. 11. 12. 13.
The system displays the ordered matches found, five results at a time. (ALT 7). The visitor scrolls forward through the list, five results per page. The visitor selects a search result (ALT 8, ALT 9, ALT 10). 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 visitors 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: A4-1: A4-2: A4-3: ALT 5: A5-1: A5-2: A5-3: A5-4: ALT 6: A6-1: A6-2: A6-3: A6-4: ALT 7: A7-1: A7-2: A7-3: The visitor selects another continent from the continent options. The system displays a map for the selected continent. The visitor selects an area from the selected map (ALT 1, ALT 2, ALT 3). Return to Scenario 2, step number 4. The visitor selects the option to zoom in. The system changes the cursor pointer into a crosshair cursor. The visitor left clicks on a point in the map. The system refreshes the webpage displaying the zoomed map. Return to Scenario 2, step number 3. The visitor selects the option to zoom out. The system changes the cursor pointer into a crosshair cursor. The visitor left clicks on a point in the map. The system refreshes the webpage displaying the zoomed map. Return to Scenario 2, step number 3. The database returns no matches. The system displays a match not found message and an option to return to the Advanced Search Page. The visitor selects the return option. 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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
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.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 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: Register

Use 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 providers first name. * b. The providers middle initial. c. The providers last name. * d. The providers email address. * e. The providers organization. f. The providers address. g. The providers category, i.e. commercial, government, educational or other. h. The providers login name. * i. The providers password. * j. The providers 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. 2.3.1.2.2. Scenario 3: Help 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 which the visitor came from.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xvi
3.
End of use case.
2.3.1.3. Use Case 3: Login

Use 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: A2-1: A2-2: A2-3: The system detects invalid login name or password. The system displays an error page. The system waits 5 seconds. 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 Actors 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 Actors email address. 10. The system displays the Password Recovery Instructions Page with instructions. 11. End of use case. ALT 1: A1-1: A1-2: A1-3: A1-2: The Actor login name is not found. The system displays a webpage indicating that the provider login name was not found. The Actor hits the ok button. The system redirects the Actor to the Provider Registration Page (Refer to Use Case 2). End of use case.
2.3.1.3.3. Scenario 3: Help Preconditions: The visitor is viewing the Login Page.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xvii
Postconditions: The visitor is viewing the Login Help Page. 1. The visitor selects the help option. 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 Data

Use 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 America A1-1: The system displays the coordinates entered. A1-2: Return to Scenario 1, step number 5. ALT 2: A2-1: A2-2: A2-3: The provider selects another continent. The system displays the map for the selected continent The provider selects an area on the selected map. 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. 4. The provider selects the option to submit the data (ALT 1).
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xviii
5. 6. 7.
The system informs provider that the information supplied has been stored into the database and will be validated. The system returns the provider to the Provider Page. End of use case.
ALT 1: The provider selects the clear option. A1-1: The system clears all fields in the submission form. A1-2: Return to Scenario 2, step number 2. 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. 4. The provider selects the option to submit the data (ALT 1). 5. The system informs provider that the information supplied has been stored into the database and will be validated. 6. The system returns the provider to the Provider Page. 7. End of use case. ALT 1: The provider selects the clear option. A1-1: The system clears all fields in the submission form. A1-2: Return to Scenario 1, step number 2. 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.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xix
2.3.1.4.6. Scenario 6: Help 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 which the visitor came from. 3. End of use case.
2.3.1.5. Use Case 5: Validate Data

Use 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: A2-1: A2-2: A2-3: A2-4: A2-5: A2-6: A2-7: The validator selects the disapprove option. The system marks the data as disapproved. The system prompts the validator for an explanation. The validator enters an explanation. The validator selects the submit option. The system sends an email to the provider indicating that the data has been rejected, including the validators explanation. The system redirects the validator to the Validator Page. 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).
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xx
6. 7. 8. 9.
The system marks the dataset as reviewed and makes the metadata available for visitor searches (Refer to Use Case 1). The system sends an email to the provider indicating that the data set has been accepted. The system redirects the validator to the Validator Page 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: A2-1: A2-2: A2-3: A2-4: A2-5: A2-6: A2-7: The validator selects the disapprove option. The system marks the data as disapproved. The system prompts the validator for an explanation. The validator enters an explanation. The validator selects the submit option. The system sends an email to the provider indicating that the data has been rejected, including the validators explanation. The system redirects the validator to the Validator Page. Return to Scenario 2, step number 1.
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 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: A2-1: A2-2: A2-3: A2-4: A2-5: A2-6: A2-7: The validator clicks disapprove option. The system marks the data as disapproved. The system prompts the validator for an explanation. The validator enters an explanation. The validator selects the submit option. The system sends an email to the provider indicating that the data has been rejected, including the validators explanation. The system redirects the validator to the Validator Page. Return to Scenario 2, step number 1.
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.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page xxi
3. 4. 5. 6. 7. 8. 9. 10. 11.
The database returns all the account information associated with that validator. The system redirects the validator to the Change Validator Information Page. The system displays a form with all the attributes associated with the user. The validator changes a field. The validator selects submit changes (ALT1). The system sends the new information to the database. The system displays a message saying that the account has been updated. The system redirects the validator to the Validator Page. 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. 2.3.1.5.5. Scenario 5: Help 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 which the visitor came from. 3. End of use case.
2.4.
General Constraints
The 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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page xxii
3.
Specific Requirements
3.1. External Interface Requirements
This section contains external interface requirements, behavioral requirements, and non-behavioral requirements.
This 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 1] 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. The systems web interface shall accept user input from the keyboard and from the mouse. The system shall have scroll bars for web pages displaying a more text than fits in the currently displayed window. 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. 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. Each webpage will display hyperlinks to adjacent pages as shown in Appendix A: Web Page Transitions. 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. 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.
[SRSreq 2] [SRSreq 3] [SRSreq 4] [SRSreq 5]
[SRSreq 6] [SRSreq 7] [SRSreq 8]
3.1.2.2. Visitor Pages

[SRSreq 9] 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 systems 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 Date 9/22/2011 3:44 A9/P9 Page 23
[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 1] [SRSreq 2] [SRSreq 3] [SRSreq 4] 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. The interactive map in the Advanced Search Page shall allow for zoom in, zoom out and placing footprints on the map. 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. The Search Results Page shall contain a numeric sequence of links labeled with numbers that behave as follows: o o o o Only the next 5 pages shall be displayed at a time, for example 1 2 3 4 5 NEXT After the first 5 results the links label shall display PREV 6 7 8 9 10 NEXT On the last 5 results the links label shall display PREV 11 12 13 14 15 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 5] [SRSreq 6] [SRSreq 7] The Login Page shall provide for the entry of a users login name and password. It will provide a clickable button labeled Logon. The Password Recovery Page shall provide for the user entry of an email address. It shall provide a clickable button labeled Submit. 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*
CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page 24
[SRSreq 8] [SRSreq 9]
Organization Address Organization Type Login Name* Password* Verify Password* 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. 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 systems 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.
Software Engineering II CS 4311 Fall 2004 Date 9/22/2011 3:44 A9/P9 Page 25
[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 Objects

No 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 systems pages, the system shall redirect the visitors browser to the links 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 visitors 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 continents 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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 26
[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 o o o o o First Name Last Name Email Address Login Name Password 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
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 27
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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 28
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. Functional
No 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. Maintainability
No 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.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 29
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 systems 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 Adaptation

Since the system will be installed and will run on the PACES server, no additional site adaptation is necessary.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 30
4.
Appendix A: Web Page Transitions

Advanced Search
Search Results Search Help
Provider Registration Registration Help
Provider Login
Main Site Group
Failed Login
Login Help/ Password Recovery
Provider group Link Center Submit Software Metadata Provider Help
Site Map
Glossary
Submit Metadata
Provider Information
Help
Submit Glossary Entry
Figure 4-6: Visitor Web Page Transition Diagram
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 31
Validator Login Failed Login Login Help/ Password Recovery
Display New MetaData
Validator Help
Validate Glossary Entry
Validate Metadata
Validate Software Metadata
Reject Data
Figure 4-7: Validator Web Page Transition Diagram
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 32
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 Login name E-mail Address Password Name Contact information Organization Account Type Description 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. 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. 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. The name (title, first, middle, and last) of the account holder. The physical mail address of the account holder. Work and fax phone numbers (optional). The name and location of the organization and department with which the account holder is affiliated. The type of user: Visitor, Provider, Validator, Administrator.
This table contains all the metadata for the system. Table 4: Metadata Data Element URL Title Description Organization Source Range Validated Validation entry Metadata Type Description The internet location of the data described by this metadata entry A brief (80 character) phrase used to identify the data set. A natural language description of the dataset described by this metadata entry. Descriptions can be up to 10,000 characters. The name and contact information for the organization sponsoring the URL. The sensor used to collect the data. The minimum and maximum latitudes and longitudes bounding the dataset. A Boolean flag that when true, indicates the metadata has been validated and is available to the general public. User name of validator and the date and time of validation. Also, notes added by validator such as justification for rejection. Software or Dataset
This table contains all the sensors and their respective attributes. Table 5: Instrument Information Data Element Instrument title Spectral Resolution Spatial Resolution Cost Description Description Instrument title, such as Landsat.
Description of the cost structure. Natural language description of instrument, up to 10,000 characters.
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 33
This table contains glossary entries. Table 6: Glossary information Data Element Entry Definition Type Verified Validation entry Description Word or phrase to be defined. Up to 2048 characters defining the entry. A Boolean flag that when true, indicates the metadata has been validated and is available to the general public. 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 Title Description URL Description Title to appear as the hyper link. Up to 10,000 characters describing the link The target of the link
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 34
6.
Appendix C: AVS System Class Diagram

Results
0..* 1 1 1..*
SearchEngine
1
Help
1..*
GUI
1 1 1 1
1 1 1
Login
1..* 1
Account
1 1..* 1 1 1
LinkCenter
1..*
Registered 1 User Glossary

1
Database Interface
Map
Provider
Validator
Figure 6-8: Class Diagram
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 35
7.
Appendix D: AVS System Data Flow Diagram

Keywords
Search Simple Search Advanced

Search Query Search Query Sensor
Sort
Query Results
Sorted Results
Visitor
Dataset Information
Display Sort
Metadata
Source Information
Search Source
Sensor Query Results
Database
Account Information
Register
Account Information
Account
Password
Encrypt
Account Info E -Mail
Notify Visitor Recover Password
UserID Temporary Password Email
Encrypted Password
Figure 7-9: Data Flow Diagram Visitor

UserID Password
Login
Provider
Encrypted Password Login Accepted
Display
Software Metadata
Submit Software Metadata
Encrypt Change Account Information

Glossary Entry Account Information
Glossary Entry Metadata Information Account Information Password Account Information
Submit Glossary Entry Submit Metadata

Software Metadata Metadata
Database
Figure 7-10: Data Flow Diagram Provider
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 36
Validation
True
Display Login
Encrypted Password
Validator
UserID Password
Encrypt
Validation
Validate Glossary Term

Account Info
Password Unverified Glossary Term Account Information
Change Account Information
Validate Software Metadata
Verified Software Metadata Validation Verified Glossary Term Verified Metadata Unverified Software Metadata Account Information
Database
Validate Metadata
Unverified Metadata
Figure 7-11: Data Flow Diagram Validator
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 37
8.
Appendix E: AVS System Prototype
Figure 8-12: Change Provider Information
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 38
Figure 8-13: Advanced Search
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 39
Figure 8-14: Metadata Validation
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 40
Figure 8-15: Login
Figure 8-16: Provider Registration
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 41
Figure 8-17: Submit Metadata
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 42
Figure 8-18: Validator Homepage
Figure 8-19: Guided Source Search #
CS 4311 Fall 2004
Date 9/22/2011 3:44 A9/P9
Page 43

CS 4311 Fall 2004: A Virtual Supermarket For Remote Sensing Data and Images

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS 4311 Fall 2004: A Virtual Supermarket For Remote Sensing Data and Images

Uploaded by

Copyright:

Available Formats

CS 4311 Fall 2004

A Virtual Supermarket for Remote Sensing Data and Images

2004 Software Engineering II

CS 42311 Fall 2004

Software Requirements Specification

Document Change Control

Software Team Members: All-Programmatic Stars CST Sputnik

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

1.4. OVERVIEW .................................................................................................IX 1.5. REFERENCES.................................................................................................X

2.1. PRODUCT PERSPECTIVE.................................................................................XI 2.2. USER CHARACTERISTICS................................................................................XI

2.3. PRODUCT FEATURES....................................................................................XII

2.4. GENERAL CONSTRAINTS.............................................................................XXII 2.5. ASSUMPTIONS AND DEPENDENCIES...............................................................XXII

3.1. EXTERNAL INTERFACE REQUIREMENTS...........................................................23

3.2. COMMUNICATIONS INTERFACES ....................................................................25 3.3. BEHAVIORAL REQUIREMENTS........................................................................25

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

Software Requirements Specification

3.3.4. Related Features..........................................................................................................................28

3.4. NON-BEHAVIORAL REQUIREMENTS.................................................................29

3.4.3. Design and Implementation Constraints......................................................................................30

3.5. OTHER REQUIREMENTS................................................................................30

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

Purpose and Intended Audience

Software Requirements Specification

Definitions, Acronyms, and Abbreviations

Software Requirements Specification

Resolution Scenarios Search Engine Server Spatial Resolution Spectral Resolution

Software Requirements Specification

1.3.2. Acronyms and Abbreviations

Software Requirements Specification

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

Figure 2-1: Use Case Diagram

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

2.3.1. Use Case Description

2.3.1.1. Use Case 1: Search for Data

Software Requirements Specification

10. 11. 12. 13.

CS 4311 Fall 2004

Date 9/22/2011 3:44 A9/P9

Software Requirements Specification

Software Requirements Specification

2.3.1.2. Use Case 2: Register

Software Requirements Specification

End of use case.

2.3.1.3. Use Case 3: Login

Software Requirements Specification

2.3.1.4. Use Case 4: Provide Data

Software Requirements Specification

Software Requirements Specification