Difference between revisions of "Functional requirements"
Jump to navigation
Jump to search
| (37 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Main Page]] > [[System | + | [[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 are organized hierarchically | + | == 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|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 the following 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''']] |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [[FR-5|'''FR-5 Import / export content''']] | |
| − | | | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | | | + | [[FR-6|'''FR-6 Administer the system''']] |
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:
- Parameters for designing the system and identifying metadata requirements.
- 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
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.