Software Requirements

Specification

Wildlife Areas Habitat Conservation Plan

Activities Management Application

Version 1.1
May 10, 2007

Prepared by:
GeoNorth LLC

Prepared for:
Washington Department of Fish and Wildlife
Document Revision History

Version Date Description

1.0 4/05/07 Document Template Created.
1.0.1 4/10/07 First Draft Development
1.0.2 4/10/07 Internal Draft Review Work
1.0.3 4/11/07 WADFW Initial Review
1.0.4 4/13/07 Preliminary Draft SRS
1.0.5 5/1/07 Draft SRS
1.0.6 5/3/07 Associate/Link Updates
1.0.7 5/4/07 Review with WADFW and Database Update
1.0.8 5/10/07 WADFW Final Draft SRS Review
1.1 5/10/07 Final SRS Document
Table of Contents
1. Introduction .......................................................................................................................................... 1
1.1. Purpose .................................................................................................................................. 1
1.2. Project Scope ......................................................................................................................... 1
2. Overall Description .............................................................................................................................. 2
2.1. Product Perspective ............................................................................................................... 2
2.2. Product Features .................................................................................................................... 2
2.3. User Classes and Characteristics .......................................................................................... 3
2.4. Operating Environment .......................................................................................................... 4
2.5. Design and Implementation Constraints ................................................................................ 4
2.6. User Documentation and Technical Support ......................................................................... 5
2.7. Assumptions and Dependencies ............................................................................................ 5
2.8. Transaction Environment ....................................................................................................... 5
3. Data Requirements ............................................................................................................................. 6
3.1. Data Requirements ................................................................................................................ 6
4. Functional Requirements .................................................................................................................... 7
4.1. Create Activity Features ......................................................................................................... 7
4.2. Edit Activity Features............................................................................................................ 10
4.3. Query Activity Features ........................................................................................................ 11
4.4. Delete/Archive Activity Features .......................................................................................... 12
4.5. Navigation Features ............................................................................................................. 12
4.6. Disconnect Activity Geodatabase ........................................................................................ 13
4.7. Reconnect Activity Geodatabase ......................................................................................... 14
5. Non-functional Requirements ............................................................................................................ 16
5.1. User Interfaces ..................................................................................................................... 16
5.2. Performance Requirements ................................................................................................. 16
Appendix A: Physical Database Model ................................................................................................ 17
Appendix B: Requirements Identifiers .................................................................................................. 18
Appendix C: Activities Data Model Description .................................................................................... 19
Appendix D: Issues List ........................................................................................................................ 21
Appendix E: Document Sign Off ........................................................................................................... 22
1. Introduction

1.1. Purpose
This Software Requirements Specification (SRS) describes the functional and nonfunctional
requirements for Release 1.0 of the Habitat Conservation Plan’s (HCP) Activities Management
Application. Members of the project team that will implement and verify correct functioning of the
system will use this document as a guide. Unless otherwise noted all requirements specified
here are Mandatory and committed for Release 1.0.

1.2. Project Scope

As part of the Habitat Conservation Plan development, this phase of the project activity focuses
on the development and implementation of an activities management application. This
application is needed by the WDFW to insure consistent collection and management of activity
information associated with the HCP process. The application will utilize a standardized
database schema and an easy to use interface for the collection of habitat activity data. This
project represents the first phase of a series of applications and databases designed to interact
with the HCP database model.

SRS v1.1.doc -1- Printed on: 5/11/2007 10:03:00 AM

2. Overall Description

2.1. Product Perspective

The product developed will provide additional functionality working within the ArcMap
environment allowing the user to query, create, edit, import and attribute Activity features.
The product will simplify and standardize the data management and maintenance associated with
Activities. The goal is to provide a system where necessary information can be easily captured
for use in future HCP related analysis.

2.2. Product Features

The main tasks the system will perform are to:
ƒ Standardize the collection of Activities in a single enterprise database (Mandatory)
ƒ Allow the easy collection of the Activities data (Mandatory)
ƒ Help standardize data collection, management, and data entry (Mandatory)
ƒ Create, Modify, Import, Delete Activity features (Mandatory)
ƒ Create New Activity Classes (Mandatory)
ƒ Compatible with Activities Database Model (Mandatory)
ƒ Standardize projection system (Mandatory)
ƒ Minimal attribution by user - Auto Populating Data (Mandatory)
ƒ Feature class editing - Point, Line, Polygon (Mandatory)
ƒ Associate Activity features with other Activity features (Mandatory)
ƒ Track events (Mandatory)
ƒ Easy navigation for the User (Mandatory)
ƒ Define Associated Activities without mapping (unmapped activities) (Mandatory)
ƒ Report if activity records are complete (Mandatory)
ƒ Disconnected editing environment - Data export processes (Mandatory)
ƒ User Auditing at Feature Level - Attribute level and historical Geodatabase tables (Highly
Desirable)
ƒ Search functionality - Attribute, Location (Highly Desirable)
ƒ Analysis done by WDFW regions (Highly Desirable)
ƒ Lookup tables for easy data entry (Highly Desirable)
ƒ Export to Excel spreadsheets (Highly Desirable)

SRS v1.1.doc -2- Printed on: 5/11/2007 10:03:00 AM

2.3. User Classes and Characteristics
User Class Characteristics

This category of users is the most prominent in the Regions

based on the interview results. The HCP Activities Management
GIS novices (favored)
Application will need to consider the limited GIS training and
experience of these users.

Although the application will be mainly designed for the GIS

novices, it will also need to allow the GIS professionals in these
GIS professionals
Regions to utilize their knowledge and GIS skills without being
constrained by the HCP Activities Application functionalities.

SRS v1.1.doc -3- Printed on: 5/11/2007 10:03:00 AM

2.4. Operating Environment
OE-1 The software application developed shall reside on the DFW desktop computers of the
application’s primary users.
OE-2 The system input data shall reside in the DFW SQL (SQL Server) database environment
and in a detached user (ACCESS) database environment.
OE-3 The system shall operate within and be compatible with the DFW network environment.
OE-4 The system shall be compatible with the current DFW minimum desktop configuration
hardware and software standards, as defined below:

Environment Standards
Desktop Operating System: Microsoft Windows 2000 SP4 or XP
Directory Services: LDAP
GIS: ArcGIS 9.2
GIS License: ArcView or Better ArcGIS Editor
Disconnected Database Types: Personal (MS Access)
Email: Groupwise (Outlook soon)
Office Applications: Microsoft Office (2000)
ArcSDE: ArcSDE 9.1 (ArcSDE 9.2 soon)
SQL Server Version 2000 (Migrating to 2005 soon)

2.5. Design and Implementation Constraints

CO-1 The system shall be developed in ArcGIS 9.2 and available as an extension on the DFW
network.
CO-2 The system shall be developed using VB.NET for .NET 2.0 framework with Windows user
interfaces.

CO- 3 Application development will adhere to the model-view-controller architectural pattern.

This pattern serves to separate data (model) and user interface (view) concerns, so that
changes to the user interface do not affect the data handling, and that the data can be
reorganized without changing the user interface. Adhereing to the model-view-controller
pattern will decouple data access and business logic from data presentation and user
interaction, by introducing an intermediate component: the controller.

CO- 4 Variables will be created using camel case (creating compound words or phrases in which
the words are joined without spaces and are capitalized within the compound with the first
letter of the variable lowercase).

CO- 5 Variables referencing ArcObjects com classes, interfaces, or objects will not be
abbreviated and will be dimensioned using a camel case naming convention. Do not use
pointers such as m_p or g_p as a prefix to ArcObjects classes/interfaces.

CO- 6 Do not use prefixes to variables such as int, str, lng, etc.

CO-7 In-line documentation for coding, flow chart and/or diagram – what each module does,
who did it and when it was done

SRS v1.1.doc -4- Printed on: 5/11/2007 10:03:00 AM

 CO-8 Methods, procedures and functions will be sufficiently commented to support
maintenance programmers with easily understanding the logic and purpose of the
routines.
CO- 9 Once delivered, code will to be managed through WDFW’s CVS repository

2.6. User Documentation and Technical Support

UD-1 The user documentation (Help and Tutorial) shall be available as a separate electronic
document (PDF) which can be opened from within the system.
UD- 2 The user documentation will use screen captures of application interfaces to illustrate
methods and procedures.

2.7. Assumptions and Dependencies

AD-1 The Department of Fish and Wildlife shall provide leadership and support to successfully
implement the HCP Activities Management Tool in the department.
AD-2 The users of the HCP Activities Management Tool shall have basic knowledge/training of
ArcGIS and its editing functions (spatial and tabular edits).
AD-3 Administrative tools for managing lookup tables will be provided (Based on budget
approval).
AD-4 The initial application will allow users to only archive (not delete) records.
AD-5 The application will be developed to accommodate 3 Event types (O&M, Recreation, and
E&R) for 3 feature types resulting in 9 Activity feature classes.

2.8. Transaction Environment

TE-1 The application will directly work with SQL server for tabular data transactions.
TE-2 The application will directly work with ArcSDE for Spatial Data transactions.
TE-3 The application will work in any ArcSDE versioning environment. Users will be required
to use the appropriate SDE connection to be within the database’s configured
transactional environment.

SRS v1.1.doc -5- Printed on: 5/11/2007 10:03:00 AM

3. Data Requirements

3.1. Data Requirements

DR-1 The system shall use corporate data located on SQLUSR1 (database) as the default data
source location, unless specified otherwise by the user.
DR-2 The user or system administrator shall be responsible for managing data in lookup tables
in the Activities Record Database.
DR-3 The database shall be stored in a SQL Server environment.
DR-4 The application must work with the database model specified in Appendix A.

SRS v1.1.doc -6- Printed on: 5/11/2007 10:03:00 AM

4. Functional Requirements
The features listed below describe the functional requirements for the Activities Management Application,
Release 1.0. The priority of each feature is identified as either Mandatory or Highly Desired. Highly
Desired requirements will be implemented only if they are deemed feasible in the design phase and fit
within the project time and cost constraints. As an aid to understand the system functionalities, please
consult the WDFW Activities Data Model Description in Appendix C.

4.1. Create Activity Features

4.1.1. Description and Priority
This section describes the processes involved with the creation of new activity feature classes in
the Activities Management Tool. Users will choose the Activity Event Type, the Activity, and
related activity types and features. (Mandatory)

4.1.2. Stimulus/Response Sequences

Stimulus: User clicks on button to launch the Activity Feature Management Tool.
Response: The system will load a window form for data entry. The form will auto fill
dropdown tools with data stored in application lookup tables.

Stimulus: User initiates the application for the first time.

Response: The system will prompt the user to set the default values for confidence and
methods sources.

Stimulus: User uses query tools to navigate to a location on the map.

Response: The system will navigate the user to the selected feature location.

Stimulus: User chooses the activity edit type (tabular or spatial) prior to editing.
Response: The system will set the edit environment based upon the type of activity edit.

Stimulus: When a spatial edit is selected, the user digitizes the new activity from scratch
or copies a feature from an existing layer. (See requirements)
Response: System creates a new activity feature and prompts the user if he/she wants to
digitize another.

Stimulus: When a tabular edit is selected, the user creates an activity record without
creating spatial data.
Response: The system will create and track the pending activity record in the database.

Stimulus: User chooses Event Type and creates a new activity record.
Response: The system creates a new activity record based on the activity event type, sets
the default values in the form.

Stimulus: User enters data in the form using text boxes and dropdown boxes.
Response: The system will require the confidence source to be set when entering data.

Stimulus: The user adds occurrence data connected with an activity.

Response: The tool will record and manage occurrence record connected to the activity
record.

Stimulus: The user creates an activity record prior to creating spatial data.
Response: The tool will create a new activity record without linked spatial data.

SRS v1.1.doc -7- Printed on: 5/11/2007 10:03:00 AM

 Stimulus: The user selects a spatial feature and then links existing spatial data to an
activity record.
Response: The tool will set the Activity Record Id in the selected spatial feature to the
Activity Record Id creating a linked relationship.

Stimulus: The user unlinks selected spatial data to an activity record.

Response: The tool will set the Activity Record Id in the selected feature to NULL to unlink
the spatial record with the activity record.

Stimulus: User defines activity (ies) that are associated with the current editable activity
record.
Response: The system will store the list of activity (ies) associated with the activity feature
in a database table. All currently selected features are unselected.

Stimulus: The user optionally creates records for associated activities (if not completed
already)
Response: The system saves the current editable record and starts a new edit session for
the new activity. For those associated activities that records are not created
are displayed on the “To Do” list.

Stimulus: The user associates activities that are recorded to the current editable Activity
Record.
Response: The tool will record the association of a activity records with the selected
features on the map. In the case of coincidental features in a selection, the
user will be required to use existing tools in ArcGIS to deselect unwanted
records.

Stimulus: The user unassociates activity records assign to an activity.

Response: The tool will unassociate selected spatial activity records by archiving the
spatial activity association records in the database.

Stimulus: User edits the confidence source of the activity record.

Response: The tool overrides the default value in the current record.

Stimulus: User selects the option to duplicate the spatial feature and/or attributes of the
activity record for the next new feature.
Response: The system will create a new feature by duplicating spatial features and/or
duplicate attribute records.

Stimulus: User chooses which fields (attributes) to be propagated into a new record.
Response: The system will propagate the selected field attribute values to the next record
created.

Stimulus: User clicks on the Edit Session close button.

Response: The system will save all edits in the activity table, feature class, and related
tables.

4.1.3. Functional Requirements

Create.Form The tool shall provide an easy to use form for the attribution of
an activity feature. This form should be used for querying
(section 4.3) and editing (section 4.2) functionality as well.
Create.Type.Selection The tool shall allow the selection of Activity Event Type.
Create.Data.Type The tool shall allow the creation of point, line, or polygon
features.

SRS v1.1.doc -8- Printed on: 5/11/2007 10:03:00 AM

 Create.Data.Multipart The user shall not be allowed to create multi-part feature
classes, only discreet features.
Create.Tools.Edit The tool shall use the existing editing tools provided by ArcGIS
Desktop.
Create.Tools.Add The tool shall allow the user to create multiple feature types for
an activity record.
Create.Tools.Copy The tool shall provide the functionality to import existing spatial
data features into the new activity feature.
Create.Dates.Calendar The tool shall provide a calendar control for the selection of date
attribute information.
Create.Metrics.Selection The tool shall provide “smart” controls that only provide the
appropriate metric denominator based upon a type.
Create.Feature.Duplicate The tool shall provide the ability to duplicate spatial and attribute
data from one feature/record to a new feature/record.
Create.Associations.Define The tool shall provide the user the ability to define the activity
features based upon the assigned activity associations.
Create.Associations.Assign The tool shall provide the user the ability to assign subordinate
activities (sub-activities) with the newly created feature.
Create.Associations.Unassign The tool shall provide the user the ability to unassign subordinate
activity relationships..
Create.Link.Assign The tool shall allow the user to assign multiple spatial features
with a single activity.
Create.Link.Unassign The tool shall allow the user to unassociate spatial activity
records that are associated with a single activity record.
Create.Occurences.Assign The tool shall provide an interface for the user to assign
occurrence information.
Create.Occurences.Frequency The tool shall automate the creation of multiple records when
dealing with frequency.
Create.Confidence.Enable The tool shall require the confidence source (and if necessary
names) be assigned anytime beginning and end dates, number
of day, frequency and effort (e.g., lbs/acres) are entered.
Create.Dropdown.Values The tool shall automatically complete dropdown forms in the tool
with values stored in an application lookup tables.
Create.Creation.Date The tool shall auto-populate the Creation Date field in the activity
feature class.
Create.Creation.By The tool shall auto-populate the Create By field in the activity
feature class. The name should be retrieve from the system
user name.
Create.Modification.Date The tool shall auto-populate the Modification Date field in the
activity feature class. This should be the same as the Creation
Date field value when a feature is created.
Create.Modifcation.By The tool shall auto-populate the Modification By field in the
activity feature class. This should be the same as the Creation
By field value when a feature is created.
Create.Confidence.Source The tool shall auto-populate and/or provide functionality for the
user to reference the confidence source for an activity record.
Create.Manage.Links The tool shall provide the user with the ability to identify records
that do not have spatial features linked to an activity record.
Create.Manage.Display The tool shall provide the user with the ability to visual see in the
map frame spatial features that do not have activity records
associated with them.

SRS v1.1.doc -9- Printed on: 5/11/2007 10:03:00 AM

 Create.Manage.Attributes The tool shall provide an easy to use interface (checkboxes) for
the user to select attributes to propagate to a new record. When
a new record is created with this option, the application will auto-
fill the edit form. The application will only store this propagated
information for the next record created.
Create.Requirement.Attributes The tool shall only allow the user to save and complete an
activity record if all the “Required” attributes are completed.

4.2. Edit Activity Features

4.2.1. Description and Priority
This section describes the editing of Activity features in the Activities Management Tool. Edit
functionality found in the Create Activity features (Section 4.1) will also be available in an edit
mode. (Mandatory)

4.2.2. Stimulus/Response Sequences

Stimulus: The user selects the tabular Activity feature to edit.
Response: The tool shall set the edit environment to the appropriate Activity tabular
record, display the form with the current record information. In the event when
more than one feature or record is selected, the form must provide a
mechanism to navigate between records.

Stimulus: The user selects a spatial Activity Feature to edit.

Response: The tool should set the edit feature to the selected spatial Activity Feature.

Stimulus: The user uses a standardized form to edit feature attribution.

Response: The tool should allow the editing of a selected activity feature attribute data in
a standard form.

Stimulus: The user uses spatial tools to modify the spatial features of the activity record.
Response: The tool should activate the ArcGIS Editing tools for the user.

Stimulus: The user queries for the Activity Feature to edit.

Response: The tool should provide tools for querying activity data and navigate to that
query result. (See section 4.3)

4.2.3. Functional Requirements

Edit.Functionality.Other The tool shall provide the same functionality found in the create
feature functionality.(Section 4.1)
Edit.Form.Functionality The tool shall allow the user to perform edits in the same form as
adding and querying data.
Edit.Select.Spatially The system shall provide the user with the ability to select
activity features through a spatial enabled user interface.
Edit.Select.Attribute The tool shall provide the user with a method to select an activity
feature based upon its attribute values.
Edit.Modification.Date The tool shall auto-populate the Modification Date field in the
activity feature class.
Edit.Modifcation.By The tool shall auto-populate the Modification By field in the
activity feature class.
SRS v1.1.doc - 10 - Printed on: 5/11/2007 10:03:00 AM
4.3. Query Activity Features
4.3.1. Description and Priority
This section describes the query functionality required by the Activities Management Tool.
(Mandatory)

4.3.2. Stimulus/Response Sequences

Stimulus: The user selects values in the edit form.
Response: The system will automatically filter the activity feature database with values
selected by the user.

Stimulus: The user uses the location query tool to query data.
Response: The system will automatically filter the activity form with the selected features.

Stimulus: The user may use the ArcGIS attribute query tool to query data.
Response: The system will automatically filter the activity form with the selected features.

Stimulus: The user uses the ArcGIS spatial selection tool to query data.
Response: The system will automatically filter the activity form with the selected features.

Stimulus: The user selects more than one feature or activity record.
Response: The tool should provide basic VCR style record navigation. (See section 4.3)

4.3.3. Functional Requirements

Query.Form.Functionality The tool shall allow the user to perform edits in the same form as
adding and querying data.
Query.Controls.Query The tool shall perform a query of the activity data when a user
selects a value from a dropdown list and when a user enters a
value in a text box.
Query.Controls.Navigation The tool shall provide controls that provide the easy navigation of
a selected set of records.
Query.Controls.Feature The tool shall zoom to and highlight the current activity record
displayed in the query/edit form if linked to spatial data.

SRS v1.1.doc - 11 - Printed on: 5/11/2007 10:03:00 AM

4.4. Delete/Archive Activity Features
4.4.1. Description and Priority
This section describes the deletion/archiving processes involved with the Activities Management
Tool. For budget purposes, the tool will only provide archiving functionality. (Mandatory)

4.4.2. Stimulus/Response Sequences

Stimulus: The user clicks on a button to delete a record.
Response: The system shall set the archive flag for the Activity record, archives the
associations, and archives the linked spatial features. The result will be to
prevent the record/feature from drawing or be captured by spatial and tabular
queries.

Stimulus: The user deletes spatial feature during an edit session.

Response: The system will set the archive flag for the spatial feature. The result will be to
prevent the feature from drawing or be captured by spatial and tabular queries.

4.4.3. Functional Requirements

Delete.Feature.Archive The tool shall change the archive field in the Activity Feature and
other associated table records to TRUE.
Delete.Feature.Definition All Feature Layers shall have a Definition Query setup with the
Archive set to FALSE.
Delete.Feature.Unarchive The tool shall allow the unarchiving of activity records that meet
a specified criteria (i.e. not a mistake).

4.5. Navigation Features

4.5.1. Description and Priority
This section describes the navigation features provided with the Activity Management Tool.
Mandatory)

4.5.2. Stimulus/Response Sequences

Stimulus: The user navigates the map with spatial navigation tools.
Response: The system will provide basic zoom and pan navigation.

Stimulus: The user navigates to features through the Attribute Form.

Response: The system will query and navigate to the queried feature. (See section4.3).

4.5.3 Functional Requirements

Navigate.Map.Tools The tool shall provide access to basic navigation tools found in
ArcGIS.
Navigate.Map.Query The tool shall provide map navigation to select spatial features
when a query is performed in the edit form.

SRS v1.1.doc - 12 - Printed on: 5/11/2007 10:03:00 AM

4.6. Disconnect Activity Geodatabase
4.6.1. Description and Priority
This section describes the functionality of creating a “disconnected” Activity Geodatabase for field
use. The tool should provide a disconnected Geodatabase, application specific database tables,
and ArcGIS Map Document. (Mandatory)

4.6.2. Stimulus/Response Sequences

Stimulus: User clicks on button to create a disconnected database.
Response: The system will prompt the user for the file directory location of the exported
database.

Stimulus: User provides a name for the exported project.

Response: The system will create a folder in the selected file directory with the name
specified by the user.

Stimulus: User selects the location and clicks ok.

Response: The system will run processes that will generate a disconnected environment
of the Activity Management tool based on the visual extent of the map
displayed in ArcGIS.

4.6.3. Functional Requirements

Disconnect.Location.Directory
The tool shall prompt the user for the output directory.
Disconnect.Location.Folders The tool shall create a new folder in the output directory. The
directory will have the name specified by the user as well as a
date stamp. (ex. MYPROJECT_041007)
Disconnect.Data.Geodatabase The tool shall create a copy of the Geodatabase data in a
personal Geodatabase in the output folder location.
Disconnect.Data.OtherTables The tool shall copy the primary and lookup tables in the activities
database to the disconnected database.
Disconnect.Data.BaseData The tools will not clip or select out base data provided in the
ArcGIS Map Document that is not part of the Activities Database.
The user will be responsible for acquiring and copying base GIS
data to the field work machine.
Disconnect.Data.Imagery The user shall be responsible for acquiring and copying imagery
(aerial photos) to the project directory.
Disconnect.Map.Document The tool shall make a copy of the ArcGIS Map Document to the
folder.
Disconnect.Map.Connections The user shall reconnect map layers to the appropriate location
of the disconnected data.
Disconnect.Date.CheckedOut The tool shall track the checkout date when the database ha
been disconnected.

SRS v1.1.doc - 13 - Printed on: 5/11/2007 10:03:00 AM

4.7. Reconnect Activity Geodatabase
4.7.1. Description and Priority
This section describes the import process of data collected in a disconnected environment.
(Mandatory)

4.7.2. Stimulus/Response Sequences

Stimulus: User clicks on button to reconnect the disconnected database to the enterprise
Activity Database.
Response: The system will prompt the user for the location of the disconnect project.

Stimulus: User selects the disconnected project directory.

Response: The system will start the import process and prompt the user when complete.

Stimulus: When the system detects identical record ids with different modification dates
in spatial and/or tabular records, the user will be prompted to reconcile the
modified records.
Response: The system will post the selected data by the user to the enterprise database.

4.7.3. Functional Requirements

Reconnect.Folder.Location The tool should prompt the user for the location of the disconnect
database.
Reconnect.Data.Import The tool shall import any record that has been modified in the
disconnected database.
Reconnect.Data.Reconcile The tool shall prompt the user when a record id in the
disconnected database and enterprise database has been
modified.
Reconnect.Data.Ids The tool should reconcile the IDs stored in the disconnected
database with the IDs in the enterprise database.
Reconnect.Data.Tables The tool will reconcile all table data from the disconnected
database. This includes lookup and relationship tables.
Reconnect.Data.Obselete The tool will reconcile data that has been flagged obsolete.
Reconnect.Data.Spatial The tool will import all modified spatial features into the
enterprise Geodatabase. Spatial data will be reconciled the
same as tabular records.

SRS v1.1.doc - 14 - Printed on: 5/11/2007 10:03:00 AM

4.8. Lookup Table Management
4.8.1. Description and Priority
This section describes the management of lookup tables in the database. (Mandatory)

4.8.2. Stimulus/Response Sequences

Stimulus: The user clicks on the lookup management interface button.
Response: The system will load a lookup table editing form.

Stimulus: The user selects from a list the lookup table to modify.
Response: The system will load the appropriate lookup table into an edit form.

Stimulus: The user edits the lookup values in the form (Add/Modify).
Response: The system will modify the lookup table information.

Stimulus: The user attempts to obsolete a lookup value.

Response: The system will query the database for instances of the lookup value in use. If
found, the obsolete request will not be allowed.

4.8.3. Functional Requirements

Lookup.Form.Edit The tool shall provide a form for the editing of lookup table
records.
Lookup.Record.Obselete The tool shall query the database for instances of the lookup
value in use. If found, the obsolete request will not be allowed.
Lookup.Modification.Config The tool shall provide a configuration file which will control the
access of modification of lookup tables.

SRS v1.1.doc - 15 - Printed on: 5/11/2007 10:03:00 AM

5. Non-functional Requirements

5.1. User Interfaces

UI-1 The user interface design shall follow .NET Coding Standards and Windows User
Interface Guidelines.
UI-2 Basic Windows Functions and Standards.
UI-3 The interface should be developed to work on a minimum screen resolution of
1280x1024.
UI-4 The interface must interact with the ArcGIS desktop as a dockable window.

5.2. Performance Requirements

PR-1 Must meet standard DFW application performance standards.
PR-2 Must work within the operating parameters of ArcGIS.

SRS v1.1.doc - 16 - Printed on: 5/11/2007 10:03:00 AM

Appendix A: Physical Database Model
The application will use the following Geodatabase Feature Classes and tables as per the following Physical Database model. Please refer to the Visio
Document and Access Database provided with this document.
VALIDEVENT_D

PK,I1 VALIDEVENT_Id SMALLINT

EVENT_LUT
FK1 EVENT_LUT_Id SMALLINT
PK EVENT_LUT_Id SMALLINT FK3 ACTIVITY_TYPE_LUT_Id SMALLINT EFFORT_D UNIT_MEASUREMENT_LUT
FK4 ACTIVITY_CLASS_LUT_Id SMALLINT
EVENT_Desc CHAR(50) FK2 ACTIVITY_SUBCLASS_LUT_Id SMALLINT PK,I1 EFFORT_Id SMALLINT PK UNIT_MEASUREMENT_LUT_Id SMALLINT
Obsolete_Flag BIT ACTIVITY_EFFORT_R
Obsolete_DT DATETIME EFFORT_Qty SMALLINT UNIT_MEASUREMENT_LUT_Desc VARCHAR(50)
PK,FK2 ACTIVITY_Id INTEGER Obsolete_Flag BIT
FK1 UNIT_MEASUREMENT_LUT_Id SMALLINT
PK,FK1,I2 EFFORT_Id SMALLINT Obsolete_DT DATETIME
FK2 MEASUREMENT_DESC_LUT_Id SMALLINT
ACTIVITY_TYPE_LUT Obsolete_Flag BIT
Obsolete_DT DATETIME
PK ACTIVITY_TYPE_LUT_Id SMALLINT MEASUREMENT_DESC_LUT

PK MEASUREMENT_DESC_LUT_Id SMALLINT
ACTIVITY_SUBCLASS_LUT ACTIVITY_TYPE_Desc VARCHAR(65)
Obsolete_Flag BIT ACTIVITY_PR_CODE_R MEASUREMENT_DESC_LUT_Desc VARCHAR(50)
PK ACTIVITY_SUBCLASS_LUT_Id SMALLINT Obsolete_DT DATETIME Obsolete_Flag BIT
PK,FK1 ACTIVITY_Id INTEGER
PK,FK2,I2 PR_CODE_LUT_Id SMALLINT Obsolete_DT DATETIME
ACTIVITY_SUBCLASS_Desc VARCHAR(60)
Obsolete_Flag BIT ACTIVITY_CLASS_LUT
Obsolete_DT SMALLINT
PK ACTIVITY_CLASS_LUT_Id SMALLINT

ACTIVITY_CLASS_LUT_Desc VARCHAR(75) ACTIVITY_RULE_R

PR_CODE_LUT
Obsolete_Flag BIT
Obsolete_DT DATETIME PK,FK1 ACTIVITY_Id INTEGER
PK,FK2,I2 RULE_LUT_Id SMALLINT PK,I2 PR_CODE_LUT_Id SMALLINT

RULE_LUT I1 PR_CODE_Code VARCHAR(10)

EVENT_D PR_CODE_Desc VARCHAR(60)
PK,I2 RULE_LUT_Id SMALLINT Obsolete_Flag BIT
PK,I1 EVENT_Id SMALLINT
Obsolete_DT DATETIME
SOURCE_TYPE_LUT I1 RULE_Type VARCHAR(50)
FK3 EVENT_LUT_Id SMALLINT
RULE_Class VARCHAR(60)
FK4 ACTIVITY_TYPE_LUT_Id SMALLINT ACTIVITY_D PK,I1 SOURCE_TYPE_LUT_Id SMALLINT
RULE_SubClass VARCHAR(50)
FK1 ACTIVITY_CLASS_LUT_Id SMALLINT
Obsolete_Flag BIT
FK2 ACTIVITY_SUBCLASS_LUT_Id SMALLINT PK,FK1 ACTIVITY_Id INTEGER SOURCE_TYPE_Desc VARCHAR(80)
Obsolete_DT DATETIME
Feature_Class_Name VARCHAR(50) Obsolete_Flag BIT
FK10 EVENT_Id INTEGER Obsolete_DT DATETIME
Begin_Date DATETIME
WLA_DESIGNATION_LUT
End_Date DATETIME
FK11 Date_CONFIDENCE_SOURCE_Id SMALLINT PK WLA_DESIGNATION_LUT_Id SMALLINT
ACTIVITY_Duration_Day_Cnt INTEGER ACTIVITY_WLA_DESIGNATION_R
FREQUENCY_LUT_Id SMALLINT I1 Subunit_Id INTEGER
FK4 Freq_CONFIDENCE_SOURCE_Id INTEGER PK,FK1 ACTIVITY_Id INTEGER
Subunit_Name VARCHAR(55)
SOURCE_TYPE_LUT_Id SMALLINT PK,FK2,I2 WLA_DESIGNATION_LUT_Id SMALLINT
I3 Unit_Id INTEGER
ACTIVITY_ASSOCIATION_R SOURCE_METHOD_LUT_Id SMALLINT Unit_Name VARCHAR(55)
Create_DFWuser_Id VARCHAR(50) I2 Superunit_Id INTEGER
PK ACTIVITY_ASSOCIATION_Id INTEGER
Create_DT DATETIME Superunit_Name VARCHAR(65)
PK,FK3 ACTIVITY_Id INTEGER
Mdfy_DFWuser_Id VARCHAR(50) I4 Wdfwreg_NUM INTEGER
Mdfy_DT DATETIME Manager VARCHAR(60)
FK2 Assoc_ACTIVITY_Id INTEGER
Comment_Txt VARCHAR(1024) ACTIVITY_PR_FUNDING_R Obsolete_Flag BIT
FK4 EVENT_Id SMALLINT
Analysis_Ind BIT Obsolete_DT DATETIME
Create_DFWuser_Id VARCHAR(50) PK,FK1 ACTIVITY_Id INTEGER
ARCHIVE_TYPE_LUT_Id CHAR(10)
Create_DT DATETIME PK,FK2,I2 PR_FUNDING_LUT_Id SMALLINT
Mdfy_DFWuser_Id VARCHAR(50) PR_FUNDING_LUT
Mdfy_DT DATETIME
ARCHIVE_TYPE_LUT_Id SMALLINT PK,I2 PR_FUNDING_LUT_Id SMALLINT

PR_FUNDING_Code CHAR(10)
FREQUENCY_LUT
I1 PR_FUNDING_Desc VARCHAR(50)
PK,I2 FREQUENCY_LUT_Id SMALLINT Obsolete_Flag BIT
Obsolete_DT DATETIME
ARCHIVE_TYPE_LUT I1 FREQUENCY_Code SMALLINT
FREQUENCY_Desc VARCHAR(25)
PK ARCHIVE_TYPE_LUT_Id SMALLINT
Obsolete_Flag BIT NEXT_ID
Obsolete_DT DATETIME
ARCHIVE_TYPE_Desc VARCHAR(25) ACTIVITY_OCCURENCE_D
Obsolete_Flag BIT
Obsolete_DT DATETIME PK,I2 ACTIVITY_OCCURENCE_Id INTEGER SOURCE_METHOD_LUT
I1 Next_Id INTEGER
FK1 ACTIVITY_Id INTEGER PK,I1 SOURCE_METHOD_LUT_Id SMALLINT
Begin_Date DATETIME
End_Date DATETIME SOURCE_METHOD_Desc VARCHAR(50)
FK3,I3 Date_CONFIDENCE_SOURCE_Id INTEGER Obsolete_Flag BIT
Duration_Days INTEGER Obsolete_DT DATETIME
Create_DFWuser_Id VARCHAR(50) Entity Legend
Create_DT DATETIME
Mdfy_DFWuser_Id VARCHAR(50)
Mdfy_DT DATETIME
CONTACTS_D Data Table
ARCHIVE_TYPE_LUT_Id SMALLINT PK CONTACTS_Id INTEGER

Last_Name VARCHAR(40) Associative Relationship

First_Name VARCHAR(40)
Middle_Name VARCHAR(30)
Organization_Name VARCHAR(100)
Line1_Addr VARCHAR(75)
Lookup Table
CONFIDENCE_LUT CONFIDENCE_SOURCE_D
Line2_Addr VARCHAR(75)
PK,I1 CONFIDENCE_LUT_Id SMALLINT PK,I4 CONFIDENCE_SOURCE_Id INTEGER Line3_Addr VARCHAR(75)
City_Name VARCHAR(30)
CONFIDENCE_Desc VARCHAR(30) CONFIDENCE_SOURCE_Document VARCHAR(80) State_Prov VARCHAR(30)
Obsolete_Flag BIT Web_Reference VARCHAR(80) I1 Zip_Code VARCHAR(30)
CONFIDENCE_SOURCE_Date DATETIME Home_Phone_Num VARCHAR(10)
Obsolete_DT DATETIME
FK2,I3 CONTACTS_Id INTEGER Work_Phone_Num VARCHAR(10) WDFW Activities Data Model - Draft #4_mm
FK3 CONFIDENCE_LUT_Id SMALLINT Cell_Phone_Num VARCHAR(10) April 26, 2007
Work_Phone_Extension_Num VARCHAR(10)
Email_Addr VARCHAR(20)

SRS v1.1.doc - 17 - Printed on: 5/11/2007 10:03:00 AM

Appendix B: Requirements Identifiers
The following is a key to the codes that uniquely identify the requirements, except for the functional
requirements in section 4 of the document.

AD Assumptions and Dependencies

CO Design and Implementation Constraint
DR Data Requirements
UD User Documentation
OE Operating Environment
PR Performance Requirement
QA Quality Attribute
UI User Interfaces

SRS v1.1.doc - 18 - Printed on: 5/11/2007 10:03:00 AM

Appendix C: Activities Data Model Description

Description of the WDFW Activities Data Model

Many different types of activities occur on WDFW owned and managed lands. These activities can be
classified as one of three broad types of activities: recreation, operation and maintenance, or
enhancement and restoration. Each of the activities can be more specifically described as participating
in a class of activities and a subclass of activities. Class and Subclass provide for a more detailed set of
distinguishing characteristics.

Activities may optionally be identified as being subject to regulations or polices. This could include
Washington Administrative Codes (WACs), Revised Code of Washington (RCW), WDFW Rules and
Regulations, local government ordinances, and Federal Laws.

Activities can occur on either a regular or periodic basis, within a calendar year or across many years.
The duration of an activity can be described by the number of days that each event of an activity occurs.
The frequency of activity can be described by it annual reoccurrence. Activities can both occur
individually or be associated with one or more other activities.

Information about activities will be collected from a variety of sources and will be based on a variety of
data collection methods and procedures. Each may have higher or lower confidence associated with
them.

Each confidence source may have some combination of the name of the source, document name, web
reference, date, contact information and a source confidence designation of:
• A Legal Description
• Empirical Data
• Expert Opinion
• Best Professional Judgement
• Modeled Data

Each activity will be designated as occurring within a described WDFW administrative area. The
designations will be hierarchical, going from Region to Complex; Complex to Wildlife Area; and Wildlife
Area to Wildlife Area Unit. Some activity areas may not be currently assigned to the hierarchy and
designated as being unassigned.

Each activity can be measured in terms of the intensity of effort that is applied. These metrics will be
expressed in terms of the quantity, units, and measure. For instance 100 (quantity) pounds (unit) per
acre (measure) or 10 (quantity) people (unit) per campsite (measure). An activity can have zero or more
measured efforts. Metrics will only be collected at the Activity level. Individual occurrences of an activity
will inherit the metrics of the parent activity. If it is important to apply a different level of effort, then a new
activity will need to be created in order to capture a variance in the metrics. The system should support
propagating existing core activity attributes into a new activity in order to minimize the need for new data
entry when the only significant change is effort. A highly desired functional property of the application
would be to allow the user to place checkboxes next to those fields that should be propagated into the
new record.

Activities often are associated with other activities. Many activities can be associated with one activity
and the one activity can be associated with one or more other activities. This results in a many-to-many
relationship between activities. The system will need to support several workflows around the process of
associating activities. This includes
• Creating activity records prior to creating spatial data
• Linking existing spatial data to an activity

SRS v1.1.doc - 19 - Printed on: 5/11/2007 10:03:00 AM

• Un-linking spatial data to an activity
• Associating an activity to other activities
• Unassociating an activity from an activity

Each activity will be managed as both tabular data and spatial data. One requirement is that the system
support creating tabular records for activities independent of the process of creating the spatial data that
must be linked to the activities. This will allow for creating a placeholder for more specific information
that will be collected during visits for satellite offices.

In order to reduce application development cost, a strategy has been identified for managing records
that are no longer needed due to a change in information, methods, or mistakes. This application deals
with both tabular and spatial data that is linked through an application assigned primary key, which is
carried in both the tabular and spatial records. It would be costly to develop an application that manages
deletions of both the tabular and spatial data. Not to mention that features could be deleted outside the
application. Each record in the Activity, Activity Association, and Activity Occurrence tables will be
attributed as being in some stage of archival state (e.g. Not Archived, Archived with Delete, Archived,
etc). This level of attribution will support a better understanding on the reason for making a record
inactive.

At beginning of a session (when application is first initiated) user will be prompted to set default options
for confidence and methods sources.

Inventory sessions will occur in the field and be disconnected from the SQL database. The application
and the tabular and spatial records will be “checked out” to the inventory biologist and used on a laptop.
While data is “checked out” that particular data on the SQL database will be editable. When data is
“checked in” the application will need to: 1) reconcile and update the SQL database with new additions
to look up tables that may have occurred when disconnected, and 2) reconcile and update any new
and/or modified activities records.

SRS v1.1.doc - 20 - Printed on: 5/11/2007 10:03:00 AM

Appendix D: Issues List

# Description Due Date Assigned To

SRS v1.1.doc - 21 - Printed on: 5/11/2007 10:03:00 AM

Appendix E: Document Sign Off
The sign off of this document indicates that the Washington Department of Fish and Wildlife has agreed
with described Software Requirements Specification in relation to the Wildlife Areas Habitat
Conservation Plan project and approves of GeoNorth to start the development of a software Design
Specification.

Jennifer Quan, WADFW Date

SRS v1.1.doc - 22 - Printed on: 5/11/2007 10:03:00 AM