Difference between revisions of "Functional requirements"

From ICA-AtoM
Jump to navigation Jump to search
Line 10: Line 10:
  
  
Functional requirements are organized hierarchically. There are six main requirements, eqch of which is broken down into sub- and sub-sub-requirements:  
+
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 (FNC = functional requirement), the number establishes its position in the hierarchy. Six main functional requirements have been identified:
 
*[[FNC-1 Establish a system of control]]
 
*[[FNC-1 Establish a system of control]]
 
*[[FNC-2 Add / edit content]]
 
*[[FNC-2 Add / edit content]]
Line 24: Line 24:
  
 
|- valign="top" align="left" style="background:#00008B; color:white"
 
|- valign="top" align="left" style="background:#00008B; color:white"
!width="250" | Requirement number
+
!width="250" | Requirement name
!width="700" | FNC-x.x.x (unique tracking number assigned to requirement)
+
!width="700" | Descriptive name assigned to requirement.
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
| style="background:silver" | Requirement name
+
| style="background:silver" | Requirement number
| Descriptive name assigned to requirement.
+
| FNC-x.x.x (unique tracking number assigned to requirement)
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
 
| style="background:silver"  | Requirement specification
 
| style="background:silver"  | Requirement specification
| Brief description of requirement: system must do X.
+
| Brief description of requirement: users of the application must be able to do X, system must do X.
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
 
| style="background:silver" | Source quotation
 
| style="background:silver" | Source quotation
| Links to standards or other documents: why must the system be able to do X?
+
| Links to standards or other documents: why must the applicable be able to do X?
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
 
| style="background:silver" | Associated metadata requirements
 
| style="background:silver" | Associated metadata requirements
| Links to metadata requirements: what data must the system capture in order to be able to do X?
+
| Links to metadata requirements: what data must the application capture in order to be able to do X?
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
 
| style="background:silver" | Associated quality requirements
 
| style="background:silver" | Associated quality requirements
| What design and interface features must the system have to do X well?
+
| What design and interface features must the application have to do X well?
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
 
| style="background:silver" | Associated technical requirements
 
| style="background:silver" | Associated technical requirements
| Links to technical requirements: what system architecture, hardware / software configurations, and programming rules must the system implement to do X?
+
| Links to technical requirements: what system architecture, hardware / software configurations, and programming rules must the application implement to do X?
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
Line 61: Line 61:
 
|- valign="top" align="left"
 
|- valign="top" align="left"
 
| style="background:silver" | Use cases
 
| style="background:silver" | Use cases
| Links to descriptions of scenarios relating to the requirement and how they are handled in ICA-AtoM.
+
| Links to descriptions of user-end scenarios relating to the requirement and how they are handled in ICA-AtoM.
  
 
|- valign="top" align="left"
 
|- valign="top" align="left"
Line 67: Line 67:
 
| Links to the User manual sections that provide step-by-step instructions for doing X.
 
| Links to the User manual sections that provide step-by-step instructions for doing X.
  
|- valign="top" align="left"
+
|}
| style="background:silver"  | Sub-requirements
+
 
| If the requirement is broken down into sub-requirements, provides links to these.
 
  
|}
+
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.

Revision as of 11:47, 5 May 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


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).


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 (FNC = functional requirement), the number establishes its position in the hierarchy. Six main functional requirements have been identified:


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

Requirement name Descriptive name assigned to requirement.
Requirement number FNC-x.x.x (unique tracking number assigned to requirement)
Requirement specification Brief description of requirement: users of the application must be able to do X, system must do X.
Source quotation Links to standards or other documents: why must the applicable be able to do X?
Associated metadata requirements Links to 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 Links to 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.