Download Requirements Analysis Phase: Objectives, Deliverables, and Processes and more Schemes and Mind Maps Business Accounting 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.
1.0 OBJECTIVE/GOALS
Objectives Successful completion of the Requirements Analysis Phase should comprise:
- Definition of approved requirements
- Creation of the System Requirements Document and Requirements Traceability Matrix
- Development of planned test activities
- Approval to progress to the Design Phase
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.
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
Concept of Operations – describes the characteristics of the proposed system from the users’ perspectives.
- Describe operational scenarios of system functions
- Identify modes of operation
Planning Team Agency CIO Project Sponsor Business Owner Project Manager
System Requirements Document (SRD) – a formal statement of a system’s requirements, including, but not limited to: functional requirements, data requirements, system interface requirements, non-functional or operational requirements, and physical requirements.
- Document detailed, measurable, consistent, and comprehensive system requirements
- Eliminate ambiguity of expectations regarding system
Planning Team Agency CIO Project Sponsor Business Owner Project Manager
Requirements Traceability Matrix (RTM) – a table that links requirements to their origins and traces them throughout the project life cycle. Developing the RTM helps to ensure that each requirement adds business value and that approved requirements are delivered.
- Establish a baseline for requirements change control, design, and testing
Planning Team Agency CIO Business Owner Project Manager
Test Master Plan (TMP) – documents the scope, content, methodology, sequence, management of, and responsibilities for test activities.
- Document and communicate tasks and activities needed to ensure that the system is adequately tested and can be successfully implemented
Project Manager Agency CIO Business Owner
Agency CIO Business Owner Project Manager
Deliverable ExecutiveSponsor ProjectSponsor Agency CIO Agency CFO BusinessOwner ProjectManager PlanningTeam ProjectStakeholders DoIT
Concept of Operations I A A I R I C C
System Requirements Document I A A I R I C C
Requirements Traceability Matrix
I A A I R I C C
Test Master Plan I A A I R I C C
Possible RACI Matrix
The Roles and Responsibilities page has detailed descriptions of these roles and their associated responsibilities.
4.0 TASKS AND ACTIVITIES
Phase 4 Requirements Analysis Phase
ExecutiveSponsor
DoIT
Agency CFO
Agency CIO
Procurement
Officer
Planning Team
Deliverables
ProjectSponsor
ProjectManager
Review Phase^ 4. Pre-requisites Monitor Project^ 4. Performance
Update PMP and^ 4. START CommunicationPlans Perform Risk4. ManagementActivities
Initiate4. RequirementsIdentification Develop the4. Concept ofOperations
Concept of Operations
- 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. through 11.6.
4.5 Initiate Requirements Identification.
The Planning Team with Project Manager supervision identifies system requirements.
Category Description
Functional Requirements Processes, information, and interactions
Non-functional Requirements
Non-functional specifications that address system operations and/or technical characteristics (such as encryption, security, hosting, environment, disaster recovery, level of service, performance, physical, capacity, sites, compliance, supportability, business continuity) System Requirement Types
The Planning Team begins a detailed analysis of the current architecture and elicits, analyzes, specifies, prioritizes, verifies, and negotiates requirements that the proposed system must deliver and support. Functional requirements describe what the system has to do. Interacting closely with project stakeholders to identify the requirements, the Planning Team may use different tools and techniques such as:
- Interviews
- Facilitated workshops
- Group creativity techniques
- Group decision making techniques
- Questionnaires and surveys
4.6.3 Guidance for Document Development
The ConOps document is used to communicate overall quantitative and qualitative system characteristics to all stakeholders, the Planning Team, the Development Team, and the Systems Team.
4.6.4 Dos and Don’ts
- Do engage affected stakeholders in ConOps development.
- Do describe operational scenarios for all operational modes and all user classes. Each scenario should include events, actions, stimuli, information, and interactions as appropriate to provide a comprehensive understanding of the operational aspects of the proposed system.
- Do develop several variations of each scenario, including, at minimum, one for normal operation, one for stress loading handling, one for exception handling, and one for degraded mode operations.
- Don’t duplicate content previously documented. Reference other SDLC documents as applicable.
4.7 Construct the Requirements Traceability Matrix.
The Planning Team constructs the RTM from the elicited requirements.
4.7.1 Document Description
The RTM is a tool that links requirements to their origins and provides a method for tracking the requirements and their implementation through the development process.
4.7.2 Typical Content
At minimum, the RTM should contain for each requirement:
- Requirement Description
- Requirement Reference in the SRD
- Source
- Current Status
- System Component/Module
- Verification Method
- Requirement Reference in Test Plan
- Date Completed
4.7.3 Guidance for Document Development
Attributes associated with each requirement should be recorded in the RTM. As the project progresses, the Planning Team updates the RTM to reflect new requirements, modified requirements, and any change to a requirement’s status. During the Design Phase, requirements are mapped to design documents to ensure all requirements are planned for in development. When the system is ready for testing, the RTM lists each requirement, the system component addressed by that requirement, and the test to verify correct functionality and implementation.
4.7.4 Dos and Don’ts
- Do consider an automated tool if the system has many requirements; commercial and open source software tools support RTM work. A spreadsheet may be sufficient depending on the size of the system.
4.8 Draft Models.
The Planning Team develops process models of the system’s functions and operations: models of the current system (As-Is processes) and models of the target system (To-Be processes). In network projects, this model will take the form of a detailed network diagram of the As-Is and To-Be system. To derive further requirements for the system, the Planning Team decomposes the process models iteratively into increasingly smaller functions and sub-functions to define all processes. The Planning Team should ensure the project stakeholders approve the process models.
4.9 Document Network Interface Requirements.
The Planning Team identifies and defines network interface requirements for the system. Network interfaces are the points of interconnection between a computer and a network. The Planning Team updates the RTM with new or modified requirements.
4.10 Assemble the System Requirements Document.
The Planning Team develops the SRD, which contains the complete system requirements and describes the functions that the system must perform.
4.10.1 Document Description
This document compiles all requirements including functional and non-functional requirements, process and data models, and interface definitions. The SRD describes the logical grouping of related processes and functions within the system and the business requirements these requirements satisfy. The document must capture the full set of requirements independent of any development approach, methodology, or organizational constraints. The final SRD helps the Project Manager obtain consensus among the Planning Team members and project stakeholders that the proposed specifications will result in a solution that satisfies project stakeholders’ needs.
4.10.2 Typical Content
The key elements of an SRD include the following items.
- Project description
- Points of contact
- Data requirements
- Functional process requirements
- Security requirements
- Audit trail requirements
- Data currency requirements
- Reliability requirements
- Recoverability requirements
- System availability requirements
4.12.3 Guidance for Document Development
The Project Manager should specify in the TMP how test activities will be managed, including organization, relationships, and responsibilities. The TMP should also document how test results will be verified and how the system will be validated.
The Project Manager updates the RTM to include a TMP reference that indicates the testing of each requirement. Elaboration of testing plans occurs in the Design and Development Phases.
4.12.4 Dos and Don’ts
- Do consider all types of testing activities required to meet project requirements.
- Do involve end users in determining the nature and extent of tests to be conducted.
- Do address how the TMP will be updated to include progressively more detail as the system is developed.
4.13 Perform Phase-Closure Activities.
The Project Manager and the Planning Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completing all Requirements Analysis Phase tasks. This review addresses:
- Status of Requirements Analysis Phase activities
- Planning status for all subsequent life cycle phases, with significant detail about the Design Phase (such as the status of pending contracts)
- Status on resource availability
- Project scope control as described in the PSS
- Changes to the project schedule and estimated completion date
- “Go-No Go” decision made to proceed to next phase, based on Requirements Analysis Phase information
- Verification that all changes are conducted in accordance with the approved Change Management Plan
The Project Manager compares actual project performance to the PMP and the projected cost of the project to determine any variances from the cost baseline during the phase-end review. The Project Manager also performs a comprehensive risk assessment of the project to update the Risk Register. The Project Manager updates the Maryland EA Repository with any new or updated components 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.
5.0 CONCLUSIONS
The approval of the System Requirements Document, RTM, and the TMP as well as the completion of the Requirements Analysis project status review and approval to proceed to the next phase signify the end of the Requirements Analysis Phase.
