At Software Development Best Practices 2005 I presented a tutorial, Introducing Problem Frames. Problem frames are a way of thinking about software problems and approaching the task of writing descriptions of desired and expected behavior. More can be found about them in Michael Jackson’s definitive book. There’s also a website devoted to problem frames. I find Jackson’s paper, Problem Frames and Software Engineering a good summary of problem frames for the mildly curious. Jackson introduces five basic problem types: workpiece, information, transformation, commanded and required behavior. Each frame can be described in terms of:

• A decomposition of a problem into a particular set of interacting domains;
• A characterization of domains as being lexical (symbolic), causal (responding to and/or causing events), or biddable (typically humans who can be asked but not forced to respond);
• A characterization of the shared interfaces (events, state changes) between domains, and;
• A depiction of a requirement and its relation to particular domains.

My tutorial illustrates Jackson’s problem framing using an email client application (thanks to colleagues Jim and Nathan who worked with me on this example). I hope to expand on it in the future. The example illustrates various frames and concerns but doesn’t go into great detail specifying requirements. That’s OK. The point was to introduce frames, not introduce the art of writing specifications after identifying frames.

For now, I’m content to have an example in hand which illustrates the basic mechanics of problem framing applied to a purely software system. Jackson’s examples and emphasis is on software interacting with the real world. He made this very clear in a posting to our Yahoo Problem Frame discussion group:

...the emphasis on physical phenomena is very important—even central⁠—to problem frames. If your problem is “given a very large integer, find its factors” there aren’t really any physical phenomena involved at all. aren’t really any physical phenomena involved at all. Of course the integer must be somehow presented to the machine, and this will involve physical phenomena of keyboard strokes or something of the kind; but these phenomena are just incidental to the problem.

I don’t think that the problem frames ideas are totally useless for a problem without signficant phenomena, but I think they lose a lot of their value and appeal. Problem frames are about engineering in the sense that Vincenti quotes: “Engineering ... [is] the practice of organizing the design and construction of any artifice which transforms the physical world around us to meet some recognized need.”

— Michael

Most folks I work with aren’t developing software to control physical devices. Yet I believe that framing could be applied to many IT software problems and help clarify what the system should do, as long as framers can transcend Jackson’s real-world focus and look inward to the interior domains prevalent in their software world and understand how to describe the shared phenomena between them.

However, I think there are several hurdles to overcome before problem framing will have a wider IT audience. Practicing analysts already have many tools for specifying systems: context diagrams, event-response tables, business rules, use cases, user navigation models, user classes, personas, data and information models, decision tables. Where do frames fit with what they are already doing? In my tutorial, I made a point that the end-products of framing aren’t just those simple frame diagrams (they are in fact only a placeholder for discussing and writing—if you are so inclined—requirements and descriptions of domains and phenomena). But framing still has to compete with other analysis activities. And the descriptions and requirements have to fit in with other behavioral descriptions analysts write. And at the end of the day, one of the tutorial attendees remarked, “Thanks for introducing problem frames to us, Rebecca. I’m not sure I am going to use them formally as an analysis tool, but I suspect just knowing about problem frames will help me write better specifications using the tools we already use.” We’ll see.

Then there is that sometimes difficult distinction to be made between specifying what the system should be vs. what it should do. People are slowly adopting techniques for specifying measurable non-functional requirements using Planguage. These ideas also compete with problem framing for mindshare.

Contrast framing with the agile practice of not writing down requirements (according to Gerard Mesazros who presented Agile Requirements with User Stories at Agile 2005, user stories are an “I.O.U. for a conversation.” Any agile person would throw up their hands and shout, “Enough! Just give me practical advice on how to apply framing techniques directly to what I do, and I’ll consider them. But I don’t want to write a lot of formal descriptions.” Framing has to be more than a set of frame diagrams that lead to descriptions or it isn’t going to find any audience the agile marketplace, even though I believe that framing is an invaluable thinking tool when having that conversation with the customer.

Those are some challenges I see. Coming up with practical techniques applying problem framing to complement and clarify the work busy people are already doing.