Business Requirements: An Essential Guide to Definition and Application in IT Projects
1. What Are Business Requirements?
Business requirements describe the changes that must be implemented in specific business areas to enhance product or service production and improve the organisation’s value proposition. More specifically, a business requirement defines the technology adopted, the integration methods applied between the users and the systems, and how this integration will impact user experience.
The agenda for this series of articles is the following:
2. Where Do Business Requirements Come From?
The quote below is from Professor Murray Gell-Mann’s brilliant book “The Quark and the Jaguar – Adventures in the Simple and the Complex”, which describes the interplay between technology and medicine, a vital field of human science.
The experts can be consulted again, of course, and the internal model [of the computer program aiding the doctors’ diagnosis of hospital patients] redesigned to take account of the successes and failures of the computer diagnoses. In that case, the extended system consisting of the computer, the model designers, and the experts can be regarded as a complex adaptive system, an artificial one “with humans in the loop”.
— Murray Gell-Mann, The Quark and the Jaguar – Adventures in the Simple and the Complex
Technology has entered most human endeavours, with experts disagreeing on how much of it is good vs bad. However, most will agree that technology will continue to be perfected while businesses strive to integrate it into their production processes.
Imagine you are running a business in an environment with plenty of competition. To survive, you use technology to enhance your offering or become more efficient in producing it. You might also use technology to create a business need that was never there in the first place. These integration requirements broadly define your business requirements.
Soon enough, your competitors will leverage those same technologies, just as you did, to improve their products or deliveries. Now, you must find newer ways or better technology just to stay in the game. This dance between business and technology is a recurring pattern familiar to most, especially in software.
The cycle between one innovation and the next, one version of the product and its successor, looks something like this:
This article will examine the business requirements creation processes from definition to gathering, documentation, review, validation, and acceptance. We also explain the purpose and methods of stakeholder analysis and management.
By the end of this article, we hope you will better understand the subtle concepts behind creating, documenting, and handling adequate business requirements.
3. Business Requirements in Software Engineering
In various industries, including IT and manufacturing, “business requirements” refer to a comprehensive set of specifications and functionalities that a system or product must possess to meet the objectives and needs of a business.
These requirements are a foundation for designing, developing, and implementing solutions to address specific business challenges or opportunities. The definition of business requirements can vary slightly across industries, but the fundamental concept remains the same. Let’s see how business requirements can differ for two critical industries: Information Technology and manufacturing.
4. Business Requirements Development
Developing business requirements typically involves collaboration between business analysts, stakeholders, and subject matter experts, regardless of the industry. This collaboration aims to capture the business’s specific needs, constraints, and expectations, providing a clear roadmap for the subsequent development or production phases.
It is important to note that effective communication and documentation of business requirements are crucial for project success. Ambiguous or incomplete requirements can lead to misunderstandings, delays, and suboptimal outcomes.
To alleviate the risk of developing incorrect business requirements, businesses often employ standardized methodologies and documentation formats, such as use cases, user stories, or requirement specifications, to ensure clarity and precision in conveying business requirements to the relevant teams.
4. Business in the Digital Age
4.1 Complex IT Solutions for Highly Sophisticated Businesses
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 most prominent banks offered services on ATM or POS machines. Today, we live almost exclusively in cashless societies that exist on electronic fund transfers (EFT), where an average consumer can pay 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.
4.2 Project Failure and Unclear 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.
— 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.
4.3 Kano’s Model of Customer Satisfaction
In the customer satisfaction model proposed by Noriaki Kano, there are three levels of customer requirements.
5. Defining Business Requirements
In the remainder of this article, we will discuss business requirements specifically in the context of IT solutions; otherwise, the ideas will be a bit vaguer than they need to be.
5.1 Business Requirements and Solution Design
A collection of business requirements determines a project’s goals and constraints, feeding into the solution design. You will undoubtedly remember seeing the words shall and should in a business requirements document (BRD).
In IT specifications, the words shall and should have a special meaning. 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.
We must remember that 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:
5.2 Business Requirements Quality
The quality of the requirements and their definitions can be divided into two levels:
6. Business Requirement Challenges
6.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:
6.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 quickly 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 critical 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.
6.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.
7. Types of Requirements
Six types of requirements can be defined:
8. FAQs
9. 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:
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.
10. 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.