How to Handle Vagueness in Software Requirements

 In continuation of the theme in the previous blog post, here is a recommendation for a perspective shift.

Vague does not necessarily mean bad.

Technically, the term implies "wandering", as per the Latin Origin ("Vagus"). 

If you think of the vagus nerve, nothing bad about it either. In fact, it is an amazing and awesome thing. It gets sensory info from a whole bunch of parts of the body to the brain. It covers a lot of ground, basically. A big-time wanderer nerve, hence, the name vagus.

This is the lens with which we should perceive so-called "vague" requirements in software engineering. They just need to be studied in more depth, understood better, and then they will reap fantastic returns. If we skim them from the surface, yes it leads to disasters, no doubt. So, the key is to allocate enough cost / effort / time (the 3 basis vectors of the Rayleigh Curve), which are the fundamental dimensions of project management as well.

When the requirements are vague, think of them as though their meaning is wandering, meandering through fields of applicability, looking for definitions that satisfy some innate and elusive quality criteria. Nothing wrong with that, it is quite likely the opposite, there is a treasure trove of opportunities buried under there somewhere.

Arriving at definitions of the requirements, and concomitantly, at quality requirements specifications, depends upon Pragmatic approaches (i.e., consensus-based judgement calls to arbitrarily pick a given prong when facing forks of ambiguities), understanding connotations (intensions) and denotations (extensions), and such philosophical principles, in the application of whatever logic-based scientific methods one adopts.

So, here's an example.

Requirement: I need stuff.

Clarification Process:

Q1: What kind of stuff?

A1: You know, stuff that comes in boxes, and some other stuff that comes on reels.

Q2: Can you give examples?

A2: Circuit breakers in boxes, wire and cable on reels.

Q3: Is it a one-time need?

A3: No, these are examples of recurring need.

Flash of insight ... Ah, ok, the requirement is for a procurement system, with potentially some additional downstream requirements on the inventory management end for container management, packaging, returnable packaging, with loop back into the procurement side of the house for return orders and such. All right, let's get into discovery mode!

See, it can be sorted out. Just need to work through it. 

• Use Logic and the Scientific Method to document the working through the process.
• Apply the art of building trust and fostering a culture of give-and-take with stakeholders and business partners during the process, in complementary double helix strands.

In summary, if the requirements are found to be vague at the outset of a project, no problem, that is more of an opportunity than a concern. Just allocate enough cost / effort / time in the discovery phase to parse them and convert them into processed versions of detailed requirements, and ...

 Hello, Uncle Bob! We're off to the races.