The process of gathering and analyzing requirements is a systematic identification, organization, and documentation of the business needs of the client for subsequent implementation in IT systems or business processes. The main stages are:
Identifying sources of requirements: interviews with clients, working groups, analysis of documentation and current processes.
Gathering requirements: using technical sessions (workshops), surveys, observations, prototyping. It is important to ensure the involvement of all stakeholders.
Analysis and categorization: identifying contradictions, duplicate tasks, classifying requirements into business/functionality/non-functional.
Documentation: formalization in the form of SRS (Specification Requirement Specification), user stories, or scenarios.
Validation and approval: conducting reviews with the client, making adjustments, approving the final version of the requirements.
Key features:
Deep understanding of business processes is necessary for the correct interpretation of the client's wishes.
Constant communication: requirements gathering is an iterative process that involves changes throughout the project.
Requirements artifacts (diagrams, models, specifications) are critically important for the further work of the team.
Can you limit yourself to only one type of requirement (for example, business or functional)?
No, a business analyst must cover all types of requirements: business, user, functional, and non-functional. Otherwise, you risk getting a product that does not meet the expectations of all stakeholders.
Is it always enough to conduct only one requirements gathering session?
No, in practice, there are many requirements that are clarified gradually, iteratively. Usually, multiple sessions are held to gather and agree on everything correctly.
Can approved requirements be changed without formal procedures?
No, any changes must go through change management processes, otherwise chaos, discrepancies, and misunderstandings between teams will arise.
When developing an analytical module for a bank, only one workshop was held at the outset. It later turned out that the functionality did not take into account the requirements of the information security service, and significant product revisions had to be made, wasting time and budget.