Models for Action: Developing Practical Approaches to Electronic Records Management and Preservation :

Appendix

Records Requirements Analysis and Implementation Tool

Records Requirements Elicitation Component

Records Requirements Implementation Component

Models for Action First Draft of Functional Requirements

Compliant - Legal and administrative requirements as well as best practices for record keeping related to a specific business process including those requirements specific to the field or discipline that the system will support, are addressed.
System Reliability - System should be administered in line with best practices in the information resource management (IRM) field to ensure the reliability of the records it produces.
Records Capture - Records are created or captured and identified to support the business process and meet all record keeping requirements.
Records Maintained - Electronic records are maintained so that they are accessible and retain their integrity for as long as they are needed.
Records Are Usable - Electronic records are usable for the purposes they were created and can be exported into an integral, accessible, usable format from the creating system to other systems. This includes the ability to transfer the records to an archival repository if necessary.

Models for Action Functional Requirements

System Reliability - System should be administered in line with best practices in the information resource management (IRM) field to ensure the reliability of the records it produces.
Records Capture - Records are created or captured and identified to support the business process and meet all record keeping requirements.
Records Maintenance and Accessibility - Electronic records are maintained so that they are accessible and retain their integrity for as long as they are needed.

Center for Technology in Government
NYS Archives and Records Administration
Models for Action Project
Records Requirements Elicitation Component

Business Process Level

1. What is the transaction to be automated (from the perspective of the customer)?

2. What are the sub-tasks associated with the transaction?*

3. For each of the subtasks gather the following information:

A. What is the purpose of the sub-task? Is it intended to fulfill a legal, regulatory or operational purpose?

1. Are there any when or how requirements for the transaction (i.e., time clocks or professional techniques)?

B. What other documents or information need to be accessed during the sub-task? Are copies of these records included in the record of the transaction?
C. Does the record of the transaction get created or modified?

1. If yes, (add to table) at what point in the transaction does the record get created or modified?
2. Who is authorized to change or modify the record?
3. What is the content of the record or the component of the record created during the sub-task?

a. Are there records created by other systems that need to be integrated into the record?
b. Are there any proofs of authenticity associated with the content created or modified during the sub-task?

*Sub-task starts a process and ends with a decision point or completes the transaction.