Scenarios Define Problem ★

Discussing a worst-case scenario...

How do you know a programmer is extroverted? He stares at YOUR shoes when he talks to you.

...you want to engage the customer and need a mechanism to support other organizational alliances between customer and developers. 

✥ ✥ ✥

Design documents are often ineffective as vehicles to communicate the customer vision of how the system should work.

There is a natural business distancing and mistrust between customers and developers. Communication between developers and customers is crucial to the success of a system. 

Therefore: 

Capture system functional requirements as use cases.

It is obvious that use cases help increase understanding of the requirements, but a less obvious aspect of this is that they help set boundaries of the problem. This became clear as one of the authors (Neil) consulted with a group who was writing patterns of use cases. When I questioned a member of the group what problem use cases solve, I got an unsatisfying answer. I probed deeper by asking how the situation would look if one didn't apply use cases, and he responded, "You wouldn't know where to start, because the problem would be too broad." Interestingly, he had never thought about use cases as a tool to bound the problem until that point. 

Use cases do not capture success scenarios alone, but all the scenarios that the system must deal with. There is no such thing as an exceptional case; make the exception the rule. Interview enough constituencies to get full coverage of the expectations of users and other stakeholders. Use cases also can, should, and almost certainly must be augmented with non-functional requirements. 

✥ ✥ ✥

It is easy to see that this is a good idea, but what does this have to do with organizations? One of the tensions in many organizations is that the developers are, well, geeks. Many don't have particularly good communication skills, or, more precisely, aren't particularly interested in interpersonal communication. So it is difficult to communicate requirements to developers. Scenarios work. So if you really want to EngageCustomers, this pattern makes it much easier. 

The problem is now defined, and the architecture can proceed in earnest. You can use scenarios as a means of dialogue and requirements clarification with your users, particularly when building and demonstrating a system or subsystem prototype. For more on this, see CatalyticScenarios in the DemoPrep pattern language from Todd Coram [BibRef-Coram1996]. 

Also read about the MercenaryAnalyst, who captures scenarios and uses them for project documentation (both internal and external). 

[BibRef-Cockburn2000] is one of the most acclaimed references on use cases. Also see CACM Nov. `88 (v. 31, no. 11) pp 1268-1287, according to Ralph Johnson. Also Rubin and Goldberg [BibRef-GoldbergRubin1995], who take scenarios all the way to the front of the process preceding design. See also [BibRef-HsiaSamuelGaoKung1994].