5 more horrible requirements

After publishing a post about the five worst requirements I’ve ever seen a while back, I received a great amount of feedback from fellow testers who wanted to share their own experiences with spine-chilling requirements over the years.

This outpour of feedback and the way the blog post seemed to resonate with many testers inspired me to write a sequel to the original post, where I take a look at five more horrible requirements that are frequently inflicted on testers.

 #1 “Reporting”

Crunching through complex data and returning actionable insights, preferably with plenty of snazzy visualisations that highlight trends and patterns in a system, is one of the most important functions of a software no matter in which industry it is implemented.

Which explains why everyone requesting new software for their business comes up to you asking for the ability to “create reports”.

Like most of the bad requirements we already tackled in our previous article, the problem here isn’t what’s being requested but rather what’s being omitted from the requested. There is no indication of how exhaustive a report should be, which metrics should be included in it and who is authorised to generate and read them.

#2 “Accessibility”

The last point leads us neatly to our second nightmare of a requirement. Accessibility can be wide or restricted, but in each case a clear profile of the type of users that will be allowed to interact with the system is needed in order to write relevant test cases for the scenarios likely to be encountered.

Moreover, accessibility doesn’t necessarily exist in a binary yes/no state. Even as the doors as flung wide open for a everyone to interact with the system, some people may have certain privileges that others don’t have. This graduated accessibility is tightly linked with the roles played by different classes of users, which in turn affects the actions they are authorised to carry out.

#3 “X cannot change”

Expanding on the idea of different levels privileges available for different users leads me to consider another howler that sends teams in a fit of despair.

Whenever clients come up to you insisting that certain aspects of the system cannot change, your prompt rebuttal should be along the lines of: “Who cannot change X?”.

More often than not, you’ll discover that their original request was actually a shorthand for the fact that certain users cannot change certain aspects of the system without permission from a supervisor or other users with high-level credentials.

#4 “Easy to use”

This tendency for clients to use shorthand language when communicating requirements really point out the main cause of horrible requirements actually existing at all.

I’m in totally agreement with those testers who have explained on a variety of internet fora that poor requirements are actually miscommunicated requirements. Our job then is to help bring clarity and practical relevance to what our clients tell us by probing intelligently the reasons behind their statements.

Making software “easy to use” is a common requirement that requires expanding upon to implement it in practice. What makes a software easy according to the client? Is it having a short training time for end-users to master the finished product? How important is this for the client and the company they represent?

These questions all help shed light on the relevant priority of a requirement, which otherwise would be just another of those standard requests you get all the time.

#5 “Robust”

Finally, rounding up our list of five more horrible requirements, is this gem of a statement.

Again, the problem here isn’t the requirement per se. Robust software is indeed a very desirable thing to have, but there is no quantitative element in that statement to align the tester’s perception with the client’s desired outcome.

Translating robustness into the metrics that are generally used to give an indication of this quality is a quick and simple way to beef up the information provided by the client. In this case, inquiring about the target time to restart after failure, for example, helps anchor the software with the client’s practical needs.

In conclusion

I find the image below hilariously sums up the state of communication between the parties involved in software development and testing.

We all have a part to play to improve communication within teams and with clients.

As mentioned above, we should be willing to take up the responsibility of helping our clients define more properly their software requirements and tease out the information the team needs to produce quality software that delivers on the client’s wishes.

Read the original post ‘5 of the word requirements I have ever seen’ here: https://reqtest.com/requirements-blog/5-of-the-worst-requirements-i-have-ever-seen/