Difference between revisions of "Functional requirements"
Jump to navigation
Jump to search
| Line 2: | Line 2: | ||
[[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: | ||
| Line 12: | Line 12: | ||
| − | + | '''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 ( | + | 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-1|FR-1 Implement a system of control]] | ||
| Line 23: | Line 23: | ||
*[[FR-6|FR-6 Administer the system]] | *[[FR-6|FR-6 Administer the system]] | ||
| − | + | ||
| + | '''Information''' | ||
Each functional requirement includes some or all of 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. | |
| − | |||
| − | |||
| − | + | *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. | |
| Line 79: | Line 54: | ||
| − | + | '''Index of functional requirements''' | |
| − | [[ | + | [[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 Identify data input methods]] |
| − | **[[ | + | **[[FR-1.1.2|FR-1.1.2 Identify repositories that will contribute descriptions]] |
| − | **[[ | + | **[[FR-1.1.3|FR-1.1.3 Identify languages in which descriptions will be accessible]] |
| − | **[[ | + | **[[FR-1.1.4|FR-1.1.4 Identify individuals who will contribute descriptions]] |
*[[FNC-1.2 | FNC-1.2 Implement a system of intellectual control]] | *[[FNC-1.2 | FNC-1.2 Implement a system of intellectual control]] | ||
Revision as of 17:44, 3 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.
- 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.
- 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