During the initial phase of solution development, the creative process is ignited and the ideas that will turn the Business Requirements into a real technical solution for the client are set in motion. In this process, the phase of translating the Business Requirements into Technical Requirements is decisive to ensure that the final solution meets the expectations for which it was created. And it is not only about meeting those expectations, but about doing it as efficiently and simply as possible, according to the technology available for its execution. In this article, I will describe some steps that, based on my experience as a Presales Engineer and as a Business Analyst, I consider necessary to translate the Business Requirements into Technical Requirements and produce documentation that can be used effectively by the technical team who will create the solution.
The Difference Between Business Requirements And Technical Requirements
The difference between Business Requirements and Technical Requirements can be difficult to establish, and the reason is simple: there is not always a clear line dividing these types of requirements. Ultimately, the goal of the Business Analyst is to end up with a document that is detailed enough to serve as the basis for the technical design and development of the final solution.
Here are some definitions for these types of requirements that I consider valid:
Business Requirements: establish expected goals and results of the solution to be implemented. It is an overview of the changes required by stakeholders and why they are important to optimize the current business processes.
Technical Requirements: it is a detailed representation of the changes and the expected results of a solution. Technical requirements describe the solution’s capabilities and qualities and provide a sufficient level of detail to start with its design and development.
Steps To Translate Business Requirements Into Technical Requirements
The steps necessary to define the Technical Requirements may vary depending on multiple factors such as type of the solution required, the industry the client belongs to, the technology or platforms available to develop the solution, and the knowledgeability of the stakeholders involved in the project, among others.
Despite these variables, the steps presented below are not the only ones, but they are relevant when creating the Technical Requirements and can serve as an effective framework from which to start.
Know the client’s business and its industry
Take the time to research the client’s business. Know their customers (whether internal or external), their market, and their competitors.
Knowing the industry jargon, at least in general, will give you an advantage when you need to have conversations with the client. You will understand more easily and quickly the information provided by the client about their requirements and business processes.
Identify internal and external stakeholders
Determine who will be involved with the solution, whether by defining the requirements, working on its operation and maintenance, or as end users, among other things.
It is important to define the roles and to know what kind of information each one can provide. This applies to both internal parties within your organization and customer stakeholders.
Prepare for the information gathering phase
The previous two steps (knowing the client’s business and identifying stakeholders) help you prepare for the information gathering phase.
Based on who the stakeholders are, it is convenient to schedule different sessions to identify their needs according to their roles.
Before meeting with the client, do research internally in your organization about previous projects that could be related to the new solution. Even if the new solution is independent of any previous projects, it is a good idea to talk to the internal personnel who can provide information about the client and their processes.
Beforehand, create a list of possible questions that will allow you to dig deeper into stakeholders’ expectations. Organize the questions according to the different roles. For example, talking to the end-user is not the same as talking to IT staff or senior executives.
Seek to know the “deeper why” of the required solution. For example, a customer statement such as “We want to automate the billing process and that the sales executives can see invoice information easily”, may have implications that are not explicit in that statement and, as Business Analysts, we must ask the right questions to get the level of detail we need. For example:
“What is the current process for handling orders and billing? What steps do you want to automate?”
“How does the fact that billing is not automated affect current processes?”
“What would be the ideal place to put the billing information so that it is easily accessible to the sales executive?”
“Is the order system integrated with the CRM platform used for managing the accounts and sales opportunities? Should the solution include some form of integration between these two technologies? “
Analyze and Investigate
Once you have obtained the client’s requirements, it is time to analyze them deeply and conduct a more exhaustive investigation. In addition to fully understanding the requirements, you should know the characteristics of the technology that will be used to develop the solution and whether any limitations prevent it from meeting expectations.
Analyze the different use cases where the solution will be applied and contrast how end users will use the solution according to their role.
Define the solution scope and review it with the client
It is important to set expectations about the scope of the solution from the early stages of the project. This will avoid confusion and customer disappointment due to unfulfilled expectations.
Depending on your organization’s processes, the scope of the solution may be defined (at least roughly) during the presale phase. However, it is always a good idea to review and keep an eye on the scope to maintain the financial health of the project and visualize possible additional sales.
Structure and organize the requirements
There are different methods for structuring and organizing the requirements. These are some strategies that can support you at this stage.
Sort the requirements into categories
Depending on the type of project, you can define different categories for the requirements. Some criteria to categorize the requirements are:
• Determine which requirements are mandatory, which are nice to have, which are excluded, and which can be added at a later stage of the project.
• Organize requirements based on the type of technical work involved. Some requirements may be related to data work (for example, data cleaning); others involve integration between different platforms; others refer to the visualization or user interface to present the information.
• Another way to categorize requirements is based on the new capabilities or features that will be implemented in the solution.
These criteria that I mentioned as examples are not mutually exclusive; rather, they can be combined depending on the solution you are working on.
Create Diagrams/Process Flows
Diagrams or process flows are my preferred way to present business processes. Diagrams allow you to graphically visualize what is often difficult to express in words and, above all, depending on the level of detail, allow complex concepts to be easily explained to different types of audiences.
There are two types of diagrams that I recommend making:
Current state: this diagram represents the different parts of the current processes that you want to modify and that will be impacted by the new solution.
Future state: represents what the steps or parts of the process will be after the new solution is implemented.
These diagrams are not only useful for representing business processes but can be extended to various types of processes and requirements.
Prioritize requirements
Establish the order in which the requirements must be executed. Some criteria for determining priority are:
- Dependence on other requirements
- Urgency
- Perceived value
- Impact on the business process
- Cost
- Sensitivity to delivery time
Align requirements with the features of the technology to be used
Creating the Technical Requirements implies understanding the Business Requirements as well as the capabilities of the technology or platform that will be used to develop the solution.
Depending on the structure of the organization where you work, the Business Analyst may not know all the technical details of the technology or platform to be used. Therefore, having internal sessions with personnel who are technology experts is essential to achieving a good definition of the technical requirements and making sure that they are based on what is really possible.
It is also advisable to have an open mind to look for possible ways to solve any impasse or limitation. The purpose is that the solution to be developed meets the customer’s requirements, and this involves thinking about the different possibilities to achieve that goal.
Evaluate your strategy
Present your strategy to different areas of your organization involved with the project and the client and ask for their feedback. Before formally presenting the Technical Requirements to the client, it is important that the internal stakeholders of your organization know and validate the result of your analysis and that no important requirements for the client have been left out. It is extra time that reduces the risk of having uncomfortable moments with the client due to unforeseen requirements.
Select the format to present the Technical Requirements
Choose the format to present the Technical Requirements. Depending on the audience, you may need to create different formats to make the presentation, even schedule different sessions to present to different audiences, using the appropriate level of technical language for each case. Remember that the main objective is for everyone to understand and be clear about the technical requirements that will be covered by the solution.
Be flexible (but keep in mind the agreed scope)
Once the Technical Requirements have been defined and agreed upon by all interested parties, it is important to know that these requirements are not set in stone. That is, throughout the project, certain requirements may vary and must be adjusted. This is part of the Requirements Life Cycle Management and it is common in many projects that the requirements vary during their development.
The important thing in these cases is to evaluate what changes can or should be included in the development of the current solution and manage the changes in the scope according to the processes established by your organization.
Conclusion
The deeper your understanding of the business requirements, the business processes involved, and the technologies selected to develop the solution, the easier it will be for you to translate Business Requirements into Technical Requirements. I don’t think there is a static path to complete this task. Each type of project will take you to explore different avenues, and the experience will definitely sharpen this skill.
