【正文】 roduces 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)品將做什么都一致理解。” 除非軟件開發(fā)小組明確地知道當(dāng)前人工系統(tǒng)有什么問題，否則，很有可能新的計算機系統(tǒng)將會在許多方面一樣地糟?；蛘咴摬僮飨到y(tǒng)的用戶是否完全不認同它的功能和可靠性？僅當(dāng)對于當(dāng)前情形有了一個清晰的認識之后，軟件開發(fā)小組才能夠試圖回答關(guān)鍵的問題，即新的軟件產(chǎn)品必須能夠做什么？回答這個問題的過程在需求分析階段完成。與此相反，需求分析階段真正的目標是確定客戶需要什么樣的軟件。 為了獲取客戶的要求，需求小組的成員必須熟悉應(yīng)用領(lǐng)域，即提議中的軟件產(chǎn)品通常要在哪些領(lǐng)域使用。因此，每個需求小組成員最初的任務(wù)之一就是熟悉應(yīng)用領(lǐng)域，除非他或她已經(jīng)在那個領(lǐng)域有過一些經(jīng)歷。畢竟，這一點很難引起工作在某一特定領(lǐng)域的人的重視，除非訪談?wù)呤褂眠m于該領(lǐng)域的術(shù)語。如果需求小組成員不理解該領(lǐng)域術(shù)語的細微差別，可能會產(chǎn)生同樣的問題。這樣的術(shù)語表不僅減少了客戶和軟件開發(fā)者之間的誤解，而且在減輕開發(fā)小組成員之間的誤解方面也是很有用的。需求獲取技術(shù) 如下： 1． 訪談。 有兩種基本的訪談類型， 程式 （ structured）和非程式化的 6 （ unstructured）。在一個非程式化的訪談中，會提出可自由回答的（ openended）問題，以便鼓勵受訪人暢所欲言。與此同時，如果訪談太過于非程式化，這也不是一個好注意。 進行一個好的訪談有時并不容易。不管他或她先前被告知什么或通過其他方式了解過什么，訪談?wù)弑仨殠еJ真傾聽受訪者的目的著手開始每一次訪談，與此同時，堅決地克制任何預(yù)先固有的成見，尊重客戶公司的意見或客戶的要求以及要構(gòu)建的產(chǎn)品的潛在用途。 一個情景是用戶可能利用目標產(chǎn)品完成某些目的的一種方式。一種技術(shù)是簡 單地列出組成情景的行為。 它們能夠以一種用戶可以理解的方式說明軟件產(chǎn)品的行為，這會促使發(fā)現(xiàn)額外的需求。 畢竟，需求分析階段的目標是獲取用戶的真正要求，并且信息的惟一來源是客戶和用戶。 3． 向相關(guān)的客戶組織成員發(fā)放問卷調(diào)查表 (questionnaire)。 進一步說，一個經(jīng)過認真思考的書面答案可能比一個隨口而出的口頭回答更準確。因為問卷調(diào)查表是預(yù)先計劃好的，所以就沒有辦法根據(jù)某一個回答再提出一個問題。 例如，印刷廠的一張表格可能反映了印刷號、紙張軋壓尺寸、濕度、油墨溫度、紙張張力等等。這些輔助理解的信息關(guān)心的是客戶眼下是如何從業(yè)的，它在決定客戶需求方面是特別有用的。 （ 當(dāng)然事先要得到被觀察方的書面許可 ）正在做的事情。通常，需求分析小組的一個或多個成員需要花上一個小時回放錄像機錄下的每個小 時的磁帶。重要的是需求分析小組要與雇員進行全面的合作，如果人們感到受威脅或受打擾，他們就很難獲得必要的信息。 獲取了最初的一系列需求之后，下一步就是提煉它們，這是一個稱為需求分析(requirements analysis)的過程。 快速原型是倉促建立的軟件，該軟件展示了目標軟件產(chǎn)品的主要功能。根據(jù)他們豐富的實踐經(jīng)驗，用戶告訴開發(fā)人員快速原型是否能夠滿足他們的要求，而且更重要的是，指出需改進的地方。 快速原型開發(fā)模型的一個重要方面包含在 ”快速 ”一詞中，全部 的要旨是盡可能快速地建立原型。如果快速原型難以工作，如果它每隔幾分鐘就崩潰，或者如果屏幕布局不很完美，這些都不要緊。 快速原型開發(fā)的一個困難是，快速原型改變起來的容易性可能鼓勵客戶要求對所交付產(chǎn)品的工作級版本做各種主要的改變。有關(guān)的問題是不得不向客戶結(jié)實快速原型不具有工作質(zhì)量，客戶將要等待具有工作質(zhì)量的版本，即使快速原型看起來做了 要求做的每件事。 至于新技術(shù)的引入，在一個組織提議使用快速原型開發(fā)模型前，至關(guān)重要的是管理者要意識到快速原型開發(fā)的優(yōu)缺點。 需求分析階段測試 盡管需求分析階段的目標是確定客戶的真正要求，通?？蛻舨皇窃?目標產(chǎn)品的最終用戶，于是有必要給用戶試驗快速原型并提出改進建議的機會，在征得客戶同意后，在軟件產(chǎn)品的交付版本中完成這種改變。 在將要到來的那個階段，從測試的觀點來看需求是可跟蹤的，這一點非常重要。在快速原型中，編號應(yīng)當(dāng)以注釋的形式在需求中每一組說明之后 出