Phase 4: Requirements Analysis - COTS 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

Objectives

Successful completion of the Requirements Analysis Phase should comprise:

Definition of approved requirements
Creation of the Functional Requirements Document and Requirements Traceability Matrix
Development of planned test activities
Performance of needed procurement activities
Completion of a COTS fit-gap analysis and requirements validation
Development of a Business Process Change Management Plan
Approval to progress to the Design Phase

Goals

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.

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

Deliverable	Goals	Developed By	Approved By
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.	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
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.	Elicit quality proposals from qualified contractors Provide contractors with sufficient information to formulate an appropriate response including an accurate schedule and cost estimate	Procurement Officer Project Manager	Agency CIO Agency CFO Project Sponsor Business Owner Project Manager
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.	Document the extent to which the COTS solution meets each validated requirement Identify which requirements the COTS solution does not meet and specifically how the gaps will be addressed	Development 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
Business Process Change Management Plan – documents the specific plans to implement agreed-upon changes to the end users’ business processes.	Identify specific plans to execute business process changes Address how business process changes will be implemented early and iteratively to mitigate business process change risks	Project Manager	Project Sponsor 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.

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
Procurement Officer
Secretary of DoIT

RACI Key

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.

4.0 Tasks and Activities

Requirements Analysis Phase Process Model 1 of 4

Requirements Analysis Phase Process Model 2 of 4

Requirements Analysis Phase Process Model 3 of 4

Requirements Analysis Phase Process Model 4 of 4

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 assurance testing and test 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 10.5.3.1.

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

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.

4.5 Initiate Requirements Identification.

The Planning Team with Project Manager supervision identifies system requirements.

Category	Description
Functional Requirements	Business processes, information, and interactions
Non-functional Requirements	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:

Interviews
Focus groups (consisting of end-users)
Facilitated workshops (e.g. Joint Application Development/Design sessions)
Group creativity techniques
Group decision making techniques
Questionnaires and surveys
Observations
Prototypes
Storyboarding

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.

4.6 Construct the Requirements Traceability Matrix.

The Planning Team constructs the RTM from the elicited requirements.

4.6.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.6.2 Typical Content

At minimum, the RTM should contain for each requirement:

Requirement Description
Requirement Reference in the FRD
Source
Current Status
System Component/Module
Fit-Gap
Configuration or Customization
Verification Method
Requirement Reference in Test Plan
Date Completed

4.6.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.6.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.
Do utilize the RTM to document configuration and customization to address requirement gaps.

4.7 Draft Process 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). 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.

4.8 Draft Data Model.

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.

4.9 Document System Interfaces.

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.

4.10 Assemble the Functional Requirements Document.

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.

4.10.1 Document Description

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.

4.10.2 Typical Content

The key elements of an FRD include the following items. Additional guidance is provided in the SDLC template.

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
Data retention 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 FRD may unnecessarily limit competitive responses to the implementation solicitation.

4.11 Develop Procurement Documents.

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.

4.12 Determine Contract and Solicitation Type.

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:

Invitation for Bid (IFB), which requires an award for lowest price by the Code of Maryland Regulations (COMAR)
RFP, which allows additional flexibility for curing and a balanced weighting of evaluation criteria between price and technical solution

Agencies are encouraged but not required to use statewide contract vehicles such as Consulting and Technical Services+ (CATS+).

4.13 Write the Scope of Work (SOW).

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:

Enables offerors to clearly understand requirements and their relative importance
Improves chances of receiving higher quality proposals
Minimizes future needs for change orders, which lead to increased project cost and delayed project completion
Allows both the State and the contractor to assess performance
Reduces risk of future claims and disputes

For CATS TORFPs refer to the CATS+ TORFP Master Template on DoIT’s web site for instructions regarding requirements for SOW development.

4.14 Establish Proposal Evaluation Criteria.

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:

Proposals should be ranked rather than scored. Technical and financial proposals are evaluated and ranked separately. Technical proposal rankings are completed first and then financial rankings.
Evaluation criteria must be clearly defined.
All criteria must be aligned to the SOW.
All criteria must be objective and not generic or ambiguous.
References must be requested and must be verified as part of the due diligence in selecting the best value proposal.
Evaluating and comparing financial proposals from different technical approaches can be difficult. In these situations, use a pricing model based on agency-provided assumptions.
When using experience in evaluation criteria, identify clearly contractor experience or contractor personnel experience as the criteria because frequently people assigned to the project are instrumental in its success, not necessarily the contractor for whom they work.

The PMBOK, fourth edition, provides the following example evaluation criteria:

Understanding of need
Overall or life cycle cost
Technical capability
Risk (including risk associated with increased business process change)
Management approach
Technical approach
Warranty
Financial capacity
Production capacity and interest
Business size and type
Past performance
References
Intellectual property rights
Proprietary rights

Additional guidance can be found on DoIT’s web site in these documents:

CATS TORFP Preparation, Solicitation, and Award Process web page
CATS I State Advance Purchasing and Inventory Control System (ADPICS) Processing Procedures
Writing a Quality Task Order Request for Proposal
TORFP Checklist
The PMBOK, fourth edition, section 12.1.3.5, provides further guidance regarding proposal evaluation and source selection criteria.

4.15 Develop the RFP.

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.

4.15.1 Document Description

The RFP is an invitation to contractors to submit a proposal to provide specific services, products, and deliverables.

4.15.2 Typical Content

The key elements of an RFP include at minimum:

Administrative information
SOW
Technical requirements
Contractor expertise required
Invoicing
Reporting requirements
Proposal format and submission requirements
Procedure for awarding contract or task order agreement
Evaluation criteria
Sample contract forms and agreements

4.15.3 Guidance for Document Development

RFPs and TORFPs should:

Facilitate accurate, appropriate, and complete responses from prospective contractors
Elicit multiple, competitive responses and allow for consideration of contractor suggestions for better ways to satisfy requirements
Facilitate easy and consistent evaluation of responses
Minimize cost, schedule, and quality risks to the State
Comply with mandatory COMAR 21 requirements
Document any known project risks so offerors can understand and respond with solutions that may mitigate these risks

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:

4.15.4 Dos and Don’ts

Do write concise and clear RFPs.
Do include deliverable acceptance criteria.
Do identify when deliverables are required.
Do identify contractor performance metrics.
Do include deliverables specifically relevant to the type of project.
Don’t complete the RFP until the draft FRD is completed and approved.
Don’t confuse the RFP with a planning document. Planning must be completed well before the RFP and documented in the PMP.

4.16 Establish Evaluation Committee.

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:

Business and technical subject matter experts (SMEs) who are knowledgeable about their respective domains and can evaluate responses
Enough members to cover all select seller activities
Members who have sufficient time to participate in the evaluation

4.17 Select Contractor(s).

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.

4.18 Validate Requirements and Finalize COTS Fit-Gap Analysis.

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:

Ensure that requirements are correct, unambiguous, complete, consistent, ranked for importance, testable, and traceable.
Ensure a common understanding of requirements among stakeholders, the agency team, and the vendor team.
Plan how each requirement will be verified. The output of the requirements validation process is documented in an updated RTM and FRD.
Determine all gaps between the capabilities provided by the COTS components and the capability required for the system, as well as the customization required to address the gaps The resulting COTS Fit-Gap Analysis document must identify requirements that:

Exist in the COTS with no change required
Exist in the COTS but require configuration
Need to be added to the COTS product
Need to be removed from the COTS product
Need change in business process
Identify and document in the COTS Fit-Gap Analysis how each validated requirement will be achieved by the COTS solution (i.e., through configuration, customization, or business process change).

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:

Validate and correct assumptions regarding the fit between stakeholder expectations and COTS functionality
Improve stakeholder understanding of COTS features and functionality
Leverage existing COTS functionality with modifications to business processes
Obtain a more accurate understanding of the activities and effort necessary to meet stakeholder expectations
Obtain information necessary to finalize "To Be" business processes

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.

4.19 Finalize "To Be" Business Processes.

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.

4.20 Develop Business Process Change Management Plan.

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:

Process, tools, and stakeholders necessary to manage business process changes
Assigned members of the Change Office
Work Breakdown Structure, resource assignments, and schedule for iteratively implementing business process changes
New processes and procedures to be developed and implemented
Communication, training, and adoption methods
Expected results of business process changes and method of evaluation
Process for modifying the Business Process Change Management Plan

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.

4.21 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.22 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.22.1 Document Description

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

4.22.2 Typical Content

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

Unit/module testing
Subsystem integration testing
Independent security testing
System testing
Independent acceptance testing
Regression testing
Beta testing

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

4.22.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.22.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.23 Perform Phase-Closure Activities.

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.

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 must obtain deliverable approval signatures before proceeding to the Design Phase.

Update the project documentation repository upon completion of the phase-closure activities.

5.0 Conclusions

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.

SDLC Phases - COTS Single

Related Links