Implicit requirements

As a tester in a normal test situation, you test with a set of requirements. These requirements provide us information how to test the application and what is needed to do that. Do we than have all the requirements? No, we don’t.

The “requirments” we have are explicit. We know of their existence and where they can be found. Our customers and/or stakeholders provide us only with these requirements in the form of documents. This information tells us, how the application is designed. Does it?

As a software tester we need to understand “how the application is designed?”, to know the application properly and to make the application work in a very efficient manner by identifying risks. A good tester will make use exploratory tests as an approach to identify those risks.

Some of these risks tend to be implicit requirements. A very simple example.

The value of the search variable is a number value. Here you already have tsome implicit requirements. One is very easy, negative numbers are not allowed for search strings. Another, which most of the time is forgotten, is the maximum value. Unless it is specifically mentioned that negative numbers are also used, you have the implicit requirement that you to deal with the maximum value of the number on the negative side. If you don’t deal with this properly, you can get very strange behavior in your application.

One specific example I experienced is the following. In the mobile telecom world, our handset (mobile telephone) uses a SIM card. This SIM card has an identifier which is called ISMI. This IMSI number is used to register to the mobile network, no matter where you are. One specific detail about the IMSI. It is a string of 15 numerical characters, e.g. 204160544313597. You find this not in the requirements, because it is common knowledge within our field. What most of the people forget is that there is an IMSI range still operational that consist out of 14 numerical characters. We have here an implicit requirement that this IMSI string consist out of a range with a length between 14 and 15 numerical characters.

Just two examples to illustrate that the requirements you get from the customers/stakeholders are not complete. You still have implicit requirements.

So, implicit requirements are gathered from experience and proper understanding of the application. A good tester knows how to find them.

References:
Dan Douglas – Understanding the Implicit Requirements of Software Architecture

Scott Sehlhorst – Gathering Implicit Requirements

Advertisements

5 Comments Add yours

  1. lisacrispin says:

    I was at Agile Roots week before last, and attended a workshop on patterns to “build less” by Kiro Harada and Tsuyoshi Ushio. Kiro made the most interesting statement: “Never listen to your customers. Observe them”. He then went on to give some examples from when he worked as a shampoo engineer. Yes, they paid people to let engineers watch them wash their hair (the observees wore swimsuits, whew). Some things that came out of it: A way to easily distinguish shampoo and conditioner bottles by feel, for when you have soap in your eyes, and more diluted shampoo, because people were washing their hair much more frequently and the shampoo was too strong.

    Looking back over many years, I’ve found that customers rarely know what they really want until they see it. I think this ties into your implicit requirements. I’m going to find more ways to observe our product’s customers!

  2. Hi Simon,

    nice post about implicit requirements. I have a follow up thoughts:
    You said that search variable is number. I do not agree that in this context, implicit requirement is that negative numbers are not allowed. This would be true if you stated that search variable is positive number.
    Why IMSI length is common knowledge? Because of implicit requirement, 3gpp standard that is well documented.
    “Numbering, Addressing and Identification” (Release 5)
    3GPP TS 23.003 v.5.4.0, Sep. 2002

    My point is that as testers, we build our credibility by putting extra effort to find the source of implicit requirements.

    Regards, Karlo.

    1. Karlo,

      You are right, I should have mentioned positive number.

      Further, I agree with your statement that we build credibility by putting extra effort in finding the source(s) of implicit requirements.

      Regards,

      Simon

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s