To describe our future state, we must develop solution requirements and designs based on the knowledge gained in previous sections of The Knowledge Brief™. Continuing from Part 6 of The Knowledge Brief™, we will broaden our understanding the future state, develop process design with user requirements, and construct solution requirements, which are typically classified as functional and non-functional. To get the most out of this post, you should probably start with Parts 6 and 7.
- The Knowledge Brief™ (Part 6): Current State Analysis
- The Knowledge Brief™ (Part 7): Capturing Business Requirements
Let's get started.
What are solution requirements?
Solution requirements are a level of (appropriate) detail that developers need to build a solution that meets business needs. In part 7 of The Knowledge Brief™, we discussed both business and stakeholder requirements. These spell out what the business needs in terms that everyone can understand. Looking at our BACCM, we see that business analysts also look at the solution, and solution requirements are all about the "details". Implementation Subject Matter Experts (ISMEs), or the people who are in charge of building, buying, assembling, or configuring solution architecture need to know what the solution needs to do, what data it will deal with, and what qualities it needs to have to meet the business needs. In other words, they need functional and non-functional requirements that are so detailed that most subject matter experts can only give them when asked and shown how.
What is the difference between function and non-functional requirements?
In this excellent video provided by Altexsoft, the author provides great visuals and explainers of the differences between functional and non-functional requirements. Do check out their YouTube channel https://www.youtube.com/watch?v=fc-5HJPBZMQ&t=35s
It is ultimately your responsibility as a business analyst to understand the specific needs of a project and translate them into clear and concise requirements. But what are the distinctions between functional and non-functional requirements? Functional requirements are those that are specific to the tasks that a system or application must be able to perform. To put it another way, they describe what the system should do. Non-functional requirements, on the other hand, address broader issues such as performance, security, scalability, and so on. They describe how the system should perform rather than what it should do.
It is critical to remember that both types of requirements are equally important in ensuring a project's success. Business analysts are often so focused on the functional aspects that they overlook the non-functional ones. However, if even one of these critical areas is overlooked, it can have a negative impact on the overall quality of the final product. So, the next time you work on a project, make sure to give equal weight to functional and non-functional requirements.
Examples of functional requirements
A functional requirement defines a business need or objective that a project must achieve. It is typically expressed as a business function or process. For example, "The system shall allow the user to login from multiple devices." Functional requirements are often used in conjunction with non-functional requirements, which define system-level attributes such as performance, security, and scalability.
Examples of non-functional requirement.
Most times non-function requirements are about the experience and quality required in a solution. One common type of non-functional requirement is called a performance requirement. Performance requirements define how well a solution must perform in order to meet the needs of the business. They can include things such as response time, throughput, and capacity. Another common type of non-functional requirement is security. Security requirements define the measures that must be in place to protect the data and systems of the organization. They can include things such as firewalls, authentication, and encryption.
Making decisions and prioritising
Although stakeholders may feel differently, not all requirements are the same. As much as we would like to have everything delivered in our project, we know that, in reality, this is highly unlikely to occur. All requirements are valued, but in order to deliver the greatest and most immediate business benefits, they must be prioritised.
The plain English meaning of the prioritisation categories is useful for helping customers understand the impact of setting a priority versus alternatives such as High, Medium, and Low. One of the ways in which we can begin to understand what is or isn't important is to use a MoSCoW technique.
In this video, Sierra Newell from ProductPlan does a great job of explaining the MoSCoW method.
MoSCoW's 4 step analysis is a way to figure out what you need for your solution. You start with the things you must have, then the things you should have, and then the things you could have. Finally, you think about the things you will have.
MoSCoW 4 step analysis stands for:
- Must have: These are the requirements that are absolutely essential for the solution. If they are not met, the solution will not be effective.
- Should have: These are the requirements that are important for the solution, but can be sacrificed if necessary.
- Could have: These are the requirements that are not essential for the solution, but would be nice to have.
- Will have: These are the requirements that may or may not be met, but will definitely be considered if possible.
An example of a "should have" requirement would be "the system should be able to handle a high volume of requests." This is not essential for the solution, but it would be nice to have if possible.
An example of a "could have" requirement would be "the system could include a search feature." This is not essential for the solution, but it would be nice to have if possible.
An example of a "must have" requirement would be "the system must allow the user to enter a new customer record." This is essential for the solution, and if it is not met, the solution will not be effective.
An example of a "will have" requirement would be "the system will be able to store customer data in a secure manner." This is not essential for the solution, but it will definitely be considered if possible.
What approaches to consider when designing the future state?
For decision makers tasked with developing and approving the future state, there are a number of different tools and techniques that can be employed.
- One popular approach is decision tree modelling and analysis, which helps to identify the optimal decision in a given situation by taking into account all of the relevant factors.
- Functional decomposition is another useful tool, which involves breaking down a process into its component parts in order to better understand how it works.
- Process modelling is also often used in order to improve existing processes or design new ones; this technique involves creating a graphical representation of a process in order to better understand its flow.
- Finally, prototyping can be used to quickly create a version of a proposed new process in order to test it out and gather feedback.
In this short video on decision trees, Dr Jennie Mitchell shows you the basic layout for a decision tree and how to calculate the probability of the decisions. So although we won't ever truely understand what the future state might be, we can make assumptions that are based on reasonably predictions and history.
Why getting your processes right matters
Many business analysts use process diagrams to help design the future state of a change project. The business analyst then uses this information to communicate the benefits of the change project to key stakeholders. A business analyst can use the BPMN diagram to develop a plan for implementing the change project. This plan can include specifying who will be responsible for each task, what resources will be required, and how long each task will take to complete. By using process diagrams, business analysts can effectively design the future state of a change project and ensure that it is successfully implemented.
Using this example provide by Lucid Chart, I have modified the BPMN model provided by Ludic Chart, to show the future state. These are the modifications
- Color code your steps to identify something that might assist in the change project. These could be risks, priorities, business rules, or requirements themselves. This is also a good opportunity to identify MoSCoW options. There is no hard rule around colour coding; rather, it is a tool to help simplify your steps.
- Include the requirement associated with the ID in these steps. THIS IS EXTREMELY IMPORTANT.When doing user stories, this will help you solidify who is related to the requirement.
- Although the jury is still out on this one, I think it is reasonable to include your systems in the process diagram when designing the future state. It is reasonable to think that most requirements these days will be system-related in some way.
- Don't forget business rules.
- Your requirement ID should be traceable to the business requirement as well as the solution requirement. Lucid Chart and other systems allow you to include a data sheet where you can provide additional information. A simple spreadsheet works too.
- There are so many options, so brainstorm with your team to decide the best way to visualise the future state.
Conclusion
In order to create a successful future state for your business, it’s important to understand what the requirements are for getting there. And quality requirements are essential in meeting the future state goals. By using solution requirements, you can develop a clear vision of the future and identify the steps needed to get there. The tools and techniques we’ve shared can help make this process easier and more effective. With careful planning and execution, you can use this approach to achieve great results for your company. What future state will you create for your business?
Happy learning
Post sponsored by Agora Insights Ltd
Post a Comment