Requirements analysis, also called requirements engineering, is the process of determining (as in understanding) user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications.
IEEE defines requirements analysis as,
- The process of studying user needs to arrive at a definition of a system, hardware or software requirements.
- The process of studying and refining system, hardware or software requirements. Requirements analysis helps to understand, interpret, classify, and organize the software requirements in order to assess the feasibility, completeness, and consistency of the requirements.
Why Requirements analysis is important?
“If requirement analysis is not completed properly or in a sluggish manner then there might be inconsistencies in the final product.”
It is during Requirements analysis phase that the foundation for all future stages is laid. If requirements are poorly elucidated, not detailed enough (or too detailed), or don’t match with what the business and/or its users want, then all the effective system architecture, elegant coding, and effective testing in the world will not yield a successful result.
Generally during requirement gathering, Client is not able to provide more details or not sure exactly what is required. Basic reason is, client comes from a non-technical background and not familiar with technical jargon’s so they find it difficult to share the exact expectations. This will cause a loop of rework in subsequent phases. Sometimes irregular communication between the engaged parties also lead to a possibility of disagreement in later phases. By the time development begins (i.e. post Sprint planning),
- Requirements should be clear, consistent and specific with no uncertainty
- Requirements should be complete, covering each and every aspect of the system under development.
- Requirements should be testable having some evaluation criteria for each requirement
Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements analysis and Software Testing
“Many bugs in a software are due to incomplete, inaccurate or ambiguous functional requirements”
Requirements analysis is an important aspect of software testing. On many traditional projects, this was devoted solely to Business Analysts, who worked closely with their clients to build out a framework onto which development could be executed. With an effective agile project, Quality Assurance engineers should also be part of this phase who can provide significant value. The software code, doesn’t matter how well it’s written, can’t do anything if there are ambiguities in requirements. It’s better to catch the requirement ambiguities and fix them in early development life cycle. It’s a fairly well established theory that the later in the software development life-cycle an issue is discovered, the more expensive it is to fix, and that most often, this cost growth curve is exponential rather than linear. So it’s important to have requirement analysis and catch these incorrect requirements before design specifications.
During Requirements analysis, test team studies the requirements from a testing point of view to identify the testable requirements. Requirements analysis involves frequent communication with various stakeholders (Client, Business Analyst, Technical Leads, and System Architects, etc.) to,
- Determine & understand specific feature expectations
- Detect and resolve conflicts that arise due to unclear and unspecified requirements
- If any clarification is needed on any particular functionality or any suggestions to implement the features or any logical issues, then raise a clarification against the requirement.
- Discover missing requirements (if there is any dependency)
- Clear all the assumptions made. Any requirement should not be based on assumptions.
- Understand the problem for which the software is to be developed
By including QA early, we can effectively shift left the cost of finding and fixing defects by identifying those issues before they’re defects – even before technical design is complete! By reviewing and commenting on requirements, they can bring all their experience in questioning and finding gaps in systems to bear on the requirements, identifying the issues before coding has even begun. This saves time and money, even if the relative rate of issue-detection is much lower than the rate during system testing.
But there is a Catch
Bringing QA into requirements analysis has to be carefully managed from a project and process standpoint. As a group, QA tends to be detail oriented and focused on making things right, and this can lead to feedback loops where QA gets caught in technical details and questions that get in the way of implementing a solution without bringing any additional value. These loops can be avoided, if the process is managed effectively.
The main advantage of requirement analysis is to make people aware of the possible detriment to the intended product brought about by any lack of clarity. Involving QA team in requirement analysis makes sure that every team member understands the requirements clearly in order to deliver a quality product. It shouldn’t be that tough of an argument 🙂