Capturing Implied Requirements


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.

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

About the author

Robert Rose-Coutré's picture Robert Rose-Coutré

Robert Rose-Coutré is a consultant with Trellist Marketing and Technology, serving as Digital Project Manager creating multilanguage country sites globally for DuPont. Robert started as a professional proofreader in 1986 and started managing teams in 1987. He has built, managed, and edited commercially successful websites; led SD QA efforts; helped launch and manage the Test/QA website in 2000, directed publishing in several industries; and once in a while writes for enjoyment. Robert earned an M.A. in English Literature and Letters, and published two books. Memberships include Senior Member - Association for Software Quality, British Museum, Mensa, and the World Intelligence Network. Contact

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!