The Perils of Ignoring Implicit Requirements

The following is based on a true story. Details have been altered to protect anonymity.

A national retail company recently rolled out a major software upgrade, impacting its back end software systems, web site, financial reporting, and several mobile apps. The requirements were captured by means of focus groups, surveys, comments, and other means. The requirements were prioritized, discussed, carefully documented, designed, implemented, and numerous test cases were designed to confirm compliance with the requirements. Most would probably agree that everything stated so far is a recipe for success. But read on.

The company in question rolled out a mobile app that initially took more than 30 seconds to load basic customer account data. Once the account data finally loaded, customers discovered them to be outdated by several days—and in some cases, wrong. The additional server load attributable to users attempting to download account data cascaded to the company’s web site, which became unresponsive during several daylight hours on one particular weekend. Additionally, the public-facing aspects of the system turned out to be confusing to customers, leading customers to visit their nearby retail locations to ask questions that employees had no idea how to answer. Most of the problems still existed to some extent even weeks after the initial rollout.

So how could all of this happen? Some might expect a highly technical answer, most likely involving an error made by one or more software engineers. However, the disastrous rollout was surprisingly not an error. Rather, it was an omission: nobody ever took into account implicit requirements.

Implicit requirements can be characterized as non-verbalized customer expectations. That is, expectations that customers have of your company’s software, but do not communicate explicitly. In many cases, the requirements are not communicated because neither stakeholders nor software engineers ever thought to ask them. Examples of implicit requirements include the following:

• Mobile app must load account information in 4 seconds or less.
• If the account information doesn’t load within that time, I will assume a failure occurred and try to reload the data by pressing the refresh button.
• Purchases should show up in my account immediately, not the next day.
• I should understand how the app works without instructions.
• If your application doesn’t work the way I think it should, I’m going to visit your retail location to ask questions.

Seem obvious? We all know that sluggish behavior and unresponsive software is unacceptable with or without implicit requirements. In this particular case, the demand for data from a particular server (exacerbated by an unresponsive mobile app) cascaded into a web site failure because the web site depended on the same overloaded servers as the mobile app. Assuming failures were occurring, customers kept pressing the refresh button which further compounded the problem. Had the team designed the back end software to withstand the data load arising from the above requirements, the cascading failure might have been avoided.

The reality of ignoring implicit requirements is this: requirements that are never captured in the first place, no matter how obvious they may seem, will not be considered during software design or implementation and will have no benchmark against which compliance can be later verified. In the above scenario, nobody load tested the database server because there existed no data transfer speed requirement requiring such a measurement. Nobody thought to design the system to feed real-time data because nobody understood that customers would expect it. Nobody thought about usability and how a confusing mobile application could adversely impact other parts of the business.

Next time you plan your next rollout, make sure to ask your customers the questions that they didn’t think to answer themselves. Make sure you gather implicit requirements.

Prolifogy is a national software consulting and development firm consisting of industry-leading Ph.D. software practitioners and researchers. To see how Prolifogy can help your organization avoid the scenario described above and many others, contact us at (855)-PROLIFOGY or contact us through our web site.

Note: Prolifogy was not a service provider to the company above while the events described above were unfolding.