A business analyst uses various methods to identify and document requirements based on the specifics of the project, the composition of stakeholders, and the desired outcomes. Methods include interviews, workshops, observation, questionnaires, documentation analysis, prototyping, and data analysis. The choice of method depends on factors such as the complexity of requirements, availability of experts and stakeholders, maturity of business processes, and time budgets.
Requirement documentation is done using formalized (SRS, BRD, User Stories) and informal (mind maps, diagrams, sketches) tools. It is important to ensure clarity, completeness, traceability, and relevance of requirements at all stages of the project. The business analyst selects the format based on the target audience, ease of maintenance, and specifics of the product.
Key features:
Which method of requirements gathering is always suitable for IT projects?
No method is universal. For example, interviews are helpful in some cases, while questionnaires or documentation analysis are more effective in a large distributed team. It all depends on the situation.
Can one rely only on user stories for all kinds of requirements?
No, user stories are good for agile projects, but for complex IT systems, technical specifications, non-functional requirements, and other formats are essential.
Should a business analyst document only the collected wishes of the client?
No, an analyst must identify hidden and conflicting requirements, analyze business needs, and justify the feasibility of implementing certain functions.
Negative case: The analyst gathered requirements exclusively through a questionnaire without discussing details with the team and the client. As a result, many requirements turned out to be irrelevant. Pros: Quickly gathered the requirements base, Cons: Requirements became outdated, critical tasks and nuances were not identified.
Positive case: The analyst used a combination of workshops, interviews, and prototyping, ensuring validation of requirements from both technical and business perspectives. Pros: Accurate and agreed-upon requirements, quick adjustments during the project. Cons: More resources and time were needed for synchronization.