Requirements

1. Introduction
   This document outlines the requirements for the Asset Configuration and Tracking Consolidation task, 2006 proposal with charge number 900626.
2. General Description
   A general description of the task is found in the Project Proposal. The tasks as described in that proposal are:

   The first step in solving this issue is to locate and document the different systems that are currently handling asset tracking and information. These systems include: SSDS, Paul Coenen's Database, BOG, and LOBO. After identifying the different systems, the information that is contained in those projects must also be detailed. From these details duplicated information can be identified.
   The next step is to then identify the different applications that are utilized to edit and maintain this information. The functionality of these interfaces will be documented to make sure that the coordinated solution meets all the needs of the individual applications and their users.
   With these pieces in hand, a decision can be made on how to best handle the coordinated system and a design will be created for this purpose. The solution will be reviewed and then implemented.
   Deliverables The final deliverable should be an application (or small set of applications) that can handle the asset tracking and configuration information so all users will go to one location to find out information about various instruments that MBARI maintains.

   
   As currently envisioned based on information learned to date (2006.11.05), the initial effort will not incorporate LOBO, and Paul Coenen's database is considered to be the same as the BOG 'instru' database.

3. Functional Requirements
   1. Address Existing Problems
      1. Minimize errors in SSDS database
         New and changed instrument data should be verified and accurate.
      2. Avoid duplicated entries in SSDS database
         The same instrument should not appear twice in the SSDS database.
      3. Simplify data entry tasks
         Make user data entry operations as simple as possible (minimizes mistakes, makes user happy).
      4. Minimize data entry tasks
         Data entered in one interface should populate the other wherever feasible.
   2. General Goals
      1. Reflect Instru Changes To SSDS Database
         Changes to the Instru database should be reflected in the SSDS database.
      2. Reflect SSDS Changes To Instru Database
         Changes to the SSDS database should be reflected in the Instru database, to the extent they are of interest to users of the Instru database.
   3. Use Cases
      The following requirements can be mapped to corresponding use cases on the Use Cases page.
      1. OSG Operator Creates New Device in Instru Database
         An OSG operator will use the Instru datbase application (MS Access) to enter a new device in the Instru data table in BOG database.
      2. OSG Operator Edits A Device in Instru Database
         An OSG operator will use the Instru datbase application (MS Access) to edit existing device information in the Instru data table in BOG database.
      3. SSDS Operator Creates New Device in SSDS Database
         An SSDS (or other) operator will enter a new device in the SSDS device table in the SSDS database.
      4. SSDS Operator Edits A Device in SSDS Database
         An SSDS (or other) operator will edit existing device information in the Device data table in the SSDS database.
4. Interface Requirements
   1. The existing MS Access interface to Paul Coenen's Instru database must be supported, or its equivalent functions provided to the satisfaction of OSG.
   2. The existing SSDS services must remain available.
   3. Planned improvements to the SSDS device entry service will be implemented (e.g., authentication, validation).
   4. Operation of the existing SSDS device search interface should be clarified.
5. Performance Requirements
   1. The changes must support the expected number of devices to be entered over the next 5 years, without significantly impacting usability.
6. Design Constraints
   1. Paul Coenen must maintain authority to control changes to the instruments of interest to him (i.e., those currently in the Instru database).
   2. Multiple users, from OSG, Development, and Engineering will be responsible for creating and editing device metadata. The system must gracefully minimize data entry errors, and allow review processes (automated and manual) to catch errors when they do occur.
7. Other non-functional attributes
   1. Security
      1. The author of each change to the SSDS database should be identifiable.
      2. Changes to device metadata should be reviewable by a designated authority for that device record.
   2. Binary Compatibility
   3. Reliability
   4. Maintainability
   5. Portability
   6. Extensibility
      1. To the extent possible, the system should take into account the likely addition of other instrument collections in the future.
   7. Reusability
   8. Application Affinity/Compatibility
   9. Resource Utilization
   10. Serviceability

I'd like to see a capability for managing calibartion information that people who process data from instruments currently may keep in properties files.  Cases where this is done include data for the radiometers and fluorometers. Posted by mccann at Dec 05, 2006 15:07

This sounds like a great functionality.  Any reason it can't be done within the current SSDS data model using the "Resource" field? Posted by amarburg at Dec 07, 2006 11:50