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 process 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 that 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. Stakeholder Analysis and Management
- 5. Business Requirement Challenges
- 6. Types of Requirements
- 7. Business Requirements Document (BRD)
- 8. Conclusion
- 9. References
- 10. Featured Articles
3. Business Requirements
By definition, a collection of business requirements determines a projects’ 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 will have to 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. Examples of design parameters can be 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 till 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.
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 agreement between stakeholders.
- In the Analysis phase, it 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 for an accurate estimation of effort and cost, adequate planning, budgeting, and efficient resource allocation
- When the code is ready for release, the Testing and QA 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. Stakeholder Analysis and Management
4.1 Why Bother?
To understand Stakeholder Analysis and its relevance to this discussion, we will start by looking at a paper published in 1981 by A. L. Mendelow and titled Environmental Scanning–The Impact of the Stakeholder Concept.
In this study, Mendelow proposes a model for managing stakeholder needs, but before going any further, let’s look at what a stakeholder is.
The definition of the term stakeholder was put forward by Ian Mitroff and Richard Mason in their publication A Logic for Strategic Management in 1980:
[…] those who depend on the organization for the realization of some of their goals, and in turn, the organization depends on them in some way for the full realization of its goals.
A list of an organization’s stakeholders can look like this:
- Regulatory bodies
The relationship between the different stakeholders and the organization (aside from the competitors) is mutual benefit. For example, suppliers can provide raw materials in return for money. On the other hand, competitors are competing with the organization for market share as well as its stakeholder contribution.
It is essential to understand that stakeholders usually possess some resources that the organization needs and their ability to refrain from supplying those resources gives them power over the organization. Power can also step from the ability to dictate alternatives or indirect influence.
This non-trivial distribution of power in a group is what makes the problem of complex social groups and their interactions interesting.
Stakeholder management becomes vital because of their power over the organization and subsequent ability to cause unwanted damage. Their requirements need to be considered in the decision-making processes or whenever a new project that might impact them is scheduled for implementation.
Project implementations are all about satisfying the stakeholder’s requirements, but what if these requirements conflict? Conflicts can arise due to restricted budgets, confined schedules, and scarce resources.
When gathering business requirements, it is essential to consider all relevant stakeholders, weigh their needs, and balance the risks.
The need to incorporate stakeholder requirements does not necessarily mean all stakeholders for efficiency reasons. To assist in screening the key stakeholders, Mendelow proposes the following model.
4.2 Mendelow’s Power-Interest Matrix
The model proposed by Aubrey Mendelow consists of four steps:
- Step 1: Identify the organization’s stakeholders by asking, “who are the people or groups that can influence the organization’s progress and success”?
- Step 2: Rate their power over the organization. Mendelow recognizes four sources of power: “possession of resources, ability to dictate alternatives, authority, and influence”. These four sources indicate how much power an individual or group has.
- Step 3: Rate the interest of each stakeholder in the outcome of the project. The sources of this interest can be emotional, financial, or value-centric. Interest can also arise if the project’s development results in a redistribution of power or creates/destroys opportunities.
- Step 4: Create an action plan as follows:
- Naturally, individuals wielding power compounded with high interest need close monitoring and engagement. Their specific requirements should be prioritized.
- Keep the powerful individuals with low interest in the project satisfied.
- Individuals interested but not powerful enough to obstruct your progress can be kept in the loop and duly informed.
- Finally, those with no interest or power can be passively monitored but would not need to be involved.
4.3 Requirement Gathering and Stakeholder Management
Based on the above, the following can be recommended:
- When preparing the requirements of a new project, ensure that the correct stakeholders have been identified and their needs or concerns duly noted.
- Requirement conflicts must be addressed. Mendelow’s power/interest matrix can be used as well as other tools.
- Stakeholder management can be an ongoing process for the duration of the project. For example, project managers regularly communicate progress to management, clients, and other departments within the organization.
5. Business Requirement Challenges
5.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, integration problems or technical infeasibility of some features 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. It typically happens when stakeholders 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.
5.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 and 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 high-level solution does not cover key design decisions, such as the technologies to be used, as these would primarily come during the low-level solution design phase.
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 that includes, for example, high availability and replication to a different geographical location. These two requirements are solution-agnostic as there might be various ways for satisfying them.
Assuming you decided that a relational database is the 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 then need to make further decisions regarding deployment methods, license size, hardware procurement, and support options.
These are business decisions that necessarily involve the client, the project manager, the procurement and supplier management departments.
Hence, your low-level persistence requirements could not be defined before settling on a specific mechanism.
5.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 level of requirement clarity. The trade-off is a high cost-of-change.
Agile, in contrast, acknowledges the fallibility of this approach in light of the inherent challenges in obtaining complete visibility on 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.
6. 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 component of the system, 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 on functional requirements. For example, “the online transaction processing 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.
7. Business Requirements Document (BRD)
Various formats allow the storage and management of technical documentation. Some are simple, like MS Word, 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 relatively 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 by 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 in the MIT Open Couse YouTube channel.