Requirements Analysis

From Archivematica
Jump to navigation Jump to search

Main Page > Projects > Vancouver Digital Archives > Requirements Analysis

Overview[edit]

The purpose of the requirements analysis phase of the project is to establish minimal baseline functional requirements, policies and procedures for a digital archives based on accepted standards.

  • The initial round of requirements gathering starts with the development of use cases based on the ISO 14721 Open Archival Information System (OAIS) reference model.
  • The OAIS is the de-facto standard for designing digital archives systems. Many digital preservation systems or projects claim to be "OAIS-compliant" and this is also a goal for the Vancouver Digital Archives project. However, there is a requirements traceability gap between the OAIS standard and systems that claim to be "OAIS-compliant". Therefore, this project is doing a detailed OAIS requirements analysis, through a use case methodology, to establish what the system requirements are for Digital Archives to be OAIS-compliant.
    • Please note: this addresses the technology and process components and not the organizational responsibilities which are also a critical component for full OAIS conformance.
  • A simple Use Case Methodology was established to structure the use cases.
  • The use cases attempt to present plain language descriptions of what the Digital Archives should accomplish. However, this is limited at times by the language and format of OAIS itself as discussed during the analysis.


  • Other standards and best practice documents will be added as requirement sources in subsequent rounds of requirements analysis.
  • Functional, metadata and technology requirements will be derived from the use cases and technology evaluation
    • Functional requirements specify what the system must be able to do
    • Metadata requirements stipulate what data attributes must be captured for each step
    • Technical requirements stipulate specific technical features, formats or protocols that must be implemented.
  • Policies and procedures are also derived from the use cases, in that they are developed to support all the steps the use cases contain. For example, a use case may state: "System implements disaster recovery policies such as duplication to remote storage facility"; successful completion of this step naturally requires the development of such policies.
  • The Functional requirements are being expressed as UML Activity Diagrams. A first set of these are based directly on the OAIS Use Cases without any additional interpretation

CoV DigitalArchives RequirementsAnalysisProcess v3.gif

OAIS Use Cases[edit]



OAIS (UML) Activity Diagrams[edit]

These diagrams are an interpretation of the OAIS Use Cases to the UML Activity Diagram format. They focus on the practical steps required to accomplish each use case. Where possible, the activity references the use case number from which it is derived.

Each activity is likely to generate some metadata and have one or more information entities as an input and output. However, these will be captured in a seperate metadata requirement analysis and information model. Likewise, each activity may be governed or restricted by one or more policy or procedures but these are also intentionally left out of the diagram for clarity. Except where they are explicitly noted, these diagrams assume that there no errors in the activity flow, i.e. these are 'sunny-day' scenarios.

Ingest[edit]

  • AD1 Receive SIP (PDF) (ODG) v1
  • AD2 Generate AIP (PDF) (ODG) v1
  • AD3 Prepare AIP for Storage (PDF) (ODG) v1

Archival Storage[edit]

Data Management[edit]

  • AD6 Update Database (PDF) (ODG)v1
  • AD7 Query Database (PDF) (ODG) v1
  • AD8 Administer Database (PDF) (ODG) v1

Access[edit]

  • AD9 Coordinate Information Request (PDF) (ODG) v1
  • AD10 Coordinate DIP Request (PDF) (ODG) v1
  • AD11 Coordinate Assistance Request (PDF) (ODG) v1
  • AD12 Coordinate Migration Request (PDF) (ODG) 1
  • AD13 Generate DIP (PDF) (ODG) v1

Administration[edit]

  • AD14 Negotiate Submisssion Agreement (PDF) (ODG) v2
  • AD15 Manage System Configuration (PDF) (ODG) v1
  • AD16 Update Archival Information (PDF) (ODG) v1
  • AD17 Control Physical Access (PDF) (ODG) v1
  • AD18 Establish Standards and Policies (PDF) (ODG) v1
  • AD19 Activate Requests (PDF) (ODG) v1
  • AD20 Administer Customer Service (PDF) (ODG) v1
  • AD21 Audit SIP Submission (PDF) (ODG) v1
  • AD22 Audit AIP Submission (PDF) (ODG) v1

Preservation Planning[edit]

  • AD23 Monitor Designated Community (PDF) (ODG) v1
  • AD24 Monitor Technology (PDF) (ODG) v1
  • AD25 Prototyping (PDF) (ODG) v1
  • AD26 Develop Preservation Strategies (PDF) (ODG) v1
  • AD27 Develop Preservation Standards (PDF) (ODG) v1
  • AD28 Profile External Data Standards(PDF) (ODG) v1
  • AD29 Develop Migration Plans (PDF) (ODG) v1
  • AD30 Update Package Designs(PDF) (ODG) v1

City of Vancouver Archives (UML) Activity Diagrams[edit]

These diagrams are derived from the OAIS UML Activity Diagrams. These were revised based on an analysis of the existing or future policies and procedures of the City of Vancouver Archives.

These UML Activity Diagrams form the baseline functional requirements for the CoV Digital Archives.

Wherever possible, the functions are assigned to software or technical tools. If it is not possible to automate these functions in the current system iteration, the functions are incorporated into a manual procedure to be carried out by a digital archivist. This ensures that the entire set of functional requirements are being carried out in the system, which is an integrated whole of software, people and procedures. The goal is to improve the level of automation and sophistication with each system iteration.

Ingest[edit]

  • AD1 Receive SIP (PDF) v1
  • AD2 Audit SIP (PDF) v5
  • AD3 Accept SIP for Ingest (PDF) v4
  • AD4 Generate AIP (PDF) v2
  • AD5 Transfer AIP to Archival Storage (PDF) v2

Archival Storage[edit]

  • AD6 Receive AIP (PDF) v2
  • AD7 Store AIP (PDF) v1
  • AD8 Provide AIP (PDF) v1
  • AD9 Recover AIP (PDF) v1

Data Management[edit]

  • AD10 Update Database (PDF) v1
  • AD11 Query Database (PDF) v1

Access[edit]

  • AD12 Request DIP (PDF) v1
  • AD13 Deliver DIP (PDF) v1
  • AD14 Provide Assistance (PDF) v1
  • AD15 Collect Feedback (PDF)

Administration[edit]

  • AD16 Update Archival Information (PDF)
  • AD17 Activate Requests (PDF)
  • AD18 Monitor Data Submission Schedule (PDF)
  • AD19 Negotiate Submission Agreement (PDF)

City of Vancouver VanDocs-Digital Archives (UML) Activity Diagrams[edit]

These diagrams are derived from the City of Vancouver UML Activity Diagrams. These were revised based on an analysis of the specific case of exporting records from VanDocs (the City's ERDMS) and ingesting them to the Digital Archives. As such, they incorporate assumptions about SIP design, and specific workflow and administrative requirements that are a special case of what is represented in the more general City of Vancovuer Archives UML diagrams. The ingest process includes an additional step - Prepare Transfer. This represents the actions the ERDMS Administrator (Records and Information Management office, subsequently referred to as RIM) must take in order to prepare SIPs for submission to the Digital Archives, and to respond to subsequent messages or requests issued from the Digital Archvies to RIM.

These UML Activity Diagrams form the baseline functional requirements for the OAIS ingest function for records exported from VanDocs for preservation in the CoV Digital Archives.

Ingest[edit]

  • AD1 Transfer SIP (PDF) v1
  • AD2 Accession SIP (PDF) v1
  • AD3 Appraise SIP (PDF) v1
  • AD4 Generate AIP (PDF) v1
  • AD5 Store AIP (PDF) v1

Metadata Requirements[edit]

Technical Requirements[edit]

File formats[edit]

Requirement Sources[edit]

Primary sources


Other Possible sources


See Also[edit]

Retrieved from "https://wiki.archivematica.org/index.php?title=Requirements_Analysis&oldid=10391"