Objective
The objective of this phase is to define in more detail the system inputs, processes, outputs and interfaces. At the end of this phase the system’s processes will be defined at the functional level, meaning the functions to be performed will be known, but not necessarily how they will be performed. Unless specifically constrained by the Project Charter, Requirements Analysis should not consider the computer programs, files and data streams.
Requirements Analysis will identify and consider the risks related to how the technology will be integrated into the standard operating procedures. Requirements Analysis will collect the functional and system requirements of the business process, the user requirements and the operational requirements (e.g., when operational what is necessary to keep the system up and running).
Entry Criteria
In order for Requirements Analysis to begin, there must be an approved Project Charter. The scope of the project will be understood and stated in the Project Charter. The roles and responsibilities for the various activities in the Development Life cycle will be known.
Roles & Responsibilities
Project Manager: The project manager is accountable for the success of this phase. The primary responsibility of the Project Manager during Requirements Analysis is to ensure the Business Analyst(s) has access to the proper: Subject Matter Experts, Business Process documentation, existing technology and potential technological solutions as well as current and desired artifacts. A major impediment to successful requirements analysis is lack of exposure to any of the previously listed items
Business Analyst – The BA must first develop a plan for how the requirements analysis activity will be accomplished. The BA must then document the business process descriptions and collect the requirements of the system from the Subject Matter Experts (SME’s) in a manner which allows traceability to documents generated in previous activities and creates a framework for future activities. All identified requirements should fall within the constraints of the project scope and align with the customer’s statement of needs. The BA will generate a requirements traceability matrix which becomes the basis for the Design activity.
The BA constructs a logical model that describes the data and processes needed to support the requested functionality. Processes are identified along with any of the associated data they use or create. The interactions of dependent processes is also defined.
Because of the variability in scope of the projects intended to fall within the confines of this life cycle, it is expected that the BA will need a flexible set of tools to properly elicit and document the business requirements. The BA will work closely with the SME’s to ensure a logical model showing processes, data structures and business activities in an accurate, consistent and complete manner.
The BA must also consider the current technical architecture, application software and data that is used to support the business function to guarantee that no necessary functionality has been overlooked. The BA will also be aware of considerations surrounding persons with disabilities and any other legal considerations. Some consideration must also be paid to capacity and growth associated with the project.
Subject Matter Expert – The Subject Matter Expert understands the current business processes and any new requirements that are to be satisfied by the project. They must work closely with the BA to transfer both stated and tacit knowledge for inclusion in the Functional Requirements Documents
Designer – The Designer receives the Artifacts produced in the Requirements Analysis phase. Because of the variability in scope of the projects intended to fall within the confines of this life cycle, it is expected that the Designers will coordinate with the BA early on to ensure there is an agreed upon set of artifacts delivered.
Testing Lead – The Testing Lead is involved during this activity to ensure that the requirements identified by the BA and accepted by the customer are measurable and that IT has the resources to complete adequate testing. Having the Testing Lead involved at this step allows for proper scheduling and preparation for the various stages of testing that occur during the SDLC.
Common Artifacts
Functional requirements document defines in more detail the system inputs, processes, outputs and interfaces. Such detail can be provided in various formats. Usually no individual technique or model is sufficient to express the requirements of a nontrivial system. Different types of projects and different varieties of customers will find success using different techniques for collecting and representing the functional requirements. Some of the optional techniques for the expression of functional requirements which could define the contents are shown in the italicized list below. Note that all of the techniques should be briefly considered at the beginning of the Requirements Analysis and appropriate ones should be determined based on type of project and customer. Note that none of the optional techniques listed are technology dependent nor do they dictate specifics to the Designers of HOW process work and accomplish the goals of the system.
- Entity-relationship diagrams (optional)
- process hierarchy diagrams (optional)
- process dependency diagrams (optional)
- logical model (optional)
- activity diagrams (optional)
- business algorithms (optional)
- entity life cycle diagrams (optional)
- entity state change matrices (optional)
- Mockups (optional)
- Data Flow Diagrams: Intended to represent the flow of information around a system (optional)
- Requirements Traceability Matrix (included at end of FRD)
Review (Revision)
The completion of Requirements Analysis is signified by a presentation of the FRD to the Customer and the Designers. At this point the Project Manager should also review the FRD for the time line for the remaining life cycle phases, review of resource availability and a risk assessment organized to align with the remaining steps of the life cycle.
Approval
When the customer signs off on the Business Requirements the software designers can begin their system design work. Depending on the technique of development there might be more than one visit to the Requirements Analysis activity. It is important that the Business Analyst, Designers and Customer agree and understand the expected iterations of Requirements analysis.
Exit Criteria
Requirements Analysis is complete when the customer signs off on the Functional Requirements Document.