5 of the worst requirements I have ever seen

Writing requirements is one of the most important aspects of product development since so many team members will depend on these lists to carry out their jobs properly.

It follows therefore, that requirements writing should be of high quality indeed, and that poor documentation will negatively impact the team’s performance.

In this article, I take a look at the five worst requirements that I’ve come across during my years of experience.

#1 – “The system must have good usability”

This one gets me every time.

Of course, a system should have good usability! Every tester and developer knows that. But to whom does it have to ‘feel good’ to? Describe the user group(s) and the knowledge expected from them.

A common theme in this list of cringe-inducing requirements is their vagueness and lack of objective criteria. Examples of measurable criteria are the time to complete a specified action. A better way to express this requirement is: “A customer service rep should be able to enter 3 issues in less than 15 minutes”. This is highly measurable.

Another way to get usability measurable is to set standards. If there is a documented company standard, you can state that the system should be built according to the standard. Of course a standard stating that the OK button should be placed to the right of the Cancel button does not automatically mean that the system gets high usability, and the only way to really know if the system is ok is to perform usability tests.

#2 – “Response time should be less than 2 seconds”

Fair enough, we all want our software to be blazingly fast. But under which conditions exactly are you expecting a two-second response time?

Is this figure taking into consideration natural variances in the response time of the system, and does it refer to a particular functionality of the product or does the PO expect a two-second response time across the board, even for critical parts of the system?

This type of requirement is doubly devious because it is cleverly disguised by the inclusion of an objective amount which gives it the appearance of legitimacy. But probe a little bit deeper and the requirement breaks down under the weight of its absurdity.

Any measurement should be given in a particular context. For example, the search functionality, or saving a new customer to the database. You also must state under what circumstances it should be measured, for example on a standardized desktop within the firewall or via ADSL on a slower computer. Also consider natural variances in the system, for instance, on salary payment day many banks are overloaded. Do you have variances on other dates, for instance upon beginning of a new month or new year?

#3 – “Round-the-clock availability”

Say what? You mean 24/7/365 support? And who’ll foot the bill exactly?

Neglecting the time, money and energy costs that go in the development and testing of the client’s requirements is a serious mistake that leads to certain disaster.

In these cases, the team has to take on the role of advisor and gently make the client aware of any obvious problems in their requirements. In some situations 24/7/365 is a reasonable requirement, for instance when it comes to internet banks. Often however this requirement is too costly to be considered realistic.

You will either have to understand if this requirement is truly that important or reach a compromise with the stakeholder. Reaching a compromise on the stakeholder’s original demands and ‘optimising’ (a useful phrase to use during negotiation!) their requirements to fit the project’s scope and budget better will save the team a lot of hassle in the long run.

#4 – The system shall work just like the previous system but on platform X

This is a classic mistake. What is usually meant is “but don’t implement ‘these features’ since we do not use them anymore.” And “we trust you also take into account all the undocumented complaints that we have had over the years about some of the features that we hate.”

When rebuilding a system with other techniques, you must do proper requirements management again, since needs have changed. A new platform also comes with pros and cons, which have to be considered. Features that worked in one way earlier will not work exactly the same way when the platform is changed.

One cheaper solution is to create a quick prototype of the system using the new technology.

Perform workshops and behavioural studies on real users to find out the gaps between the prototype and the final product. This is also a good way to elaborate on new features and possibly constrains that come with the new platform.

#5 – The system has to be bug-free

This shows an immature way of looking at quality assurance and involvement from both customer and supplier. You have to establish a proper change management process and a testing process that involves both parties with clear responsibilities early on.

Other things that often have to be discussed in immature projects are documentation, help system, and end-user training.

In conclusion

The effects of poorly written requirements are far-reaching and wide-ranging.

It costs time and money to get a team to focus all its efforts on developing a product and the requirements give the members the bearings they need to go through the process with a clear image of the end-result in mind.

Their importance cannot be underestimated in the developing process since they provide the script with which team members base their performances and work together to produce software worth using.