Requirements Gathering
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:
For which business purposes is the product created
Which specific user needs does it need to solve
In which cases and scenarios do users and entities interact with each other, and which parameters and characteristics are required for that
How many types of users should be involved to ensure automation of user interaction at the level of all business processes
What new data is generated as a result of certain operations, and what will they be used for in the future
What permissions and capabilities should users have according to their type
How to optimize the script of single or multiple operations for user convenience
What entities should the product be endowed with
Which informers should the system issue at the appropriate steps so that the user understands what is happening and how long it will last or how it will end
What is each type of user persona, what is he used to, what is important to him, what can he expect from a new product, and what does he not want here
What checks should be applied to ensure the validity of all calculations and results
What characteristics and parameters should each entity have
How many functional units the resulting product should include
What data will the system operate on, and how many operations need to be performed
Other aspects complement spatial understanding of the product from the business requirements perspective
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.
Flexible Methodologies
PMI, 6th edition
Extreme Programming
We have long been convinced from our experience that everything depends on the volume of the product and its business logic, budget and deadline.
Product Types
A large product with 1+ years of development time and over 50 team members
A small-sized product with less than 0.5 years of development time and up to 25 people
A medium-sized product with 0.5 - 1 year of development time and up to 50 team members
A small-sized product with a few months of development time and up to 10 team members
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?
Flexible Methodologies
Step-by-step preparation of requirements, which involves gathering requirements for functionality planned for a sprint or iteration.
Extreme Programming
The ongoing negotiation of requirements, sometimes daily, for functionality under development and with little lead time.
PMI, 6th edition
Complete preparation and validation of business requirements before starting product programming.
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.
Extreme Programming
The most expensive, most protracted, and least amount of quality.
Flexible Methodologies
More expensive, more protracted, and produce less qualitative compared to RMI.
PMI, 6th edition
The cheapest, fastest, highest quality.
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.
Extreme Programming
The largest number of changes and modifications, refactoring, and architecture changes.
Flexible Methodologies
Lots of changes and revisions, refactoring, and architecture changes.
PMI, 6th edition
The least number of changes and 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!