The Requirements Analysis Phase begins when the previous phase objectives have been achieved. Documentation related to user requirements from the Concept Development Phase and the Planning Phase shall be used as the basis for further user needs analysis and the development of detailed requirements. Multiple-release projects require only one iteration of the Requirements Analysis Phase, which should involve requirements definition for all planned releases.
1.0: Objectives / Goals
2.0: Deliverables and Approvals
4.0: Tasks and Activities
Successful completion of the Requirements Analysis Phase should comprise:
The purpose of the Requirements Analysis Phase is to transform the needs and high-level requirements specified in earlier phases into unambiguous (measurable and testable), traceable, complete, consistent, and stakeholder-approved requirements.
Back To Top
SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated. The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize. State agencies may use formats other than the templates, as long as the deliverables include all required content.
The development and distribution of SDLC deliverables:
During the development of documentation, the Planning Team should:
The following is a listing of deliverables required of all projects for this phase of work.
Concept of Operations (ConOps) - describes the characteristics of the proposed system from the users’ perspectives.
System Requirements Document (SRD) - a formal statement of a system’s requirements, including, but not limited to: functional requirements, data requirements, system interface requirements, non-functional or operational requirements, and physical requirements.
Requirements Traceability Matrix (RTM) - a table that links requirements to their origins and traces them throughout the project life cycle. Developing the RTM helps to ensure that each requirement adds business value and that approved requirements are delivered.
Test Master Plan (TMP) - documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.
All deliverables other than those identified as Updates should be developed in this phase. Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.
Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table. A signature page or section should accompany each deliverable requiring approval. DoIT will periodically request copies of these documents as part of its oversight responsibilities..
The following personnel participate in the work activities in this phase:
Responsible – Describes role that executes the activities to achieve the task.
Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides.
Consulted – Describes roles that provide subject matter expertise.
Informed – Describes roles that receive information about the task.
The Roles and Responsibilities page has detailed descriptions of these roles and their associated responsibilities.
The Project Manager ensures the following prerequisites for this phase are complete:
The Project Manager monitors project performance by gathering status information about:
To measure project effort at all life cycle phases, the Project Manager establishes timelines and metrics for success when planning project tasks. This project performance information must be used as an input to the monthly and quarterly reporting provided to the DoIT Project Management Office (PMO). The Project Manager also organizes and oversees systematic quality management reviews of project work as a part of project performance monitoring.
The PMBOK provides additional details about controlling project work in sections 4.4 and 4.5, about project scope control in section 5.5, and about performance reporting in section 10.5.3.1.
The Project Manager routinely updates the PMP (at least quarterly) to ensure the PMP reflects project performance accurately. Review project performance controls and risks for deviations from the baseline.
Information dissemination is one of the Project Manager’s most important responsibilities. The Project Manager reviews and updates the Communication Management Plan at least quarterly to account for potential changes in project stakeholders. The Project Manager distributes the updated PMP and risk management information according to the revised Communication Management Plan. PMBOK, Chapter 10 contains additional details regarding project communications and information distribution.
The Project Manager conducts risk management activities, including:
Monitoring and control activities should address:
These activities occur throughout project duration to track and mitigate any new or changed project risks. The results of risk monitoring and control activities must be documented in the project’s Risk Register and included in monthly and quarterly reporting to DoIT PMO. The PMBOK has details for risk management activities in section 11, particularly sections 11.2 through 11.6.
The Planning Team with Project Manager supervision identifies system requirements.
Processes, information, and interactions
Non-functional specifications that address system operations and/or technical characteristics (such as encryption, security, hosting, environment, disaster recovery, level of service, performance, physical, capacity, sites, compliance, supportability, business continuity)
System Requirement Types
The Planning Team begins a detailed analysis of the current architecture and elicits, analyzes, specifies, prioritizes, verifies, and negotiates requirements that the proposed system must deliver and support. Functional requirements describe what the system has to do. Interacting closely with project stakeholders to identify the requirements, the Planning Team may use different tools and techniques such as:
PMBOK, fourth edition, section 5.1.2, has additional information regarding tools and techniques for requirements analysis. During requirements elicitation, the Planning Team should note all assumptions and constraints that will affect development and operation of the system. Requirements should also be prioritized based on relative importance and by when they are needed.
In addition to functional requirements, requirements analysis identifies non-functional requirements such as operational and technical requirements. Non-functional requirements describe characteristics or specific parameters of the system and include audit, availability, interface, capacity, performance, usage, security, back-up, physical, and site requirements.
The Planning Team should describe the system as the functions to be performed and not specific hardware, programs, files and data streams. The requirements must be unambiguous (measurable and testable), traceable, complete, consistent, and approved.
The Planning Team may perform these activities concurrently and iteratively to refine the set of requirements. The requirements’ level of detail should be sufficient to develop information for deliverables as well as remaining procurement documents. All requirements must be consistent with the State of Maryland Information Technology Security Policy and Standards on the DoIT website. As requirements are identified, the Planning Team should determine in which release each requirement will be implemented.
The Concept of Operations document describes the characteristics of the proposed system from the users’ perspectives. Additional information may be found in the Institute of Electrical and Electronics Engineering (IEEE) Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document.
At minimum, the ConOps should contain:
The ConOps document is used to communicate overall quantitative and qualitative system characteristics to stakeholders, the Planning Team, the Development Team, and the Systems Team.
The Planning Team constructs the RTM from the elicited requirements.
The RTM is a tool that links requirements to their origins and provides a method for tracking the requirements and their implementation through the development process.
At minimum, the RTM should contain for each requirement:
Attributes associated with each requirement should be recorded in the RTM. As the project progresses, the Planning Team updates the RTM to reflect new requirements, modified requirements, and any change to a requirement’s status. During the Design Phase, requirements are mapped to design documents to ensure all requirements are planned for in development. When the system is ready for testing, the RTM lists each requirement, the system component addressed by that requirement, and the test to verify correct functionality and implementation.
The Planning Team develops process models of the system’s functions and operations: models of the current system (As-Is processes) and models of the target system (To-Be processes). In network projects, this model will take the form of a detailed network diagram of the As-Is and To-Be system. To derive further requirements for the system, the Planning Team decomposes the process model iteratively into increasingly smaller functions and sub-functions to define all processes. The Planning Team should ensure the project stakeholders approve the process models.
The Planning Team identifies and defines network interface requirements for the system. Network interfaces are the points of interconnection between a computer and a network. The Planning Team determines how network interfaces will be implemented through multiple releases and updates the RTM with new or modified requirements.
The Planning Team develops the SRD, which contains the complete system requirements and describes the functions that the system must perform.
This document compiles all requirements including functional and non-functional requirements, process and data models, and interface definitions. The SRD describes the logical grouping of related processes and functions within the system and the business requirements these requirements satisfy. The document must capture the full set of requirements independent of any development approach, methodology, or organizational constraints. The final SRD helps the Project Manager obtain consensus among the Planning Team members and project stakeholders that the proposed specifications will result in a solution that satisfies project stakeholders’ needs.
The key elements of an SRD include the following items.
The Project Manager locates and assigns qualified, available agency personnel to be members of the Development Team. Ensure the Development Team understands the PSS.
The Project Manager with extensive input from the Agency CIO and Business Owner develops the TMP, which documents the testing of all aspects of the system. Defining the test plans this early in the life cycle allows teams, project stakeholders, and agency management to obtain a more accurate understanding of the effort and schedule required to ensure system quality.
The TMP documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.
The TMP must identify the scope, content, methodology, sequence, management of, and responsibilities for all test activities, including:
Agencies may use the SDLC TMP template to help ensure that all appropriate testing activities are defined and documented.
The Project Manager should specify in the TMP how test activities will be managed, including organization, relationships, and responsibilities. The TMP should also document how test results will be verified and how the system will be validated.
The Project Manager updates the RTM to include a TMP reference that indicates the testing of each requirement. Elaboration of testing plans occurs in the Design and Development Phases.
The Project Manager and the Planning Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completing all Requirements Analysis Phase tasks. This review addresses:
The Project Manager compares actual project performance to the PMP and the projected cost of the project to determine any variances from the cost baseline during the phase-end review. The Project Manager also performs a comprehensive risk assessment of the project to update the Risk Register. The Project Manager updates the Maryland EA Repository with any new or updated components before beginning the next phase, Design.
The Project Manager must obtain deliverable approval signatures before proceeding to the Design Phase.
Update the project documentation repository upon completion of the phase-closure activities.
The approval of the System Requirements Document, Requirements Traceability Matrix, and the Test Master Plan as well as the completion of the Requirements Analysis project status review and approval to proceed to the next phase signify the end of the Requirements Analysis Phase.
100 Community Place, Crownsville, MD 21032
300-301 West Preston Street, Baltimore MD 21201
410-697-9700 - Dial 7-1-1 to place a call through Maryland Relay