Requirements Analysis Tutorial

6.1 Requirements Analysis

Hello and welcome to the sixth lesson of the Certification of Competency in Business Analysis™ (CCBA®) course offered by Simplilearn. In the previous lesson, we discussed enterprise analysis. In this lesson, we will understand requirements analysis. This knowledge area is important as it collects most of the information in a form which details and validates the requirements that support solutions—the deliverables. Most of this lesson is dedicated to the discussion of how to drill down into requirements and determine if the suggested requirements can actually support the solution and its desired results. The tasks employed to determine the details of the requirements are prioritizing, organizing, defining assumptions and constraints, modeling, verifying, and validating. Let us begin with the objectives of this lesson in the next slide.

6.2 Objectives

After completing this lesson, you will be able to: Describe the requirements analysis knowledge area Explain how to prioritize requirements based on specific criteria Use decision analysis to prioritize requirements Identify the models used to specify requirements Verify the requirements from stakeholders to use on the implemented solution Let us find out what requirement analysis is in the next slide.

6.3 Introduction to Requirements Analysis

Requirements analysis of business analysis activities includes defining capabilities, stakeholder requirements, and solution requirements. The business analysts will define the required capabilities of a potential solution that will fulfill stakeholder needs. Then the stakeholder requirements, which describe what a solution must be capable of doing to meet the needs of one or more stakeholder groups, should be defined. Finally, the solution requirements, which describe the behavior of solution components to be constructed, are defined. We will be introduced to requirements analysis knowledge tasks, inputs, and outputs, in the next slide

6.4 Requirements Analysis Diagram

The following are the inputs: Business Case Business Need Requirements Organizational Process Assets Requirements Management Plan Stakeholder Concerns Stakeholder List, Roles, and Responsibilities Solution Scope The following are the outputs: Assumptions and Constraints Requirements Structure is an organized structure for the requirements and a documented set of relationships between them. Requirements [Prioritized] have an attribute that describes their relative importance to the stakeholders and the organization. Requirements [Validated] are those that can be demonstrated to deliver value to the stakeholders and are aligned with the business goals and objectives. Requirements [Verified] are requirements of sufficient quality to allow further work based on those requirements to be performed. Stakeholder or Solution Requirements have been modeled; they comprise specified, detailed requirements. In the next slide, we will be discussing what requirements analysis is.

6.5 What is Requirements Analysis

This slide presents an overview of each requirements analysis knowledge task before detailing each task individually. Requirements analysis is providing the best requirements support to a solution to a need. The first step is to analyze sponsor or stakeholder needs to determine and document the business needs for the solution. A solution scope is developed using stakeholder and SME input to develop high-level solutions. Then the requirements for the high-level solutions are developed. The enterprise is reviewed for the ability to provide those necessary requirements. If it can, detailed solutions and requirements are created. If not, the project may be terminated and the solution will not be implemented until the necessary requirements are delivered. Once consensus for a solution has been reached, it is time to focus on the process of analyzing the best possible arrangement of requirements and determine how they will affect the deliverable, i.e., the benefits of the solution. Next, we will learn about the prioritize requirements diagram.

6.6 Prioritize Requirements Diagram

The following are the inputs: Business Case Business Need Requirements Requirements Management Plan Stakeholder List, Roles, and Responsibilities The following is the output: Requirements [Prioritized] The following are the techniques: Decision Analysis Risk Analysis MoSCoW Analysis Timeboxing/Budgeting Voting In the next slide, we will be discussing prioritizing requirements

6.7 Prioritizing Requirements

Prioritizing requirements helps focus on the implementation of the most critical requirements that support solutions. A business case describes the key goals and reasoning for a project. The business case is a subsection of the enterprise analysis. It is a narrative description for justification of a project to meet the changing needs. As with all of the documentation, the ongoing analysis process may force changes in the business case. Business value is the prioritization based on a cost-benefit analysis. Normally, more valuable the requirement solution, higher will be the priority. Business risk can be analyzed using various techniques. In the next slide, we will find out about decision analysis.

6.8 Prioritize Requirements Decisions Analysis

Financial analysis is used if the outcomes of KPIs are measured in financial terms. Examining potential financial outcomes helps to identify the requirements that will help deliver the best financial outcome. The following are the most common terms of financial analysis. Rate of Return: This is the most common term used to express the percentage of return on an investment over a certain period. However, most of the time, the term is used incorrectly because the ‘real rate of return’ is based on the total return of investment capital and the investment returns over and above the original investment capital. Moreover, for longer investments, the capital investment should be discounted for inflation. Discounted cash flow (DCF): The purpose of DCF analysis is to estimate the money received from an investment, adjusted for the time value of money. Net present value (NPV): NPV compares the value of a dollar today to its value in the future, taking inflation and returns into account. If the NPV of a prospective project is positive, it should be accepted. However, if NPV is negative, the project should probably be rejected because cash flow will also be negative. Internal rate of return (IRR): IRR can be thought of as a means to measure the rate of growth of a project and the returns, discounted for inflation. IRR is used to justify that a project can return a higher estimate in comparison with other investment opportunities. Average rate of return (ARR): ARR measures the average ROI over a certain period. Cost-Benefit Analysis: A commonly used tool to determine the benefits, both tangible and intangible, in comparison to the costs of capturing the benefits. Payback period: It is the time taken for an investment to return the capital investment. It does not discount for inflation. In effect, an investment does not start earning a ‘real return on investment’ until the initial investment has been repaid. In cases where there are measureable KPIs (Key Performance Indicators) such as financial indicators or units of productivity, it becomes a matter of weighing the importance of the data, as well as knowing what the relative risks are to obtain the KPIs. The findings can be set up in a table to rank according to the highest KPIs and the lowest corresponding risk level. For example, a new software application may not just offer an optimal solution, but also pose the maximum amount of cost due to integration with other existing systems. Uncertainty of outcome is a technique to estimate the probability of a desired outcome. In this situation, stakeholders and SMEs who are familiar with the processes involved develop a consensus estimate of the probability (percentage) of certain outcomes. Those estimated outcomes are ranked from the highest to the lowest probability. Often, a decision tree is used as a tool to help decide. Let us discuss other criteria used to prioritize requirements.

6.9 Prioritize Requirements Business Risk Analysis Techniques

The following are other business risk analysis techniques: MoSCoW Analysis: A memory word that describes the breakdown of requirements into the following four categories: ‘Must’: It signifies a requirement that must be satisfied in the solution. ‘Should’: It signifies a requirement with a high priority that should be included in the solution, if possible. The restrictions might be budget, availability of equipment, or knowledge. It is a requirement that is important, but can be provided through other means. ‘Could’: It describes a requirement that would be nice to have but is not necessary in the solution. It would be included in the requirements list if time and budget allow. ‘Won’t’: It represents a requirement which the stakeholders agree should not be included in the solution at this time, but may be revisited in the future. Timeboxing/budgeting prioritizes requirements based on some fixed constraints such as time to implement a requirement or budgeting. Timeboxing is based on the amount of time that is allocated for the implementation of a particular requirement. For example, a requirement that has a fixed amount of time to be implemented might be seen as more critical if other factors depend on the task completion within the allocated “Time box”. There are certain approaches that can be taken when considering timeboxing prioritization. They are: All in: Here, all requirements are assigned a time or budget cost. Those requirements that cannot meet these constraints are removed. All out: Here, the general time and budget to complete the implementation of all requirements for a solution are established. The requirements are accommodated until the allocated project time or budget constraints have been reached. Selective: Here, high priority requirements are identified and requirements are added or reduced to fit the calendar time or budget constraints. Budgeting is a necessity constrained by the budget allocated to the requirement. As labor is a major cost of any project, both time and money are important factors. However, in certain stages of a project, time, or budget allocation can become more important. Indeed, the idea of pricing a project is the estimation of how long and how much cost would be required to deliver the stated benefits. Voting is a technique where key stakeholders are given a certain amount of votes (or tokens) to allocate on requirements. The requirements with the most votes are prioritized accordingly. Let us cover prioritization factors in the next slide.

6.10 Prioritize Factors

Let us continue with the discussion of the remaining items necessary for the prioritization of requirements. Implementation difficulty can help to prioritize requirements. If a requirement appears difficult to implement, there may be a need to look for an easier way to implement it. However, if a requirement is critical to the solution, it should be prioritized as much as possible toward the start of implementation. If there is a critical requirement identified toward the end of implementation, it can leave an entire project vulnerable to exceeding the budget or nullifying it.. It is always better to know the serious flaws earlier in a project. Ideally, easy to implement requirements are preferred. Probability of success is a primary consideration. Higher the probability of a requirement in helping to provide a successful outcome, greater should be its priority. This can be done by using the MoSCoW technique and asking for stakeholder’s assign (vote) on probabilities of success. Policy and Regulatory Compliance is taken into consideration to ensure that the requirements are in compliance, and they may take preference over stakeholder consensus because, by definition, compliance is mandatory unless waivers can be obtained. Relationship to other requirements can dictate the priority of implementation. For example, a group of requirements that must be installed in a particular sequence will be prioritized according to the sequence. Stakeholder agreement on the prioritized requirements list needs to be supported by a consensus of the stakeholders on the priority list. Urgency can become important depending on the project and timeliness. For example, if a key piece of equipment becomes inoperable and directly affects the solution, the first requirement would be to replace or fix the equipment. In the next slide, we will discuss the business benefit analysis technique.

6.11 Prioritization Requirements Business Benefit Analysis Techniques

The decision tree is a process flow or a systematic “walk through” of the outcomes of different scenarios. Outcome probabilities are assigned at the end of each process. The decision tree also helps brainstorm possible solutions and requirements that may apply to the solution scope. For example, as seen in the diagram in the slide, decision ‘A’ forks off into two different scenarios depending on a variable. Each scenario is assigned and has a probability of success. On the other hand, decision ‘B’ has only one scenario with an assigned probability of success. However, each scenario has other considerations such as cost, ease of implementation, etc., that should also be considered in the process. Uncertainty of outcome is a technique to estimate the probability of a desired outcome. In this situation, stakeholders and SMEs who are familiar with the processes involved develop a consensus estimate of the probability (percentage) of certain outcomes. Those estimated outcomes are ranked from the highest to the lowest probability. Often, a decision tree is used as a tool to help decide. Let us return to the requirements analysis task of organizing requirements.

6.12 Organize Requirements Diagram

Once prioritized, the requirements need to be organized to provide a clear and coherent view of how they will support the solutions. The objective of organization is the clear definition of requirements relationships. The purpose of organizing the requirements is to create views of the potential solutions that are clearly understood by all stakeholders in the domain of the solutions. The two main objectives that support the purpose of the organization are to describe clearly, which models are appropriate for describing how the requirements function to provide the solution, and to identify the relationships and dependencies of the requirements involved in the solution. The following are the inputs: Organizational Process Assets Requirements [Stated] Solution Scope The following is the output: Requirements Structure The following are the techniques: Business Rules Analysis defines the rules that govern decisions in an organization and that define, constrain, or enable organizational operations. Data Flow Diagrams show how information is input, processed, stored, and output from a system. Data Modeling is done to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them. Functional Decomposition Organization Modeling Process Modeling is done to understand how work that involves multiple roles and departments is performed within an organization. Scenarios and Use Cases describe how an actor interacts with a solution to accomplish one or more of that actor’s goals or to respond to an event. Scope Modeling describes the scope of analysis or the scope of a solution. User Stories describe the functionality that users need from a solution to meet a business objective. In the next slide, we will be discussing specifying and modeling requirements.

6.13 Specify and Model Requirements Diagram

The following are the inputs: Requirements [Stated] Requirements Structure The following is the output: Requirements Structure (with additional information) The following are the techniques: Acceptance and Evaluation Criteria Definition defines requirements that must be met for a solution to be considered acceptable to stakeholders. Business Rules Analysis Data Dictionary and Glossary is an analysis model describing the data structures and attributes needed by the system. Data Flow Diagrams illustrate processes that occur along with the flow of data to and from these processes. Data Modeling depicts the logical structure of data independent of the data design or data storage mechanisms. Functional Decomposition Interface Analysis Metrics and Key Performance Indicators indicate a quantifiable level of an indicator that an organization wants to accomplish at a specific point in time. Non-Functional Requirements Analysis Organization Modeling Process Modeling Prototyping Scenarios and Use Cases Sequence Diagrams show objects participating in interactions and the messages exchanged between them. User Stories In the next slide, we will be discussing assumptions and constraints

6.14 Define Assumptions and Constraints Diagram

The following is the input: Stakeholder Concerns The following is the output: Assumptions and Constraints The following are the techniques: Problem Tracking Risk Analysis In the next slide, we will be discussing defining assumption and constraints

6.15 Defining Assumptions and Constraints

Defining assumptions and constraints answers the question of what factors will affect the priority of a solution. After the prioritization and organization of requirements have been completed, it is time to check for factors outside the actual tasks, which can affect the implementation. As some of these exogenous factors may not be known to the domain stakeholders and SMEs, it is important to include input from departments that may not be directly involved in the domain. For example, a requirement might need the installation of a holding pond. The legal department would need to be involved as there may be local building codes and environmental requirements to be fulfilled. This would be a regulatory constraint that will add to the cost of the project as well as the risk of fines and project cessation if the regulations are not complied with. To define assumptions, the stakeholders, SMEs, and sponsor need to make sure that the need complies with the goals and mission of the company. It is important to identify the need correctly, as the assumption of the perceived need decides the solution and the implementation of it. For example, a sponsor might be misinformed about the possible regulatory restrictions on an existing process. Before deciding on the need to make changes, the causal factors should be carefully investigated to make sure the assumption of the need is real, and that there are no other ways to address a potential problem or the imagined need. Sometimes, a need can be deferred until certain measureable events take place before the implementation of a solution. Constraints to addressing a need are usually budgetary, physical, regulatory, technical, internal, and ethical-social-political. Business constraints are the business limitations that can affect solutions. Business constraints are factors that cannot be changed or are impractical to change to fit a solution. Examples are budgetary constraints, time restrictions, resource and skill set limitations, and organizational restrictions as spelled out in the corporate charter. As with assumptions, the constraints should be verified by stakeholder consensus and any outside sources of historical data that support the constraint on the potential solutions. Budgetary is a direct cost-benefit analysis. Sometimes, projects are justified in containing a long-term cost-benefit solution. For example, a company may decide to invest in a project that may have a long pay back horizon, but this can be justified in terms of company image, relative low costs or discounted pricing, or strategic advantages. Technical constraints are the technical design and implementation factors that affect how and if a solution is viable. Technical constraints are common to most software projects as new software capabilities may need to be integrated with legacy or existing software systems. Often, this requires special language capabilities, hardware requirements, software platforms, and communication interfaces. Often, the BA or the stakeholders have the technical capability to define the actual technical constraints and will need to outsource to experts in specific solutions. Defining assumptions and constraints is an important aspect of the analysis and the output is basic to the success of the project. In the next slide, we will be discussing verifying requirements.

6.16 Verify Requirements Diagram

‘Verify requirements’ is the final check of the solution scenarios. Verifying requirements is the process of reviewing the solution scenarios and ensuring the requirements support the solutions. The BA and stakeholders are charged with the task of making sure the requirements are ready for formal review by customers and users, and that they provide all the information for further development and implementation of the requirements. The following are the inputs: Requirements [Any, Except Stated] The following is the output: Requirements [Verified] The following are the techniques: Acceptance and Evaluation Criteria Definition Problem Tracking Structured Walkthrough In the next slide, we will be discussing validating requirements.

6.17 Validate Requirements Diagram

The following are the inputs: Business Case Stakeholder, Solution, or Transition Requirements [Verified] The following is the output: Requirements [Validated] The following are the techniques: Acceptance and Evaluation Criteria Definition Metrics and Key Performance Indicators Prototyping Risk Analysis Structured Walkthrough Now, let us go through a few questions to check your understanding of the concepts discussed.

6.19 Summary

Here is a quick recap of what we have learned in this lesson: Requirements analysis is to define required capabilities, stakeholder requirements, and solution requirements. Prioritizing requirements explains which requirements will be completed and in which order. Verifying requirements ensures that the requirements have been defined correctly. Validating requirements ensures that stakeholder, solution, and transition requirements align with business requirements.

6.20 Thank You

In the next lesson, we will learn about solution assessment and validation.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy