Glossary

I have been big on the idea of creating a glossary of the terms and jargon that are embedded in a specific client's problem domain, and doing this very early in the project lifecycle. The justification is that these terms are often thrown around early and throughout a project, but their meanings are not all grasped by everyone until much later. Also, the people on the client's side often disagree among themselves about particular terms' definitions. This lack of clarity often results in subtle bugs in the system, or simply in expensive rework downstream. A quick search shows that some requirements methodologies (such as Steeltrace and maybe others) already encourage this. Putting it into practice seems like a lesser priority to some, but I think this is one of those little things with a big payoff that's hard to measure.