Download Requirements Analysis Phase: Functional and Non-Functional Requirements for IT Projects and more Study notes Business in PDF only on Docsity!
PHASE 4: REQUIREMENTS ANALYSIS PHASE
The Requirements Analysis Phase begins when the previous phase objectives have been achieved. Documentation related to user requirements from the Concept Development Phase and the Planning Phase shall be used as the basis for further user needs analysis and the development of detailed requirements. Multiple-release projects require only one iteration of the Requirements Analysis Phase, which should involve requirements definition for all planned releases.
1.0 OBJECTIVE/G OALS
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
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.
Deliverable ExecutiveSponsor ProjectSponsor Agency CIO Agency CFO BusinessOwner ProjectManager PlanningTeam ProjectStakeholders ProcurementOfficer DoIT
Functional Requirements Document
I A A I R I C C
Requirements Traceability Matrix
I A A I R I C C
Procurement Documents I A A A I R I I A C
COTS Fit-Gap Analysis I A A I R I C C
Test Master Plan I A A I R I C C
Business Process Change Management Plan
I A I C R I C C
Possible RACI Matrix
The Roles and Responsibilities page has detailed descriptions of these roles and their associated responsibilities.
Phase 4 Requirements Analysis Phase
ExecutiveSponsor
Deliverables
DoIT
Planning Team
ProjectManager
ProjectSponsor
Agency CIO
Procurement
Officer
Agency CFO
Draft Data Model
ProcurementDevelop Documents
Draft Process Models
Document System Interfaces
Functional Requirements Document
Assemble the Functional Requirements Document
RequirementsConstruct the Traceability Matrix
Requirements Traceability Matrix
Phase 4 Requirements Analysis Phase
ExecutiveSponsor
Deliverables
DoIT
Planning Team
ProjectManager
ProjectSponsor
Agency CIO
Procurement
Officer
Agency CFO
Develop the RFP
Establish Evaluation Committee
Write the Scope of Work
Select Contractor
Establish Proposal Evaluation Criteria
Procurement Documents
Determine Contract and Solicitation Type
- 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
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. 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
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
- Planned Release
- 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 determines how system interfaces will be implemented through multiple releases and 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
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. Fixed-price agreements should tie contractor payments to the completion and agency acceptance of project deliverables. An 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 Project Scope Statement 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 (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 website 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
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 “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:
- CATS TORFP Preparation, Solicitation, and Award Process web page
- CATS I State ADPICS Processing Procedures
- Writing a Quality Task Order Request for Proposal
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.
- Do require contractors to include a proposed approach for multiple-release implementation, as well as associated risks, in their proposals.
- 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 I 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.
