软件开发外文翻译

1、Requirements PhaseThe 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 clients current situation as precisely a

2、s possible. For example, it is inadequate to say, “ They need a computer-aided 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 co

3、mputerized system will be equally “lousy. “ Similarly, if a personal computer manufacturer is contemplating development of a new operating system, the first step is to evaluate the firms current operating system and analyze carefully exactly why it is unsatisfactory. To take an extreme example, it i

4、s 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

5、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 commonly held misconception is that , during the requirements phase, the developers must determine what software

6、 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 t

7、hese ideas to the developers, because most clients are less computer literate than the members of the development team.To elicit the clients 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 t

8、o 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 unles

9、s he or she already has experience in that general area. It is particularly important to use correct terminology when communicating 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

10、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 termino

11、logy 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

12、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 clients needs, that is, requirements elic

13、itation. Elicitation technique as follows: 1. Interviews.The members of the requirements team meet with members of the client organization 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

14、, structured and unstructured. In a structured interview, specific, preplanned, close-ended questions are posed. In an unstructured interview, open-ended questions are asked, to encourage the person being interviewed to speak out. Some of these facts might not have come to light had the interview be

15、en 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 wide-ranging answers but within the context of the information needed by the interviewer.Conductin

16、g 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 organization if the interviewer already has made up his or her mind regarding the clients needs. No matter what he or she previ

17、ously 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 company or the needs of the clients and potent

18、ial uses of the software product to be built.2. Scenarios.A scenario is a way a user might utilize the target product to accomplish some objective. A scenario can be depicted in a number of ways. One technique is simply to list the actions comprising the scenario .Another technique is to set up a st

19、oryboard, a series of diagrams depicting the sequence of events.They can demonstrate the behavior of the product in a way that is comprehensible to the user. This can result in additional requirements coming to light, as in the weight-loss planner example. Because scenarios can be understood by user

20、s, the utilization of scenarios can ensure that the client and users play an active role throughout the requirements analysis process. After all, the aim of the requirements analysis phase is to elicit the real needs of the client, and the only source of this information is the client and the users.

21、 Scenarios(or more precisely, use cases) play an important role in object-oriented analysis.3. To send a questionnaire to the relevant members of the client organization.This technique is useful when the opinions of, say, hundreds of individuals need to be determined. Furthermore, a carefully though

22、t-out written answer may be more accurate than an immediate verbal response to a question posed by an interviewer. However, an unstructured interview conducted by a methodical interviewer who listens carefully and poses questions that expand on initial responses usually yields far better information

23、 than a thoughtfully worded questionnaire. Because questionnaires are preplanned, there is no way that a question can be posed in response to an answer.4. To examine the various forms used by the client.For example, a form in a print shop might reflect press number, paper roll size, humidity, ink te

24、mperature, paper tension, and so on. The various fields in this form shed light on the flow of print jobs and the relative importance of the steps in the printing process. Other documents, such as operating procedures and job descriptions, also can be powerful tools for finding out exactly what is d

25、one and how. Such comprehensive information regarding how the client currently does business can be extraordinarily helpful in determining the clients needs. Therefore, careful perusal of client documentation should never be overlooked as a source of information that can lead to an accurate assessme

26、nt of the clients needs.5. To set up videotape cameras within the workplace to record (with the prior written permission of those being observed) exactly what is being done.One difficulty of this technique is that it can take a long time to analyze the tapes. In general, one or more members of the r

27、equirements analysis team has to spend an hour playing back the tape for every hour that the cameras record. This time is in addition to what is needed to assess what was observed. More seriously, this technique has been known to backfire badly because employees may view the cameras as an unwarrante

28、d invasion of privacy. It is important that the requirements analysis team have the full cooperation of all employees; it can be extremely difficult to obtain the necessary information if people feel threatened or harassed. The possible risks should be considered carefully before introducing cameras

29、 or, for that matter, taking any other action that has the potential to anger employees. An initial set of requirements has been elicited, the next step is to refine them, a process called requirements analysis. The members of the requirements team discuss the list of requirements with the various i

30、ndividuals interviewed to determine if anything has been omitted. Then, because the most accurate and powerful requirements analysis technique is rapid prototyping, a rapid prototype is built.A rapid prototype is hastily built software that exhibits the key functionality of the target product. The c

31、lient and intended users of the product now experiment with the rapid prototype, while members of the development team watch and take notes. Based on their hands-on experience, users tell the developers how the rapid prototype satisfies their needs and, more important, identify the areas that need i

32、mprovement. The developers change the rapid prototype until both sides are convinced that the needs of the client are accurately encapsulated in the rapid prototype. The rapid prototype then is used as the basis for drawing up the specifications. An important aspect of the rapid prototyping model is

33、 embodied in the word rapid. The whole idea is to build the prototype as quickly as possible. After all, the purpose of the rapid prototype is to provide the client with an understanding of the product, and the sooner, the better. It does not matter if the rapid prototype hardly works, if it crashes

34、 every few minutes, or if the screen layouts are less than perfect. The purpose of the rapid prototype is to enable the client and the developers to agree as quickly as possible on what the product is to do. Therefore, any imperfections in the rapid prototype may be ignored, provided they do not ser

35、iously impair the functionality of the rapid prototype and thereby give a misleading impression of how the product will behave.One difficulty with rapid prototyping is that the ease with which changes generally can be made to a rapid prototype may encourage the client to request all sorts of major c

36、hanges to the delivered operational-quality version of the product. Furthermore, the client may expect the changes to be implemented as rapidly as changes to the rapid prototype. A related challenge is having to explain to the client that the rapid prototype is not of operational quality and the cli

37、ent will have to wait for the operational-quality version, even though the rapid prototype appears to do everything needed. Before rapid prototyping is used, it is essential that the managers responsible for developing the product discuss these and related issues with the client.As with the introduc

38、tion of any new technology, before an organization introduces the rapid prototyping model it is vital that management be aware of the advantages and disadvantages of rapid prototyping. In all fairness, although the case for rapid prototyping is strong, it has not yet been proven beyond all doubt.Tes

39、ting during the requirements phaseAlthough the aim of the requirements phase is to establish the clients real needs, usually the client will not be the primary user of the target product. It therefore is essential to give the users the opportunity to experiment with the rapid prototype and suggest c

40、hanges that, when approved by the client, will be implemented in the delivered version of the software product.Therefore, the role of the software quality assurance group during the rapid prototyping phase is to ensure that the relevant individuals in the client organization have the opportunity to

41、interact with the rapid prototype and their suggestions actually reach the client or, perhaps, a committee of client managers responsible for analyzing the suggestions of the users.Form the viewpoint of testing during the phases that are to come, it is essential that the requirements be traceable. T

42、o achieve this, the statements of the requirements need to be numbered to enable the SQA to trace them through the subsequent phases. The numbering should appear in the rapid prototype in the form of comments adjacent to the group of statements that implements each item in the requirements.外文翻译需求阶段将

43、一个软件产品及时而又不超出预算地开发出来的机会有时是很小的，除非软件开发小组的成员对软件产品将做什么都一致理解。要达到这种全体一致首先是尽可能精确地分析客户当前的状态形势，例如，这样说是不合适的：“因为他们抱怨他们的人工设计系统很糟，所以他们需要一个计算机辅助设计系统。”除非软件开发小组明确地知道当前人工系统有什么问题，否则，很有可能新的计算机系统将会在许多方面一样地糟。同样，如果一个个人计算机制造商正打算开发一个新的操作系统，第一步是评价企业单前的操作系统，并认真准确地分析为什么它不能令人满意。或者该操作系统的用户是否完全不认同它的功能和可靠性？仅当对于当前情形有了一个清晰的认识之后，软件开

44、发小组才能够试图回答关键的问题，即新的软件产品必须能够做什么？回答这个问题的过程在需求分析阶段完成。人们通常持有的一个错误概念是，在需求分析阶段，开发者必须客户想要什么样的软件。与此相反，需求分析阶段真正的目标是确定客户需要什么样的软件。问题在于许多客户不知道他们需要什么，更进一步说，即使一个客户对什么是他们所需要的有一个好的想法，他也可能难于准确地将这些想法传达给开发者，因为大多数客户的计算机知识比起软件开发小组成员来讲要少得多。为了获取客户的要求，需求小组的成员必须熟悉应用领域，即提议中的软件产品通常要在哪些领域使用。例如，如果没有首先对银行业或护理专业有某种程度的熟悉，就不太容易向一个银

45、行家或护士问出有意义的问题。因此，每个需求小组成员最初的任务之一就是熟悉应用领域，除非他或她已经在那个领域有过一些经历。当与客户和目标软件的可能用户交流时，特别重要的一点是使用正确的术语。毕竟，这一点很难引起工作在某一特定领域的人的重视，除非访谈者使用适于该领域的术语。更重要的是，使用一个不合适的术语可能会导致曲解，甚至会造成发行一个有错误的软件产品的结果。如果需求小组成员不理解该领域术语的细微差别，可能会产生同样的问题。解决术语问题的一个办法是建立术语表，当需求分析小组成员开始学习应用领域知识时，将初始的词条插入到术语表中，然后，每当需求分析小组成员遇到新的术语时就更新该术语表。这样的术语表

46、不仅减少了客户和软件开发者之间的误解，而且在减轻开发小组成员之间的误解方面也是很有用的。一旦需求分析小组成员熟悉了该应用领域之后，下一步就是由他们来开始确定客户的要求，即进行需求获取。需求获取技术如下：1 访谈。需求小组成员会见客户组织的成员，直到他们确信已经从客户和该产品未来的用户处获取了所有相关信息。有两种基本的访谈类型，程式（structured）和非程式化的（unstructured）。在一个程式化的访谈中，提出特定的、预先计划好的、受限回答的（close-ended）问题。在一个非程式化的访谈中，会提出可自由回答的（open-ended）问题，以便鼓励受访人畅所欲言。要是访谈过于程式

47、化了，有些事实可能就发现不了。与此同时，如果访谈太过于非程式化，这也不是一个好注意。因此，应当以一种这样的方式提出问题：他能够鼓励受访者给出范围广泛的回答，但该回答又不要超出访谈者所需信息的范围。进行一个好的访谈有时并不容易。首先，访谈者必须熟悉应用领域；其二，如果访谈者已经决意尊重客户需求的话，访谈客户组织的成员时是没有访谈要点的。不管他或她先前被告知什么或通过其他方式了解过什么，访谈者必须带着认真倾听受访者的目的着手开始每一次访谈，与此同时，坚决地克制任何预先固有的成见，尊重客户公司的意见或客户的要求以及要构建的产品的潜在用途。2 情景。一个情景是用户可能利用目标产品完成某些目的的一种方式

48、。可以用多中方式描述情景。一种技术是简单地列出组成情景的行为。另一种技术是建立情景板（story board），它是描述事件序列的一系列图表。它们能够以一种用户可以理解的方式说明软件产品的行为，这会促使发现额外的需求。因为情景能够被用户所理解，情景的使用可以确保客户和用户在整个需求分析过程中自始至终发挥积极作用。毕竟，需求分析阶段的目标是获取用户的真正要求，并且信息的惟一来源是客户和用户。情景（或更精确地说是用例（user case）在面向对象的分析中发挥着重要作用。3 向相关的客户组织成员发放问卷调查表(questionnaire)。这个技术在需要考虑比如说几百个个体的需求意见时很有用。进一步说，一个经过认真思考的书面答案可能比一个随口而出的口头回答更准确。然而，有一个很有办法的访谈人进行的非程式化的访谈，由于他能够认真倾听受访者的意见并提出进一步的问题，从而将起初得到的响应大大扩展了，这样的比一个经过深思熟虑的纸面上的问卷调查表通常揭示出更多的信息。因为问卷调