UC-1.2.1

From ICA-AtoM
Revision as of 16:12, 11 July 2008 by Richard (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Please note that ICA-AtoM is no longer actively supported by Artefactual Systems.
Visit https://www.accesstomemory.org for information about AtoM, the currently supported version.

Implement an arrangement policy

Main Page > System requirements > Use cases

Summary

Overview

  • An institution establishes its arrangement policy and customizes the application to implement it.


Context (parent cases)


Actors

  • Primary actor: institution.
  • Secondary actors: administrator.


Description

Preconditions

  • Institution establishes a policy on arrangement.


Trigger

  • N/A.


Successful outcome

  • Application customized so that user options reflect institution's arrangement policy..


Main scenario

Scenario A:

1. Institution establishes the highest level of arrangement it will employ.

  • E.g. Fonds, series, record group established as highest level.

2. Institution establishes the number of levels of arrangement it will employ.

  • E.g. no sub-fonds, no more than three series levels (series, sub- and sub-sub-series).

3. Administrator edits the default "Levels of description" taxonomy shipped with ICA-AtoM, so that drop-down lists show only levels and terms allowed by policy.


Exceptions / variations

Scenario B:

Institution changes policy and for a transitional period retains old data values in the application (pending conversion) but allows users to use only new values.

  • E.g. application contains descriptions registered as "Record group" but term no longer allowed for new descriptions.

ICA-AtoM cannot currently (v1.0 beta) accommodate this scenario. A term cannot be deleted from a taxonomy if other records are already registered to it. In a future release, it will be possible to make taxonomy terms "inactive" so that data integrity is protected, while drop-down list for on-going data entry show only the preferred terms.


Requirements

Functional requirements


Metadata requirements


Technical requirements

  • N/A


Documentation

Diagrams

  • N/A


User Manual