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.