Gathering Requirements

No rule says you can't work more closely with the business experts or someone who can act as proxy for the customers. (If there is such a "rule" where you work, and customers are off limits to you due to perceived time constraints or political reasons, we'd urge you to explore other career opportunities, if at all possible.) Seek out the parties responsible for producing business requirements. Ask them to tell you how they define quality for this application. Review the requirements document and see if it matches what they tell you. If you help the business experts clearly state what they want, you'll make a huge contribution toward the success of the project.

As the project proceeds, felling rainforests and contributing to global warming as it churns out paper, review ensuing documents, such as functional requirements and user interface design, with the customers. Keep working with them to define and refine their quality criteria and make sure these criteria are reflected in the documentation. Business experts are bound to change their minds on a daily basis, and in a traditional methodology, this is the time when it's okay for them to do so. Challenge them to think ahead, and help them visualize how the application is really going to work. Screen mockups or even drawings on a whiteboard can help them do this.

Prototyping and usability testing are a huge help, particularly for end-user-oriented applications, but few shops make this investment. Push for them anyway. You can be an agent for change. If nothing else, you'll have more fun at work (or possibly more frustration; we can't guarantee anything!).

If there's no formal usability testing, get samples of the application from the requirements and specification documents and show them to anyone who faintly resembles the ultimate user of the application. If you can't do this together with the business experts, give them feedback anyway. You may save them from locking themselves into a function or feature they'd be unhappy with later. Business experts are usually glad to have this kind of feedback. Just as when you report defects to programmers, keep the emotion out of your feedback. Point out your research results and let the marketing professional, product designer, or whoever your business expert is decide how to react.

Once you've gathered some information, do what you can to move the project along. The longer you spend on the requirements and definition phase, the more likely it is that the business expert's requirements will be obsolete by the time the software is delivered. Push whoever is managing the project to get signoff, and proceed to development as quickly as possible. Push for shorter releases and more iterative development. If you get discouraged and think nobody is open for change, talk with the development managers and tell them your ideas. You could be pleasantly surprised.