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.
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.
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 following is a listing of deliverables required of all projects for this phase of work.
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.
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 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
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.
|
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 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, 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 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 procurement documents. All requirements must be consistent with the State of Maryland Information Technology Security Policy and Standards on the DoIT website.
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 table 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
- 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.
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.
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.
4.9 Document System Interfaces.
The Planning Team identifies and defines internal, external, and user 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.
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 website 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
- 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 website in these documents:
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
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 “Contractor” and “IT Policies, Standards and Guidelines”.
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 website 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 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. Refer to these documents and others on DoIT’s website.
4.18 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.19 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.19.1 Document Description
The TMP documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.
4.19.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.19.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.19.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.20 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 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.
