【正文】 xperience in that general area. It is particularly important to use correct terminology when municating with the client and potential users of the target software. After all, it is hard to be taken seriously by a person working in a specific domain unless the interviewer uses the nomenclature appropriate for that domain. More important, use of an inappropriate word may lead to a misunderstanding, eventually resulting in a faulty product being delivered. The same problem can arise if the members of the requirements team do not understand the subtleties of the terminology of the domain. One way to solve the problem with terminology is to build a glossary. The initial entries are inserted while the team learns the application domain. Then the glossary is updated whenever the members of the requirements team encounter new terminology. Not only does such a glossary reduce confusion between client and developers, it also is useful in lessening misunderstandings between members of the development team. Once the requirements team have acquired familiarity with the domain, the next step is for them to start to determine the client’s needs, that is, requirements elicitation. Elicitation technique as follows: 2 1. Interviews. The members of the requirements team meet with members of the client anization until they are convinced that they have elicited all relevant information from the client and future users of the product. There are two basic types of interview, structured and unstructured. In a structured interview, specific, preplanned, closeended questions are posed. In an unstructured interview, openended questions are asked, to encourage the person being interviewed to speak out. Some of these facts might not have e to light had the interview been more structured. At the same time, it is not a good idea if the interview is too unstructured. Therefore, questions should be posed in such a way as to encourage the person being interviewed to give wideranging answers but within the context of the information needed by the interviewer. Conducting a good interview is not always easy. First, the interviewer must be familiar with the application domain. Second, there is no point in interviewing a member of the client anization if the interviewer already has made up his or her mind regarding the client’s needs. No matter what he or she previously has been told or learned by other means, the interviewer must approach every interview with the intention of listening carefully to what the person being interviewed has to say while firmly suppressing any preconceived notions regarding the client pany or the needs of the clients and potential uses of the software product to be built. 2. Scenarios. A scenario is a way a user might utilize the target product to acplish some objective. A scenario can be depicted in a number of ways. One technique is simply to list the actions prising the scenario .Another technique is to set up a storyboard, a series of diagrams depicting the sequence of events. They can demonstrate the behavior of the product in a way that is prehensible to the user. This can result in additional requirements ing to light, as in the weightloss planner example. Because scenarios can be understood by users, the utiliza