Objectively Correct Requirements

by Nick de Voil 23. May 2012 15:23

I've been reading a piece by Tal Bloom on the excellent UXmatters site about triangulation of requirements to ensure that "objectively true" requirements are defined. It's a nice article but I do object to some of the ideas implicit in the terminology.

Without people necessarily realising it, the chimera of "objectively true" or “correct” requirements has bedevilled development projects for decades and there's a widespread but largely unspoken belief in the validity of the concept.  I don't believe it's helpful. A requirement is not a neutral fact and the idea of objective truth is simply not applicable when speaking of requirements.

A requirement is in reality a complex speech act [1] within a complex context. I would formalise this as follows.

Part 1 (Context): Person or group of people A asks and/or pays another person or group B to design, construct and/or deliver a product or service C, which will be used for functions D1..Dn by a person or group E in context F.*

Part 2: (Speech act): A says to B, “you will have fulfilled our contract if and when the situation G, i.e. the use of C by E in F, is characterized by attributes H1..Hn when perceived by person or group I.” **

Now, if we're talking about the engineering of a physical deliverable such as a building, a bridge or an aircraft, then D1..Dn and F are stable and don't vary depending on the identity of E, and we can define H1..Hn in ways that are relatively uncontroversial and don't vary depending on the identity of I. In this context, D1..Dn support simple and universal physical human activities such as locomotion and shelter. F is bounded by well-known laws of physics, physiology, meteorology, geology, mechanics and so on.

However, if the system under consideration is a human activity system, or an information system that is to support a human activity system, then D1..Dn and F are subject to unpredictable change and H1..Hn are hard to define in a reliable and uncontroversial way. In this context, D1..Dn support activities, tasks and objectives which can often only be defined in terms whose meaning is individually or socially constructed. The same applies to F.

So Part 1 presents some difficulties of its own where "objective truth" is concerned, although the requirements engineering and business analysis fraternities have gone a long way towards developing solutions. But the real problem is Part 2. A speech act of this type isn't amenable to evaluation in terms of truth. It's a performative [2] utterance rather than a constative one - in other words, it doesn't purport to be a statement of fact. Rather, it constitutes the taking of a position by an actor. To complicate matters further, a truly holistic view would recognise that in practice there are often multiple contracts negotiated between different pairs of stakeholders.

It's curious that the way we often talk about requirements seems to owe a lot to the ancient Greek philosophers. To speak of "impurities" in requirements suggests that a requirement is a substance like iron or gold with an inherent essence, as Aristotle might have said. In view of the complex web of meanings implied by the above, this is clearly wrong. Likewise, language such as “vision”, “lift individuals beyond their own personal, limited perspective into a place of true collaboration” and “objectively true project requirements” implies a belief in a Platonic ideal which the deliverable should approximate or tend towards. I think we need to look at things a different way and recognise that no such ideal ever exists except for very "hard" systems engineering problems.

All that said, I agree with the central point of the article, which I would put this way: the most reliable way of reaching an outcome which is satisfactory to all parties is to ensure that A1..n, B1..n, E1..n, I1..n all have the opportunity to reach a shared understanding of what constitutes G and H1..n. I would add that, for a complex product, this is a cyclical process informed by experience and dialogue, like all human meaning-making (hence the value of prototyping and perpetual beta). It might be tempting to suggest that something must be objectively true if a large number of people agree on it, but that consensus will often only be a fleeting one.

 

*Note on Part 1: This definition can be broken down further as follows:

 Part 1.1 (Contracting context) ): Person or group of people A asks and/or pays another person or group B to design, construct and/or deliver a product or service C1

Part 1.2 (Usage context): Product or service C2 is used for functions D1..Dn by a person or group E in context F.

 

**Note on the whole definition: This describes the situation where the supplier is contracted to provide a product to a customer. A different but increasingly common situation involves a supplier designing a product which it hopes to sell to multiple customers, as follows:

Part 1 (Context): Person or group B decides to design and construct a product or service C, which will be used for functions D1..Dn by a person or group E in context F, in the hope that person or group A will buy it.

Part 2: (Speech act): B say to themselves, "A would wish the situation G, i.e. the use of C by E in F, to be characterized by attributes H1..Hn when perceived by person or group I."

User-centred design adds another perspective to this definition of Part 2:

I says to B, "A would wish the situation G, i.e. the use of C by E in F, to be characterized by attributes H1..Hn when perceived by person or group I".

 

References

[1] Searle, J. (1969). Speech Acts. Cambridge, UK: Cambridge University Press.

[2] Austin, J.L.  (1962). How to Do Things with Words. Oxford: Clarendon Press.

Interaction in a Social Context

by Nick de Voil 3. May 2012 20:15
I've been interested for some time in how usability can be extended into, and integrated with, the field of enterprise systems design - not just in terms of the surface details of user interface, but also  at a deeper level of what Ronald Stamper calls "organisational semiotics", trying to get away from the Model Human Processor and taking into account things like social psychology, social anthropology, cultural analysis and discourse analysis.

The latest edition of Interfaces magazine has an intriguing article called Enterprise Usability Architecture, which talks about integrating usability with enterprise architecture. The interesting part comes at the end, where it says that "social models of HCI fill a gap that exists in both disciplines". It refers to the "Model of Interaction in a Social Context (MISC)".

This aroused my curiosity. I had never heard of MISC, and nor had Google, but eventually I found it in the PhD thesis of one of the article's authors, Sarah McDaid: "A model for human-computer interaction based on human-human communication in a social context".

MISC is an ambitious model identifying seven "layers" of the human-to-human communication process: task, presentation, session, control, cognition, effector and physical. Without going into all their meanings here, suffice it to say that this scheme is very helpful in showing some of the things that are often left out of consideration, both in ineffective person-to-person communication, and in traditional systems design. MISC then goes on to identify elements for consideration at each level. Some of these are familiar - for example, the Task level includes consideration of Goals, Sub-tasks etc. But others are less so. At the Presentation level, Roles, Relationships, Responsibilities, Social Rules and Social Norms are considered. The Session and Control levels deal with conversation structure.

Most interesting for me is the so-called Cognition layer. As McDaid writes, "This layer endeavours to take account of the personality and life-experiences of the participants and the impact that this has on their interpretation of the proceedings around them. These elements of the model are principally derived from work done in the field of social psychology." It includes elements like personality, emotional state, causal attribution, stereotyping and meta-perception.

The article in Interfaces does not specify how any of this is to be integrated into enterprise architecture, but I like McDaid's agenda and I do believe that this is a useful framework from which many good things might come.