【正文】 ter if the rapid prototype hardly works, if it crashes 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 seriously 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 changes to the delivered operationalquality 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 client will have to wait for the operationalquality version, even though the rapid prototype appears to do everything needed. Before rapid prototyping is used, it is 4 essential that the managers responsible for developing the product discuss these and related issues with the client. As with the introduction of any new technology, before an anization 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. Testing during the requirements phase Although the aim of the requirements phase is to establish the client’s 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 changes 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 anization have the opportunity to interact with the rapid prototype and their suggestions actually reach the client or, perhaps, a mittee of client managers responsible for analyzing the suggestions of the users. Form the viewpoint of testing during the phases that are to e, it is essential that the requirements be traceable. To 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 ments adjacent to the group of statements that implements each item in the requirements. 5 外文翻譯 需求階段 將一個軟件產(chǎn)品及時而又不超出預(yù)算地開發(fā)出來的機(jī)會有時是很小的，除非軟件開發(fā)小組的成員對軟件產(chǎn)品將做什么都一致理解。 要達(dá)到這種全體一致首先是盡可能精確地分析客戶當(dāng)前的狀態(tài)形勢，例如，這樣說是不合適的：“因?yàn)樗麄儽г顾麄兊娜斯ぴO(shè)計(jì)系統(tǒng)很糟 ，所以他們需要一個計(jì)算機(jī)輔助設(shè)計(jì)系統(tǒng)?！?除非軟件開發(fā)小組明確地知道當(dāng)前人工系統(tǒng)有什么問題，否則，很有可能新的計(jì)算機(jī)系統(tǒng)將會在許多方面一樣地糟。同樣，如果 一個個人計(jì)算機(jī)制造商正打算開發(fā)一個新的操作系統(tǒng)，第一步是評價企業(yè)單前的操作系統(tǒng)，并認(rèn)真準(zhǔn)確地分析為什么它 不能令人滿意。或者該操作系統(tǒng)的用戶是否完全不認(rèn)同它的功能和可靠性？僅當(dāng)對于當(dāng)前情形有了一個清晰的認(rèn)識之后，軟件開發(fā)小組才能夠試圖回答關(guān)鍵的問題，即新的軟件產(chǎn)品必須能夠做什么？回答這個問題的過程在需求分析階段完成。 人們通常持有的一個錯誤概念是，在需求分析階段，開發(fā)者必須客戶想要什么樣的軟件。與此相反，需求分析階段真正的目標(biāo)是確定客戶需要什么樣的軟件。問題在于許多客戶不知道他們需要什么，更進(jìn)一步說，即使一個客戶對什么是他們所需要的有一個好的想法，他也可能難于準(zhǔn)確地將這些想法傳達(dá)給開發(fā)者，