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 / Goals2.0: Deliverables and Approvals3.0: Roles4.0: Tasks and Activities5.0: Conclusions
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. During the Requirements Analysis Phase, the agency will conduct any procurement needed for the project.
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.
Functional Requirements Document (FRD) – formal statement of a system’s functional requirements, including, but not limited to: functional process requirements, data requirements, system interface requirements, and non-functional or operational 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.
Procurement Documents – documents such as a RFP or a TORFP that elicit competitive and comprehensive offers from potential contractors for a product or service. The document should specify the scope of the desired procurement, define the evaluation process, and delineate the deliverables and requirements associated with the project.
COTS Fit-Gap Analysis – identifies in detail the extent to which the COTS solution meets each of the validated requirements and how all gaps will be addressed in the new system.
Test Master Plan (TMP) – documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.
Business Process Change Management Plan – documents the specific plans to implement agreed-upon changes to the end users’ business processes.
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:
If the Planning Team is considering a COTS solution, including either on-premise software or Software-as-a-Service (SaaS), ensure that risk identification and analysis considers the unique risks associated with these types of efforts. See the Build Versus Buy related link for additional guidance.
Risk management 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.
Business processes, information, and interactions
Non-functional specifications that address system operations and/or technical characteristics (such as accessibility, encryption, security, hosting, environment, disaster recovery, level of service, performance, 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 business functions and requirements that the proposed system must deliver and support. The business requirements are generally known as functional requirements and describe what the system has to do. Interacting closely with project stakeholders and end users to identify the functional 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 implementation 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, capacity, performance, and security requirements. Other non-functional requirements include compliance with regulations and standards such as data retention and the Maryland IT Non-Visual Access Regulatory Standards.
The Planning Team should describe the system as the functions to be performed and not specific hardware, programs, files and data streams. 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 procurement documents. All requirements must be consistent with the State of Maryland Information Technology Security Policy and Standards on the DoIT website.
Prior to the RFP, the requirements should be as unambiguous (measurable and testable), traceable, complete, and consistent as possible and must be approved by stakeholders. For COTS implementation RFPs, agencies must balance the need to comprehensively and clearly define requirements and expectations while simultaneously ensuring that they do not limit procurement competition and unnecessarily disqualify solutions that may meet the business need. As such, agencies must define requirements to a sufficient level of detail for prospective vendors to understand current business processes, mandatory requirements, and optional requirements.
In order to optimize the level of detailed requirements included in the RFP, agencies are strongly encouraged to first investigate available COTS options and functionality. Planning teams should use the information gathered from industry research and product demonstrations to further refine requirements to be as unambiguous and comprehensive as possible.
Another way agencies may learn about available options is to conduct research regarding other states that have implemented similar systems and then leverage the lessons learned from the research in the requirements definition process.
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). 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 business processes. Both As-Is and To-Be business process definition is required for all projects, except projects that introduce entirely new business functions. For entirely new business functions, To-Be business process should be defined. This step is necessary to ensure that agencies do not misapply technology to outdated, inefficient, and dysfunctional business processes. The Planning Team should ensure the project stakeholders and end users approve the process models.
For COTS implementation projects, including SaaS acquisitions, the To-Be process model for the target system cannot be finalized until after the completion of the COTS fit-gap analysis. Although agencies should include a preliminary target system To-Be process model in the RFP, the functionality of the selected COTS package must influence the finalized future processes.
The Planning Team develops a draft conceptual data model to document the business processes and underlying data. The data model depicts the data structure, its characteristics, and the relationships between the data using graphical notation. A data dictionary supports the data model as the repository of information about the data, including details on entities, their attributes, and relationships between the entities.
The Planning Team can elaborate further on the requirements after drafts of the data model and data dictionary are complete. As the data model is refined, the Planning Team must include data exchanged with external systems. The Planning Team should review and cross-reference the process model and the data model to ensure the requirements exist and are consistently defined.
Although COTS implementation RFPs should include the preliminary data model for the future system, this model must be finalized after the COTS selection to ensure that it is compatible with the solution.
The Planning Team identifies and defines internal and external interface requirements for the system. The internal interface requirements involve data interactions within the system and likely focus on performance or reliability. The external interface requirements may influence non-functional requirements such as security, performance, and accessibility. The Planning Team updates the RTM with new or modified requirements.
The Planning Team develops the FRD, which contains the complete system requirements and describes the functions that the system must perform. The draft FRD must be included in the RFP and finalized after the requirements validation and COTS fit-gap analysis.
This document compiles all requirements including functional and non-functional requirements, process and data models, and interface definitions. The FRD 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 FRD 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 FRD include the following items. Additional guidance is provided in the SDLC template.
The Procurement Officer with the assistance of the Project Manager develops all procurement documents. Agencies are strongly encouraged to complete and issue procurement documents for system implementation after requirements are defined and documented in detail; this timing allows potential contractors to evaluate, scope, and price project work properly. Depending on the scope of service solicited, procurement documents may be developed in other SDLC phases.
Procurement documents such as RFPs and TORFPs are distributed to elicit competitive and comprehensive offers from potential contractors for a product or service. RFPs and TORFPs specify the scope of the desired procurement, define the evaluation process, delineate the deliverables and requirements associated with the project, and establish a contractual agreement for the delivery of the good or service. Careful planning and development of procurement documents help avoid or mitigate project risks or transfer project risks to the contractor.
The Procurement Officer determines the type of contract and solicitation based on work from the Planning Phase. The type of contract determines the level of risk shared between the State and a contractor. Fixed-price contracts generally reduce the risk to the State by ensuring that any cost increase due to adverse performance is the responsibility of the contractor, who is legally obligated to complete the project. FP agreements should tie contractor payments to the completion and agency acceptance of project deliverables. A FP contract is best used when the service or product to be developed is fully defined before the start of work. Time-and-materials contract types are more appropriate for level of effort engagements or projects with significant unknowns. The PMBOK, fourth edition, section 12.1.2, further discusses FP, T&M, and other contract types.
The Procurement Officer also determines the type of solicitation:
Agencies are encouraged but not required to use statewide contract vehicles such as Consulting and Technical Services+ (CATS+).
The Procurement Officer with the Project Manager writes the SOW, which defines the project boundaries. One of the most critical parts of a procurement document, the SOW describes in detail the project deliverables, deliverable requirements, and the work required to create those deliverables. Agencies should leverage the information in the PSS to ensure consistency. The level of quality, specificity, and completeness of the SOW significantly impacts the quality and overall success of the project throughout its life cycle.
A well-written SOW:
For CATS TORFPs refer to the CATS+ TORFP Master Template on DoIT’s web site for instructions regarding requirements for SOW development.
The Business Owner and Project Manager with input from the Agency CIO develop the proposal evaluation criteria to rate proposals. The proposal evaluation criteria should be specific, objective, and repeatable and must be included in the RFP, so offerors know how the State will evaluate their proposals and under which criteria the winner will be awarded a contract or task order. Considerations for proposal evaluation criteria include:
The PMBOK, fourth edition, provides the following example evaluation criteria:
Additional guidance can be found on DoIT’s web site in these documents:
The PMBOK, fourth edition, section 188.8.131.52, provides further guidance regarding proposal evaluation and source selection criteria.
The Procurement Officer with the assistance of the Planning Team develops the RFP after the FRD is approved and baselined and the SOW is finalized.
The RFP is an invitation to contractors to submit a proposal to provide specific services, products, and deliverables.
The key elements of an RFP include at minimum:
RFPs and TORFPs should:
For COTS implementation projects, RFPs must include detailed current (or "as is") business requirements and require that responses include proposed future (or "To Be") business processes so that agencies may evaluate the level of organizational change required to implement the proposed solution.
RFPs should also require that proposals include a proposed data model that meets requirements, leverages the agency’s preliminary data model, and is compatible with solution capabilities.
In addition, RFPs must require that responses include a preliminary COTS fit-gap analysis so that agencies may evaluate the level of risk associated with customizing the proposed solution to meet both mandatory and optional requirements. This analysis must specify, for each requirement, whether a COTS configuration or customization will be required. COTS configuration options require no programmatic code and are completely tested by the contractor prior to COTS release, whereas customization requires programmatic code.
All RFPs and TORFPs must explicitly require complete compliance with the State of Maryland SDLC and other policies and guidelines. Specifically, each TORFP must include the following language:
The TO Contractor(s) shall be required to comply with all applicable laws, regulations, policies, standards and guidelines affecting information technology projects, which may be created or changed periodically. The TO Contractor(s) shall adhere to and remain abreast of current, new, and revised laws, regulations, policies, standards and guidelines affecting project execution. The following policies, guidelines and methodologies can be found at www.doit.maryland.gov. Select “Policies and Guidance”.
These may include, but are not limited to:
A. The nine project management knowledge areas in the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK). The TO Contractor(s) shall follow the project management methodologies that are consistent with the most recent edition of the PMBOK Guide. TO Contractor’s staff and subcontractors are to follow a consistent methodology for all TO activities.
B. The State’s SDLC methodology at: www.DoIT.maryland.gov - keyword: SDLC.
C. The State’s IT Security Policy and Standards at: www.DoIT.maryland.gov - keyword: Security Policy.
D. The State’s IT Project Oversight at: www.DoIT.maryland.gov - keyword: IT Project Oversight.
E. The State of Maryland Enterprise Architecture at www.DoIT.maryland.gov - keyword: MTAF (Maryland Technical Architecture Framework).
F. Nonvisual Access Clause for Information Technology Procurements at www.DoIT.maryland.gov – keyword: Nonvisual Access.
All RFPs and TORFPs must explicitly require contractors who propose alternative development methodologies to include an SDLC compliance approach, which describes in detail how they will comply with all SDLC requirements, in their proposals.
Additional guidance can be found on DoIT’s web site in:
The Procurement Officer and Project Manager solicit input from the Agency CIO and Business Sponsor and designate agency personnel and end users for the Agency Evaluation Committee (AEC). AEC staff should include:
The AEC follows a formal evaluation process to review and select the contractor using the evaluation method and evaluation criteria defined earlier. Under the guidance of the Procurement Officer, the AEC evaluates each proposal according to all applicable State laws and regulations. The AEC determines technical ratings based on the evaluation criteria outlined in the RFP/TORFP. After the technical rankings, the Procurement Officer forwards financial proposals for each qualified proposal to the AEC. The AEC establishes the financial rankings and determines the combined technical and financial ranking of each qualified proposal. Based on these rankings, the AEC recommends an awardee based on best value.
Specific procedures for CATS Task Order contractor selection and award are included on the CATS+ TORFP Preparation, Solicitation, and Award Process web page and the CATS+ State ADPICS Processing Procedures document. Refer to these documents and others on DoIT's website.
Immediately after the initiation of the COTS contractor, team members must work together to validate requirements and complete the COTS fit-gap analysis to achieve the following:
Effective requirements validation helps to ensure that requirements are defined to the level of detail necessary to properly build, test, implement and track throughout the life cycle. In essence, the validation process is a proactive risk mitigation strategy to prevent underestimation and quality deficiencies resulting from ambiguous requirements.
Conducting the final COTS Fit-Gap Analysis at this stage allows the team to:
Requirements validation and final COTS fit-gap analysis are frequently performed in parallel to ensure that the requirements validation is sufficiently influenced by an understanding of the COTS functionality.
In order to leverage existing COTS functionality, COTS implementation projects require much more stakeholder negotiation and compromise. As planning teams complete the COTS fit-gap analysis, they may decide to modify business processes to use base COTS functionality, minimize customization risk, and minimize customization costs and associated schedule extensions. After the completion of the final COTS fit-gap analysis, agencies must update and finalize the “To Be” business process model to be consistent with decisions made in the fit-gap analysis.
The updates for "To Be" business processes are typically driven by the gaps identified in the fit-gap analysis. As the Planning Team, including stakeholders and vendors, discuss the options to address identified gaps between COTS functionality, requirements, and stakeholder expectations, they should consider the possibility of modifying business processes to utilize existing COTS functionality. The final decision for each gap should be based upon a cost-benefit analysis that considers the level of organizational change and risk associated with modifying the business process. For SaaS efforts, agencies should understand configuration limitations and the increased need for business process change and plan early to address the risks associated with the change. To ensure that stakeholders have the information they need to finalize and adopt “To Be” business processes, stakeholders must participate in hands-on experiments with the solution to fully conceptualize how the business need will be met.
Agencies must explicitly identify and document the plan to implement agreed-upon changes to the end users’ business processes. This plan should account for all types of end users and the changes necessary for individuals and organizations.
The Project Manager must identify all necessary activities, resources, tools, and associated estimates to achieve required changes to the business processes. It is critical that the Project Manager obtain input from representative end users to ensure that the Business Process Change Management Plan is comprehensive, realistic, and accepted by stakeholders. Upon completion of the plan, the project schedule and other project management plans must be updated to account for all necessary implementation activities and time required for effective adoption.
Specifically, the Business Process Change Management Plan must address the following:
The Business Process Change Management Plan should address how the team will begin executing business process changes in the Development Phase and iteratively thereafter to mitigate the risks associated with significant business process change.
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 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.
The approval of the Functional 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