Capturing Implied Requirements


get answers to your questions efficiently and to maximize the helpfulness of your time in each interview.

After the Interviews
Be sure you've exhausted the pool of people available who can give you insight into the possible incompleteness areas and insight into any other implied requirements. Incorporate the answers to your questions into your notes, which should now look more like actual requirements items to add to the formal document.

Vet and Implement the Interview Results
Vetting your interview results means sifting through your notes and identifying those that should be added to the requirements document. After the interviews, some items may need further discussion or a second opinion from another key stakeholder. For example, you may want to discuss the splash screen with both the marketing director and the vice president of sales. Make those judgments as you go.

Now that you've captured implied requirements, you should be ready to start converting implied requirements into documented requirements. The punch line, of course, is that as you revise, you will find more areas of possible incompleteness (not to mention the endless changes that will ensue). Reviewing a complex document will generate questions ad infinitum , so you just have to decide when to stop, which could be the most important decision the RG makes.

A Good Place to Start-Common Area Where Implied Requirements Hide
Implied requirements commonly exist in the area of user workflow. Don't confuse workflow with use cases, though. Use cases are part of the puzzle, but requirements are also driven by where use cases fit into the user's larger workflow.

In the 1990s, software programs were not intuitive as a rule. It was the programmers who decided how to organize functionality and where to put features. Design had nothing to do with user workflow. The conventional wisdom in many companies was that the Help system, especially the context-sensitive component, was there to train people and reduce the pain of the steep learning curve. In the 1990s, my job was to write and develop these Help systems. I'll conclude this article with the story of how capturing implied requirements through a key interview saved a Help system.

By the 2000s, as more people used software programs for more everyday purposes, user workflow migrated from Help systems into the actual product design. Nowadays, user workflow should be central to any requirements document, but you will find that a lot of workflow components are missing. If you have the luxury of being able to interview actual users, you'll find that workflow is still the biggest gap, and where you are almost certain to find implied requirements.

A Case from the Archives
For one of my Help system projects completed in the 1990s, I had finished a highly organized, logical Help system that I thought was a masterpiece. It fully and comprehensively reflected the structure and flow of the product design. I finished several weeks before the release date, and I had an opportunity to go onsite to spend an hour with an actual user. The users of this software product were van drivers, and the product was on their laptops, which they carried with them in the field. I took the beta product with my Help system integrated on a laptop to chat with John, a man who had been a driver for twenty years and was now a supervisor of drivers.

With my suit and tie and a new haircut, I showed John the best new components of my Help system. John's first response was, "That's the same old hard-to-use Help we've been stuck with for years." My one-hour

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.