Requirements Versus On-Site Customer

Johnny was an expert in the system. He was the designer and programmer on the original system years earlier. During my work on the project, his role was systems engineer. From his vast knowledge of the system, he wrote the requirements spec. We worked together to extract the names of the use cases implied by the requirements. Johnny would elaborate the requirements just in time for us to design and implement them. Johnny was always under pressure to deliver the next batch of use cases. Sometimes it took him longer to figure out the use cases than it took for us to implement them. That always upset him. It was working quite well. I really came to appreciate having an on-site customer.

One day, Johnny, Paul, and I had finished reviewing the use cases and went to start the development work. We worked out the impact of the new use case on the existing design. We used a high-tech tool known as a whiteboard. The system design was in our heads, so we extracted enough of the design, putting it on the whiteboard, and talked through the changes. Once we were happy with our direction, Paul and I went to Paul's cube to get started.

Within minutes of starting, we had a problem. We read the detailed use case again. There was an area of interpretation. We had just discussed it with Johnny a half hour before, but Paul said, "Johnny said we should retry the transaction under these conditions." I said, "No, in this case, we are supposed to log a message and continue. ...

Get Beautiful Teams now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.