go back to the blog

Requirements. The Reality Is…

  • 14/03/2013
  • no comments
  • Posted by EuroSTAR

We recently published a video that was recorded at the 2012 EuroSTAR Conference during a 5 minute Soap-Box session. In the video Fiona Charles discusses ‘Requirements suck? Get over it!’ You can watch the video here.

Johan Zandhuis responded to this blog post with ‘Requirements suck? Get over it!’ … No, go get them!

Mohinder Khosla now gives his views on Requirements.

Requirements. The Reality Is…

John Sterman of MIT, an expert in systems thinking says that “We think that what we see is what there really is”. Our mind comes with factory settings that cause us to confuse our perceptions of the world with reality. Every time someone says, “The reality is ….” that confusion is reinforced. This is further enforced by our education to recall facts on demand, even those facts that are interpretations of others of the world. These are not implanted in our minds but the very nature of factory settings to seek to perpetuate themselves that have found a way in our education system.

If we seek to find customer requirements through some means then our perceptions of them may differ from that of the customer and may set us on the wrong path. If testers and developers are presented with the same model of the requirement we expect end result should be what customer wants. The reality is somewhat screwed because developers and testers have different mindsets but when engaged together can bring about solutions closer to reality if the cultural differences are taken out of the equation. It is said that opposing models are the richest source to view problems in new light. These should be considered as learning opportunities to be appreciated, welcomed and understood. We learn little if we all see problems exactly the same way. The agreement is gratifying but can be deceiving too if both have overlooked something crucial. Our efforts should be devoted to mind the gap created by our perceptions of customer requirements through collaboration and communication.

The following sections highlights my views how we should manage requirements gap without resorting to blame game.

Lost in Translation or Cultural Differences between Business and IT:

Software development is neither science nor engineering discipline but social science in broader sense. Customers have needs that they express through requirements. The part of our brain (limbic brain) that expresses needs has no language and our frontal brain (neocortex) translates them into a list of things that meets their needs. We all have heard the expression “Lost in Translation”. This is because our brain takes shortcuts when processing information and may miss some important details. It is hard to document what our customer really need because of the cultural differences between business and IT. If we endeavour to achieve perfect requirements before we start development then we may be misguided. Even in cases where we are presented with perfect requirements to work with we may still end up with conflicting models of them that may not fully meet customers’ needs.
My experience working throughout SDLC on a number of large projects shows that customers are not upfront with their full requirements but slowly feed them through as we go through the analysis and design phases. One project I worked on, we spent months and months capturing requirements and when it came to signing them off, customer rewrote them from scratch. You can imagine the drain on resources and the project time scale. The approach to requirement gathering is not perfect and sometimes unpleasant. The advent of agile made it easier to adopt more sensible approach to requirement capture eliminating some of the risks associated with project failures we all experience.

Bridging the Gap:

If we identify gaps in requirements during the development (testing included), the best approach is to have a conversation with the customer for clarification. The reason we don’t get accurate requirements from the customer in the first place is, as stated before, we do not speak the same language and because of cultural differences. There are barriers to what customer wants and what we can deliver although there has been great effort in bridging that gap. Some of the agile projects I have come across follow 3 Amigo approaches where tester is considered a key team member and get involved at the requirement initiation stage. Those who follow Specification-By-example, SBE for short, are aware that scenarios extracted after conversation with the customer form part of testing. During this stage, key requirements are clarified so that everyone including tester is on the same page. BDD tools such as Cucumber have been developed so that customers can input scenarios that developers can use to test their code. I have noticed that some customers find it difficult or are restricted by the syntax Given-Then-Then. This has recently been refined by another level of abstraction Behaviour-Driven JavaScript with Yadda that makes it easier to input specification in English-like language. I went to see a demo of this tool recently and I liked what I saw. The input to the tool can be explained by an example below.

If there are 100 green bottles standing on the wall and 1 green bottle accidently fall then there are 99 green bottles on the wall.

Instead of inputting the scenario as:

Given 100 green bottles standing on the wall
When 1 green bottle should accidentally fall
Then there are 99 green bottles standing on the wall

You input scenario as:

100 green bottles standing on the wall
1 green bottle should accidentally fall
There are 99 green bottles standing on the wall

The above scenario gets broken down using regular expression. The regular expression identifies which steps are compatible with the input text, and to provide arguments to the function. The abstraction layer is glued to the code to run. The customer need not know how it works except how to input scenarios. The tool helps bridge the requirement gap because of customer buy-in. At the moment tool is limited to JavaScript but it is early days.
Those who follow work of Gojko Adzic on Impact Mapping may be familiar that the technique is another attempt to extract requirements that customer needs than what he wants. Teams who adopted or experienced the technique have benefited. It is early days before full potentials would be all too clear but it is step in the right direction.
There are ways of bridging the gap between the business and IT and our efforts should be focused in making that partnership smoother and successful without resorting to blame game. My point is that IT is making great strides in the requirement capture space to collaborate with the customers at an early stage so that the right systems are built and less project failures.

Stakeholders to talk to

One of the difficult things in requirements capture is finding all those stakeholders before development can begin. The task is sometimes left to testers to identify those who would interact directly with system under test (SUT). These could be humans as well as non-humans and even systems interfacing with SUT. There are also stakeholders and systems that interact indirectly with SUT and should be considered during testing. It is quite common that requirements for latter are missed because of oversight. I call former stakeholders as part of system and latter super-system.
There are also misconceptions amongst testers that there are lack of requirements for them to test and they spend a great deal of their time searching for information instead of devoting time to test. We all have worked on projects where documentation is scarce and others with high demand for production of documentation especially with systems that demand greater scrutiny due to regulatory requirements. All in all, it is our responsibility to seek advice where clarity warrants it.

Requirements are hard to agree

If you ever watched the movie CRASH then you may have observed the escalating confrontation between Daniel, a Hispanic and Farhad, an Iranian shopkeeper, a recent immigrant to poor neighbourhood of Los Angeles. Farhad decided to buy a gun with the help of his daughter Dorri, who managed the transaction with the shop owner, to protect his shop against thieves who broke into his shop or held him up several times. Insurance company sends Daniel, an independent locksmith who looks like a scary-looking, bald-shaven head, wearing an earring, several tattoos and dressed like a local gangs but a decent family man, to repair the lock. Daniel replaced the broken lock but Farhad repeated asking ‘have you fixed the lock’. Daniel tries to explain that the problem is not with the lock but with the door itself which needs replacing. What follow is the misinterpretations of each other’s stance that had tragic consequences. Farhad becomes convinced and went to Daniel’s home, when his shop was broken in again and the insurance would not pay up, thinking Daniel is behind all the break-ins and shot him but was shielded by Daniel’s daughter who took the shot. Lucky for Farhad, his daughter bought him blank rounds of ammunition saving him from first degree murder and Daniel’s daughter from injuries.
The movie vividly shows how distinction between subjective constructions and objective reality can be a matter of life and death. The compelling scene described above speaks directly to the importance of a stance that consciously distinguishes between objective reality and its many subjective models. Their models are real to them that they are willing to take extreme actions. The overriding lesson from their story is that anything we think is real is actually a model of reality and that model is probably imperfect in some important aspects. We are connected to reality by our model of it.
Most of us are conventional thinkers and we come with, as psychologists describe, factory settings. It takes a great deal of effort to develop our tools and get practical experience before we come to know how to change these settings, a topic for another day. In the case of Daniel and Farhad, they could have taken more conciliatory approach to bridge the gap. The outcome would have been very different if they had. The point I am trying to make here is that perfect requirements do not lead to perfect solutions just our manifestations of what we make of them.
There is little realism in thinking that we must have all the information upfront at the start of our work. We have a duty to satisfy customers functional and emotional requirements; instead of trade off one for the other. Go find the information you seek and have a warm conversation (a message repeated here) with the customer so you both are on the same page.

We are Analyst First, Tester Later

I think there is a good reason why we (testers) have been bestowed the title Test Analyst. This is because most of what we do is analysis of requirements before the task of testing commences and later analysis of results of our testing to ensure what is required is delivered. Analysis is the hardest and most critical part of our job than testing itself. A tester once told me, testing is easy, the hardest job is analysis leading up to testing. That’s why business values our inputs and that’s why we rebel when coding is pushed as key skill for testers. This is a built-in defence mechanism within us because we are afraid to lose our analytical skill vital for our survival as test analysts if that happens.

Our Choices are

There are no easy answers but the best advice I can offer is to keep an open mind. Things are not that simple on the requirement front but perseverance pays off. The business environment is constantly changing and we should embrace the change. Remember times when requirements were written at the back of a cigarette fag. That has not changed except we use post-it notes that we stick on a white board for visibility. Requirements do not have to be wrapped in a fancy binder and sealed in a box to surprise us. Open and frank conversation with the customer is the way forward and it goes a long way.

Blog post by

go back to the blog


Leave your blog link in the comments below.

EuroSTAR In Pictures

View image gallery