A commonly held misconception is that , during the Requirement phase, the developers must determine what software the cleint wants .

On the contrary, the real objective of the requirement phase, the real objective is what software the client needs .

The problem is that many clients do not know what they need. Further more, even a client who has good idea of what is needed may have difficulty in accurately conveying these ideas to developers. Hence the need for requirement elicitation

To elicit the client's needs, the members of the requiremnts team must be familiar with application domain, that is the < b> Context in which the proposed software is to be used.

For example, it is not easy to ask meaningful questions to banker without first aqcuiring some familiarity with banking.

Therefore, the initial tasks of each member of the requirement analysis team is to acquire familiarity with the application domain or the Context in that general area.

It is very important to use correct terminology when communicating with the client and potential users of the target software.

One way to solve the problem with terminology is to build a glossary, which is useful in lessing misunderstandings between the members of the development team.