How to think about Requirements resolution process!!!

In preparation for my presentation at Dreamforce’22, I was reviewing some articles that I have set aside for reference and as ideas for professional changes and improvements.
And one thing always catches my attention.
Requirements resolution process.
It seems simple and complex at the same time, and it is. I would like to share some points of how I do to use this process in a more productive way.

1- Analysis Phase
simplify the request in the best understandable way, separating it into blocks of information. Many times we receive a request that seems like a book, but to better understand and make our brain start thinking in a more logical way about what we are about to do the division into blocks of information helps to start the process of thinking about what is being asked.

2- Solution Thinking
After this initial analysis and its divisions, we will already have a clearer idea of what we will be working on and our brain is already thinking about how to solve this demand. In this phase we will put the probable solutions for this demand, regardless of their complexity or form of execution, the important thing is to have these solutions listed.

3- Finding the best possible solution
Already with all the thought process and reasoning of the solution for the demand, we will have a fundamental step that is the separation of the solutions and the choice of the best one for that request.
It must be simple, efficient, easy to maintain, and acceptable in terms of the architecture standards followed for development. Remembering that each company has its own standards and ways of working with developments in Clouds and Salesforce Applications.
– simple, what is the easiest way to solve this request? code, flow, formula? we should focus on the practical part of the solution.
– efficient, not always the most complex, just as simple sometimes is not. Here we must think not only about solving the request, but also about the overall medium to long term flow of your action.
– sustainable, what will happen to it if some demand for change comes or some new process is implemented similar to it? can it be adapted or reused? how much effort will we have to change it or adapt it?
– is it the best choice to follow? is this the result I expect or better than what they expect? here the phase of communicating what will be done is primordial, because for us it is the best way to follow but for those who requested it, maybe not due to the result that will be presented in the end.

4- Development phases
after finding the best solution we must think about the steps for its modeling and construction. my suggestion here would be to start at the end asking the question “to reach my final result what would be the previous step until the final result”. this question must be answered until the arrival of the initial phase, so we’ll go more smoothly to the next step.

5- Mapping the steps and elements in the development
With the answers on how to execute each step of the development now we will put on paper each element to execute this step. This is usually where we will invest more time to find out how to perform the action needed at this stage.

6- Assembling and Testing
here is the most fun part of the process, putting everything together and testing…. assembling will be easy but testing will be the “cat’s eye”. mentally we are prepared to execute the ideal test for our solution and the test will be the correct or rather the desirable way to go in the end. But the error tests, most of the time, we don’t execute them as we should. And here comes the mapping of the negative factor, the one of how not to do or execute the process.

7- Implementing
Here we are usually divided into stages of implementation and several times executed by other teams or people. In this phase we put together our package, change set or whatever name you have in the company you work for. But the important thing is to put all the elements you used to create the solution so that it can be implemented in the higher environments until it is implemented in production.

Simple huh!!! On paper yes, but in real life we know that it is not always flowers and our path is more painful and complicated.
But I sincerely hope that this article will make your life or path smoother.
Remember that the developer may be a future architect. Why not think like one right away? Who will gain the most from this is you.