requirements gathering

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating those risks.

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.

In part 1 of this article (published as a weekly column on May 22), Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management.

When deciding how a user's task is to be supported in our software, we often look at possible design solutions and select one that's best for the product and the user. As the project deadline approaches, however, we might choose to dismiss some features outright. In this column, Jeff Patton suggests we try keeping more features by adjusting their scale.