軟件開發(fā)外文翻譯-文庫吧資料
2024-11-09 21:04本頁面
【正文】 of answering this question is carried out during the requirements phase. A monly held misconception is that , during the requirements phase, the developers must determine what software the client wants. On the contrary, the real objective of the requirements phase is to determine what software the client needs. The problem is that many clients do not know what they need. Furthermore, even a client who has a good idea of what is needed may have difficulty in accurately conveying these ideas to the developers, because most clients are less puter literate than the members of the development team. To elicit the client’s needs, the members of the requirements team must be familiar with the application domain, that is, the general area in which the proposed software product is to be used. For example, it is not easy to ask meaningful questions of a banker or a nurse without first acquiring some familiarity with banking or nursing. Therefore, one of the initial tasks of each member of the requirements analysis team is to acquire familiarity with the application domain unless he or she already has experience 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 appli
公司管理相關(guān)推薦
鄂ICP備17016276號-1