Download 3. Specific Requirements - Courses - The University of Texas at El

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

page
1
page
2
page
3
page
4
page
5
page
6
page
7
page
8
page
9
page
10
page
11
page
12
page
13
page
14
page
15
page
16
page
17
page
18
page
19
page
20
page
21
page
22
page
23
page
24
page
25
page
26
page
27
page
28
page
29
page
30
page
31
page
32
page
33
page
34
page
35
page
36
page
37
page
38
page
39
page
40
page
41
page
42
page
43
Document related concepts

Microsoft Jet Database Engine wikipedia , lookup

Entity–attribute–value model wikipedia , lookup

Relational model wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Database model wikipedia , lookup

Clusterpoint wikipedia , lookup

Transcript 
CS 4311 Fall 2004
A Virtual Supermarket for Remote Sensing Data and
Images
Version <0.91>
5/6/2017
©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
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
0.91
09/02/2004
Software Engineering II
Modifier
Omar Ochoa
Steve Roach
Omar Ochoa
Omar Ochoa
Omar Ochoa
Steve Roach
Steve Roach
Omar Ochoa
Omar Ochoa/Steve
Roach
Omar Ochoa
CS 4311 Fall 2004
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
Date
Page
5/6/2017 2:14 AM
ii
Software Requirements Specification
TABLE OF CONTENTS
DOCUMENT CONTROL ...........................................................................................................................II
APPROVAL ....................................................................................................... II
DOCUMENT CHANGE CONTROL ....................................................................... II
DISTRIBUTION LIST .......................................................................................... II
CHANGE SUMMARY ......................................................................................... II
1.
INTRODUCTION ................................................................................................................................. 6
1.1.
1.2.
1.3.
PURPOSE AND INTENDED AUDIENCE......................................................6
SCOPE OF PRODUCT ...............................................................................6
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ..................................7
1.3.1.
1.3.2.
1.4.
1.5.
2.
OVERVIEW .............................................................................................9
REFERENCES ....................................................................................... 10
GENERAL DESCRIPTION ............................................................................................................... 11
2.1.
2.2.
PRODUCT PERSPECTIVE ...................................................................... 11
USER CHARACTERISTICS .................................................................... 11
2.2.1.
2.2.1.1.
2.2.1.2.
2.2.1.3.
2.2.1.4.
2.3.
2.3.1.1.
2.3.1.2.
2.3.1.3.
2.3.1.4.
2.3.1.5.
2.4.
2.5.
Actors ..................................................................................................................................... 11
Visitor ...............................................................................................................................................11
Provider .............................................................................................................................................12
Validator ...........................................................................................................................................12
Database ............................................................................................................................................12
PRODUCT FEATURES ........................................................................... 12
2.3.1.
3.
Definitions ............................................................................................................................... 7
Acronyms and Abbreviations ................................................................................................... 9
Use Case Description ............................................................................................................ 13
Use Case 1: Search for Data ..............................................................................................................13
Use Case 2: Register .........................................................................................................................16
Use Case 3: Login .............................................................................................................................17
Use Case 4: Provide Data ..................................................................................................................18
Use Case 5: Validate Data .................................................................................................................20
GENERAL CONSTRAINTS..................................................................... 22
ASSUMPTIONS AND DEPENDENCIES .................................................... 22
SPECIFIC REQUIREMENTS ........................................................................................................... 23
3.1.
EXTERNAL INTERFACE REQUIREMENTS .............................................. 23
3.1.1.
3.1.2.
3.1.2.1.
3.1.2.2.
3.1.2.3.
3.1.2.4.
3.2.
3.3.
Hardware Interfaces .............................................................................................................. 23
Software Interfaces ................................................................................................................ 23
General Interface Requirements ........................................................................................................23
Visitor Pages .....................................................................................................................................23
Provider Pages...................................................................................................................................24
Validator Pages .................................................................................................................................25
COMMUNICATIONS INTERFACES ......................................................... 25
BEHAVIORAL REQUIREMENTS ............................................................ 25
3.3.1.
3.3.1.1.
3.3.1.2.
3.3.1.3.
3.3.2.
Same Class of User ................................................................................................................ 25
Visitor ...............................................................................................................................................25
Provider .............................................................................................................................................26
Validator ...........................................................................................................................................26
Related Real-world Objects ................................................................................................... 26
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
iii
Software Requirements Specification
3.3.3.
3.3.3.1.
3.3.3.2.
3.3.3.3.
3.3.4.
3.3.4.1.
3.3.4.2.
3.3.4.3.
3.3.5.
3.4.
Visitor Stimulus ................................................................................................................................26
Provider Stimulus ..............................................................................................................................27
Validator Stimulus ............................................................................................................................28
Related Features .................................................................................................................... 28
Querying ...........................................................................................................................................28
Automated Data Collection ...............................................................................................................28
Creating Administrative Reports .......................................................................................................29
Functional.............................................................................................................................. 29
NON-BEHAVIORAL REQUIREMENTS .................................................... 29
3.4.1.
3.4.2.
3.4.2.1.
3.4.2.2.
3.4.2.3.
3.4.2.4.
3.4.3.
3.5.
Stimulus ................................................................................................................................. 26
Performance Requirements ................................................................................................... 29
Qualitative Requirements ...................................................................................................... 29
Availability........................................................................................................................................29
Security .............................................................................................................................................29
Maintainability ..................................................................................................................................29
Portability ..........................................................................................................................................29
Design and Implementation Constraints ............................................................................... 29
OTHER REQUIREMENTS ...................................................................... 30
3.5.1.
3.5.2.
3.5.3.
Database ................................................................................................................................ 30
Operations ............................................................................................................................. 30
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
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
iv
Software Requirements Specification
TABLES
Table 1: Definitions ................................................................................................................................................7
Table 2: Acronyms and Abbreviations ...................................................................................................................9
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
Figure 2-1: Use Case Diagram ............................................................................................................................. 12
Figure 3-1: Home/Search Page ............................................................................................................................. 24
Figure 4-1: Visitor Web Page Transition Diagram ............................................................................................... 31
Figure 4-1: Validator Web Page Transition Diagram ........................................................................................... 32
Figure 8-1: Change Provider Information ............................................................................................................ 38
Figure 8-2: Advanced Search ............................................................................................................................... 39
Figure 8-3: Metadata Validation........................................................................................................................... 40
Figure 8-4: Login.................................................................................................................................................. 41
Figure 8-5: Provider Registration ......................................................................................................................... 41
Figure 8-6: Submit Metadata ................................................................................................................................ 42
Figure 8-7: Validator Homepage .......................................................................................................................... 43
Figure 8-7: Guided Search .................................................................................................................................... 43
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
v
Software Requirements Specification
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
obtained, and how the user can access the data. AVS will allow a user to search for data using a natural
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
6
Software Requirements Specification
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
Hit
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 browser’s 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.
A request to a web server from a web browser or other client.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
7
Software Requirements Specification
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
Table
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 earth’s 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.
A collection of records in a relational database.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
8
Software Requirements Specification
Trigger Condition
Update
Use Case
Use Case Diagram
Validator
Visitor
Windows
Operating System
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 user’s 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
MEANING
A Virtual Supermarket for Remote Sensing Data and Images
DBMS
Database Management System
DFD
Data Flow Diagram
ESC
Escape
GEON
Geosciences Cyberinfrastructure Network
GIF
Graphic Interchange Format
GIS
Geographic Information System
GUI
Graphical User Interface
JPEG
Joint Photographic Experts Group (Image Format)
NASA
National Aeronautics and Space Administration.
OS
Operating System
PACES
Pan American Center for Earth and Environmental Studies
SQL
Structured Query Language
SRS
Software Requirements Specification
STD
State Transition Diagram
TIFF
Tagged Image File Format
URL
Universal Resource Locator.
UTEP
University of Texas at El Paso
WWW
World Wide Web
e.g.
for example
RADAR
Radio Detection And Ranging
i.e.
that is
1.4.
Overview
The SRS is divided into four major sections: Introduction, General Description, Specific Requirements, and
Appendices.
Section 2 (General Description) contains:
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
9
Software Requirements Specification
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.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
10
Software Requirements Specification
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 system’s search
interface will allow the user to specify various characteristics of the data in order to find data sets that match the
given search criteria, e.g. spatial resolution, spectral resolution, geographical location, costs. The result of the
queries will be links (URLs) to the location of the matching data. This system will also allow its users to
provide data sets of their own which, after a validation process, will be supplied to the information repository in
order to make it available to other users. This system is self-contained however, it is not independent given that
its functionality relies on the database that PACES will provide, which will not be a part of the system.
AVS is a web-based software system that provides services for registered and non-registered users. Registered
users, known as data providers, are able to store descriptions of their online remote sensing data sets. These
data sets may include “pretty pictures”, geo-referenced images, and binary data. Providers add metadata to the
system by providing a link to their data and a specific description of the data, including location, date, data type,
longitude, and latitude. Non-registered users, known as visitors, can search and browse through the metadata.
To maintain the security and integrity of the metadata, validators verify and data posted by data providers
before it is available to visitors.
AVS is being developed for PACES. The technical mission of PACES is to contribute to NASA’s Earth and
Science Enterprise by conducting research in several areas of the geological, physical and environmental
sciences. Other search engines are available on the World Wide Web (WWW) to search for remotely sensed
data however; these search engines are not unified as a common entity. The interfaces for each of these search
engines vary, and the information they contain may not be as reliable as needed for scientific purposes. The
AVS software system intends to merge all of the most important and dependable remotely sensed data sources
into one entity that will provide this information for free to the general public, according to PACES mission
statement.
2.2.
User 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.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
11
Software Requirements Specification
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 user’s 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
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
12
Software Requirements Specification
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-2: Home/Search Page.
Postconditions: The visitor is viewing the Search Results Page.
1. The visitor enters a list of keywords describing the query.
2. The visitor selects image (ALT 1).
3. The visitor clicks the submit button.
4. The system processes the visitor’s search query and constructs an SQL query.
5. The system submits an SQL search query to the database.
6. The database returns URLs and descriptions of metadata to the system.
7. The system orders the results according to how well the metadata matches the query and how available the
site is.
8. The system displays the ordered matches found, five results at a time. (ALT 2).
9. The visitor scrolls forward through the list, five results per page.
10. The visitor selects a search result (ALT 3).
11. The system redirects the visitor to the URL associated with that metadata and records the visitors IP
address, the time, and the target of the click through.
12. End of use case.
ALT 1: The visitor selects the dataset option.
A1-1: The system continues with the Advanced Search, Use Case 1, Scenario 2.
ALT 2: The database returns no matches.
A1-1: The system displays the message “No match found” on the Search Results Page.
A1-2: End of use case.
ALT 3: The visitor refines his search query and enters a new list of keywords describing his query.
A4-1: Return to Scenario 1, step number 2.
2.3.1.1.2. Scenario 2: Advanced Search
Preconditions: The visitor is viewing the Advanced Search Page as shown in Figure 2-2: Advanced Search
Postconditions: The visitor is viewing the Search Results.
1. The visitor enters a list of keywords describing his query.
2. The visitor selects a source from the sources table (ALT 1, ALT 2).
3. The visitor selects a footprint from the map of US & North America (ALT 1, ALT 3, ALT 4, ALT 5, ALT
6).
4. The system displays the coordinates of the selected area.
5. The visitor clicks the submit button.
6. The system processes the visitor’s search query and constructs an SQL query.
7. The system submits an SQL search query to the database.
8. The database returns URLs and descriptions of metadata to the system.
9. The system orders the results according to how well the metadata matches the query and how available the
site is.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
13
Software Requirements Specification
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 visitor’s source search query and constructs an SQL query.
A2-7: The system submits an SQL search query to the database.
A2-8: The database returns the matching sensors.
A2-9: The system redirects the visitor to the Advanced Search Page.
A2-10: The system populates the sources table using the results of the matching sensors query.
A2-11: Return to Scenario 2, step number 3.
ALT 3: The visitor selects coordinates option.
A3-1: The visitor enters the longitude and latitude as search parameters.
A3-2: Return to Scenario 2, step number 5.
ALT 4:
A4-1:
A4-2:
A4-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.
ALT 5:
A5-1:
A5-2:
A5-3:
A5-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.
ALT 6:
A6-1:
A6-2:
A6-3:
A6-4:
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.
ALT 7:
A7-1:
A7-2:
A7-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.
ALT 9: The visitor selects the N page.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
14
Software Requirements Specification
A9-1:
A9-2:
The system displays the results associated with the N page.
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.
ALT 1: The visitor selects the option to return to the Home Search Page.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
15
Software Requirements Specification
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 provider’s first name. *
b. The provider’s middle initial.
c. The provider’s last name. *
d. The provider’s email address. *
e. The provider’s organization.
f. The provider’s address.
g. The provider’s category, i.e. commercial, government, educational or other.
h. The provider’s login name. *
i. The provider’s password. *
j. The provider’s password verification. *
2. The provider fills out the form with the requested information and selects the option to submit (ALT 1).
3. The system verifies that the required attributes are present, that the email address has a valid form, that the
login name does not exist in the database, and that the password and password verification are identical.
(ALT 2, ALT 3).
4. The system displays a thank you page which contains instructions.
5. The provider presses continue with login link option.
6. The system displays the Login page (Refer to Use Case 3).
7. End of use case.
ALT 1: The user selects the option to clear the form.
A1-1: The system sets the webpage to its default state, without submitting any information.
A1-2: System returns to Scenario 1, step number 1.
ALT 2: The system detects invalid registration information. Required fields are empty, email address does not
have a valid format, the login name is already in use, or the passwords do not match.
A2-1: The system displays the registration webpage.
A2-2: The system informs that one or more of the required fields are incorrect (such as invalid login name, or
login name already exists), marks them in red, and includes description of appropriate corrective
actions.
A2-3: The user corrects the marked fields and resubmits the information pressing the submit button (ALT 1).
A2-4: System returns to Scenario 1, step number 3.
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.
3. End of use case.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
16
Software Requirements Specification
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 Actor’s email address.
7. The system creates a new temporary password and emails it to the Actor.
8. The system submits the new password to the database.
9. The system sends the new password to the Actor’s email address.
10. The system displays the Password Recovery Instructions Page with instructions.
11. End of use case.
ALT 1:
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.
Postconditions: The visitor is viewing the Login Help Page.
1. The visitor selects the help option.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
17
Software Requirements Specification
2.
3.
The system redirects the visitor to the Login Help Page and to the section associated with the page from
which the visitor came from.
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).
5. The system informs provider that the information supplied has been stored into the database and will be
validated.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
18
Software Requirements Specification
6.
7.
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.
2.3.1.4.6. Scenario 6: Help
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
19
Software Requirements Specification
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
validator’s 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).
6. The system marks the dataset as reviewed and makes the metadata available for visitor searches (Refer to
Use Case 1).
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
20
Software Requirements Specification
7.
8.
9.
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
validator’s 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
validator’s 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.
3. The database returns all the account information associated with that validator.
4. The system redirects the validator to the Change Validator Information Page.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
21
Software Requirements Specification
5.
6.
7.
8.
9.
10.
11.
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.
Software Engineering II
CS 4311 Fall 2004
Date
Page
5/6/2017 2:14 AM
22
Software Requirements Specification
3.
Specific Requirements
This section contains external interface requirements, behavioral requirements, and non-behavioral
requirements.
3.1.
External Interface 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 01] The system shall have a web-based graphical user interface (GUI) constructed from standard
web-interface elements such radio buttons, text boxes, check boxes, drop down lists, tables, and
URLs.
[SRSreq 02] The system’s web interface shall accept user input from the keyboard and from the mouse.
[SRSreq 03] The system shall have scroll bars for web pages displaying a more text than fits in the currently
displayed window.
[SRSreq 04] The system shall present a confirmation prompt to the user with the options to continue or cancel
the operation whenever a user selects an operation that may modify the contents of the database.
[SRSreq 05] The title for all the webpages on the system shall be composed of the text “Remote Sensing
Supermarket” and the title of the specific page. Specific page names are given in the page
transition map given in Appendix A: Web Page Transitions.
[SRSreq 06] Each webpage will display hyperlinks to adjacent pages as shown in Appendix A: Web Page
Transitions.
[SRSreq 07] All webpages shall contain the logos from appropriate sponsors. These include, UTEP, PACES,
NASA, and GEON. These logos shall be hyperlinked to the homepages of these organizations.
[SRSreq 08] Each web page that responds to user actions shall have an associated help page. Pages requiring
help pages are shown in Appendix A: Web Page Transitions. Each help page shall contain
instructions and explanations on how to use the webpage associated with it.
3.1.2.2. Visitor Pages
[SRSreq 09] The Home/Search webpage shall contain a description of the motivation and purpose behind the
system being built, as shown Figure 3-2: Home/Search Page.
[SRSreq 10] The Glossary Page shall contain links to approved remote sensing glossaries available on line
and a list of terms and definitions provided by the client and AVS users.
[SRSreq 11] When the length of the number of entries displayed in The Glossary Page exceeds two standard
window lengths, the Glossary Page shall have hyperlinked shortcuts to each letter of the alphabet
to facilitate faster searches.
[SRSreq 12] The Site Map Page shall contain a graphical representation of the layout of the system’s
webpages.
[SRSreq 13] The Link Center shall display a table containing links to other sites of interest.
[SRSreq 14] The Contact Us Page shall display information on how to contact the persons responsible for the
system and a link to the PACES donations webpage.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
23
Software Requirements Specification
[SRSreq 15] The Advanced Search Page shall display table containing sensor sources and an interactive map
as shown in Figure 3-1: Advanced Search.
[SRSreq 01] The Guided Sensor Search Page shall allow a visitor to describe a source and the system will
search the database for matching sources as shown in Figure 3-8: Guided Source Search.
[SRSreq 02] The interactive map in the Advanced Search Page shall allow for zoom in, zoom out and placing
footprints on the map.
[SRSreq 03] The Search Results Page shall contain the total number of results returned by the query, result
descriptions, and links to the URL of the result.
[SRSreq 04] The Search Results Page shall contain a numeric sequence of links labeled with numbers that
behave as follows:
o
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-2: Home/Search Page
3.1.2.3. Provider Pages
[SRSreq 05] The Login Page shall provide for the entry of a user’s login name and password. It will provide a
clickable button labeled “Logon”.
[SRSreq 06] The Password Recovery Page shall provide for the user entry of an email address. It shall provide
a clickable button labeled “Submit.”
[SRSreq 07] The Register Page shall provide fields for users to enter the following text elements (the elements
marked with “*” are required):





First Name*
Middle Initial
Last Name*
Email Address*
Organization
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
24
Software Requirements Specification





Address
Organization Type
Login Name*
Password*
Verify Password*
[SRSreq 08] The Change Provider Information Page shall provide an interface that displays all of the provider
information obtained from the Register page and allows a user to modify the data.
[SRSreq 09] The Submit Metadata Page shall allow a provider to enter a URL, a text description of up to 250
words, a sensor source and the observed location of the metadata by either entering the
coordinates or by drawing a footprint on a map. (A word is a maximum of 5 characters.)
[SRSreq 10] The Submit Software Metadata Page shall allow a provider to enter a URL, a text description of
up to 250 words, and a cost. (A word is a maximum of 5 characters.)
[SRSreq 11] The Submit Glossary Term Page shall allow a provider to enter a term and a definition. The
definition may contain up to 250 words. (A word is a maximum of 5 characters.)
3.1.2.4. Validator Pages
[SRSreq 12] The validator interface shall be accessed through a different URL than the visitor and provider
URL.
[SRSreq 13] The Validate Software Metadata Page shall display the URL, description, metadata, and cost of
metadata entries that have not yet been validated.
[SRSreq 14] The Validate Glossary Term Page shall display the term and description for each entry that has
not yet been validated.
[SRSreq 15] The Change Validator Information Page shall provide an interface that displays all of the
validator information and allows a user to modify the data.
3.2.
Communications Interfaces
PACES is currently involved in the development of the GEON grid, a cyberinfrastructure for the geological
sciences. To this end, the AVS system’s functionality must be adaptable to grid services. The following
requirements enable the system to be ported to grid services in the future.
[SRSreq 16] The AVS system shall provide all of the search functionality as Web Services.
3.3.
Behavioral Requirements
3.3.1. Same Class of User
[SRSreq 17] The primary system shall support two kinds of user: Visitors and Providers.
[SRSreq 18] A separate site shall support Validators. This site shall be accessed through a different URL than
the URL of the primary system.
[SRSreq 19] The system shall allow a user to access the help page for any page to which the user has access.
3.3.1.1. Visitor
[SRSreq 20] The system shall allow a visitor to search for images or datasets.
[SRSreq 21] The system shall allow a visitor to search by using a simple search or an advanced search.
[SRSreq 22] The system shall allow a visitor to view a glossary term.
[SRSreq 23] The system shall allow a visitor to read the help web pages.
[SRSreq 24] The system shall allow a visitor to view a site map.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
25
Software Requirements Specification
[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 system’s pages, the system shall redirect the
visitor’s browser to the link’s target page. Links internal to the system are described in Appendix
A: Web Page Transitions.
3.3.3.1. Visitor Stimulus
[SRSreq 37] When a visitor selects the Search option and no search criteria have been entered or selected, the
system shall ignore the selection and continue to display the current page.
[SRSreq 38] When a visitor selects the Search option and a search query has been entered on the Home Search
page, the system shall scan the search query, extract key words, construct and submit an SQL
query to the DBMS, and display the results in a Search Results page.
[SRSreq 39] When a visitor selects the submit option on the Advanced Search Page, the system shall construct
an SQL query based on the visitor’s entries. The SQL query shall be sent to the database.
[SRSreq 40] When the system receives results from the database for a query, the system shall build and
display the results dynamically.
[SRSreq 41] On the Advanced Search Page, upon the visitor clicking on another continent link the system
shall switch the default map to that continent’s map.
[SRSreq 42] When the visitor clicks on the Footprint button the system shall change the cursor into a crosshair
and enable drawing footprints on the map.
[SRSreq 43] When drawing footprints is enabled, if the visitor clicks and holds the left button of the mouse on
the map the system shall start drawing a footprint.
[SRSreq 44] When drawing footprints is enabled and if the visitor is holding the left button of the mouse, if
the visitor drags the mouse over an area a footprint shall be drawn on the map.
[SRSreq 45] When drawing footprints is enabled and if the visitor is holding the left button of the mouse, if
the visitor releases the left button of the mouse the system shall disable drawing, change the
crosshair cursor into a normal cursor and fill in the coordinates.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
26
Software Requirements Specification
[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
appear as the registration page does, except that the fields will be filled with the provider
information.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
27
Software Requirements Specification
[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.
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.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
28
Software Requirements Specification
[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.
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.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
29
Software Requirements Specification
[SRSreq 91] The system shall be implemented using the .NET architecture. The system’s GUI shall be built as
Web Applications.
3.5.
Other Requirements
3.5.1. Database
[SRSreq 92] The system shall interface with a DBMS described in Error! Reference source not found.
[SRSreq 93] The database system on the server side shall be an Oracle database. The DBMS shall be provided
by PACES.
[SRSreq 94] The database shall be factored into third normal form or Boyce-Codd normal form in order to
avoid update and delete anomalies.
3.5.2. Operations
[SRSreq 95] Operation of the system shall be handed over to the PACES staff upon delivery of the system.
3.5.3. Site Adaptation
Since the system will be installed and will run on the PACES server, no additional site adaptation is necessary.
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
30
Software Requirements Specification
4.
Appendix A: Web Page Transitions
Advanced Search
Search Results
Search Help
Provider
Registration
Main Site Group
Registration
Help
Provider
Login
Failed
Login
Login Help/
Password
Recovery
Provider group
Link Center
Site Map
Provider
Help
Submit
Software
Metadata
Provider
Information
Submit
Metadata
Glossary
Submit Glossary
Entry
Help
Figure 4-1: Visitor Web Page Transition Diagram
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
31
Software Requirements Specification
Validator
Login
Login Help/
Password
Recovery
Failed
Login
Display New MetaData
Validate
Glossary
Entry
Validate
Metadata
Validator
Help
Validate
Software
Metadata
Reject Data
Figure 4-2: Validator Web Page Transition Diagram
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
32
Software Requirements Specification
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
Software Engineering II
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
5/6/2017 2:14 AM
Page
33
Software Requirements Specification
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
Software Engineering II
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
5/6/2017 2:14 AM
Page
34
Software Requirements Specification
6.
Appendix C: AVS System Class Diagram
SearchEngine
Results
0..*
1
1
1
1..*
GUI
Help
LinkCenter
Account
Login
11
1
1 1
1..*
1
1..*
1
1
1..*
1
1..*
1
1
Registered 1
User
Glossary
1
Database
Interface
1
1
Map
Provider
Validator
Figure 6-1: Class Diagram
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
35
Software Requirements Specification
7.
Appendix D: AVS System Data Flow Diagram
Keywords
SearchSimple
Dataset Information
SearchAdvanced
Visitor
Sorted Results
Sort
Search Query
Query Results
Display
Search Query
Sort
Sensor
SearchSource
Source Information
Sensor Query Results
Register
Account Information
Metadata
Database
Password
Account
Encrypt
Account Information
Account Info E-Mail
Notify Visitor
Recover
Password
UserID
Encrypted Password
Temporary Password Email
Figure 7-1: Data Flow Diagram – Visitor
Login
UserID
Password
Provider
Encrypted Password
Login Accepted
Display
Software Metadata
Submit
Software
Metadata
Encrypt
Glossary Entry
Metadata Information
Account Information
Change
Account
Information
Submit
Glossary
Entry
Submit
Metadata
Password
Account Information
Glossary Entry
Account Information
Database
Software Metadata
Metadata
Figure 7-2: Data Flow Diagram – Provider
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
36
Software Requirements Specification
True
Validation
Validator
Display
Login
UserID
Password
Encrypt
Encrypted Password
Validate
Glossary
Term
Password
Change
Account
Information
Unverified Glossary Term
Validation
Account Info
Account Information
Validate
Software
Metadata
Verified Software Metadata
Validation
Account Information
Verified Glossary Term
Verified Metadata
Unverified Software Metadata
Validate
Metadata
Database
Unverified Metadata
Figure 7-3: Data Flow Diagram – Validator
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
37
Software Requirements Specification
8.
Appendix E: AVS System Prototype
Figure 8-1: Change Provider Information
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
38
Software Requirements Specification
Figure 8-2: Advanced Search
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
39
Software Requirements Specification
Figure 8-3: Metadata Validation
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
40
Software Requirements Specification
Figure 8-4: Login
Figure 8-5: Provider Registration
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
41
Software Requirements Specification
Figure 8-6: Submit Metadata
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
42
Software Requirements Specification
Figure 8-7: Validator Homepage
Figure 8-8: Guided Source Search
#
Software Engineering II
CS 4311 Fall 2004
Date
5/6/2017 2:14 AM
Page
43
Related documents
Tutorology E-bay for knowledge
Tutorology E-bay for knowledge
The Micro-Environment
The Micro-Environment
Visitor Attraction SWOT Analysis template
Visitor Attraction SWOT Analysis template
On-line marketing communications
On-line marketing communications
Roge Oliveira
Roge Oliveira
databases_mis
databases_mis
Extract, Transform and Load
Extract, Transform and Load
SiteMarketingManagerJDupdatedandapprovedJan2017
SiteMarketingManagerJDupdatedandapprovedJan2017
TARGET MARKETS AND MARKET SEGMENTATION
TARGET MARKETS AND MARKET SEGMENTATION
Web Site Administration – glossary
Web Site Administration – glossary
JOB DESCRIPTION
JOB DESCRIPTION