Phase 4: Requirements Analysis - Hardware Single Release Project

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.


1.0: Objectives / Goals
2.0: Deliverables and Approvals
3.0: Roles
4.0: Tasks and Activities
5.0: Conclusions

1.0 Objectives / Goals


Successful completion of the Requirements Analysis Phase should comprise:

  • Definition of approved requirements
  • Creation of the System Requirements Document and Requirements Traceability Matrix
  • Development of planned test activities
  • Approval to progress to the Design Phase


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

2.0 Deliverables and Approvals

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 document 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:

  • Ensure common understanding among Planning Team members and stakeholders,
  • Serve as a reminder of specified plans as projects become increasingly complex,
  • Provide agency senior management and other State officials insight into project risks and ongoing performance,
  • Encourage the execution of repeatable and consistent processes,
  • Facilitate the implementation of project management and agency IT best practices, and
  • Result in a comprehensive record of project performance useful for many purposes (e.g. staff knowledge transfer, budgetary and other assessment activities, lessons learned).


During the development of documentation, the Planning Team should:

  • Write comprehensive, easy to understand documents with no redundant information.
  • Develop an organized document repository for critical project information, so Planning Team members can easily access, store, and reference project documents and other deliverables from all life cycle phases.
  • Implement routine deliverable reviews to correct inaccuracy, incompleteness, and ambiguities.
  • Recognize that sample templates for deliverables are available; agencies might accept deliverables in different formats as long as all required information is present. The content of these deliverables might expand or shrink depending on the size, scope, and complexity of the project.
  • Recycle or reference information from earlier documents where possible and beneficial.


The following is a listing of deliverables required of all projects for this phase of work.



Developed By

Approved By

Concept of Operations – describes the characteristics of the proposed system from the users’ perspectives.

·         Describe operational scenarios of system functions

·         Identify modes of operation

Planning Team

Agency CIO

Project Sponsor

Business Owner

Project Manager

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.

·         Document detailed, measurable, consistent, and comprehensive system requirements

·         Eliminate ambiguity of expectations regarding system

Planning Team

Agency CIO

Project Sponsor

Business Owner

Project Manager

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.

·         Establish a baseline for requirements change control, design, and testing

Planning Team

Agency CIO

Business Owner

Project Manager

Test Master Plan (TMP) documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. 

·         Document and communicate tasks and activities needed to ensure that the system is adequately tested and can be successfully implemented

Project Manager

Agency CIO

Business Owner

Agency CIO

Business Owner

Project Manager


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.

Back To Top

3.0 Roles

The following personnel participate in the work activities in this phase:

  • Agency CIO
  • Agency CFO
  • Project Sponsor
  • Executive Sponsor
  • Business Owner
  • Project Manager
  • Planning Team
  • Project Stakeholders
  • Secretary of DoIT



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 who receive information about the task.


The Roles and Responsibilities page has detailed descriptions of these roles and their associated responsibilities.


Back To Top

4.0 Tasks and Activities

Requirements Analysis Phase Process Model 1 of 2 

Requirements Analysis Phase Process Model 2 of 2  


4.1 Review Phase Prerequisites. 

The Project Manager ensures the following prerequisites for this phase are complete:

  • Project Management Plan and schedule showing target completion dates for requirements analysis activities
  • Schedule Management Plan addressing the current state of the project’s schedule, the factors that might influence it, and management of those factors (See additional information in the PMBOK, fourth edition, section 6.)
  • Approval and baseline of the PSS, RMP, and PMP

4.2 Monitor Project Performance.

The Project Manager monitors project performance by gathering status information about:

  • All changes to baseline data
  • Change management information
  • Activity progress with status details
  • List of complete and incomplete deliverables
  • Activities initiated and finished
  • Quality management reviews and results
  • Estimated time to completion
  • Resource utilization data
  • Changes to project scope
  • Costs authorized and incurred


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

4.3 Update PMP and Communication Management Plan.

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.

4.4 Perform Risk Management Activities. 

The Project Manager conducts risk management activities, including:

  • Identification – determination of risks, emerging risks, and risk characteristics
  • Risk Analysis – quantitative and/or qualitative analysis of each identified risk.  Usually, qualitative risk management techniques are the most applicable for State projects.  Risk analysis methods, as well as the conditions under which each method might be used, are described in detail in PMBOK, Chapter 11.
  • Response Planning – planning of methods for developing mitigation, transfer, or avoidance strategies to reduce risk
  • Monitoring and Control – definition of procedures to track risks, monitor residual risk, identify new risks, execute response plans, and evaluate risk management effectiveness


Monitoring and control activities should address:

  • Status of identified risks and risk responses
  • Planned results versus actual results of risk responses
  • Effectiveness of previously planned risk responses
  • New risks
  • Closed risks
  • Risk process improvements
  • Comparison of the amount of contingency reserves remaining to the amount of risk remaining to determine if remaining reserve is adequate


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.

4.5 Initiate Requirements Identification.

The Planning Team with Project Manager supervision identifies system requirements.



Functional Requirements

Processes, information, and interactions

Non-functional Requirements

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:

  • Interviews
  • Facilitated workshops
  • Group creativity techniques
  • Group decision making techniques
  • Questionnaires and surveys


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 web site.

4.6 Develop the Concept of Operations.

4.6.1 Document Description

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.

4.6.2 Typical Content 

At minimum, the ConOps should contain:

  • Scope – typically identifies scope, including both the system scope and the deliverables in scope (may reference PSS)
  • Current system and situation – addresses background, operational policies, constraints, description of the current system and situation, current system modes of operation, users and personnel involved, and support environment
  • Justification for and nature of changes – includes justification of changes, description of desired changes, change priorities, changes considered but not included
  • Concepts for the proposed system – includes description of the proposed system, modes of operation, users and other personnel to be involved, and the to-be support environment
  • Operational scenarios – includes step-by-step descriptions of how the proposed system should operate and interact with interfaces under a given set of circumstances
  • Summary of impacts – identifies operational and organizational impacts as well as impacts during installation and implementation
  • Analysis of the proposed system – includes summary of improvements, disadvantages and limitations, alternatives and trade-offs considered (may reference the PSS)

4.6.3 Guidance for Document Development 

The ConOps document is used to communicate overall quantitative and qualitative system characteristics to all stakeholders, the Planning Team, the Development Team, and the Systems Team.

4.6.4 Dos and Don’ts 

  • Do engage affected stakeholders in ConOps development.
  • Do describe operational scenarios for all operational modes and all user classes.  Each scenario should include events, actions, stimuli, information, and interactions as appropriate to provide a comprehensive understanding of the operational aspects of the proposed system.
  • Do develop several variations of each scenario, including, at minimum, one for normal operation, one for stress loading handling, one for exception handling, and one for degraded mode operations.
  • Don't duplicate content previously documented.  Reference other SDLC documents as applicable.

4.7 Construct the Requirements Traceability Matrix.

The Planning Team constructs the RTM from the elicited requirements.

4.7.1 Document Description

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. 

4.7.2 Typical Content

At minimum, the RTM should contain for each requirement:

  • Requirement Description
  • Requirement Reference in the SRD
  • Source
  • Current Status
  • System Component/Module
  • Verification Method
  • Requirement Reference in Test Plan
  • Date Completed

4.7.3 Guidance for Document Development

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.

4.7.4 Dos and Don'ts

  • Do consider an automated tool if the system has many requirements; commercial and open source software tools support RTM work.  A spreadsheet may be sufficient depending on the size of the system.

4.8 Draft Models.

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 models iteratively into increasingly smaller functions and sub-functions to define all processes.  The Planning Team should ensure the project stakeholders approve the process models.

4.9 Document Network Interface Requirements.

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 updates the RTM with new or modified requirements.

4.10 Assemble the System Requirements Document.

The Planning Team develops the SRD, which contains the complete system requirements and describes the functions that the system must perform.

4.10.1 Document Description

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.

4.10.2 Typical Content

The key elements of an SRD include the following items.

  • Project description
  • Points of contact
  • Data requirements
  • Functional process requirements
  • Security requirements
  • Audit trail requirements
  • Data currency requirements
  • Reliability requirements
  • Recoverability requirements
  • System availability requirements
  • Fault tolerance requirements
  • Performance requirements
  • Capacity requirements
  • Glossary

4.10.3 Dos and Don'ts

  • Do include requirements that are complete, consistent, measurable, and indivisible.
  • Do involve all project stakeholders in the identification and validation of requirements.
  • Don’t confuse requirements with design specifications. Erroneously including design specifications in the SRD may unnecessarily limit competitive responses to the implementation solicitation.

4.11 Staff Development Team.

The Project Manager locates and assigns qualified, available agency personnel to be members of the Development Team. Ensure the Development Team understands the PSS.

4.12 Develop Test Master Plan.

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.

4.12.1 Document Description

The TMP documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. 

4.12.2 Typical Content

The TMP must identify the scope, content, methodology, sequence, management of, and responsibilities for all test activities, including:

  • Unit/module testing
  • Independent security testing
  • System testing
  • Independent acceptance testing (optional)


Agencies may use the SDLC TMP template to help ensure that all appropriate testing activities are defined and documented. 

4.12.3 Guidance for Document Development

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.

4.12.4 Dos and Don'ts

  • Do consider all types of testing activities required to meet project requirements.
  • Do involve end users in determining the nature and extent of tests to be conducted.
  • Do address how the TMP will be updated to include progressively more detail as the system is developed.

4.13 Perform Phase-Closure Activities.

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:

  • Status of Requirements Analysis Phase activities
  • Planning status for all subsequent life cycle phases, with significant detail about the Design Phase (such as the status of pending contracts)
  • Status on resource availability
  • Project scope control as described in the PSS
  • Changes to the project schedule and estimated completion date
  • "Go-No Go" decision made to proceed to next phase, based on Requirements Analysis Phase information
  • Verification that all changes are conducted in accordance with the approved Change Management Plan


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


Back To Top

5.0 Conclusions

The approval of the System Requirements Document, RTM, and the TMP 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.