It's easy to get caught up in the inertia of a project and forget to ask exactly what we are developing, who our customers are, and what their goals with our software might be. Few software projects have the time and budget to figure out what their project is through trial and error. Getting clarity on project focus not only helps productivity, working to create software that people actually need increases our chances for success.

People often point to requirements documents and process manuals as ways to guide a new tester. Research into knowledge transfer, as described in The Social Life of Information, suggests that there is much more to the process of learning. Michael Bolton describes his own experiences on a new project, noting how the documentation helped ... and didn't.

Imprecise language makes understanding and, therefore, software verification more difficult. This article describes techniques for detecting and repairing vague and ambiguous software requirements.

In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements.