軟件開發(fā)外文翻譯(已修改)
2024-11-17 21:04 本頁(yè)面
【正文】 1 Requirements Phase The chances of a product being developed on time and within budget are somewhat slim unless the members of the software development team agree on what the software product will do. The first step in achieving this unanimity is to analyze the client’s current situation as precisely as possible. For example, it is inadequate to say, “ They need a puteraided design system because they claim their manual design system, there is lousy. “ Unless the development team knows exactly what is wrong with the current manual system, there is a high probability that aspects of the new puterized system will be equally “l(fā)ousy. “ Similarly, if a personal puter manufacturer is contemplating development of a new operating system, the first step is to evaluate the firm’s current operating system and analyze carefully exactly why it is unsatisfactory. To take an extreme example, it is vital to know whether the problem exists only in the mind of the sales manager, who blames the operating system for poor sales, or whether users of the operating system are thoroughly disenchanted with its functionality and reliability. Only after a clear picture of the present situation has been gained can the team attempt to answer the critical question, What must the new product be able to do? The process 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
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1