Most software applications are not used by their own developers; they are intended to be used by the developer's customers, clients , and end-users. This implies that someone in your development organization had better spend a lot of time communicating with users so that their requirements can be correctly understood . In the calculator example from the first commandment, a developer may be perfectly happy with the four basic arithmetic functions while the user would like a square root function or a memory function. What the developer thinks is a complete set of requirements isn't necessarily so.
Moving from a trivial to a real world example, an enterprise-wide IT application may have many types of users, each with their own business requirements. Take a payroll system for example. One type of user is the employee, whose requirements include getting paid the correct amount in a timely fashion. A second type of user is a manager, who wants to be able to administer salary increases and track budgets . A third type of user might be the HR administrator, who wants to compare salary ranges across an entire organization. Each user type will have unique requirements.
The second part of this commandment focuses on the word "often." Frequent communication is required, among other reasons, because English (or any other modern language) is an imprecise language. Communication with users only starts at the requirements definition phase. A developer may have to discuss a requirement with a user several times before the true definition of the requirement is captured. In addition, user requirements are likely to change often, and indeed several requirements may even conflict. Frequent communication with users gives the developer early notice of requirements changes the user is considering.
A successful software development organization has established processes for frequently communicating with users during all stages of the development process. The sooner an incorrect or missing requirement is discovered , the easier it is to fix the problem. Many successful development organizations have made customer advisory teams an integral part of the software development process. Such customer teams participate in all stages of development from initial requirements gathering to production acceptance signoff. The Web-Centric Production Acceptance (WCPA) process presented in Chapter 13 is another vehicle for bringing users and developers together and promoting and instilling good communication practices.