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:Business Requirements in Software Engineering Business Requirements: An Essential Guide to Definition and Application in IT Projects
Business Requirements Document (BRD) Business Requirements Document: 7 Easy Steps for Writing a Great BRD
Stakeholder Analysis and Management Overview of Stakeholder Analysis and Management Cost of Change Cost of Change — The Hidden Driver Behind Our Software Delivery ChoicesThe 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.
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.
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.
Agile Software Development — First Principles and Foundational ElementsThe 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.
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.
