In the world of technology, we have been arguing about the term “requirements” since the dawn of the computer age. Every business analyst, project manager, and software developer has their own view of requirements.
Some of us love them, some of us hate them. Some of us think they are the very heart and soul of a project, while others think they are the bane of software development. But at a very basic level, a requirement is simply any statement that places limits on the software solution that satisfies the business needs.
A major challenge is that the level of detail varies widely depending on the source. Asking a business owner or high-level executive for their requirements is different than asking someone in the trenches who will interact directly with the solution or asking the person who must build the product or application.
When creating a digital solution, you are working with three distinct groups of people:
- First are the C-level executives and sponsors who care about the project and want it to succeed.
- Then there are the stakeholders who have the authority to influence any product under development including those who will use the product when it is released.
- Finally, there are the tech providers who will build it; for them, details about your business needs and goals help them create a better product.
To address the needs of all three groups effectively, the IIBA® (International Institute of Business Analysis™) has defined three levels of Requirements:
- Business Requirements
- Stakeholder Requirements
- Solution Requirements
Let’s look at each level.
Business Requirements Are the Outcome of Strategic Business Analysis
Historically (e.g., in a Waterfall approach) Strategic Business Analysis was the preliminary work preceding a project or initiative.
The purpose of Strategic Business Analysis was to clearly define the scope and goal of proposed IT projects. If the initial feasibility analysis determined that the project was unlikely to deliver a positive outcome for the organizations, it was canceled. If the outcome was to approve the project, Strategic Business Analysis delivered high-level business requirements.
As per the IIBA® definition, “Business Requirements” define an outcome that would benefit the organization as a whole or a specific subset.
Whether you call it “Strategic Business Analysis” or not and whether you create “Business Requirements” or not, someone must decide whether to solve a particular problem or take advantage of an opportunity.
Decision makers at this level of detail are typically senior executives or owners of the organization. At this lofty level, the software development method (SDM) has limited impact on the decision-making process.
An example of a Business Requirement for a startup marketing company could be:
By the end of 2022, we will increase our market share by 25% through aggressive use of social media.
This structure specifies:
- WHAT the organization wants to achieve (increase market share by 25%)
- WHEN they want to achieve it (by the end of 2022)
- HOW they expect to achieve it (through aggressive use of social media)
Notice that both the goal (WHAT) and the timeframe (WHEN) are expressed in measurable terms.
A good guide for writing business requirements is the SMART acronym. It stands for Specific, Measurable, Achievable, Relevant, and Time-bound. Business requirements are primarily used by management to decide if they are willing to invest resources to achieve the desired outcome.
Agile Business Analysis: Getting and Writing Lean Requirements
Learn at your own pace: Business Analysis techniques for discovering, writing, and analyzing Business and Stakeholder Requirements, User Stories, Features, and Gherkin Given-When-Then Acceptance Criteria and tests.
What Are Stakeholder Requirements?
The next level of requirements according to IIBA® is Stakeholder Requirements. Stakeholder Requirements express a feature, function, fact, or behavior that would benefit a subset of people within the organization.
A stakeholder is either an individual, a group, or an organizational unit (e.g., department, division, etc.) that will be affected by or has the authority to affect the proposed software product. They may be inside or outside the organization sponsoring the initiative or project.
A good Stakeholder Requirement Example would be:
Airline passengers can view available seats to select their preference once the ticket is paid.
This Stakeholder Requirement specifies who the beneficiary is (passenger), what the stakeholder wants to do (view available seats), the business value for the stakeholder (select preference), and a limiting condition (ticket is paid).
It tells developers who wants what, why they want it, and under what circumstances the request will be satisfied. Those are great key criteria for any stakeholder requirement.
Find Out Our Approach to Getting Business and Stakeholder Requirements!
Our online course: How to Facilitate Agile Meetings and User Story Workshops teaches the skills needed to facilitate live or virtual group discussions and JAD Sessions to elicit and analyze requirements, user stories, and features.
Solution Requirements: Developers Need Functional and Non-Functional Requirements
Business and Stakeholder Requirements are essential, but they are not enough. If software developers and other members of the technical team want to create a program that works as intended, they need more detail—the kind of detail the International Institute of Business Analysis (IIBA®) calls Solution Requirements, which are divided into two subtypes – Functional and Non-functional Requirements.
Functional Requirements (FR)
Functional Requirements describe what the product, app or a user needs to do or know.
That means, they describe:
- functions the software will perform (ideally expressed in active-verb-direct-object format, e.g., “Reserve Seat”) OR
- data the function needs (Available Seats) or produces (Reserved Seat).
Here is a Functional Requirement Example:
Calculate the total cost including delivery charges and taxes.
It states that the product or application must be able to perform a function (DO something) that calculates the total charges (data) and taxes (data) on an invoice (data).
Non-Functional Requirements (NFR)
A Non-functional Requirement (NFR) describes expectations on the HOW well the functions are performed. These provide the developers with information such as how often the function will be used in a specific time frame (up to 1000/day), how quickly the function must react (the average response time must be less than 3 seconds), etc. NFRs are typically expressed as complete sentences and related to relevant Functional, Stakeholder, or Business Requirements.
Functional and Non-functional Requirements Can Make or Break Your Project
The Challenge with Solution Requirements
Solution requirements are the level of detail that most developers need to start coding. In traditional (e.g., Waterfall) development environments, all three levels of detail (Business, Stakeholder, and Solution Requirements) are created for the entire project before a line of code is written. That allows for a reasonably accurate estimate of the overall effort required to deliver the solution.
However, coding and testing the entire digital solution can take months. Due to changing business needs, evolving technology, or business environments, many of the requested features are no longer a priority when they are delivered.
Post-mortem evaluations of millions of IT projects show that the majority of the originally defined features is never delivered. The work of eliciting, capturing, clarifying, and creating the requirements defining those features represent significant but unnecessary waste.
Lean and agile software development philosophies and agile business analysis techniques originated to address that specific problem.
Are User Stories Stakeholder Requirements?
Most of the wasted effort on traditional requirements was caused by the process of translating stakeholder requirements into solution requirements.
User Stories are an alternative mode for expressing business needs of individuals that reduce or ideally eliminate that waste. Whereas the word “requirement” suggests something that is an absolute need, the User Story is by definition “… a reminder for a conversation between a developer and a user …”.
That definition implies that a User Story is subject to interpretation. The Functional and Non-Functional Solution Requirements (documented or not) are the result of that conversation.
To eliminate the wasted effort of clarifying requirements that are never implemented, the conversation takes place immediately prior to the developer starting to code.
User Stories express something the business community MIGHT want assuming IT can deliver it in a reasonable timeframe. The emphasis, however, is on simplicity. The User Story just expresses what one role in the business community needs from IT.
There is so much more to be said about User Stories! If you want to know more, I have written extensively about them in my post “The Everything User Story Guide: Tips and Tricks for Writing Better Requirements“.
Last Thoughts
The bottom line is you should do whatever makes your project and your team successful. Sometimes that will mean using Agile User Stories; sometimes that will mean using Traditional/Waterfall Requirements; sometimes it will mean mixing and matching the best of both worlds. The key is figuring out what works best with your team and your project.
- Where do your products or projects fall?
- Which method do you like best, and why?
Please share your comments, suggestions, insights, rebuttals, and thoughts in the comments.
