Tag Archives: problem frames

Fitting problem framing into everything else you do

Posted on by
3

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 Engineeringgood 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.

Framing and Questioning

Posted on by
1

As a mental exercise, two colleagues and I have been spending time uncovering and documenting the problem frames in internet email. It is nice to frame a complex, concrete example that has architecture descriptions readily available. We can compare what we come up with against the machinery that’s already been built. Initially, I didn’t want to know too much about how things really worked so I could stack up our frames against the architectural solutions that already exist. Lately I’ve discovered that by examining technical architecture descriptions, I can quickly frame new parts of the problem which I can then use to loop back and try to understand the reasoning behind existing architecture.

Based on the problem we’re framing, we can also conveniently draw parallels between email and the physical world of postal mail. Today, Jim explained to Nathan the difference between local and internet based dispatching of mail by drawing an analogy to delivering mail within your house. If you address a letter to another family member, there’s no need to put it in mailbox, just hand deliver it. While the physical analog of postal mail is interesting, there’s a point where it is critical to drop it and focus on the problem at hand. Analogies only take you so far. But this got me thinking. How did the original architects of email find their inspiration? Did they create their solution based on perceptions of how the postal mail was handled? And if they did, when did they break away from that mental model and do the really heavy mental lifting needed to finish their design?

To me, an important aspect of framing is the questions it leads you to ask. Answering those questions helps you make design decisions. But even when looking at an existing technical design, framing has value. You can question why things are as they are and what problems were being solved. For example, in Qmail why are there two mail delivery strategies—one for local and one for non-local email? Presumably, because local messages can be processed faster and cheaper. Which leads to asking whether this is really necessary or a holdover from earlier computing days? Thinking for a bit, we enumerated a number of reasons why local mail can and should be handled differently than remote mail. (No need to check for spam, no need to go to a domain name service to get the host to transfer to, processing can continue when the parts of the internet are down). In short, local email can be processed much more efficiently and outgoing mail should be processed much more reliably; they are two different concerns that shouldn’t be lumped together into the same solution. Problem frames can help you focus and subdivide a problem into smaller ones. I want to continue to wade deep into software machinery and critically examine whether framing helps me understand the nature of problems. I’m concluding it does. So far I’m not inventing anything, just exploring known territory. But even there I find value in framing and then asking why. Makes me feel like a two-year old, but then again, maybe not. Analogies only go so far.

Timely events in Use Cases

Posted on by
1

Last week in a use case writing course I was teaching, a student presented me with a use case where he had been puzzling over how to accurately express the passage of time. His use case occurred over a period of several days and went something like this

Day 1:
The user does this
And this
And the system does this
Day 2:
The system does this
Another action..
Day 3:
The system does this
The user does this
And then things are finished

Although it accurately reflected the passage of time in the current system, he wasn’t satisfied with it. He wanted to describe a new version that could be more responsive. Instead of waiting for nightly data feeds, what if the system could process data more quickly? Expressing this in terms of time passing (day 1, day 2, etc.) seemed too concrete and limiting. After probing a bit, I suggested he consider restating this passage of time as events that enabled the use case to move forward. For example, “Day one” could become “Prediction made”, “Day two” could become “Project Completed”, and so forth. This shift in thinking–from describing elapsed time to describing events in a complex process–brought clarity to this use case and will influence the system re-design.

People can get bogged down because they don’t know how to express passage of time or lengthy pauses in action. Some might be tempted to “fix” the above use case by splitting it into three smaller one with appropriate pre and post conditions. That technical solution would only obscure the user’s overarching goal.

My eventful solution, another alternative, was inspired by Michael Jackson’s Problem Frames. Jackson emphasizes that, “the point of software development is to build machines that interact with the world and change it.” Jackson is big on describing problems in terms of domains and software “machines” having direct interfaces where shared phenomena flow between them. He cautions, “Don’t think of an interface as a queue or pipe or stream of messages flowing between the domains; instead think of events and states and values as being shared between the connected domains. Each interface is an interface of shared phenomena.” This notion of shared phenomena has been difficult for me to wrap my head around. I don’t typically think about what’s going out there in the world when I’m focusing on writing usage descriptions. But Jackson’s viewpoint is slowly starting to influence my thinking. Sometimes eventful interjections can help explain why the user or the system is doing what they are doing and lift you out of writing uninformative “skin level deep” descriptions.

Problem Frames and an Eager Designer

Posted on by
2

The past few weeks I have been participating in a book study group on Michael Jackson’s Problem Frames: Analyzing and structuring software development problems. Problem frames are a concept that Michael Jackson (the UK software analyst, not the courtroom celebrity) invented to characterize classes of problems that computer programs solve. According to Jackson,

“A problem frame defines the shape of a problem by capturing the characteristics and interconnections of the parts of the world it is concerned with, and the concerns and difficulties that are likely to arise. So problem frames help you to focus on the problem, instead of drifting into inventing solutions.”

Problem frames are lenses you apply to look more deeply at a problem. If you know what type of problem you are looking at, you can ask intelligent questions and make tighter specifications for how your software should behave and how it should interact with things in the world. Being a designer, I’m always looking to solve problems. Yet it is true that mixing up problems with solutions can cause interesting communication problems and disconnects.

Consider this statement from a Canadian farmer about the trouble with daylight saving time: “Chickens do not adapt to the changed clock until several weeks have gone by so the first week of April and the last week of October are very frustrating for us.” OK, I’ve gotta ask, do chickens really understand changed clocks? Of course not. The problem isn’t that chickens can’t adjust to the changed clock. The problem is that farmers’ sleeping and waking habits shift as a consequence of daylight saving time. The chickens still are disrupted, but only because the farmers have adjusted their behavior. Let’s not mix up cause with effect.

Jackson’s book is full of examples that exercise the muscles in your brain that help you untangle cause from effect and explore how much of the real world you have to understand before you can specify how your software should behave. It has been novel for me to take several steps back in order to deeply understand the nature of a problem. Be aware that I have a healthy skepticism for “big upfront analysis” just like I do for “big upfront design”. I don’t think the right approach for me is to spend lots of time deeply pondering problems before I start thinking about solutions. But l hope to apply Jackson’s ideas and deep insights on problems into practical advice and recommendations for those who aren’t keen on formalisms. Stay tuned.