The RREC translates the Functional Requirements into a set of questions or prompts that assist in the comprehensive identification of application-specific records management requirements. The goal is to seamlessly integrate the capture of these requirements into activities normally conducted during business process improvement and system design. The three components of the RREC can be mapped directly to the three categories of Functional Requirements as shown in the figure above.

The following sections present an overview of each of the three levels of the RREC. For each level, we provide a description of objectives, specify questions to be addressed, and give steps and hints for use.

The Business Process Level of the RREC was developed to support the identification of records management requirements associated with a given business process. It is also designed to identify records management requirements that are required by law, regulation, professional requirements, or organizational policy and practices at the sub-task level. These distinctions are important in terms of justifying requirements and determining which, if any, sub-tasks can be eliminated or modified.

This level of the RREC seeks information at the record component and business process levels. The records management requirements gathered at this level are focused on collecting information about the process itself, and the modifications to records at points in the process, in terms of how the record is modified (what is added, deleted, or changed) and the individuals who have authority to make the modifications.

The Business Process Level questions identify required information about time clocks associated with the process to ensure that information about start and end times associated with a given task are captured. They also identify other information or documents that may need to be accessed and consulted, but perhaps not integrated into the record, so that, at minimum, the system will allow for references to these sources. This section of the RREC also captures information about the types of documents that must be integrated into the record, as well as any proofs of authenticity, such as original signatures, notarizations, or electronic time stamps, that must be captured at the document or record component level.

The Business Process Level of the RREC also supports the identification of objects (another way to think about components of a record) that can later become the objects in an object-oriented database structure. This level also identifies the required meta data (information about the object including when it was modified and by whom) for each of the objects or components of a record.

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 subtasks associated with the transaction?*
3. For each of the subtasks...
Basis for the answer
	Legal	Regulatory	Best Practices	Agency policies & practices
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 standard professional techniques)
B. What other documents or information must be accessed during the sub-task?
C. Is the record of the transaction created or modified?
1. If yes, at what point in the transaction is the record 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 or added during the sub- task?
a. Are there documents or information created by other systems that must be integrated into the record?
b. Is there any information about the component of the record that must be collected and maintained?
c. Are there any proofs of authenticity associated with the content created or modified during the sub-task?
*A sub-task starts a process and ends with a decision point or completes the transaction.

As shown in the figure below, the primary unit of analysis for the Record Level of the RREC is the record itself. In general terms, this section of the tool seeks to capture records management requirements associated with access and use over time, for both the record in aggregate and its component parts. The questions are focused on capturing records management requirements related to the access and maintenance of records once they have been created, or after a business transaction has been completed.

This section of the RREC identifies the specific components of the record that must be retrievable and reproducible for use by both internal and external secondary users. It also focuses on the identification of an organization's records disposition plan, including the individual(s) responsible for disposing of records according to the plan and those responsible for modifying or updating the plan.

The Record Level specifies the information that must be collected in identifying a comprehensive set of records management requirements, but it does not dictate the mechanisms by which the questions are asked and answered. Several methods can be used. For example, the answers can be acquired through interviews of relevant staff, conversations with experts such as legal staff, group decision conferences, or surveys. The method used to answer the questions outlined in the Record Level of the RREC should be determined in much the same way a research method would be selected to answer a research question. A variety of factors need to be considered and the most cost-effective mechanism for gathering the information should be used.

Records Requirements Eliciation Component Record Level
1. What are the current components of a complete or final record of the transaction?
2. What are the minimal components to provide evidence of the transaction? (If you went to court, what would be the minimum information that you would need?)
3. Are there any laws, regs, or professional best practices that specify the structure (including medium, format, relationships) of the record or any of its components?
4. What information must be created to control, manage, and access the record throughout its life-cycle? (What information about the record do you need: e.g. who created it, when, etc.)
5. For each of the components of the record, what information is essential to access, verify the authenticity, interpret the contents, etc.?
6. During what other business processes might you need access to this record? For each of these other business processes, which components of the record need to be accessed? For each of these business processes, what are the best ways to access the records (i.e. indexing)?*
7. Who are the external secondary users of the record? Which components of the record are required by external secondary users? For each of these secondary uses, what are the most efficient/effective ways of accessing components of the records (i.e. indexing)? How will the record be reproduced to meet the needs of internal and external secondary users? What are the rules, laws, and regulationss that restrict or open access to these records to external users? If these records are covered by FOIL: For those components of the record that the Agency wishes to restrict access to, which category of exemption does the component fall under? For each of the components, what format are they currently in (e.g. GIS, database, WP, paper forms, narrative maps) and how will they be reproduced for distribution?
8. What is the record disposition plan?
9. Who is responsible for authorizing the disposition of records?
10. Who is responsible for authorizing the development or changes to the records disposition plan?
* Identify the business process that requires the most robust access and then determine if the other processes require additional access methods

Records Requirements Elicitation Component System Level
How will the system accommodate the required integration of records from other systems?
What other systems might these records be migrated to?
What is your system's migration plan?
For each of the technologies being used to support the business process:      What are the meta data requirements?      What are the industry standards?      What are the jurisdictional standards?

The System Level of the RREC is more directly related to technology than the other levels. As shown in the figure above, the questions at this level are focused on how a system will support the integration of the information and documents (record components) identified at the Business Process and Record Levels. In other words, the Business Process Level questions facilitate the identification of what information and documents must be integrated into a record, the Record Level focuses on how the record and its components will be maintained and accessed over time, and the System Level focuses on how, from a technical standpoint, an information system will accommodate the integration of, and ongoing access to, record components. This section also poses questions about future system migrations, by focusing on the types of hardware and software platforms that the system may be migrated to over time. These questions prompt the user to consider the feasibility of alternative migration plans which may have an effect on current technology choices.

The System Level questions also identify meta data, industry standards, and jurisdictional requirements associated with specific technology choices. For example, technologies such as digital imaging, GIS, and EDI may require different types of meta data and may require that certain standards are met within a given state or nation, or these standards may be tied to commonly accepted industry standards. Additionally, industry, organizational, or professional standards for system administration, back- up, and disaster recovery are identified through this level of the RREC.