In a dynamic world, in which business objectives change along the domain trends and based on the ever varying consumer's interest, the mutual understanding of the requirements by those that formulate them and by those who implement them represents the key to succeed in software development projects.
Especially when developing products on multiple sites, condition which becomes more and more common amongst business companies, along with the globalization, not just regarding the customer base but also concerning the development of the product and the teams that deal with these activities, which also spread on different continents and cultures, it is of most importance to correctly understand and quantify the product requirements and product solution based upon the first.
Misunderstanding, misinterpreting product requirements causing erroneous implementations and forcing projects to derail, exceeding costs and discovering defects too late in the process, leads too many times to unnecessary and pricy functionalities that too few use for those to justify their cost.
As a solution to misunderstood or badly communicated requirements stands the shaking hands method which brings not a definitive answer but a way towards improving the formulation and communication of the product requirements and the offering of viable solutions to fulfill them. The method can also be described as a sign of, hand over or validation of the requirements/solution. Many of us do this all the time, at each meeting with our stakeholders or clients, but it becomes obvious in bigger projects with higher business priority that those methods are imperative for being able to benefit from effective solutions, for increasing the customer base and for proactivity on the market. In short, it becomes essential to shake hands upon the solutions proposed for fulfilling the product requirements between those who formulate the requirements and those that accomplish them.
There are artefacts that facilitate the shaking hands method like the proof of concept (POC), prototyping and design, descriptive documents of APIs (Application Programing Interface), UML models, architectural diagrams, etc. I will describe below a few of those that I have used in the projects I have worked on, along with the benefits they bring in the communication between the clients, stakeholders, product managers, product owners, business analysts and architects, tech leads, delivery managers, implementation team, SCRUM teams.
The POC or Proof of Concept represents a demonstration having the scope to verify that certain concepts or theories are applicable in the real world. Another terminology used is that of a "proof of principle". A POC in developing software products describes distinct processes with different objectives and different participants, may also offer partial solutions based on a smaller number of users acting in business roles for establishing if a system satisfies specific product requirements. Therefore, the main objective of a POC is to find solutions to technical challenges, like the way in which systems can be integrated or like obtaining data (which result from determined processes) by using certain configurations.
A few years ago, I was working for an outsourcing software business; a pretty big client of this company was in need of a complex piece of functionality which required more development teams and many months of work. To ensure the fact that we had correctly understood the requirements, we decided to start a POC with the client's agreement. It was a success, the client saw a prototype of the solution which would accomplish their goals; we discovered gaps in the requirements, that would have been exposed otherwise too late in the development process, we even changed the client's opinion on certain requirements and gave up altogether others. The proof of concept helped with the communication between us and our client, us being the ones implementing the solution. We felt owners of the proposed Solution having the client's full agreement.
"Prototyping and design" symbolizes the creation of interactive interfaces which present functionalities in a visual way. This is an artefact often used in the online world but also in representing any physical or virtual product without actually needing to build it. Axure, for example, is a software application used to prototype and Adobe Photoshop is one used for design. There are many similar apps available on the market, but regardless of the tools used, the importance of creating prototypes and designs sits within their visual impact. People perceive better what they can see with their own eyes, they seem to better understand when they have in front of them a model with which they can interact. It is the same with clients or stakeholders, they react much better to an interactive interface which allows them to understand and visualize what will become the product in which they are investing. For the projects I currently work on and where there is an actual need of a visual representation, it is common practice to use prototyping to exemplify and ask the stakeholder's opinion in regards to product decisions. As a Product Owner, I use this artefact as often as I can to obtain a better understanding of the solution that will be implemented, so as for the stakeholders of those projects to benefit from what they really need and for them to always keep track of the product improvement proposals (in this case I refer to the Betfair site as a product).
Fig. 1 Prototyping
Many other methods can be selected to facilitate the shaking of hands upon solutions that will implement the product as per requirements. By using them, we can ensure a healthier and smoother transition from requirements to the end product, passing through all refinement processes, from transmitting those and finally implementing and testing the product. When requirements are uniformly understood and the implementing solution is universally accepted amongst the parties involved, only then there can be assurance in a product that accomplishes all real needs and satisfies them by a spot on implementation.
by Ovidiu Deac
by Radu Butnaru
by Daniel Donea
