軟件開發外文翻譯-資料下載頁

【導讀】abletodo?phase.

　　

【正文】 因為大多數客戶的計算機 知識比起軟件開發小組成員來講要少得多。 為了獲取客戶的要求，需求小組的成員必須熟悉應用領域，即提議中的軟件產品通常要在哪些領域使用。 例如，如果沒有首先對銀行業或護理專業有某種程度的熟悉，就不太容易向一個銀行家或護士問出有意義的問題。因此，每個需求小組成員最初的任務之一就是熟悉應用領域，除非他或她已經在那個領域有過一些經歷。 當與客戶和目標軟件的可能用戶交流時，特別重要的一點是使用正確的術語。畢竟，這一點很難引起工作在某一特定領域的人的重視，除非訪談者使用適于該領域的術語。更重要的是，使用一個不合適的術語可能會 導致曲解，甚至會造成發行一個有錯誤的軟件產品的結果。如果需求小組成員不理解該領域術語的細微差別，可能會產生同樣的問題。 解決術語問題的一個辦法是建立術語表，當需求分析小組成員開始學習應用領域知識時，將初始的詞條插入到術語表中，然后，每當需求分析小組成員遇到新的術語時就更新該術語表。這樣的術語表不僅減少了客戶和軟件開發者之間的誤解，而且在減輕開發小組成員之間的誤解方面也是很有用的。 一旦需求分析小組成員熟悉了該應用領域之后，下一步就是由他們來開始確定客戶的要求，即進行需求獲取。需求獲取技術 如下： 1． 訪談。 需求 小組成員會見客戶組織的成員，直到他們確信已經從客戶和該產品未來的用戶處獲取了所有相關信息。 有兩種基本的訪談類型， 程式 （ structured）和非程式化的 6 （ unstructured）。 在一個程式化的訪談中，提出特定的、預先計劃好的、受限回答的（ closeended）問題。在一個非程式化的訪談中，會提出可自由回答的（ openended）問題，以便鼓勵受訪人暢所欲言。要是訪談過于程式化了，有些事實可能就發現不了。與此同時，如果訪談太過于非程式化，這也不是一個好注意。 因此，應當以一種這樣的方式提出問題：他能夠鼓 勵受訪者給出范圍廣泛的回答，但該回答又不要超出訪談者所需信息的范圍。 進行一個好的訪談有時并不容易。首先，訪談者必須熟悉應用領域；其二，如果訪談者已經決意尊重客戶需求的話，訪談客戶組織的成員時是沒有訪談要點的。不管他或她先前被告知什么或通過其他方式了解過什么，訪談者必須帶著認真傾聽受訪者的目的著手開始每一次訪談，與此同時，堅決地克制任何預先固有的成見，尊重客戶公司的意見或客戶的要求以及要構建的產品的潛在用途。 2． 情景 。 一個情景是用戶可能利用目標產品完成某些目的的一種方式。 可以用多中方式描述情景。一種技術是簡 單地列出組成情景的行為。另一種技術是建立情景板（ story board），它是描述事件序列的一系列圖表。 它們能夠以一種用戶可以理解的方式說明軟件產品的行為，這會促使發現額外的需求。因為 情景能夠被用戶所理解，情景的 使用可以確保客戶和用戶在整個需求分析過程中自始至終發揮積極作用。 畢竟，需求分析階段的目標是獲取用戶的真正要求，并且信息的惟一來源是客戶和用戶。 情景（或更精確地說是用例（ user case））在面向對象的分析中發揮著重要作用。 3． 向相關的客戶組織成員發放問卷調查表 (questionnaire)。 這個技術在需要考慮比如說幾百個個體的需求意見時很有用。 進一步說，一個經過認真思考的書面答案可能比一個隨口而出的口頭回答更準確。然而，有一個很有辦法的訪談人進行的非程式化的訪談，由于他能夠認真傾聽受訪者的意見并提出進一步的問題，從而將起初得到的響應大大擴展了，這樣的比一個經過深思熟慮的紙面上的問卷調查表通常揭示出更多的信息。因為問卷調查表是預先計劃好的，所以就沒有辦法根據某一個回答再提出一個問題。 4． 檢查客戶所使用的各種表格 (form)。 例如，印刷廠的一張表格可能反映了印刷號、紙張軋壓尺寸、濕度、油墨溫度、紙張張力等等。這個表格中的各種域顯示了印刷工作的流程以及印刷過程，它也可以是準確找出“已做了什么”和“是如何做的”等的強有力工具。這些輔助理解的信息關心的是客戶眼下是如何從業的，它在決定客戶需求方面是特別有用的。因此，認真研讀 客戶文檔絕不應當僅僅被小看為一個信息源，它能夠導致準確地把握客戶的要求。 （ 當然事先要得到被觀察方的書面許可 ）正在做的事情。 7 這項技術的難點之一是它可能花費很長時間去分析錄像帶。通常，需求分析小組的一個或多個成員需要花上一個小時回放錄像機錄下的每個小 時的磁帶。這個時間對于評估所觀察到的東西而言是額外增加的，更嚴重的是，這一技術據說已經產生了嚴重的適得其反的結果，因為雇員可能將攝像機看做是對他們個人隱私的一種不當的入侵。重要的是需求分析小組要與雇員進行全面的合作，如果人們感到受威脅或受打擾，他們就很難獲得必要的信息。在引入攝像機或者采用任何其他有可能激怒雇員的行動前，可能的危險必須仔細考慮到。 獲取了最初的一系列需求之后，下一步就是提煉它們，這是一個稱為需求分析(requirements analysis)的過程。 需求小組成員與各個受訪者討論需求清 單，決定是否忽略了什么；然后因為最精確和有力的需求分析技術是快速原型開發，因此，要建立快速原型。 快速原型是倉促建立的軟件，該軟件展示了目標軟件產品的主要功能。客戶和該產品預定的用戶對快速原型進行實驗的同時，開發小組成員觀察并做記錄。根據他們豐富的實踐經驗，用戶告訴開發人員快速原型是否能夠滿足他們的要求，而且更重要的是，指出需改進的地方。隨后，開發人員改進快速原型，直至雙方確認客戶的要求已準確地包含在快速原型中，然后快速原型就作為擬訂規格說明的基礎。 快速原型開發模型的一個重要方面包含在 ”快速 ”一詞中，全部 的要旨是盡可能快速地建立原型。說到底，快速原型的目的是向客戶提供對軟件產品的理解，并且是盡可能快、盡可能好的理解。如果快速原型難以工作，如果它每隔幾分鐘就崩潰，或者如果屏幕布局不很完美，這些都不要緊。快速原型的意圖是使客戶和開發者能夠在該產品做哪些事情方面盡可能快速地達成一致意見，因此，快速原型中的任何不完美之處都可以忽略不計，前提是它們沒有嚴重損害快速原型的功能并讓人對產品的行為產生誤解。 快速原型開發的一個困難是，快速原型改變起來的容易性可能鼓勵客戶要求對所交付產品的工作級版本做各種主要的改變。進一步地 ，客戶可能期望實現的改變盡可能與對快速原型的改變一樣快。有關的問題是不得不向客戶結實快速原型不具有工作質量，客戶將要等待具有工作質量的版本，即使快速原型看起來做了 要求做的每件事。在使用快速原型開發之前，負責開發該產品的管理者與客戶討論這些相關問題是必須的。 至于新技術的引入，在一個組織提議使用快速原型開發模型前，至關重要的是管理者要意識到快速原型開發的優缺點。 公平地說，盡管快速原型開發的事例強有說服力，但還沒有證明他是無懈可擊的。 需求分析階段測試 盡管需求分析階段的目標是確定客戶的真正要求，通常客戶不是該 目標產品的最終用戶，于是有必要給用戶試驗快速原型并提出改進建議的機會，在征得客戶同意后，在軟件產品的交付版本中完成這種改變。 因此，在快速原型開發階段，軟件質量保證小組的任務是確保客戶組織中的有關人 8 員有機會與快速原型交互，并且保證讓他們的建議確實送達負責分析用戶建議的客戶(也可能是一個客戶管理者委員會 )。 在將要到來的那個階段，從測試的觀點來看需求是可跟蹤的，這一點非常重要。要達到這個要求，應當將需求的說明編號，從而使 SQL 能夠在隨后的階段中跟蹤它們。在快速原型中，編號應當以注釋的形式在需求中每一組說明之后 出現。