How do you know what a system is supposed to do and what it is not supposed to do? Formal requirements are intended to create an easily validated, maintainable and comprehensive set of documents communicating the system’s planned functional scope in terms of tasks and behaviours.
It is well understood that a higher quality product demands a higher upfront investment. However, compromises regarding quality versus cost are made every day and tight project budgets and short timelines often greatly reduce the interest in formalized documentation, requirements or otherwise.
“The communication of functional requirements and specifications is the most difficult, critical, and error-prone task in IT projects. Research has shown that projects that proceed to the construction and coding phase with missing or wrong functional requirements and specifications are almost certain to fail.” – Bill Walton, A Systematic Approach for More Effective Communication of Functional Requirements and Specifications.
In the fast-paced changing world of software development there is a continuous challenge to communicate the expectations for the system and its internally and externally facing behaviours. Formal, documented requirements often suffer because of the challenges of keeping up with short iterative project life-cycles, continually evolving product scope and customer demands, and uncertain or changing screens and interfaces.
Without clearly stated requirements, testing, specifically, is unable to perform its job of both verifying that the system was implemented correctly and validating that the correct system was implemented.
A balanced approach that maximizes the contribution of the organization’s available resources within the project constraints is required. The following proven light-weight solution tailored to your timeframes and resource realities can allow testing to, in the absence of complete formal requirements, capture critical information about the system without slowing development. The resulting artifacts can also serve as a direct input into testing activities.
