Difference between revisions of "Functional requirements"

From ICA-AtoM
Jump to navigation Jump to search
 
(50 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Main Page]] > [[System Requirements]] > Functional requirements
+
[[Main Page]] > [[System requirements]] > Functional requirements
  
 +
== Purpose ==
  
 
Functional requirements state what the system must be able to do. The requirements provide:
 
Functional requirements state what the system must be able to do. The requirements provide:
*Parameters for designing the system.
+
 
 +
*Parameters for designing the system and identifying [[Metadata requirements|metadata requirements]].
 +
 
 
*Criteria for testing the system (used in initial release and future iterations and upgrades).
 
*Criteria for testing the system (used in initial release and future iterations and upgrades).
 +
 
*Planning guidelines for developing the system (improve existing or add new functionality).
 
*Planning guidelines for developing the system (improve existing or add new functionality).
 +
 
*Documentation for standards compliance (link requirements to relevant international or national descriptive standards)
 
*Documentation for standards compliance (link requirements to relevant international or national descriptive standards)
 +
 
*A framework for structuring user-end documentation (step-by-step procedures for how to do things in the system).
 
*A framework for structuring user-end documentation (step-by-step procedures for how to do things in the system).
  
  
Functional requirements have been organized around the core functions of repositories holding archival material. ICA-AtoM currently focuses on two functions:  
+
== Organization ==
*[[Intellectual and administrative control]] (support arrangement and description of archival holdings).
+
 
*[[Search and use]] (support search and use of descriptions by researchers).
+
Functional requirements are organized hierarchically, with high-level requirements broken down into sub- and sub-sub-requirements. To facilitate cross-references and links, each requirement has been assigned an alpha-numeric code: the alpha prefix designates the type of requirement (FR = functional requirement), the number establishes its position in the hierarchy. Six main functional requirements have been identified:
 +
 
 +
[[FR-1|FR-1 Implement a system of control]]
 +
 
 +
[[FR-2|FR-2 Add / edit content]]
 +
 
 +
[[FR-3|FR-3 Translate content]]
 +
 
 +
[[FR-4|FR-4 Access content]]
 +
 
 +
[[FR-5|FR-5 Import / export content]]
 +
 
 +
[[FR-6|FR-6 Administer the system]]
 +
 
 +
 
 +
== Information ==
 +
 
 +
Each functional requirement includes some or all of the following information:
 +
 
 +
*'''Requirement number''': FR-x.x.x, unique tracking number assigned to requirement.
 +
 
 +
*'''Requirement name''': descriptive name assigned to requirement.
 +
 
 +
*'''Specification''': brief description of requirement; users of the application must be able to do X, the system must be able to do X.
 +
 
 +
*'''Context (parent requirements)''': links to higher-level requirements, if applicable.
 +
 
 +
*'''Sub-requirements''': links to lower-level requirements, if applicable.
 +
 
 +
*'''Source quotations''': links to standards or other documents: why must the applicable be able to do X?
 +
 
 +
*'''Associated metadata requirements''': what data must the application capture in order to be able to do X?
 +
 
 +
*'''Associated quality requirements''': what design and interface features must the application have to do X '''well'''?
 +
 
 +
*'''Associated technical requirements''': what system architecture, hardware / software configurations, and programming rules must the application implement to do X?
 +
 
 +
*'''ICA-AtoM implementation''': brief description of how ICA-AtoM implements X.
 +
 
 +
*'''Known issues''': brief indication of known problems or limitations in the current version of ICA-AtoM that should be addressed in future releases.
 +
 
 +
*'''Use cases''': links to descriptions of user-end scenarios relating to the requirement and how they are handled in ICA-AtoM.
 +
 
 +
*'''User Manual sections''': links to the User manual sections that provide step-by-step instructions for doing X.
 +
 
 +
 
 +
Note that most of this detail will only be found at the lower-level requirements. Higher-level requirements will typically only include the requirement name, number, specification, and source quotation, with links to the lower-level sub-requirements.
 +
 
 +
 
 +
== Index of functional requirements ==
 +
 
 +
The following is the full index of functional requirements identified to date.
 +
 
 +
 
 +
[[FR-1|'''FR-1 Implement a system of control''']]
 +
 
 +
*[[FR-1.1|FR-1.1 Define system scope]]
 +
**[[FR-1.1.1|FR-1.1.1 Specify data input methods]]
 +
**[[FR-1.1.2|FR-1.1.2 Specify repositories that will contribute descriptions]]
 +
**[[FR-1.1.3|FR-1.1.3 Specify languages in which descriptions will be accessible]]
 +
**[[FR-1.1.4|FR-1.1.4 Specify individuals who will contribute descriptions]]
 +
 
 +
*[[FR-1.2 |FR-1.2 Implement a system of intellectual control]]
 +
**[[FR-1.2.1|FR-1.2.1 Describe material at multiple levels of arrangement]]
 +
**[[FR-1.2.2|FR-1.2.2 Establish the highest level of arrangement]]
 +
**[[FR-1.2.3|FR-1.2.3 Establish the number of levels of arrangement]]
 +
**[[FR-1.2.4|FR-1.2.4 Comply with descriptive standards]]
 +
**[[FR-1.2.5|FR-1.2.5 Establish level of detail required]]
 +
 
 +
*[[FR-1.3|FR-1.3 Implement a system of administrative control]]
 +
 
 +
*[[FR-1.4| FR-1.4 Implement a system of physical control]]
 +
 
 +
 
 +
[[FR-2|'''FR-2 Add / edit content''']]
 +
 
 +
*[[FR-2.1|FR-2.1 Appraise materials]]
 +
 +
*[[FR-2.2|FR-2.2 Acquire archival materials]]
 +
 +
*[[FR-2.3|FR-2.3 Store archival materials]]
 +
 +
*[[FR-2.4|FR-2.4 Preserve archival materials]]
 +
 +
*[[FR-2.5|FR-2.5 Describe archival materials]]
 +
**[[FR-2.5.1|FR-2.5.1 Identify units of description]]
 +
**[[FR-2.5.2|FR-2.5.2 Describe context (origin and custody) of archival materials]]
 +
**[[FR-2.5.3|FR-2.5.3 Describe content and structure of archival materials]]
 +
**[[FR-2.5.4|FR-2.5.4 Indicate conditions of access and use of archival materials]]
 +
**[[FR-2.5.5|FR-2.5.5 Indicate related archival materials]]
 +
 +
*[[FR-2.6|FR-2.6 Describe actors that interact with archival materials]]
 +
**[[FR-2.6.1|FR-2.6.1 Identify actors]]
 +
**[[FR-2.6.2|FR-2.6.2 Describe the nature, context, and activities of actors]]
 +
**[[FR-2.6.3|FR-2.6.3 Indicate relationships between actors]]
 +
**[[FR-2.6.4|FR-2.6.4 Identify related archival materials]]
 +
 +
*[[FR-2.7|FR-2.7 Describe institutions that have custody of archival materials]]
 +
 +
*[[FR-2.8|FR-2.8 Control descripiton records]]
 +
 +
*[[FR-2.9|FR-2.9 Assign access points to descriptions]]
 +
 +
*[[FR-2.10|FR-2.10 Administer access to archival materials]]
 +
 +
*[[FR-2.11|FR-2.11 Promote archival materials]]
 +
 
 +
 
 +
[[FR-3|'''FR-3 Translate content''']]
 +
 
 +
 
 +
[[FR-4|'''FR-4 Access content''']]
  
  
A number of functions remain outside the scope of the current version or are only partially supported. Inclusion of these functions serves primarily as a placeholder for requirements for future development of the system.
+
[[FR-5|'''FR-5 Import / export content''']]
*[[Acquisition]] (accession material, transfer / capture / ingest material, track donors, appraise for acquisition, appraise for monetary evaluation).
 
*[[Physical control]] (store and retrieve archival material, manage storage space).
 
*[[Preservation]] (implement strategies for long-term preservation of archival material).
 
*[[Access administration]] (provide reference service, deliver access to archival material).
 
*[[Outreach]] (exhibit objects, promote holdings, repositories, and the archival profession).
 
  
  
Each functional requirement includes the following information:
+
[[FR-6|'''FR-6 Administer the system''']]
*Requirement name.
 
*Requirement specification (system must do X).
 
*Requirement quotation (which section of which standard requires that the system do X?).
 
*Associated metadata requirements (what fields must the system have to do X?).
 
*Associated usability requirements (what features msut the system have to do X well from a user / interface point of view?).
 
*ICA-AtoM implementation (how does ICA-AtoM implement X?).
 
*Associated ''User Manual'' sections (links to step-by-step instructions for doing X).
 

Latest revision as of 12:14, 11 July 2008

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.

Main Page > System requirements > Functional requirements

Purpose

Functional requirements state what the system must be able to do. The requirements provide:

  • Criteria for testing the system (used in initial release and future iterations and upgrades).
  • Planning guidelines for developing the system (improve existing or add new functionality).
  • Documentation for standards compliance (link requirements to relevant international or national descriptive standards)
  • A framework for structuring user-end documentation (step-by-step procedures for how to do things in the system).


Organization

Functional requirements are organized hierarchically, with high-level requirements broken down into sub- and sub-sub-requirements. To facilitate cross-references and links, each requirement has been assigned an alpha-numeric code: the alpha prefix designates the type of requirement (FR = functional requirement), the number establishes its position in the hierarchy. Six main functional requirements have been identified:

FR-1 Implement a system of control

FR-2 Add / edit content

FR-3 Translate content

FR-4 Access content

FR-5 Import / export content

FR-6 Administer the system


Information

Each functional requirement includes some or all of the following information:

  • Requirement number: FR-x.x.x, unique tracking number assigned to requirement.
  • Requirement name: descriptive name assigned to requirement.
  • Specification: brief description of requirement; users of the application must be able to do X, the system must be able to do X.
  • Context (parent requirements): links to higher-level requirements, if applicable.
  • Sub-requirements: links to lower-level requirements, if applicable.
  • Source quotations: links to standards or other documents: why must the applicable be able to do X?
  • Associated metadata requirements: what data must the application capture in order to be able to do X?
  • Associated quality requirements: what design and interface features must the application have to do X well?
  • Associated technical requirements: what system architecture, hardware / software configurations, and programming rules must the application implement to do X?
  • ICA-AtoM implementation: brief description of how ICA-AtoM implements X.
  • Known issues: brief indication of known problems or limitations in the current version of ICA-AtoM that should be addressed in future releases.
  • Use cases: links to descriptions of user-end scenarios relating to the requirement and how they are handled in ICA-AtoM.
  • User Manual sections: links to the User manual sections that provide step-by-step instructions for doing X.


Note that most of this detail will only be found at the lower-level requirements. Higher-level requirements will typically only include the requirement name, number, specification, and source quotation, with links to the lower-level sub-requirements.


Index of functional requirements

The following is the full index of functional requirements identified to date.


FR-1 Implement a system of control


FR-2 Add / edit content


FR-3 Translate content


FR-4 Access content


FR-5 Import / export content


FR-6 Administer the system