Perception, Misperception and Counterfactuals

An alternative title for this post would be "Requirement Underpinnings".

To begin, let's fence off the philosophical brink of solipsism. The practical world of providing value to stakeholders (whatever that means) is grounded by the assumption that there is a "real world" that is capable of change. This "real world" is assumed to be the source of sensory inputs that lead to perception. In this context, "perception" is distinguished from "reception". That is, for example, whereas the eye receives sensory input in the form of photons interacting with the retina, the mind perceives an image. Exactly how this happens need not concern us; suffice it to say that it is a complex distributed process that is less than perfect.

Perception, then, is an imperfect representation of an external reality: a model, a set of beliefs, a theory. So how does it differ from misperception? Psychologically, there is no real distinction, at the time of (mis)perception: misperceived reality is as real to the misperceiver as perceived reality is to perceiver. This is similar to the semantic distinction between knowledge and belief. Part of the distinction, skirting the epistemological minefield, is that knowledge is "true" by definition. Likewise, perceptions are "more accurate" beliefs whereas misperceptions are "materially inaccurate". Another distinction between knowledge and belief, also applicable to (mis)perception, is the degree of conviction. For a belief to be a plausible candidate for the epithet "knowledge", within the mind of the believer, the believer must be convinced of its "truth".

It is to be hoped that "requirements" are underpinned by accurate perception rather than inaccurate misperception. Although in practice this cannot be assumed to be the case, we can assume that it is for the purpose of this exposition. When a mind contemplates the "real world" being different from how it is, it is operating in the domain of "counterfactuals", rather than "misperception". The psychologigal reaction to the difference between (perceived) actuality (or "real world") and the (contemplated) counterfactual is some combination of attraction and aversion. Leaving aside deeper consideration of the theory of mind, it seems to be in the interplay between such reactions to the counterfactual that the intention to sustain or alter the actuality arises.

To some extent, such reactions may be rational. And to some extent, non-rational reactions may be perceived by the mind itsef as rational. This, however, is a topic for another time. The term used here to represent the complex intention of the mind is "value". We put to one side the psychological processes that lead to the perception of "value", together with the underlying conflicts that, in practice, are often the source of inconsistency. So our focus is on the conscious and rational perception of value in the mind. This is not to suggest that "requirements" cannot arise from the non-rational or non-conscious, however.

So we move on to effecting or preventing real change to the actuality. Because the mind perceives positive or negative value from a contemplated change, it makes decisions that it believes will increase the likelihood that its more valued state of affairs will be the actuality. By the effect of these decisions, "words" and "deeds" (and silence and inaction), another mind draws inferences about what is valued. There is, in short, "communication". Communication is necessarily imperfect, since it is a form of perception; the perceiving mind incorporates beliefs about the other mind into its model of external actuality (and, indirectly, into its couterfactual models). The important point is that communicated value is qualitatively different from uncommunicated value. Under what circumstances either should be considered a "requirement" is, of course, purely a question of semantics. But it is only in the realm of communicated value that the "requirements practitioner" can operate, whether by stimulating or responding to the communication.

How communicated value translates into explicit requirements (however imperfectly specified) is considered in an earlier post.

Requirements Revisited

A recent post on the Seilevel Forum asks: What do Testers Test? Is it against the requirements or the design specification. A partial answer is "either or both, it depends". The standard v-model of testing suggests that there is testing appropriate to each level of specification. How much you do of each is a classic trade-off question.

But it seems to me that the received wisdom overlooks an important consideration, one that is generally missing from requirements practices. The important point is that specifications do not generally specify absolute outcomes (so they're a bit of a misnomer in that regard). What they do specify is a range of valuable outcomes, what Roger Cauvin has referred to as the "least stringent condition".

Clearly, if the design specification calls for behaviour that is more stringent than the requirement specification, compliance with the design specification implies compliance with the requirement specification, so testing both involves redundancy. More importantly, though, what you really want to test against is the most stringent condition or, perhaps, the most stringent condition of value.

This post is entitled Requirements Revisited because that is what we ultimately need to test against. Not what we think is wanted; not what we asked for; but what we're told we've got! Or, at least, as much of what we're told we've got as we think is valuable.

If our super developers claim to have given us extra performance or potentially useful unrequested function, testing provides evidence for such claims (though it is not the only source of evidence). But if we don't need it, why prove it works? Only because (or when) the risk of not doing so exceeds the cost. I have worked on extremely flexible systems in the past where the extent to which a capability had been tested was more of a limitation, in some cases, than the function or performance. We lacked a formal approach to revisiting the requirement specifications, so we could end up with change requests whose only impact was additional testing or risk assessment.

In short, for each element of any level of specification, there is (or should be) a claimed level of satisfaction. After testing (or other validation), there is a proven level of satisfaction. Any case where the claimed level of satisfaction exceeds the proven level is an identified risk. Signoff on testing constitutes acceptance of the identified risks.

My Introduction to Luke Houghton

I promised I would share which Luke Houghton post was the first I read. The title of this post links to it. In part, what impressed me most immediately about this post, in the first few words, was the almost casual way he shrugged off the reader's preconceptions. In this way, it calls to mind the brilliant beginning of Diderot's Jacques le Fataliste.

Bloggers of the world, you have about 2 seconds to retain and augment my interest. So far, none has succeeded as effectively as Luke. Of course, in part that is due to my own state of mind at the time. But the immediacy of the connection is largely Luke's responsibility, whether achieved by contrivance or the mysterious operation of a spark of genius.

Once he'd grabbed my attention, he had to deliver! And he did. The ideas weren't the best I'd come across that day, but they were worth reading. There is no need for a detailed critique. You now know where to begin. Begin!

Agoraphilia

I'm not a natural blogger.

The only reason I created this blog was as a publicly accessible link between my contributions on other people's blogs and fora.

I've found it useful, myself. But I wonder how useful others have found it...

Well, little by little we learn. Until now, I suppose I've been more concerned about the possibility than the occurrence. Now, I think it may be time to give social networking a try. I've signed up for del.icio.us and subscribed to the requirement tag. Perhaps that's why you're here?

Welcome!

Discovering Luke Houghton

In a later post, I'll create a link to the first Luke Houghton blog post that I came across, via a link from someone else's blog. I'm just grabbing bragging rights here: I spotted the Luke Houghton phenomenon before it began. Reading that very first blog, I recognised someone with eine ganz besondere Weltanschauung. In a little while, I'll begin to explain what makes Luke Houghton special. For the time being, let's just be content to read his blog and reflect. And if you already have, why not read mine and leave your mind open to the possibilities of synthesis...

Why Separate Business Rules from Requirements

...and if you do, what requirements are left?

Prioritization and Value Maximization [Tyner Blain]

Very powerful introduction to the value-driven approach.