Sometimes the user, project sponsor, and other key stakeholders haven't provided in the requirements documentation all the expectations of the software you're building. Instead, these expectations are only implied. In a perfect requirements-gathering process, there would be no such thing as an "implied requirement" because every requirement would be captured in the document. But no process is perfect, in theory or in practice. This article should help you look for and recognize the presence of implied requirements and learn how to capture them and convert them to documented requirements.
The Requirements Guru
Before you can begin capturing implied requirements, you need to fully grasp everything in the current requirements document. This may seem elementary, but often no one person on the project team understands every item in the requirements document. That's why you need a requirements guru (RG).
One likely candidate for the RG role is a QA manager, if your company has one. Regardless who you chose, the RG must be able to grasp user nuances, high-level business needs, and detailed technical specifications. Obviously, this person must also have the authority to edit the document and access to talk to the key stakeholders, including end-users. (Caveat: for projects with a large staff, the RG could be a small group of two or three people-but the fewer the better.)
Verifying Requirements Integrity
You should review the document and implement the usual steps in bolstering the its integrity. That is, verify that every item in the requirements is unambiguous and correct and that items are not jumbled together. Each requirement should be reduced to the smallest possible piece, recorded as its own line item, and separated from other items. Also, verify that all the requirements are organized in a way that makes sense with the workflow of the product. This preliminary editorial work is a major project in itself.
The formula for verifying requirements integrity generally includes "completeness." So review with an eye for completeness, and take detailed notes wherever you see definite or possible incompleteness. As you detect and note incompleteness, you are starting the process of capturing implied requirements.
Obviously, wherever you see "definite incompleteness" and you know what needs to be added, you simply add it to the document in its proper place (with appropriate input and notifications). But where you see "possible incompleteness" you will need to save your notes for future reference. These notes serve as your worksheet for capturing implied requirements.
Interviews
Most people know the importance of interviews in the requirements-gathering process. Interviews are also a critical step in capturing implied requirements.
By this time, you have edited and organized the requirements document, as well as analyzed it for possible incompleteness. So you should be intimately familiar with its contents. You should also have notes saved that outline areas that seem incomplete, perhaps with some idea of what may need to be added. Now it's time to fill in the gaps.
One of the best places to start is to re-interview the same people who were interviewed in the initial requirements-gathering process. You may also find it helpful to interview some people who were left out of the initial process, based on the areas of incompleteness you've discovered.
Your notes will be most helpful if they are organized logically according to relevant areas of the product. They will be even easier to use in your interviews if they also are organized based on the relevant area of requirements (e.g., technical, end-user, business). For example, if the product's Search feature has missing requirements, some are technical and some user-interface related, include the technical Search issue in your list of questions for the development representative, and include the user-interface issue in your list of questions for the end-user. Part of your worksheet may look something like this:
 |
This table is an example of one way to categorize and organize questions. Yours may be different. The important thing is to organize your notes for quick-and-easy reference, which helps you in two ways:
1. It helps you to easily identify with whom you need to set up interviews.
2. It helps you during the interview, to 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 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.
