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.

Recipe for Success in Software Engineering

 

Logic and sermons never convince …

Walt Whitman, Leaves of Grass

Reference – as quoted by Roman Kossak in “Mathematical Logic (On Numbers, Sets, Structures, and Symmetry)”, Springer Graduate Texts in Philosophy.

Now,

What sense does this quotation imply in the context of Software Engineering?

Ut infra:

Logic is the foundation for the Scientific Method. We use methods in software engineering, both structured and formal, such as entity / relationship diagrams, business process models, und so Weiter, to specify requirements for software development. Such methods constitute the use of the scientific method, which, as mentioned in the beginning of this paragraph, is built upon the foundation of Logic.

So far, so good.

Now, referring to Walt Whitman’s point in that poem as quoted above, the use of Logic as the foundation is valid. But it should NOT be used to convince.

In software engineering contexts, convincing means getting signoffs from stakeholders on requirements.

The foundation should indeed utilize the scientific method. BUT, getting agreement for its use, gaining adoption, these should hinge upon a complementary entity, namely, art.

Strengthening stakeholder relationships, also known as business partner engagement, is an art that complements whatever logical and scientific methodologies are applied for the specification of requirement for design and build purposes.

Obtaining signoffs is an art.

These complementary entities of science and art should always function together, like the double helix strands of the DNA polymer.

This is the recipe for success in software engineering.