Requirements analysis involves organising requirements, modelling requirements and designs, validating information, identifying solutions that answer the business needs, and assessing the potential value gained by performing these tasks.
Once the business analyst gathers all of the necessary information through elicitation efforts
, the business analysts can start their work on requirements analysis and design definition. The analysed, structured, and stakeholder-verified requirements lay a foundation for design definition and ultimately developing a solution that will bring value to the organisation.
The main distinction between requirements and designs is in the way they are used and who benefits from them. What is a requirement for one stakeholder can be a design for another. They both have their role in defining the change and can be overarching in their scope or precisely detailed depending on who they are intended for.
In performing requirements analysis and design definition, business analysts use all of the BABOK’s BACCM concepts. They define and guide changes by transforming elicited information into requirements and analyse the needs to come up with the solution of the highest value. They do this by working closely with stakeholders to provide the context in which the requirements and designs will be easily understandable and usable.
The BABOK list six tasks that the BAs should perform as a part of this knowledge area.
Table of Contents
Specify and Model Requirements
Specifying and modelling requirements involves a detailed description of the requirements that is done by analysing, synthesising, and refining elicited information.
When this process is focused on understanding the organisational needs it produces requirements. If its main focus is on developing a solution, it provides a design as an outcome. Some organisations have strictly established modelling methods, where the analysis must adhere to these rules while specifying requirements. The process of specifying and modelling requirements also includes capturing and recording requirements metadata and attributes.
The main inputs of the task of specifying and modelling requirements are elicitation results obtained for any state during the process. The primary expected output is specified and modelled requirements in the form of text, diagrams, or matrices.
The key elements of this task are:
- Modelling Requirements
- Requirements Analysis
- Representing Requirements and Attributes
- Implementing the Appropriate Levels of Abstraction
Useful guidelines and tools at this stage are modelling notations/standards, modelling tools, requirements architecture, requirements life cycle management, and solution scope. The recommended techniques for specifying and modelling requirements are:
- Acceptance and Evaluation Criteria
- Business Capability Analysis
- Business Model Canvas
- Business Rules Analysis
- Concept Modelling
- Data Dictionary
- Data Flow Diagrams
- Data Modelling
- Decision Modelling
- Functional Decomposition
- Glossary
- Interface Analysis
- Non-Functional Requirements Analysis
- Organisational Modelling
- Process Modelling
- Prototyping
- Roles and Permissions Matrix
- Root Cause Analysis
- Scope Modelling
- Sequence Diagrams
- Stakeholder List, map, or Personas
- State Modelling
- Use Cases and Scenarios
- User Stories
This task involves any stakeholder who takes part in the process or has the results presented to them for verification and approval.
Verify Requirements
When verifying requirements, the business analysts confirm that the created requirements and designs are developed in a way that is useful to the stakeholders and that they are detailed, consistent, and of high quality.
The requirements need to be verified by both business analysts and stakeholders so they are confined as valid for further use and contain relevant information. The requirement and design specification should be clear and easy to understand and their model should follow established formal standards and represent the real situation in the organisation.
The specified and modelled requirements serve as a primary input for requirements verification and this process should produce verified requirements as its output.
The requirements verification has three key elements:
- Characteristics of Requirements and Designs Quality
- Verification Activities
- Checklists
The main guidelines or tools of use when performing this business analysis task are the requirements lifecycle management tools. The most common techniques are:
- Acceptance and Evaluation Criteria
- Item Tracking
- Metrics and Key Performance Indicators (KPIs)
- Reviews
This task involves domain subject matter expert, implementation subject matter expert, and any stakeholder that takes part in the process and may help identify problematic requirements.
Validate Requirements
Requirements validation is necessary to ensure that developed requirements and designed help accomplish set organisational goals and bring value to the stakeholders. It’s a continuous process that is performed throughout the project and makes sure that the transition, stakeholder, and solution requirements and designs are in sync with the overall business requirements. To validate requirements, the business analyst must have a clear picture of what is desired future state for stakeholders. Achieving the desired future state is the main purpose of requirements validation.
The main input of requirements validation is the specified and modelled requirement of any type. Validation can not be completed before the requirement is verified but can begin before complete verification. The expected output when validating requirements is a validated requirement and design that deliver value and is aligned with overall business goals.
The key elements of requirements validation are:
- Identifying Assumptions
- Defining Measurable Evaluation Criteria
- Evaluating Alignment with Solution Scope
The business analysts can use several guidelines and tools while validating requirements: business objectives, future state description, potential value, and solution scope. The BABOK suggests the following techniques be used:
- Acceptance and Validation Criteria
- Document Analysis
- Financial Analysis
- Item Tracking
- Metrics and Key Performance Indicators (KPIs)
- Reviews
- Risk Analysis and Management
The key stakeholders for requirements validation are customer, user, sponsor, and any other stakeholders who collaborate with the business analysts and may be of help discovering problematic requirements.
Define Requirements Architecture
Defining requirements architecture implies structuring all of the requirements so that they support each other and contribute to accomplishing overall business objectives.
The requirements architecture is the framework that consists of all of the change requirements. All of the individual requirements within this structure must be cohesive and complement each other so they can produce value to the stakeholders.
The requirements infrastructure is used to gain a better understanding of the models and their fit to the solution scope, help organise those requirements, illustrate models interaction and mutual relationship, and contribute to decision making in reaching the organisational goals.
The key inputs for defining requirement architecture are information management approach, requirements of any state, and solution scope. The main output is organised requirements architecture.
This task includes the following elements:
- Requirements Viewpoints and Views
- Template Architectures
- Completeness
- Relating and Verifying Requirements Relationships
- Business Analysis Information Architecture
The guidelines and tools of use for this task are architecture management software, legal/regulatory information, and methodologies and frameworks. The techniques business analysts usually employ are:
Data Modelling
- Functional Decomposition
- Interviews
- Organisational Modelling
- Scope Modelling
- Workshops
The key stakeholders for this part of the business analysis process are domain subject matter expert, implementation subject matter expert, project manager, sponsor, tester, and any other stakeholder who may use requirements architecture.
Define Design Options
By defining design options, the business analysts identify and describe different ways to satisfy an organisational need. They define the solution approaches, explore opportunities, and allocate requirements across the business change components.
As the designs exist on a lower level than the overall change strategy and have more tactical than strategic roles, it’s important to evaluate the tactical trade-offs between different design alternatives and their effect on the overall change.
Defining design options relies on the following inputs: change strategy, validated and prioritised requirements, and requirements architecture. The main outputs of this task are the design options – the ways to meet the needs in a given context.
Several elements are a part of this task:
- Defining Solution Approaches
- Identifying Improvement Opportunities
- Requirements Allocation
- Describing Design Options
The useful guidelines and tools are existing solutions, future state description, traced requirements, and solution scope. The usual techniques used are:
- Benchmarking and Market Analysis
- Brainstorming
- Document Analysis
- Interviews
- Lessons Learned
- Mind Mapping
- Root Cause Analysis
- Surveyor Questionnaire
- Vendor Assessment
- Workshops
The primary stakeholders for defining design options are domain subject matter expert, implementation subject matter expert, operational support, project manager, and supplier.
Analyse Potential Value and Recommend Solution
Each requirement and design option brings a certain potential value to the proposed solution. One of the jobs of the business analyst is to estimate that value and compare different options to produce the highest value. The analysis of value can be planned in advance or performed as the project progresses per the occurring changes. Every option has its benefits and disadvantages that need to be explored. Sometimes, there is no definite best option and in those cases, all of them may be rejected or the work can start on multiple options and select the one that performs the best.
Inputs for this stage of the process are potential value and design options, and the task is expected to produce the output in the form of a solution recommendation.
The elements of “Analyse Potential Value and Recommend Solution” task are:
- Expected Benefits
- Expected Costs
- Determining Value
- Assessing Design Options and Recommending Solution
The business analysts use the following guidelines and tools for this task: business objectives, current state description, future state description, risk analysis results, and solution scope. The recommended techniques are:
- Acceptance and Evaluation Criteria
- Backlog Management
- Brainstorming
- Business Cases
- Business Model Canvas
- Decision Analysis
- Estimation
- Financial Analysis
- Focus Groups
- Interviews
- Metrics and Key Performance Indicators (KPIs)
- Risk Analysis and Management
- Survey or Questionnaire
- SWOT Analysis
- Workshops
Analysing potential value and recommending a solution involves the following stakeholders: customer, domain subject matter expert, end-user, implementation subject matter expert, project manager, regulator, and sponsor.
Requirements Analysis and Design Templates
Business Analysis Doctor has a set of supporting requirements analysis and design templates in a business analysis template package and includes a requirements verification checklist, software requirements specification (SRS) template, use case description template, solution design document.
Conclusion – Requirements Analysis and Design Definition
Requirements analysis and design definition involves organising requirements, modelling requirements and designs, validating information, identifying solutions that answer the business needs, and assessing the potential value gained by performing these tasks. Requirements analysis has the benefit of having a clear set of requirements.
Learn more about the other IIBA business analysis knowledge areas:
