In the past year or two, I have repeatedly been jolted into a very particular type of reflection by an experience which I initially supposed was unique, or at least rare.
But I am starting to suspect, on the basis both of personal experience and of things that other people have written, that it is in fact a common element of the human condition.
I am referring to the existence of parallel worlds.
Each of us inhabits one or more small worlds: the world of the Londoner, Parisian, Milanese, New Yorker; the world of the parent; the world of the art-lover or theatre-goer or rock-climber or gardener or nature-watcher or whatever; I could go on. And, obviously, we live in the world of our work: the world of law or medicine or accountancy or programming or business. Or even requirements.
Now to requirements people, the fact seems obvious: a requirement says simply and directly what somebody wants (and is prepared to pay for), so plainly it is a useful communication to somebody else who can provide it (and is happy to be paid for it).
We are, I feel, not specially attached to the R-word; need or wish or demand or goal or objective or mission or problem description or specification or, heaven help us, target would all do, at a pinch. The Swedes use "krav" which obviously has something to do with craving more or less desperately for something. The French use "exigeance", which seems to have connotations of extracting something from someone, possibly at the point of a sword. The essential idea is not changed by one iota, one jot or tittle (these are the smallest letters in the Greek and Hebrew alphabets, respectively).
We are no better at agreeing on any of the other terms in our domain.
The way we measure what we are asking for is called a measure of effectiveness, a measure of performance, a guarantee, an acceptance criterion, a fit criterion and so on and so forth. We check we have attained these measures by validation, or verification, or an inseparable "V&V", or just by testing.
People don't agree whether a system - surely one of the most basic words in the lexicon of systems, software, and requirements engineering - means a computer, a computer together with its software, a whole network of computational and communications hardware and software, just the software, or the entire working entity including the people and procedures needed to enable it to deliver results. We don't agree on what the people who operate this stuff are called, either.
A service ... ah, service. There are literally dozens of conflicting meanings. Worse, intelligent and, I suppose, well-meaning people confuse two or more meanings, or perhaps intentionally elide them together so as to convey a warm fuzzy impression while actually trying to "sell" you their idea of how to design better software. But I digress.
The thing that has repeatedly shocked me is not that people use variations on common terminology. It is that whole groups of people have quietly been living, working, going to conferences and even writing books about requirements, not only without using the R-word, but - and it is this that gives me an eerie feeling, like standing in a Japanese tower-block in a mild earthquake, or meeting someone you thought were dead, or hearing about someone with the same name as you who went to your school, only you never met them before - without any sign of ever having heard tell of the whole industry, research field and literature that is requirements work: indeed, that is requirements engineering, software engineering and systems engineering all rolled into one.
They are simply pottering about, like the peaceful citizens of Shangri-La in James Hilton's fine novel Lost Horizon (1933). Up there in the pure clear Himalayan air of their hidden valley, people identify stakeholder groups and market needs, define products to add to product lines, conduct trade-offs of candidate designs against stakeholder goals, set priorities, write requirements and develop and test products - without using any of the nouns in this sentence, other than accidentally.
Or, like the denizens of Philip Pullman's Northern Lights (aka The Golden Compass) (1995), they live in a world - or worlds - which superficially resemble ours, with normal-sounding places like Oxford; only, all kinds of oddities, like alethiometers and dæmons, are casually mentioned as if they were the most normal things in the world.
What do people do when they DON'T do requirements?
They do
and, I expect, a whole host of other things that I've never yet heard of.
Now, in some of these instances, as with user stories and use cases, the people concerned know perfectly well that they could be writing requirements, are familiar with the software engineering literature, and have chosen to do things differently - in a practical and sometimes agile way.
But in other cases, whole industries, no, whole disciplines of practice and research and publishing, have never had so much as a Pullmanian brush with requirements.
And they are expending enormous effort on inventing ways to handle stakeholders, and goals, and scenarios, and context, and non-functional requirements, and definitions, and rationale, and priorities, and measurements.
Spooky, isn't it?
(c) 2009 Ian Alexander
Books you may like: