【正文】 ow 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ā)出來的機會有時是很小的，除非軟件開發(fā)小組的成員對軟件產(chǎn)品將做什么都一致理解?；蛘咴摬僮飨到y(tǒng)的用戶是否完全不認同它的功能和可靠性？僅當對于當前情形有了一個清晰的認識之后，軟件開發(fā)小組才能夠試圖回答關(guān)鍵的問題，即新的軟件產(chǎn)品必須能夠做什么？回答這個問題的過程在需求分析階段完成。 為了獲取客戶的要求，需求小組的成員必須熟悉應(yīng)用領(lǐng)域，即提議中的軟件產(chǎn)品通常要在哪些領(lǐng)域使用。畢竟，這一點很難引起工作在某一特定領(lǐng)域的人的重視，除非訪談?wù)呤褂眠m于該領(lǐng)域的術(shù)語。這樣的術(shù)語表不僅減少了客戶和軟件開發(fā)者之間的誤解，而且在減輕開發(fā)小組成員之間的誤解方面也是很有用的。 有兩種基本的訪談類型， 程式 （ structured）和非程式化的 6 （ unstructured）。與此同時，如果訪談太過于非程式化，這也不是一個好注意。不管他或她先前被告知什么或通過其他方式了解過什么，訪談?wù)弑仨殠еJ真傾聽受訪者的目的著手開始每一次訪談，與此同時，堅決地克制任何預(yù)先固有的成見，尊重客戶公司的意見或客戶的要求以及要構(gòu)建的產(chǎn)品的潛在用途。一種技術(shù)是簡 單地列出組成情景的行為。 畢竟，需求分析階段的目標是獲取用戶的真正要求，并且信息的惟一來源是客戶和用戶。 進一步說，一個經(jīng)過認真思考的書面答案可能比一個隨口而出的口頭回答更準確。 例如，印刷廠的一張表格可能反映了印刷號、紙張軋壓尺寸、濕度、油墨溫度、紙張張力等等。 （ 當然事先要得到被觀察方的書面許可 ）正在做的事情。重要的是需求分析小組要與雇員進行全面的合作，如果人們感到受威脅或受打擾，他們就很難獲得必要的信息。 快速原型是倉促建立的軟件，該軟件展示了目標軟件產(chǎn)品的主要功能。 快速原型開發(fā)模型的一個重要方面包含在 ”快速 ”一詞中，全部 的要旨是盡可能快速地建立原型。 快速原型開發(fā)的一個困難是，快速原型改變起來的容易性可能鼓勵客戶要求對所交付產(chǎn)品的工作級版本做各種主要的改變。 至于新技術(shù)的引入，在一個組織提議使用快速原型開發(fā)模型前，至關(guān)重要的是管理者要意識到快速原型開發(fā)的優(yōu)缺點。 在將要到來的那個階段，從測試的觀點來看需求是可跟蹤的，這一點非常重