Ultimately business analysts will need to create or facilitate a list of requirements, all of which revolve around the future state. All of the steps outlined in The Knowledge Brief™ allow us to ensure that we meet these quality requirements. In this blog post, we discuss what business and stakeholder requirements are, why stories matter and the basics of capturing requirements. Due to the volume of information to be shared around requirements, we will cover solution requirements in part 8 of The Knowledge Brief.
Toward the end of the post you can download your free copy of a requirements template from our library. There is a lot to cover when it comes to requirements and we will have to create additional posts but for now lets get going...
What are business requirements?
A Business Requirement is a high-level statement describing what is required from the business’s perspective. It relates to a representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed. They also provide the scope of a business need or problem that needs to be addressed through a specific activity or project.
How can you tell if it is a quality business requirement? Ask yourself:
- Can roles in the business use/learn this capability when it is done?
- Will this requirement meet a need in the long term even when the project is complete?
- Can we measure its impact and performance within the organisation?
- Will this requirement become part of a process?
- Is the business requirement short, sharp and explicit?
Examples of business requirements
- Business Requirements define WHAT the business is trying to achieve (Build a home)
- In turn, Business Requirements define WHY a project should be undertaken or a solution implemented (We have started this project so that we can replace the home that was burnt down therefore we building a new home)
- Business Requirements define the metrics that will be used to measure success (by 2018)
- Business Requirements are at the enterprise level and do not define requirements that are specific to any particular group of stakeholders within the organization
Standard business requirements check list
You can rely on having a typical check list of what type of business requirements every project may need. This is important because sometimes in the midst of the requirements development, some obvious areas are ignored like policies and reporting. It is therefore important to have a check list to ensure a broad set of potential requirements:
- Communications
- Competition
- Customers
- Data
- External Factors
- Financial
- People
- Process
- Regulations/Policies
- Reporting
- Safety
- Security
- Suppliers
- Technology
It is beneficial to categorise these in order to trace the requirement and the associated user story. I recommend that you use a simple format such as BR1.1, BR14.2, or BR14.3 if you don't have a tool that does this already. If you don't have a specific requirements tool, a spreadsheet will assist you in managing this. Only the requirement category, along with the ID and number of events, would be listed in the Knowledge Brief. A status icon could also be included. After all, the Knowledge Brief is meant to be (as the name implies) brief, so the details are a separate artefact for the implementation team.
Why stories matter
In this video by Darrell O'Donnell, he says that if you hear the phrase "better requirements," take a step back and stop. You're getting mixed messages. You do need better requirements, but most consultants will gladly assist you in "deriving better requirements," which is probably the wrong thing to do. We don't think in terms of requirements by default.
BUT - we are all natural storytellers, and our brains are wired to think in terms of stories. When we hear stories, we can't help but imagine ourselves as characters in them.
So, let's begin with Stories....This approach is equally applicable to blockchain and Self-Sovereign Identity projects.
How do you know if you have a quality stakeholder requirement?
As discussed in the previous video, stories are a way in which to start a conversation around what is required, i.e. a requirement. A stakeholder requirement describes the needs of a specific stakeholder or group of stakeholders that must be met in order for the business requirements to be met. They act as a link (bridge) between business requirements and various types of solution requirements.
There are several ways in which to capture stakeholder requirements but typically for companies using an agile approach user stories are used.
- Who?
- What?
- Why?
Note: If the User Story includes a “how”, it is a Functional and/or Non-function Requirements and should be categorized accordingly.
How can you tell if it is a quality stakeholder requirement? Ask yourself:
- Is the user requirement directly related to the business requirement (ie it doesn’t fall outside the requirement but rather is an expansion/explanation of the details required)
- Is the user supposed to add a requirement at all? If so, to what business requirement measure?
- Does the requirement follow the Who, What, Why principle?
- What role do they play? Do they make decisions? Where do they fit in the RACI?
- Are all stakeholders in agreement the requirements state?
- Have the users been validated?
How do you ensure quality of requirements?
Even though the needs of the stakeholder who will use the requirements or designs are what determine quality in the end, we still have to write our requirements using a quality standard and this means writing them in a way anyone can understand what they mean:
- Atomic: independent of other requirements or designs and easy to understand on its own.
- Completed: with enough information to guide future work and enough detail to allow work to continue. The level of completeness that is needed depends on the point in the life cycle where the requirement is being looked at or shown and how it is being looked at.
- Consistent: in line with what the stakeholders have said they need and not in conflict with other requirements.
- Concise: contains no extraneous and unnecessary content. • Feasible: Reasonable and possible within the agreed-upon risk, schedule, and budget, or thought to be possible enough to study further through experiments or prototypes.
- Clear: the requirement must be written in a way that makes it clear if a solution meets the associated need or not.
- Testable: It can be checked to see if the requirement or plan has been met. Depending on how abstract the requirement or design is, there are different ways to check that it has been met.
- Prioritized: ranked, grouped, or negotiated based on how important and valuable it is compared to all other needs.
- Understandable: it uses words and phrases that the audience already knows.
How to capture requirements
In this video by The Agile Business Analyst he discusses a simple way of capturing and tracing requirements using an excel spreadsheet. This technique describes how to manage requirements, as well as how to engineer and structure them. There are several different approaches to capturing and managing requirements and several tools available. I have provided a spreadsheet that we recommend that is similar to this one but allows the mapping of the high-level requirements into part 7 of The Knowledge Brief while breaking down into the depth of the requirements, click here.
To download your free copy of a requirements template similar to the one described in this video, click here
Key Learnings
- Ultimately business analysts will need to create or facilitate a list of requirements, all of which revolve around the future state.
- All of the previous steps from 1 - 6 outlined in The Knowledge Brief™ allow us to ensure that we meet quality requirements.
- In this blog post we discuss what business and stakeholder requirements are, why stories matter and the basics of capturing requirements.
- Is the business requirement short, sharp and explicit?
- If you don't have a specific requirements tool, a spreadsheet will assist you in managing this.
- Only the requirement category, along with the ID and number of events, should be listed in part 7 of The Knowledge Brief.
- A stakeholder requirement is a subset of a business requirement and describes the needs of a specific stakeholder or group of stakeholders that must be met in order for the business requirements to be met.
Summary
In this post we discussed what business requirements are, how they are captured, what makes a quality requirements and some tips on what they look like. If we use the case of an investigative journalist, here we understand how the case has come together and how all the parts relate. Thus, requirements are essentially the evidence related to what we have been investigating all this time.
To find out more about solution requirements check out part 8 of The Knowledge Brief.
Post sponsored by Agora Insights Ltd
References:
The Knowledge Brief™ is a product of Agora Insights Ltd. All rights are reserved
Post a Comment