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.
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.
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.
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.
2. Business Requirements
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.
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.
The quality of the requirements and their definitions can be divided into two levels:
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:
All of the issues presented above can be managed and controlled with the proper procedures:
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.
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.
4. Types of Requirements
Six types of requirements can be defined:
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:
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:
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.
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.
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:
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:
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.
- 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.