Capturing Implied Requirements


meeting turned into three hours. I questioned John extensively on what he wanted to see, how the drivers normally used the Help system, and how he would like to see the Help system work. John was absolutely delighted that the person actually producing the Help system was there listening to him explain his dissatisfactions and his needs.

Three weeks later at release, the Help system looked completely different. It now included specific common-usage walkthroughs, much different cross-referencing, reorganized tables of contents designed in conformance with user workflow, and a design-structure table of contents as a secondary view.

My boss and the CEO of the company received phone calls from John expressing his appreciation for the meeting with the "Help guy" and for the much improved system. Within six months, I received a bonus and a promotion. I cannot say for sure that those rewards were a direct result of the revised Help system, but I am sure it was a factor. The most important moral of the story, however, is that you need to capture implied requirements if you want to deliver the product that the customer wants to use.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.