Business Requirements: An Essential Guide to Definition and Application in IT Projects

1. Overview

The complexity of business requirements in IT projects has experienced exponential growth due to pressures from increasingly sophisticated client preferences, novel technologies, and fierce competition.

Consider, for example, the case of financial payments. In the mid-80s, most payment transactions occurred inside bank branches, and only the biggest banks offered services on ATM or POS machines. Today, we live almost exclusively in cashless societies that subsist on electronic fund transfers (EFT) and where an average consumer can make payments with plastic cards, mobile phones, watches, cheques, web links, and mobile applications. These taken-for-granted technologies might have sounded more sci-fi than real only a decade or two ago.

Hundreds of applications are simultaneously involved in enabling and supporting these payment methods, working together seamlessly, while their success rests prominently on a clear definition and implementation of business requirements.

Increasing Complexity of Business Requirements in ePayments

Many instances of IT project failure can be traced back to unclear requirements, poor understanding of the business case, and scope creep (ref. 6 reasons why your IT project will fail and Top 10 Reasons Why Projects Fail).

Overshooting the budget, missing deadlines, and software deliveries of little or no business value to customers are typical outcomes of failed projects.

IT projects are notoriously difficult to manage. A survey published in HBR found that the average IT project overran its budget by 27%. Moreover, at least one in six IT projects turns into a “black swan” with a cost overrun of 200% and a schedule overrun of 70%. In other words, while most IT projects will fall short of their budget targets, a few might overshoot the targets so much as to cause catastrophic organization-wide problems. KMart’s massive $1.2B failed IT modernization project, for instance, was a big contributor to its bankruptcy.

— HBR

Numerous other reasons contribute to project failures, such as size (the bigger they are, the more likely they are to fail), inconsistent practices, lack of talent and support from leadership, and cultural blockers.

The challenges that requirement definition brings probably compound these factors as full knowledge of business requirements at the beginning of the project is not possible for reasons we elaborate on later.

In the customer satisfaction model proposed by Noriaki Kano, there are three levels of customer requirements.

Basic Requirements (or Dissatisfiers). These are the must-haves. You get no credit for meeting those requirements but a lot of dissatisfaction if you don’t.
Variable Requirements (or Satisfiers). These have a direct impact on your organization’s ratings. They typically include timely delivery and good customer service.
Latent Requirements (or Delighters). These set you apart from the competition and are usually the product of innovation.

This article will examine the business requirements production processes from definition to gathering, documentation, review, validation, and acceptance. We also explain the purpose and methods of stakeholder analysis and management.

By this article’s end, we hope you will better understand the subtle concepts behind creating, documenting, and handling adequate business requirements.

The Critical Importance of Software Project Management

2. Business Requirements

2.1 Definition

A collection of business requirements determines a project’s goals and constraints.

You will undoubtedly remember seeing the words shall and should in a business requirements document (BRD).

Shall is often used to define a hard constraint that developers must implement. On the other hand, should denote a desirable but not compulsory requirement.

Any successful solution design must satisfy all hard constraints and whatever can be achieved from the list of desirable ones. Solution design is an optimization exercise where tradeoffs are made between budget, deadlines, performance, and feature richness.

To better understand how this optimization exercise unfolds, we need to explain three concepts from Systems Engineering: design and objective spaces and the mapping between them.

The design space is spanned by a vector of all design parameters at your disposal. Design parameters can include all the hardware and software you can use in your solution and the parameters that control their behaviour and performance.

In the case of hardware, these could be the number of available CPUs, memory size, and disk speeds. For software, these can be application settings or deployment methods.

Every unique combination of parameters is a point in the design space.

An objective space is spanned by a vector of goals and constraints such as cost and schedule. Theoretically, your budget can go from zero to infinite, and your deadlines can go from now to forever.

Every combination of design parameters, represented by a point in the design space, can be mapped to a point in the objective space by calculating its cost and implementation plan.

Some business requirements will constrain your design space, while others will constrain the objective space.

Every point in the constrained design space where its counterpart falls in the constrained objective space is a potential solution to your optimization problem. As an architect, your job is to find the optimal combination to form your solution.

Part 1: Solution Design — Introduction and First Principles

2.2 Goal

A clear, concise, and unambiguous Business Requirements Document (BRD) creates the following advantages in several stages of the Software Development Lifecycle (SDLC):

During the project kick-off phase, the BRD provides a solid base for stakeholder agreement.
The Analysis phase allows for the reduction of rework, a significant source of project risk, and poor quality deliveries by providing input to the solution design phase. It also permits accurate cost and effort estimation, adequate planning, budgeting, and efficient resource allocation.
The verification and validation phase kicks in when the code is ready for release. A well-written BRD provides the basis for verifying that the requirements have been met by acting as input to the test plan and test case creation process. Performance constraints provide input for the preparation and execution of stress testing.
Finally, the BRD is used for project acceptance and product ownership transfer to the client, formally moving the project into support mode.

2.3 Quality

The quality of the requirements and their definitions can be divided into two levels:

On the individual level, every requirement should be verifiable, clear (unambiguous), and feasible.
As a whole, the set of requirements should not contain redundancies or conflicting constraints (otherwise, the technical feasibility of the solution would be jeopardized) and should be complete.

3. Business Requirement Challenges

3.1 Addressable Challenges

Defining business requirements that can be set in stone is not feasible for technical and other reasons. Here is a list of the most prominent:

A vague understanding of the business case prevents writing precise requirements initially, and you will only have more clarity as you get to know the problem more. This issue occurs when inexperienced Business Analysts (BA) define requirements without being proficient in the business/technical aspects of the problem.
Volatility: Requirements originate from various stakeholders, and the lengthier the schedule, the more likely it would be to observe a change in business requirements. A typical example would be new regulations that regulatory agencies constantly publish and mandate.
Conflicting requirements: These may go undetected at the start of the project if the requirements review process is not diligent and rigorous enough and stakeholder analysis is not completed.
Technical infeasibility: When working with novel or emerging technologies, some features’ integration problems or technical infeasibility might only be discovered after development has started. This problem does not exist for old problems with tried and tested solutions.
Scope creep is another issue. Stakeholders typically create additional requirements after the project scope has been signed off.

All of the issues presented above can be managed and controlled with the proper procedures:

Talented BAs with expertise in the industry can be hired
Project scope can be locked, and change management processes implemented to prevent scope creep
Agile methods can be practised to deal with volatility
Simulations or Proof of Concept exercises can be run to assess technical feasibility
Proper stakeholder management techniques can eliminate conflicting requirements.

3.2 Inherent Challenges

A more fundamental obstacle exists, however, that prevents the requirement definition from being fully elucidated at project initiation. This problem is innate, cannot be easily addressed, and has to do with defining low-level requirements.

You typically have high-level requirements from which solution architects would create a high-level design at project inception.

The high-level solution does not cover key design decisions, such as the technologies used, as these would primarily come during the low-level solution design phase.

Your design choices will require further input from the stakeholders and a constant dialogue must be maintained.

From an article published on pmi.org discussing the top reasons for IT project failures, we the following:

Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together.

— Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together.

To illustrate the idea, consider the choice you have to make when selecting a database vendor.

On a high level, you know you need a storage mechanism to persist application data, but at this stage, this storage mechanism could be a file, a relational, or a NoSQL database.

You can have specific requirements for this mechanism, including high availability and replication to a different geographical location. These two requirements are solution-agnostic as there might be various ways to satisfy them.

Assuming a relational database is the way to go, you must select a provider. You can go for open-source software to avoid licensing fees, or you could choose to collaborate with a well-known brand. You must make further decisions regarding deployment methods, license size, hardware procurement, and support options.

These are business decisions involving the client, the project manager, and the procurement and supplier management departments.

Hence, your low-level persistence requirements could not be defined before settling on a specific mechanism.

3.3 Handling Requirement Definition Challenges

Two broad categories encompass the many solutions proposed for handling big projects with complex requirements. These categories are lightweight (Extreme Programming, Agile, and DevOps) and heavyweight project delivery methodologies (Waterfall and the Hybrid Model).

The methods they employ for dealing with business requirements ambiguity are pretty different.

The success of Waterfall-based project management is predicated on complete requirement clarity as early as the beginning of the design phase of the SDLC.

Massive analysis and design efforts are carried out before implementation to achieve the desired clarity requirement. The trade-off is a high cost of change.

In contrast, Agile acknowledges this approach’s fallibility in light of the inherent challenges in obtaining complete visibility of business requirements and proposes an iterative method instead.

The iterative approach does not try to find the shortest path towards project closure but focuses instead on smaller and more frequent releases, and the trade-off here is the timeframe for scope.

It is interesting to note that Agile and Waterfall are imperfect, and project suitability should be assessed before adopting one or the other. In most cases, a Hybrid model will do just fine unless you can implement DevOps, which is the best we have today.

Understanding the SDLC in Software Engineering: A Comprehensive Guide

4. Types of Requirements

Six types of requirements can be defined:

Functional requirements. These take the form of an actor completing an action on a specific object. The actor is a system component, the action is a function it provides, and the object is the recipient of that action. For example, ” the user management interface shall allow clients to change their passwords”.
Performance requirements. These requirements act as qualifiers for functional requirements. For example, “the IT system must support 1000 Transactions per Second on weekends with response times averaging 1 second and 95% of response times less than 5 seconds”.
Constraints are mandatory requirements that are typically applied to the solution components. They cannot be traded off for cost, timeline, or performance. For example, the solution must not cost more than $0.5M.
Integration requirements determine which third-party systems the solution interfaces with.
Environmental requirements determine the conditions under which the solution would run. For example, how well-trained support or operations staff must be, which languages the user interface must support, and which OS systems will be used.
Non-functional requirements. These are covered by the ISO 25010 software quality standard, such as compatibility, reliability, and security.

Part 2: Solution Design — How to Identify the Design Characteristics of Modern IT Systems

5. Business Requirements Document (BRD)

5.1 What is a Business Requirement Document (BRD)?

A Business Requirement Document (BRD) is a document that outlines the business requirements for a software application or system. It serves as a communication tool between the business stakeholders and the development team to ensure that the project is built to meet the business needs. The BRD defines the functional and non-functional requirements and any constraints, assumptions, risks, and dependencies.

Various formats allow the storage and management of technical documentation. Some are simple, like MS Word, and others are more complicated such as Confluence.

Below is a list of things to consider:

Requirement size: complex requirements for large projects would be better off stored on specialized tools instead of simple text processing applications. Such tools can make navigation, search, and editing much more effortless. It can also allow the seamless addition of interactive data visualizations like tables and graphs.
Version Tracking and Control are necessary when the number of people collaborating on a project is relatively large (more than five people can be considered large) and updates are frequent.
Collaboration activities involve reviewing, commenting, monitoring, watching, and updating a team. These activities can become a nightmare without the necessary infrastructure. I believe the Atlassian suite to be the gold standard at the time of writing.

Part 4: Solution Design Documents — What You Need to Know

5.2 Why is a Business Requirement Document Important?

Creating a BRD is critical to the success of a software development project for several reasons:

Communication: A BRD provides a clear and concise way to communicate the business needs and requirements to the development team, ensuring everyone is on the same page.
Alignment: A BRD helps ensure that the project goals align with the business goals and objectives. It also ensures the development team builds the right solution to the business problem.
Documentation: A BRD provides a comprehensive business requirements record and serves as a reference document throughout the project lifecycle.
Validation: A BRD provides a basis for validating the project deliverables and ensuring they meet the business needs.

6. How to Create a Business Requirement Document

Creating a BRD is a collaborative effort that involves business stakeholders, subject matter experts, and the development team. Here are the key steps involved in creating a BRD:

Step 1: Identify Business Objectives and Goals

The first step in creating a BRD is identifying the business objectives and goals. This involves understanding the business problem that needs to be solved and defining the expected outcomes.

Step 2: Identify Stakeholders

Identify the stakeholders involved in the project and their roles and responsibilities. This includes business stakeholders, subject matter experts, and development team members.

Stakeholder Analysis and Management

Step 3: Define Functional Requirements

Functional requirements define what the system or application should do. This includes features, capabilities, and behaviours necessary to achieve the business objectives.

Step 4: Define Non-Functional Requirements

Non-functional requirements define how the system or application should perform. This includes performance, reliability, usability, security, and other quality attributes.

Stress, Load, and Performance Testing in Software and IT Systems

Step 5: Define Assumptions, Constraints, Risks, and Dependencies

Assumptions are factors that are considered to be true but are not verified. Constraints are limitations that must be considered in the design and development of the system or application. Risks are potential problems that could impact the success of the project. Dependencies must be established before the system or application can be built or deployed.

Step 6: Review and Approve the BRD

Once the BRD is complete, it should be reviewed and approved by all stakeholders. This ensures that everyone agrees on the business requirements and that there is a shared understanding of what needs to be built.

7. Tips for Creating an Effective Business Requirement Document

Here are some tips to help you create an effective BRD:

Be specific and detailed: Use clear and concise language to define the requirements and provide examples to illustrate the expected behaviour.
Avoid ambiguity: Make sure the requirements are unambiguous and there is no room for interpretation.
Consider the audience: Tailor the language and level of detail to the audience, ensuring everyone understands the requirements.
Include visuals: Use diagrams, flowcharts, and other visual aids to help illustrate the requirements and make them easier to understand.
Prioritize requirements: Rank the requirements in order of importance so that the development team knows which requirements to focus on first.
Test the requirements: Define test cases and acceptance criteria to ensure the requirements are met, and the system or application works as expected.
Be flexible: Be prepared to revise the BRD as needed based on feedback and changes in the project scope.

8. Common Mistakes to Avoid

While creating a BRD is critical to the success of a software development project, there are some common mistakes that you should avoid:

Not involving all stakeholders: It is important to involve all stakeholders in creating the BRD, including business leaders, end-users, and technical experts. Leaving out any key stakeholders can lead to misunderstandings and missed requirements.
Being too vague or general: The BRD should be specific and detailed, outlining the business needs and requirements clearly and concisely. Being too vague or general can lead to misinterpretations and confusion.
Overcomplicating the document: While the BRD should be detailed, it should also be easy to understand. Avoid using technical jargon or overly complex language that can make the document difficult to comprehend.
Not prioritizing requirements: It is important to rank the requirements in order of importance so that the development team knows which requirements to focus on first. Failure to do so can lead to delays in the project and wasted resources.
Failing to test the requirements: Define test cases and acceptance criteria to ensure the requirements are met, and the system or application works as expected. Failure to do so can lead to costly errors and delays in the project.

9. FAQs

A BRD outlines the business requirements for a software application or system, while a Functional Specification Document (FSD) outlines the technical requirements for implementing the solution. The FSD is typically based on the BRD and provides a more detailed description of how the solution will be built.

Creating a BRD requires collaboration between business stakeholders, subject matter experts, and the development team. Each group brings a unique perspective to the project and can help ensure the requirements are comprehensive and accurate.

The length of a BRD will depend on the complexity of the project and the level of detail required. A typical BRD may range from 10 to 50 pages, but no set length exists.

Yes, a BRD can be revised as needed based on feedback and changes in the project scope. It is important to keep all stakeholders informed of any changes to the BRD.

If the BRD is not clear or complete, it can lead to misunderstandings and delays in the project. Ensuring the BRD is comprehensive and accurate to minimize these risks is important.

10. Conclusion

Even considering the most conservative estimates, the percentage of failed IT projects is still staggering.

A recent article published on financesonline.com states that 22% of all IT projects surveyed did not reach their goals, while 12% were deemed failures.

Of the various reasons given, “inaccurate requirement gathering” made it to third place, with 35% citing it as one of the reasons behind the failure of their projects.

Other equally consequential reasons could have some element of stakeholder mismanagement inferred:

Poorly defined opportunities and risks, 29%
Poor communication, 29%
Inadequate sponsor support, 26%

Hence, substantial gains can be made simply by improving the requirement gathering, definition, documentation, and validation processes.

Operational Excellence is predicated on the flawless execution of every SDLC stage, starting with requirement definition. We hope that you find this article valuable in that regard.

Principles of Operational Excellence in Software Development

11. References

Environmental Scanning–The Impact of the Stakeholder Concept — Aubrey Mendelow
Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts — Ronald K. Mitchell, Bradley R. Agle, and Donna J. Wood
A great lecture on Requirement Definition (geared for Systems Engineering) can be found on the MIT Open Couse YouTube channel.