The complexity of business requirements in IT projects has experienced exponential growth due to pressures by 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, weblinks, 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 the 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.
There are, of course, numerous other reasons that 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.
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. Table of Contents
- 1. Overview
- 2. Table of Contents
- 3. Business Requirements
- 4. Business Requirement Challenges
- 5. Types of Requirements
- 6. Business Requirements Document (BRD)
- 7. Conclusion
- 8. References
- 9. Featured Articles
3. 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 denotes 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 essentially 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 infinity, 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.
- During the project kick-off phase, the BRD provides a solid base for agreement between stakeholders.
- The Analysis phase allows for the reduction of rework, a significant source of project risk, and poor quality deliveries by providing the input to the solution design phase. It also permits accurate cost and effort estimation, adequate planning, budgeting, and efficient resource allocation.
- When the code is ready for release, the verification and validation phase kicks in, in which case 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.
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.
4. Business Requirement Challenges
4.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 where solutions have been tried and tested.
- 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
- Conflicting requirements can be eliminated by proper stakeholder management techniques.
4.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 the low-level requirements.
You typically have high-level requirements from which solution architects would create a high-level solution design at project inception.
The design choices you make will require further input from the stakeholders, and a constant dialogue has to 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.
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 you decided that a relational database is a way to go, you now 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.
4.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 any implementation to achieve the desired requirement clarity. 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 both Agile and Waterfall are not perfect, and project suitability should be assessed before adopting one or the other. In most cases, a Hybrid model will do just fine unless you have the ability to implement DevOps, which is the best we have today.
5. Types of Requirements
Six types of requirements can be defined:
- Functional: 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: 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 it will be deployed on.
- Non-functional requirements: these are covered by the ISO 25010 software quality standard, such as compatibility, reliability, and security.
6. Business Requirements Document (BRD)
Various formats allow the storage and management of technical documentation. Some are simple, like MS Word, and others 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 is a must 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
Even if we consider the most conservative estimates, the percentage of IT projects that fail 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.
- 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.