I know I'm in the minority but was never a big fan of MSCs, ping-pong diagrams or other things in that family. To me, they convey far too little information to be support enabling specifications. In good requirements engineering it's all about detail, detail, detail — and in the end that can be conveyed only verbally, with instant feedback. Time put into pretty pictures tends to infuse delay and inertia into the process, because people are disinclined to change pretty pictures. A good requirements formalism provides a way to document agreed decisions during the conversation. In the end they aren't terribly useful for delivering requirements over the wall from an analyst to the team. And in lean development, we want that conversation: that's the essence of “everyone, all together, from early on.”

Second, a few good words are worth a thousand pictures. The problem with the picture is that it lacks, er, context. There's no information about timing which, in your example, is all-important. How long is the table expected to wait to pay the bill when they are done? What is the cue for the waiter to come to the table to handle the bill-paying? What are the preconditions? post conditions? invariants during the transaction? what is the goal of the use case? what are the non-functional requirements? If you want to convey the gist of a scenario to a listening audience then tell a story. There are all kinds of great tools in this area: personas, user profiling, and user narratives. (Not user stories — that's another tirade.)

The bigger problem — and this isn't just about MSCs, though they make it worse — is that people tend to show only the main success scenario. There are always alternative scenarios and it's crucial to capture the decisions. There can be many alternatives for paying the bill: credit card? cash? the client walks out without paying? the waiter needs to make change? tip? tip on credit card machine? paper credit card machine? wifi-based credit card machine? same waiter tenders the bill and picks it up? different one? waiter takes tip? table-clearer takes tip? MSCs can't show these things clearly; it becomes a terrible mess. If you present each scenario as a separate MSC then the programmer has a terrible job weaving them together: the synchronisation and decision points between scenarios are ill-defined at best. A Wirfs-Brock format tabular use case presents this information in a clear, structured way that can be used to drive tests and code.

Third, MSCs tend to be time-ordered. There are some “sequences” where time doesn't matter. If the table wishes to pay by credit card, the Waiter has to fetch the credit card machine. It doesn't matter if the waiter fetches the machine before coming to the table to discuss the bill or whether the waiter does that when the table presents the credit or debit card to the waiter. Capturing things at that level of sequence deviation is irrelevant to the business, and use cases are designed to capture business imperatives. Most people don't understand that use cases are DFDs in disguise, in which the notion of time has been stripped out.

The reason this is important is that we want to give the programmer as much freedom in selecting branching options as we can. We don't want to stipulate, in the requirements, things that aren't necessary for proper functioning of the business. This is particularly important given an important limitation of today's programming technology as regards DCI. A Context is a use case — not a scenario. Too many people think that use case is Swedish for scenario. A use case is a structured collection of related scenarios that all try to achieve a common goal under a delineated set of conditions. And the programmer has to weave together those scenarios into code. In DCI, you could in theory have one scenario per Context, but that leads to duplicated code, bad cohesion, making decisions in the wrong places (e.g., where to put the decisions about branching within the use case) and so forth. A good Context is a use case whose structure may be quite different than the main success scenario.

So, yes, the MSC is pretty, and it may help someone understand a projection of some subset of a simplification of the problem. Sometimes that's even useful. If you feel it fits that use on the web site, you can experiment with it. I do think we have an opportunity to challenge our constituency to more professional approaches to requirements management. I think that promoting to an activity aided by a tool gives the tool and formalism more credibility than it is due: these things are for markers and whiteboards rather than anything that goes into the project documentation. It's very un-lean.

I'm seeing more and more of this tool focus here in the DCI community and it concerns me.

As an exercise to underscore my concerns, write the code that you in good conscience would deliver to a restaurant to support this function. Compare it with your MSC. Evaluate the information overlap. You'll be amazed.