Exploring without Requirements

This is not finished, but roughly sharable. I wrote the articles for (some) links.

Why to explore, without requirements

Requirements are handy.

They're also seen as unquestionable, complete, and so necessary to testing that testing cannot start without requirements. This fetish is a barrier to starting work, particularly where the context makes it hard or dangerous to take a decision to start work.

Which is silly, because testing reveals requirements. And because your requirements are wrong.

Testing involves judgement, and judgement involves comparison. If you typically judge against a model built from requirements, you'll feel uncomfortable without them. A decision not to test may seem reasonable. Your decision may not be as clear-cut enough to relax into, every time: I'll write about that shortly, in Testing Without Requirements.

Exploration, on the other hand, can proceed merrily without requirements. If you're holding off looking at a system because you don't know what it's for, you're denying yourself the pleasure of exploration. Hedonism aside, your're denying your organisation the your perspectives on what that software system is building / installing / using / changing / deleting / corrupting / allowing / hindering. Get over yourself.

Ways to explore, without requirements

How do you explore without requirements? You work with what you've got. Exploration requires an artefact. That artefact will reveal itself to you in different ways, depending on how you approach it.

Here are a few general ways to explore a software system:

• Explore the system as it is now, to look at how it transforms information
• Explore the system as it is now, to look at its parts and their interrelations
• Explore the data that the system contains, how it is represented, and what it satisfies
• Explore what the system naturally does, gather evidence about the intent of its makers and its apparent purpose.
• Explore the underlying technologies and component technologies of the system, their capabilities, and the constraints that those technologies impose on the system
• Explore for shortcuts that the system takes to be responsive / performant / low-impact, and the ways that it might be hardened to be usable, to be secure, to be resilient.
• Explore the feedback and the regulators in the system.
• Explore the limits and capacities of the system and its parts.
• Explore the boundaries of the system – what is inside and what is outside.
• Explore the ways that the system tells others about itself – manuals, specs, contracts, error messages, API descriptions, schemas, standards.

An artefact is a made thing, which means it had a maker with an intention, it has a purpose, it has expectations and history and a meaning.

These qualities go beyond what it is: as how it was made, how it will be used, how long it might be expected to last, what needs to be done to keep it valuable, what might be dangerous about it. We might see those qualities as to do with the relation between the artefact and its context. An ivory chesspiece is different whether one sees it as part of a set, or part of the current game, or part of the walrus it was carved from. A book is different whether one sees it as a collection of fine-grained paper, as a collection of ordered words, as a singular part of the author’s oeuvre, as a firelighter or as the guiding urge of a cultural movement.

• Explore the system as it is now, looking at how it interacts with external things – users, other systems, filesystems.
• Explore the ways that the system has been constructed, installed and set in motion
• Explore the system's history – how it has changed, who made those changes, and why.
• Explore the system's intended purpose.
• Explore the system's use to those who don't attend to its intended purpose.
• Explore the system in a human context – what do people feel about it? What do they use it for? How are they disappointed? How are they delighted? How do they misuse it?
• Explore the system's end-of-life: what happens to its responsibilities, to its data, to its parts, to its users, to its licenses, to its secrets?
• Explore the reasons that it might reach the end of its life.
• Explore the ways that its connections to other systems and its transactions change over time.
• Explore the ways that it is regulated and limited, and what controls or sets the limits and regulations.
• Explore ways that it interacts with cycles that are out of step / much longer / shorter than its own.

You'd find analogous approaches if you're testing a document or a map or a library or a building or a process. I expect you can add to this list, from inside or outside testing. Do add a comment with your own example. I may add it to this page.

We can all explore without requirements, and we can all build model of what we find.

The trick is to start.