Table of Contents | Chapter 5 | Chapter 7
6.0 OBJECTIVE
6.1 TASKS AND ACTIVITIES
6.1.1
Analyze and Document Requirements
6.1.2
Develop the Test Criteria and Plans
6.1.3
Develop an Interface Control Document
6.1.4
Review and Assess FOIA/PA Requirements
6.1.5
Conduct Functional Review
6.1.6
Revise Previous Documentation
6.2 ROLES AND RESPONSIBILITIES
6.3 DELIVERABLES
6.3.1
Functional Requirements Document
6.3.2
Test and Evaluation Master Plan
6.3.3
Interface Control Document
6.3.4
Privacy Act Notice/Privacy Impact Assessment
The Requirements Analysis Phase will begin when the previous phase documentation has been approved or by management direction. Documentation related to user requirements from the Planning Phase shall be used as the basis for further user needs analysis and the development of detailed user requirements. The analysis may reveal new insights into the overall information systems requirements, and, in such instances, all deliverables should be revised to reflect this analysis.
During the Requirements Analysis Phase, the system shall be defined in more detail with regard to system inputs, processes, outputs, and interfaces. This definition process occurs at the functional level. The system shall be described in terms of the functions to be performed, not in terms of computer programs, files, and data streams. The emphasis in this phase is on determining what functions must be performed rather than how to perform those functions.
The following tasks are performed during the Requirements Analysis Phase. The tasks and activities actually performed depend on the nature of the project. Guidelines for selection and inclusion of tasks for the Requirements Analysis Phase may be found in Chapter 13, Alternative SDLC Work Patterns.
First consolidate and affirm the business needs. Analyze the intended use of the system and specify the functional and data requirements. Connect the functional requirements to the data requirements. Define functional and system requirements that are not easily expressed in data and process models Refine the high level architecture and logical design to support the system and functional requirements
A logical model is constructed that describes the fundamental processes and data needed to support the desired business functionality. This logical model will show how processes interact and how processes create and use data. These processes will be derived from the activity descriptions provided in the System Boundary Document.
Functions and entity types contained in the logical model are extended and refined from those provided in the Concept Development Phase. End-users and business area experts will evaluate all identified processes and data structures to ensure accuracy, logical consistency, and completeness. An analysis of business activities and data structures is performed to produce entity-relationship diagrams, process hierarchy diagrams, process dependency diagrams, and associated documentation. An interaction analysis is performed to define the interaction between the business activities and business data. This analysis produces process logic and action diagrams, definitions of the business algorithms, entity life-cycle diagrams, and entity state change matrices. A detailed analysis of the current technical architecture, application software, and data is conducted to ensure that limitations or unique requirements have not been overlooked.
Include all possible requirements including those for:
Establish the test criteria and begin test planning. Include all areas where testing will take place and who is responsible for the testing. Identify the testing environment, what tests will be performed, test procedures; and traceability back to the requirements.
Describe what will be tested in terms of the data or information. If individual modules are being tested separately, this needs to be stated in the Master Plan. Smaller plans may be needed for specialized testing, but they should all be referenced in the Master Plan.
The project team responsible for the development of this system needs to articulate the other systems (if any) this system will interface with. Identify any interfaces and the exchange of data or functionality that occurs. All areas that connect need to be documented for security as well as information flow purposes.
The FOIA/PA describes the process and procedures for compliance with personal identifier information. A Records Management representative will determine if what you plan constitutes a system as a Privacy Act System of Records. A system of records notice must be published for each new system of records that is established or existing system of records that is revised. If needed, a Privacy Act Notice for the Federal Register will be prepared.
The collection, use, maintenance, and dissemination of information on individuals by any Department component require a thorough analysis of both legal and privacy policy issues. Whether a system is automated or manual, privacy protections should be integrated into the development of the system. To ensure that the Department properly addresses the privacy concerns of individuals as systems are developed, Departmental policy mandates that components develop and utilize the Privacy Impact Assessment (PIA) processes.
Federal regulations require that all records no longer needed for the conduct of the regular business of the agency be disposed of, retired, or preserved in a manner consistent with official Records Disposition Schedules. The decisions concerning the disposition criteria, including when and how records are to be disposed, and the coordination with the Records Management representatives to prepare the Records Disposition Schedule for the proposed system, shall be the responsibilities of the Project Manager.
The Functional and Data Requirements Review is conducted in the Requirements Analysis Phase by the technical review board. This is where the functional requirements identified in the FRD are reviewed to see if they are sufficiently detailed and are testable. It also provides the Project Manager with the opportunity to ensure a complete understanding of the requirements and that the documented requirements can support a detailed design of the proposed system.
Review and update previous phase documentation if necessary before moving to the next phase.
Serves as the foundation for system design and development; captures user requirements to be implemented in a new or enhanced system; the systems subject matter experts document these requirements into the requirements traceability matrix, which shows mapping of each detailed functional requirement to its source. This is a complete, user oriented functional and data requirements for the system which must be defined, analyzed, and documented to ensure that user and system requirements have been collected and documented.
All requirements must include considerations for capacity and growth. Where feasible,
I-CASE tools should be used to assist in the analysis, definition, and documentation. The requirements document should include but is not limited to records and privacy act, electronic record management, record disposition schedule, and components’ unique requirements. Consideration must also be given to persons with disabilities as required by the Rehabilitation Act, 20 U.S.C., Sec 794d (West Supp. 1999). Appendix C-14 provides a template for the Functional Requirements Document.
Ensures that all aspects of the system are adequately tested and can be implemented; documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. Unit, integration, and independence acceptance testing activities are performed during the development phase. Unit and integration tests are performed under the direction of the project manager. Independence acceptance testing is performed independently from the developing team and is coordinated with the Quality Assurance (QA) office. Acceptance tests will be performed in a test environment that duplicates the production environment as much as possible. They will ensure that the requirements are defined in a manner that is verifiable. They will support the traceability of the requirements form the source documentation to the design documentation to the test documentation. They will also verify the proper implementation of the functional requirements. Appendix C-15 provides a template for the Test and Evaluation Master Plan.
The types of test activities discussed in the subsequent sections are identified more specifically in the Integration and Test Phase of the life cycle and are included in the test plan and test analysis report.
• Unit/Module Testing
• Subsystem Integration Testing
• Independent Security Testing
• Functional Qualification Testing
• User Acceptance Testing
• Beta Testing
The Interface Control Document (ICD) provides an outline for use in the specification of requirements imposed on one or more systems, subsystems configuration items or other system components to achieve one or more interfaces among these entities. Overall, an ICD can cover requirements for any number of interfaces between any number of systems. Appendix C-16 provides a template for the Interface Control Document.
For any system that has been determined to be an official System of Records (in terms of the criteria established by the Privacy Act (PA)), a special System of Records Notice shall be published in the Federal Register. This Notice identifies the purpose of the system; describes its routine use and what types of information and data are contained in its records; describes where and how the records are located; and identifies who the System Manager is. While the Records Management Representatives are responsible for determining if a system is a PA System of Records, it is the Project Managers’ responsibility to prepare the actual Notice for publication in the Federal Register. As with the Records Disposition Schedule, however, it is the Project Manager’s responsibility to coordinate with and assist the System Proponent in preparing the PA Notice.
The System of Records Notice shall be a required deliverable for the Requirements Analysis Phase of system development. The Privacy Impact Assessment is also a deliverable in this Phase. This is a written evaluation of the impact that the implementation of the proposed system would have on privacy. Guidance for preparing a privacy impact assessment can be found at http://dojnet.doj.gov/jmd/irm/imss/itsecurity/itsecurityhome.html (available to DOJ Employees only).
In the Requirements Analysis Phase, it is important to get everyone involved with the project to discuss and document their requirements. A baseline is important in order to begin the next phase. The requirements from the FRD may become part of a solicitation in the Acquisition Plan.
Upon completion of all Requirements Analysis Phase tasks and receipt of resources for the next phase, the Project Manager, together with the project team should prepare and present a project status review for the decision maker and project stakeholders. The review should address: (1) Requirements Analysis Phase activities status, (2) planning status for all subsequent life cycle phases (with significant detail on the next phase, to include the status of pending contract actions), (3) resource availability status, and (4) acquisition risk assessments of subsequent life cycle phases given the planned acquisition strategy.