Problem
How do you get the information you need about your product's required capabilities, the resources needed for its completion, and other relevant issues?
Forces:
Information and expertise are distributed among different individuals, roles, or organizations
All too often, software designers are removed from users.
Users often don't know exactly what they want, anyway.
System testers want closure on system specifications as soon as possible so they can begin planning for testing.
Solution
Put together a team to specify user requirements. The team should include a developer, a user or user's representative, and a system tester (at least one of each). These individuals will work through the issues surrounding product requirements, often using small prototypes to identify the requirements and determine testing criteria. The user of prototypes can be closely tied to using use cases or similar usage scenarios as analysis and validation tools.
One are in which this approach is especially useful is in the specification and disign of the user interface. The developer creates mock-ups of the user interface, and the user and system tester examine them. In this way, this small subteam can go therough many different designs of the user interface and select the best one.
This approach of making fast iterative prototypes should help reduce overall development time. In addition, reviewing various interfaces will help users better understand their own needs.
Rationale
Highly effective developments are tightly coupled to users as well as validation teams. Such teams have a strong awareness of their customers' needs. A particularly striking example of this was a project where a team consisting of a system engineer, system tester, and user interface designer worked together closely for several weeks. They produced numerous iterations of the user interface, sometimes as many as three per week. This close itneraction was a key to the success of the project.
Variation
An interesting variation on this pattern is to have team members come from different backgrounds. They may have not only different proffessional experience but also different coltural, ethnic, racial, gender, or even religious backgrounds. Jim Coplien related a software architecture exercise in which teams of all-men, all-women, and mixed gender teams worked closely to create software architectures for various problems. The mixed groups consistently outperformed the others.
Related Patterns
This pattern is similar to Whitenack's RappelPrototypes pattern [BibRef-Whitenack1995]. Copliens' EngageCustomers pattern describes the necessity of having a close association with customers; DiversityOfMembership provides a pattern for achieving and using that association. It acts as a bridge between EngageCustomers and Whitenack's RequirementsSpecificationpattern, which descrives ways to capture requirements.