When you create a product from scratch, Requirements Gathering is a critical stage that no one likes. This is because both the executors from the customer’s side and the developers have to think about a large number of issues while facing a ton of work ahead of them. At the same time, it is necessary to somehow start collecting the required information and validate it with stakeholders, who usually are not active participants in the process but must confirm that the solutions proposed to them are acceptable.
To understand why there is so much controversy about which approach to gathering requirements to choose, we should look at a rough list of questions that need answers to get a product vision and move forward:
That’s quite a lot, isn’t it?
That is why Business Requirements and Functional Requirements are critical to the product’s success, the budget and time spent on its development, and the quality of its technical implementation. After all, this information collected during the Project Discovery stage, serves as the basis for forming all technical requirements.
That is why there are several approaches to dealing with it faster, easier, and more effectively.
We have long been convinced from our experience that everything depends on the volume of the product and its business logic, budget and deadline.
Warning! When the budget is limited, the deadline is actually not of decisive importance. Therefore, you should choose an approach that prevents the preparation and validation of requirements before the start of product programming to minimize the costs of changes and revisions.
How do you know what’s right for your product?
When and for what scope of work are the requirements prepared?
Although we should note that often tight development timelines can be a wrong reason for choosing extreme programming or agile methodologies. The argument is that there is an urgent need to develop an early product version to demonstrate to potential clients or investors as soon as possible.
However, if the budget limit is still there, there is something one must remember. Requirements that are hastily collected for a part of the product and not validated through the prism of a holistic vision of the complete functionality ALWAYS entail overspending. For numerous changes and revisions in the future and delay the launch of the product as well. At the same time, the funds spent on such changes and modifications can be safely regarded as wasted.
Comparison of budget, timeline: qualities of the same product with different approaches.
However, no matter how accurately the Requirements are explored and set during Project Discovery, still in the process of software development, teams and customers face Clarifications to requirements, their Expansion, Change, and, as a result, revisions. The development team engaged in programming process does not like all this at all, and the customers do not like the bills for their implementation. However, experience shows that it is necessary to be guided by what primarily limits the Customer and properly accept the consequences.
Comparison of scope of changes, revisions, refactoring and architecture changes.
Of course, the domain expertise that the team possesses and the availability of relevant experiences also play an essential role in the quality of requirements gathering and the number of subsequent changes and revisions. As well as the participation and involvement of the customer in this process. Therefore, the best result is always at the intersection of all the aforementioned factors.
Have a good choice!