Finding the accurate composition of Technical and Business Requirements for the perfect Product Symphony
The usual expectations from an application development is to simply solve the needs of the business. While we collect and solve the business problems, we tend to miss the technical requirements that are needed to help the application engine running. Overdoing the technical requirement can sometimes impact delivering the business requirements as much as under-doing it. Some of the most important questions to ask are:
· How should the composition of business requirements be balanced with the technical/non-functional requirements?
· How should we prioritise between Technical and Business requirements?
· Should we implement the technical requirement first making the foundation ready?
The answers to the above questions, and the methodology used to arrive at those answers, will drive us towards finding El-Dorado of opportunities that exist when technical and business requirements have the right balance.
The need to find the balance
Most of the cases, we tend to follow the simple Venn diagram approach. Have the list of Business Requirements along with the Technical Requirements, find the overlap — That’s what we have all done at least once or may even be still doing it!
Is this as simple as this looks? Can we take the priorities of both the requirements and just implement both of them?
Some of the Technical / Non-Functional Requirements that need to be considered:
· Scalability
· Reliability
· Availability
· Recoverability
· Security
· Performance
· Supportability
· Operability
The priorities of these depend on the business requirements as such. Mapping the technology based on business capabilities is important. A quick case maybe for scalability as a priority requirement when the business is looking at scaling volume or an unprecedent surge of users.
NFR — The unsung hero
By now, most of us would have realized that NFRs are the cogs in the business wheel of requirements. They have bigger impact though might appear trivial. When focusing on the key requirements, it is easy to not give enough importance to the supporting requirements like NFR — But, remember the success of a product depends on how the NFRs are visualized and implemented.
When designing an application, if the load based on the number of concurrent users is not considered — the application may not perform well. The right technical composition along with the business requirements would help the application to perform and scale. While considering the requirements to implement — It is important to consider the application scale strategy to ensure that the NFR requirements are prioritized and planned at the right levels.
If one of the prime requirement is for the application to serve the customers at all time — High Availability shall be of primary focus. The architecture needs to have the redundancy built into it to ensure that the failure doesn’t impact operations. Availability zones along with the auto scaling capabilities are also to be considered as the key principles while designing an HA architecture.
The approach
The suggested approach is the ‘sliding window on hour glass’ model. The hour glass represents the Business and Technical requirements prioritized based product strategy and vision. The first phase of any implementation would be a soft launch or a pilot implementation to learn and measure the success criteria along with improvement pointers.
During this time, based on the strategy slide the window as represented in the figure to implement the set of business and technical requirements.
The above representation is based on an assumed business strategy where the application is meant to be implemented in phases for continuous feedback.
We can notice the difference in distribution of the window across the requirements. This mainly depends on the strategy. As per the above model, the first phase is in an meant to be used for obtaining the feedback on the user reaction and the system. This demands that the foundational requirements are in place. Thus, The ‘discover’ phase covers the most crucial business requirements supported by the basic technical foundations needed to run the application. The second phase, ‘explore’ phase, is more of an investigative technique to test the application in a possible scaled model — The Technical requirements that enable scalability and performance are to be focused more than the next priority of business requirements and hence the window is more spread on the Technical requirements.
The third phase is where the application is implemented at large scale. This is the full blown model of the application with most of the business and technical requirements covered.
This model helps us in understanding the market’s reaction to the product at a smaller scale while making an informed decision about the technical aspect of it based on strategy and vision of the application
Conclusion
It is important for the application to heed to the business requirements. However, it is equally important that the necessary Non-functional requirements are covered when the application is rolled out in phases. The right technical composure in the implementation of the business capabilities heavily rely on the Business strategy and the real definition of the phased implementation approach. The ideal mantra for the application, to be able to serve the business needs, is to have the technical requirements and the functional requirements have a well-balanced composition that can be implemented in sync at the right time (phase)
