.png)
4 types of requirements you will use on all projects
- Igor' Arkhipov
- May 15, 2020
- 5 min read
As an analyst, it is your job to work with requirements. However, different people in the business will have very different expectations of what those requirements will look like. The reason for that, there is no such thing as a universal definition of a “requirement”. Instead, there are different levels of requirements a business analyst needs to work on to be effective.
According to the BABOK® Guide:
A requirement is a usable representation of a need.
Depending on the type of need and the audience for representation, you will get a different type of requirement.
Business level
On a high level, we are talking about business requirements. A business requirement, contrary to common misconception, is not a “requirement that comes from a non-IT stakeholder”. Instead, these represent the statements of goals, objectives, and outcomes that describe why a change is needed. In a broader sense, these form the justification for a business case and explain what is it the business as a whole expects from an initiative.
The business requirements can be described in terms of existing problems to be solved and opportunities to be addressed and will likely be associated with business KPIs. This will allow the business to make a decision whether a requirement has been fulfilled. If you have ever been involved in business case creation, this document is a great example of business requirements.
E.g. if you have an e-commerce solution, business requirements that you may encounter may look like:
Increase conversion rates from landing pages by 5%
Decrease cart abandonment rate by 10%
Increase average cart size by 2 items
Introduce a new delivery method
As you see, these do not talk about specific features or solutions, but rather focus on the business outcomes of your initiatives. As such, these requirements are likely to be managed outside of your delivery backlog in a separate registry with separate reporting to validate their implementation.
Stakeholders level
A business can be defined as an organised group of people with a particular purpose. Those people individually will be contributing to achieving the organisational goals (therefore satisfying the business requirements). At the same time, depending on their role in the business they may have very specific individual needs for the solution. Same is true for all the potential end users of the solution — they may have very different perspectives, come from different backgrounds, and express different needs.
Collectively, we call all these individuals stakeholders, their respective requirements — stakeholder requirements. User stories for example is a typical way to capture the stakeholder level requirements, as they explicitly state who the stakeholder is, what their expectation is and why they need it.
For the e-commerce example, stakeholder lever requirements may look like this:
As a returning visitor, I want my cart retained so that I don’t need to reselect the items again
As a previous visitor, I want to receive a reminder that I have items in my cart so I don’t forget about them
As you see, these are much more immediately actionable than the business requirements and when implemented serve the need to achieve the business objectives at the same time solving immediate stakeholders’ problems.
Solution level
Once we understand the stakeholders’ needs, we can start designing the solutions. Solution requirements will describe the capabilities and qualities of a solution that meets the stakeholder requirements.
This level of requirements provides with the proper level of detail to enable the development and implementation of the solution. Basically, they describe what the solution is and how it is going to function. Therefore, solution requirements can be divided into two categories:
Functional. These will describe the solution in terms of the reaction of the solution to internal and external stimuli — the solution behaviour. Quite often functional requirements are captured as acceptance criteria for the user stories: what is the behaviour of the solution that will satisfy the stakeholder requirement.
Non-functional. These can be defined as requirements to quality or service level as they do not relate directly to the behaviour or functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
An example of a functional requirement can be:
Given that the user has items in the cartAnd their session is expiredWhen 2 hours pass since their last interaction on the websiteThen the system will send a reminder email to continue shopping
Functional requirements will most likely sit somewhere in your backlog next to related stakeholder requirements (or even be a part of the same ticket or story card).
Non-functional requirements are likely to be applied as a blanket rule to the solution and constrain all of the functional requirements in the backlog. Typically, non-functional requirements cover areas like:
Security: The need for access levels, approval workflows, password requirements, inactivity timeouts, encryption, complex authorization.
Audit: The need for preserving logs, what to save, for how long to store, where to store them.
Capacity: An expected number of concurrent users, the total number of users, expected number of concurrent operations, expected growth.
Availability: The hours of operation, criticality for business, allowance for maintenance time. Supported browsers and devices, responsiveness to the screen resolution.
Accessibility: The need to be accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.
Maintainability: A need for conformance to any of the standards (internal Enterprise architecture, code style, best practices)
Recoverability: The scope and frequencies for backups, the time allowance to get retrieved and restored from backups.
Performance: The response times — page load time, critical operations execution time
Documentation: The needs for user documentation, administration documentation, development documentation, and training.
Examples of non-functional requirements would be:
Comply with WCAG 2.1 AA level of accessibility
Handle up to 100 requests per minute with no delays in response
Migration level
When a new solution is implemented, there is always a period of time when the business adjusts to it and makes sure the old systems and process are decommissioned and smoothly replaced by the new ones. The requirements that arise from this migration are called transition requirements.
They describe the capabilities that the solution must have and the conditions the solution must meet to facilitate the transition from the current state to the future state, but which are not needed once the change is complete.
Unlike other requirements types, transition requirements have a temporary nature, that means they are no longer needed after the transition is complete and there is little room for reuse.
Transition requirements address topics such as:
data conversion and migration (read more about it here),
organisational change including training,
and maintaining business continuity.
Examples of transition requirements can be:
Migrate the user data from legacy systems to the new solution
Train the system users
Gradually release the new solution with constant monitoring to reduce the risk of downtime and critical defects on production environment
In conclusion
Regardless of which type of project you work on, you will have to deal with all 4 levels of requirements:
Business requirements to understand why the business is investing in the project and what the success looks like
Stakeholder requirements to understand what different stakeholders will want from the solution
Solution requirements to design how the solution is going to work
Transition requirements to help the business migrate into the new solution smoothly
Each type will come from different sources and will require different means to manage. Missing any one of them may result in issues with the project, so make sure you address them all!
References
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)
Comments