Waiting for Non-Functional Requirements?
Waiting for non-functional requirements often turns out to be similar to waiting for Godot. They never turn up!
Attaining functional requirements from business departments can be quite challenging, but acquiring non-functional requirements can sometimes seem impossible. So, how can Quality Assurance Engineers handle this tricky situation? Should missing requirements be ignored? Can cross- browser testing be overlooked, load tests be neglected and performance tests be disregarded? The simple answer is no! Just because requirements are not documented, does not mean they do not exist. Obviously, requirements that are not clearly defined, cannot be verified. Nevertheless, the resulting product would most likely not pass validation successfully. So, how can these equally essential requirements be unearthed?
Often, non-functional requirements are implied rather than be explicitly expressed. But experience, and asking the right questions, will unveil the desired requirements.
Example
Imagine going to a car dealer. You might have wishes, aka requirements, regarding the exterior colour, the sound system and whether it has an automatic gearbox or not. But will you tell the car salesman that you want to travel at 100 miles per hour with three passengers? Most likely not, because you expect the car to be able to do that. Let’s call it an “expected standard”.
Let’s transfer the vehicle example to a website. The website’s owner will expect it to be “fast enough”. To be more precise, the owner will expect a potential user of the website to browse the site easily without delays in any chosen browser. Furthermore, they will expect not only for that to hold true for one user, but for multiple concurrent users too. All these requirements are implicit expectations that linger in the air and need to be captured — to be made explicit.
Three ways to handle implicit expectations
One way to make them explicit is by asking the right questions. An important part of requirements engineering is to ask relevant questions that will lead to obtaining the actual requirements. If this was not done whilst scoping a project, it can be done on a smaller scale during the refinement meetings, prior to a sprint. Finding the right questions to ask is either a matter of experience or of studied knowledge. Seasoned Quality Assurance Engineers will never forget to ask about load and performance due mostly to painful experience with missing requirements. Equally, there are enough books, webinars and lectures on non-functional requirements that can help raise awareness and from which the right set of questions can be learned. Coming back to the vehicle example, the car dealer will most likely know to ask how many passengers you will be traveling with and how fast you wish to travel.
Side note: If you don’t want to rely blindly on a team’s experience to make sure that potential non-functional requirements are considered, mention them in the Definition of Ready. This way they will be considered on story level and find their way into the acceptance criteria.
An alternative possibility is to follow de facto industry standards. Generally a website is not a new invention. There are many out there that can provide data from which to derive requirements. For example, by using statistics of similar websites, the distribution of browsers and browser versions can be obtained. Furthermore, response times of “fast” websites can be measured and set as a standard to be met. The expected number of concurrent users can be tricky, but by making assumptions on the expected usage, in combination with extrapolation, a solid basis can be defined. In the vehicle example the dealer would assume that you will be traveling with the statistical average of 3 passengers and will want to be able to travel at the maximum legal speed of 70 miles per hour.
A further possibility is to work with hypotheses that are expected to result in desired behaviour and consecutively measure their success. For example, if you are unsure how fast a website should load, you can ask yourself what result you actually want to achieve. In this case you can define success as losing a maximum of 0.5 % of users while a page is still loading. To achieve this the hypothesis is made that a page load time of 1 second will not lead to a bounce rate above 0.5 %. This “load time <= 1s“ is a clear requirement that can be implemented and tested accordingly. Once in production, the actual bounce rate is measured. If the desired rate is not achieved, the load time must be reduced accordingly and measured again in production. This is a typical example of the agile method of “inspect and adapt”, helping if the initial picture is not clear. This approach is not applicable to the vehicle example, as you would most likely not be happy to exchange your car for a different model after a short time once you notice it is not fast enough!
Wrap up
Should non-functional requirements be ignored if not available? Definitely not! User experience massively depends on the above mentioned criteria and will impact the success of most businesses. Don’t wait for them! Instead, obtain them by asking the right questions, generate them by using de facto industry standards, or make assumptions in combination with clear success criteria to satisfy them.
