/ Zoological Information Management System (ZIMS) Project
Acquisition Business Use Case
/ Client: / International Species Information System (ISIS)
Prepared by:
CGI INFORMATION SYSTEMS AND MANAGEMENT CONSULTANTS INC.
Author / Diane Akai
Issue Date / August 4, 2004
Version / 01.00
Document Reference / PM044
Template Version / PMF001 – v01.05
Proprietary Information Notice: This document has been developed and created by ZIMS project team. The information contained herein is confidential and proprietary and cannot be used unless specifically permitted in writing by CGI and International Species Information System (ISIS) in connection with the Zoological Information Management System Project. The recipient of this document, by its retention and use, agrees to hold this document and its content in strict confidence and to protect the same from loss, theft or unauthorized use. This document shall not be copied or communicated to any third party, in whole or in part by any means without the prior written consent of ZIMS PMO. This Proprietary Information Notice is an integral part of this document and shall not be removed or altered.
Zoological Information Management System (ZIMS)
Acquisition Business Use Case /

Document Location

Current released documentation for this project can be found on the ZIMS website. Printed documents and locally copied files may become obsolete due to changes to the master document. Please contact the Project Control Officer of the ZIMS project to obtain a printed copy of the latest version of the document.

Approvals

This document requires the following approvals.

Name / Organization
Mark Switzer / CGI
Victor Risinger / CGI
Syed Hassan / ISIS

Signed approval forms are filed in the Project Control Book (PCB).

Distribution List – Controlled

The people on the controlled list will be notified of updates to this document. Others should ensure that they are working from a current copy of this document before making decisions based on the information contained within the document. This document has been distributed to:

Name / Organization
Mudassar Habib / Inforica
Rohan D’souza / Inforica
Savio Pereira / Inforica
Mark Switzer / CGI
Victor Risinger / CGI
Diane Akai / CGI

Distribution List – Uncontrolled

This document is available to all CGI and authorized ISIS personnel on the ZIMS website. All users of the ZIMS project are advised to visit the website for the current version of the document.

Document Version History

Version Number / Revision Date / Summary of Changes / Modified by
00.01 / July 29th, 2004 / Initial version, based on information from JAD 1. / Diane Akai
00.02 / August 4th, 2004 / Review / Mark Switzer
01.00 / August 4th, 2004 / For external distribution. / Diane Akai

Table of Contents

1.0Overview

1.1Use Case ID

1.2Use Case Name

1.3Use Case Description

1.4Use Case Priority

1.5Frequency of Use

2.0Actors

2.1Primary Actors

2.2Secondary Actors

2.3Stakeholders

3.0Conditions

3.1Triggers

3.2Pre-Conditions

3.3Constraints

3.4Post-Conditions

3.4.1Success Post-Conditions

3.4.2Failed Post Conditions

4.0Flow of Events

4.1Basic Flow

4.2Alternative Flows

4.2.1New Acquisition (from Step 2)

4.2.2Record not Found – New Acquisition (from Step 1 of Alternative Flow 4.2.1)

4.2.3Mandatory Acquisition Information not Available (from step 2 of Alternative Flow 4.2.1)

4.2.4Record not Found – Change in Responsibility (from Step 3)

4.2.5Responsibility Change already Recorded (from Step 4)

4.2.6Acquisition Recording Not to be Completed (from Step 5)

4.2.7Data Review Errors (from Step 6)

4.2.8Data Validation Errors (from Step 7)

4.3Included Use Cases

5.0Information Required

6.0Business Rules

7.0Other Requirements, Issues and Considerations

7.1Special Requirements

7.2Assumptions

7.3Issues

7.4Considerations

7.5Cross References

8.0Workflows

ISIS and CGI Restricted
Doc. #: PM044 / Page 1 / Version 01.00
Issue Date: August 4, 2004
Zoological Information Management System (ZIMS)
Acquisition Business Use Case /

1.0Overview

1.1Use Case ID

BUC0001

1.2Use Case Name

Acquisition

1.3Use Case Description

This use case describes the business activity whereby receipt of an individual or group by an institution and/or a responsibility for an individual or group is documented.

Acquisition is from the point of view of the receiving institution. “Acquisition” refers to assigning and recording new responsibility (i.e. physical possession, legal ownership, and/or governmental management responsibility) for a newly received or an already accessioned individual or group.

For already accessioned animals, change(s) in responsibility for animals transferred (physically, legally and/or management responsibility) from another institution (zoological or government) is the result of a disposition by another institution.

For newly received animals, information recorded also includes other acquisition-related information (e.g. source, how obtained, life stage at time of acquisition, parameters about the acquisition).

Acquisition information is documented at the time of initial addition (accession) of the individual or group to an institution’s inventory, or when a change in responsibility for the individual or group occurs.

The objective of this activity is to maintain accurate and up-to-date information about an individual or group acquisition and responsibility for the individual or group.

1.4Use Case Priority

This business activity is critical. It is mandatory for all institutions.

1.5Frequency of Use

As needed – may be daily or multiple times a day - whenever animals are received by an institution or there is a change in responsibility for the animal(s).

2.0Actors

2.1Primary Actors

  • Recorder

2.2Secondary Actors

  • Documenter
  • Data Reviewer
  • Validator

2.3Stakeholders

  • Government agencies
  • ISIS
  • Zoo Boards
  • Universities (education institutions)
  • Studbookkeepers
  • Zoo/Aquarium Staff
  • Legal owner of the individual or group
  • Regulatory Agencies
  • Vets
  • Regional Zoo/Aquarium Associations
  • Public
  • Conservation Agencies
  • Etc.

3.0Conditions

3.1Triggers

  • A new individual or group is physically received by an institution (responsibility for physical possession).

And/or

  • There is a change in the legal ownership and/or governmental management responsibility for an individual or group. This includes initial assignment of responsibility when an individual or group is received by the institution and is added (accessioned) to an institution’s inventory.

3.2Pre-Conditions

  • The individual or group to be assigned responsibility (acquisitioned) must have been properly accessioned.
  • Information about the acquisition is documented and communicated by the sending institution.
  • The individual or group has been given appropriate identification(s).

3.3Constraints

  • An animal or animals physically transferred from another institution may die or not arrive at the destination, or a different animal(s) than expected is received by the receiving institution.
  • Institution documentation is not in order.
  • The institution with previous responsibility (physical, legal or government managed) for the individual or group may not have recorded the disposition of the animal(s) before the receiving institution receives it e.g. in cases where the wrong animal(s) was sent.

3.4Post-Conditions

3.4.1Success Post-Conditions

Acquisition information about a new individual or group received by the institution and/or responsibility information (new or changed) for the individual or group is completely and properly recorded.

3.4.2Failed Post Conditions

Acquisition information about a new individual or group received by the institution and/or responsibility information (new or changed) for the individual or group is not properly recorded or completed.

4.0Flow of Events

4.1Basic Flow

  1. The use case begins when a new individual or group is physically received by an institution and/or there is a change in responsibility for an individual or group.
  2. The Recorder determines if it is a new acquisition or a change in responsibility. If it is a new acquisition, see Alternative Flow 4.2.2.
  3. The Recorder looks for the record for the individual or group. If the record is not found and it is a new acquisition, see Alternative Flow 4.2.3. If the record is not found and it is not a new acquisition, but a change in responsibility, see Alternative Flow 4.2.4.
  4. The Recorder reviews the acquisition history of the individual or group. If the responsibility change has already been recorded, see Alternative Flow 4.2.5.
  5. The Recorder records the new responsibility assignment (physical, legal and/or governmental management) information for the individual or group. If the Recorder cannot or does not wish to complete the entry for any reason, see Alternative Flow 4.2.6.
  6. The Data Reviewer validates the information and edits, accepts or rejects acquisition. If the information is not correct, see Alternative Flow 4.2.7.
  7. The Validator ensures that the information is correct. If the information is not correct, see Alternative Flow 4.2.8.
  8. The use case ends.

4.2Alternative Flows

4.2.1New Acquisition (from Step 2)

  1. The Recorder looks for the record for the individual or group. If the record is not found, see Alternative Flow 4.2.2.
  2. The Recorder records information about the new acquisition. If the mandatory acquisition information is not available, see Alternative Flow 4.2.3.
  3. The Recorder records initial responsibility assignment (physical, legal and/or governmental management) information for the individual or group.
  4. The use case resumes at step 6 of the Basic Flow.

4.2.2Record not Found – New Acquisition (from Step 1 of Alternative Flow 4.2.1)

  1. The Recorder investigates if the individual or group was accessioned.
  2. If the required information is obtained, the use case resumes at step 2 of Alternative Flow 4.2.1.
  3. If the required information is not obtained, the use case ends. (Condition may be that accession was not done, or the wrong animal was received and so needs to be accessioned).

4.2.3Mandatory Acquisition Information not Available (from step 2 of Alternative Flow 4.2.1)

  1. The Recorder investigates with the Documenter or sending institution.
  2. If the required information is obtained, the use case resumes at step 3 of Alternative Flow 4.2.1.
  3. If the required information is not obtained, the use case ends.

4.2.4Record not Found – Change in Responsibility (from Step 3)

  1. The Recorder investigates if the individual or group was accessioned.
  2. If the required information is obtained, the use case resumes at step 4 of the Basic Flow.
  3. If the required information is not obtained, the use case ends.

4.2.5Responsibility Change already Recorded (from Step 4)

  1. The Recorder investigates the cause of the apparent duplication.
  1. If the duplication is resolved and the change is to be recorded, the use case resumes at step 5 of the Basic Flow.
  2. If the responsibility change is not to be recorded, the use case ends.

4.2.6Acquisition Recording Not to be Completed (from Step 5)

  1. The Recorder suspends or cancels the activity.
  1. The use case ends.

4.2.7Data Review Errors (from Step 6)

  1. The Data Reviewer investigates with the Recorder or Documenter.
  1. The Recorder corrects the data.
  2. The use case ends.

4.2.8Data Validation Errors (from Step 7)

  1. The Validator investigates with the Recorder or Documenter.
  1. The Recorder corrects the data.
  2. The use case ends.

4.3Included Use Cases

None

5.0Information Required

  • Date of acquisition data recording
  • Time stamp of acquisition data recording
  • Name of documenter
  • Method of determination of the acquisition
  • Name of recorder
  • Estimated date of acquisition
  • Estimated time of acquisition
  • Estimated time of acquisition error factor
  • Actual date of acquisition
  • Actual time of acquisition
  • Name of Data Reviewer
  • Review date
  • Review time
  • Date ranges
  • Legal status
  • Name of new legal owner
  • Physical status
  • Name of new physical owner
  • Government managed status
  • Name of new governmental management agency responsible
  • Multimedia
  • Permits for acquisition
  • Collection type (rehab/rescue, main collection, museum, quarantine)
  • Sender name
  • Name of originating physical owner
  • Name of originating legal owner
  • Name of originating governmental management agency
  • Birth/Pre-Birth, Hatch/Pre-Hatch additional acquisition data
  • Acquisition type
  • Additional Transit related data (e.g.: shipping cost, broker, shipper)
  • Acquisition price for individual or group
  • Additional “Off-Shore” related data (e.g.: quarantine conditions)
  • Collection location (if from the wild)
  • Insurance-related acquisition information

6.0Business Rules

  • Acquisition applies to individual animals, a group of animals, parts of animals or parts of coral (split from parent).
  • Parts of individual animals or animals in groups may be acquisitioned, only if they are not samples taken from the animals.
  • An individual or group may not have been transferred from or may not have been in the responsibility of another institution e.g. if the animal(s) came from the wild or a birth was within the institution assigning responsibility for the animal(s).

7.0Other Requirements, Issues and Considerations

7.1Special Requirements

  • Authorization to enter acquisition information for an individual or group.
  • Need to be able to import or export data.
  • Legal requirements – too many to list
  • Depersonalization of data based on institution.
  • Animal security (privacy) – relating to shows, exhibits, etc
  • Some form of transaction clearing house is needed – to enable matching transactions across regional boundaries.

7.2Assumptions

None

7.3Issues

  1. Is Documenter still needed as an Actor, since documentation of the acquisition is listed as a pre-condition i.e. prior to the start of the activity?
  2. What is the “date range” data for – effective period of an acquisition type?

7.4Considerations

None

7.5Cross References

8.0Workflows

ISIS and CGI Restricted
Doc. #: PM044 / Page 1 / Version 01.00
Issue Date: August 4, 2004