Requirements are not necessarily required

In the grand tradition of being difficult, I'm rediscovering an antipattern that has killed projects in the past. I'll call it "too specific requirements".

The symptoms are stacks and reams of requirements that you MUST implement, even if there are better ways to solve the apparent problem. Case in point: We have a rock solid requirement to build a user preference management screen. Unfortunately, most of the preferences we need to collect are (IMHO) better collected and maintained in situ.

As an example, one requirement is to "enable the user to select their default payment method". Of the hundreds of possible solutions, the requirement implies that we should have a special screen where users can find this option, select it, then never see it again when checking out their items.

This sounds great on paper, but I'm struck by the notion that a user would EVER know or think to go to some other screen (preferences? My Profile? not sure what to call it) to save their default payment type. In addition, the extra problem is now that we've hidden their payment type, how will they know how to select a new payment type?

A better way (unproven as yet) might be to collect this option WHILE they are checking out and selecting it. This way, instead of conducting extensive user training for our "stupid users", we can make it more natural.

Comments

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image