【正文】 （5） 訪談中最好及時用草圖繪制模型（用例、DFD、思維圖）。（3） 靈活采用封閉式問題（類似判斷題）、半封閉式問題（類似選擇題）和開放式問題（類似簡答題）。在此描述主要的一些策略或技巧。需要注意的是，每一次交流一定要求記錄，對于交流的結果還可以進行分類，便于后續(xù)的分析活動。 訪談的溝通技巧訪談過程是一個對溝通技巧要求較高的活動，要求訪談者善于傾聽、善于表達。在不同階段訪談不同類型的人，訪談的話題與目的也有所不同。然后，根據(jù)他們的要求來確定系統(tǒng)的整體目標和系統(tǒng)的工作范圍。216。缺點是占用時間長，信息可能存在片面性。216。1. 用戶訪談用戶訪談是最常見、也是最基本的需求獲取技術。計劃性體現(xiàn)在對調研對象、問題、實踐的計劃；科學性則表現(xiàn)在如何有效地選擇合適的方法。如何提高需求獲取的有效性一直以來是困擾大家的問題。圖表 31：需求開發(fā)工作一般在整個軟件開發(fā)過程中要至少需要迭代三次。圖表 23需求工程工作量分布圖示第3章. 需求開發(fā)3.. 需求開發(fā)管理需求開發(fā)工作要點包括需求獲取、需求分析、需求規(guī)格編寫、需求評審四個具體的活動。最大的好處就是在開發(fā)后期和整個維護階段的返工的工作量可以大大減少。需求管理則是對需求的實現(xiàn)、變化進行追蹤的全過程，重點在于開發(fā)的軟件滿足這些需求。如圖表 22需求工程圖所示，需求工程包括需求開發(fā)和需求管理兩大范疇。但唯獨只有需求被稱為工程?？沈炞C性則是說明需求提供了驗證所需的信息，也能夠指導測試活動。如下表示例。相對科學的劃分優(yōu)先級有充分性和必要性兩個維度。要想更好地對項目進行管理，就需要有效的區(qū)分出優(yōu)先級。2) 無歧義性：歧義主要是不同背景的人在傳遞時加入不同理解而導致的，因此僅靠文檔來傳遞需求是不充分的，文檔無法代替溝通，還需要配合一些驗證活動才能夠盡可能的緩解歧義問題。一方面是在調研階段找多方面的人來獲取需求。2. 不失真需求的正確性和無歧義性是一組相關的要求，指的是確保需求在信息傳遞的過程中不失真。1) 必須從業(yè)務角度來組織各種需求項。這點在實際需求活動中很難做到或衡量。下文將其分為四組，逐一介紹。對于那些無法實現(xiàn)的要求，應向用戶做充分的解釋，以求得用戶的諒解。需要注意的是，必須全面理解用戶的各項要求，但又不能全盤接受用戶所有的要求，因為用戶提出的要求并非都是合理的。項目需求管理過程主要包括對用戶提出的出示需求的確認過程和對用戶提出需求變更的控制過程。項目的計劃、項目的開發(fā)活動及開發(fā)的產品應與項目需求保持一致，隨需求的變化而調整。即使設計和實現(xiàn)的再正確可靠，也不是用戶真正想要的東西。. 軟件需求的重要性開發(fā)軟件項目就像和用戶一起從河的兩邊開始修建橋梁，如果沒有很好的理解和管理用戶的需求，開發(fā)出來的軟件不是用戶希望的，那么這座橋就永遠不可能對接成功。例如，當前導購人員使用的平臺電腦的操作系統(tǒng)不支持FLASH插件、鄉(xiāng)村支局點的電腦配置較低等。216。 非技術因素決定的選型對軟件開發(fā)而言，技術選型會基于企業(yè)內部的相關規(guī)定。3. 設計約束設計約束看似簡單，但如果不了解而導致收集需求時出現(xiàn)遺漏的現(xiàn)象。因此開發(fā)人員會認為這項原則是可以破壞的。216。但很多開發(fā)人員根本不看它，因為這樣的定性描述是沒有標準的，因此信息的有效性不大。216。非功能需求比功能需求要求更嚴格，更不易滿足，因為如果不能滿足非功能需求，系統(tǒng)將無法運行。本教材推薦使用用例的方法。為了解決這個問題，現(xiàn)代需求理論更加強調需求分析人員從用戶的角度，將系統(tǒng)理解為一個黑盒子，從橫向的使用視角來整理需求。1. 功能需求對于功能需求而言，最為關鍵的地方是如何對其進行組織，否則一句話、一句話的描述就會顯得十分零散，很難保證開發(fā)人員逐一滿足這些需求。軟件需求規(guī)格在開發(fā)、測試、質量保證、項目管理以及相關項目功能中都起到了重要的作用。質量屬性是通過多種角度對產品的特性進行描述，從而反映產品功能。它包括：產品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)；非功能性需求（例如性能要求等）；設計或實現(xiàn)的約束條件及質量屬性。它是需求分析與建模的產物，即形成軟件需求規(guī)格。3. 軟件需求軟件需求定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶通過使用此軟件能完成它們的任務，從而滿足業(yè)務需求。 存在矛盾：由于用戶處于企業(yè)組織的不同層面、地域等，難免出現(xiàn)盲人摸象的現(xiàn)象，從而導致需求的片面性，甚至在不同用戶之間會有不同的觀點。 零散：用戶會提出不同角度、不同層面、不同粒度的需求，而且通常是以一句話的形式提出的。通常是在業(yè)務需求定義的基礎上進行用戶訪談、調查，對用戶使用的場景進行整理，從而建立用戶角度的需求。實際上在項目立項階段就整理完成了。圖表 21軟件需求按照層次1. 業(yè)務需求業(yè)務需求反映了組織機構或客戶對系統(tǒng)、產品高層次的目標要求，由管理人員或市場分析人員確定。對于軟件項目的需求，首先要明確用戶的要求，澄清模糊的需求，與用戶達成共識。軟件需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達到什么樣的性能。也許有很多人簡單地認為軟件需求就是用戶需要實現(xiàn)的功能加上一些非功能方面的要求。若要有效的解決問題，就需要反思問題背后的本質原因，掌握需求理論與工作方法，針對性的找到適用的需求方法，構思、嘗試出真正在本組織內有效的緩解手段。第2章節(jié)有關于“合理劃分優(yōu)先級的方法”的詳細說明。5. 提供了不需要的功能很多項目中都或多或少的含了些很少使用或無人使用的功能，這種情況如何在事前預防呢？在需求階段有效地劃分優(yōu)先級是個辦法。l 采用面向對象思想。l 采用嚴格的需求變更管理流程。l 不準確的計劃等。l 用戶和需求開發(fā)人員在理解上的差異。要解決這樣的問題，在當前國內的軟件實施環(huán)境下，能做的是it人員主動地幫助使用者更好的理解軟件成本，說明清楚為什么做不到，取得理解，達成一致才是關鍵。3. 不切實際的用戶期望很多情況下，業(yè)務人員都會提出大量的需求，有些是技術上根本無法實現(xiàn)的，有的則是項目費用、項目時間等預算內無法實現(xiàn)的。2. 缺乏用戶參與在很多項目中，使用者都不能有效地參與到項目中來，諸如“你們先做，做出來我們試試，有問題再改”之類的話也是常常聽到。 需求驗證是重要的需求質量環(huán)節(jié)，目的是暴露出更多的錯誤，而確認則代表了職責。 按“組織層次”劃分來完成需求的驗證。而采用業(yè)務導向的結構，是用業(yè)務人員熟悉的場景為索引，加之樹型層析結構可以將宏觀信息與微觀信息進行有效剝離。 采用“業(yè)務導向”的樹型層次結構展現(xiàn)需求文檔。答案應該是“業(yè)務專家或業(yè)務代表要比it人員更適合對完整性進行評價”。要破解這個問題。表11 項目成敗因素分析成功因素權重失敗因素權重用戶參與%不完整的需求%決策層支持%缺乏用戶的參與%清晰的需求描述%資源不足%合適的規(guī)劃%不且實際的用戶期望%現(xiàn)實的客戶期望%缺乏決策層的支持%較小的里程碑%需求變更頻繁%有才能的員工%規(guī)劃不足%主權%提供了不需要的功能%清晰的遠景和目標%缺乏IT管理%努力工作和穩(wěn)定的員工%技術能力缺乏%其他%其他%. 需求常見問題分析下面簡要地對需求相關的這些失敗因素做初步的分析，更多的內容將隨著本書的進程繼續(xù)深入。為了幫助軟件開發(fā)組織找到明確的改進方向，Standish Group還總結出了十大成功保證和十大敗因，如表11所示。軟件需求是軟件項目最難把握的問題，同時又是關系項目成敗的關鍵因素。軟件需求是軟件項目關鍵的一個輸入，和傳統(tǒng)的生產企業(yè)相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點。業(yè)務需求分析師目 錄目 錄 2第1章. 軟件需求現(xiàn)狀與常見問題 7. 軟件需求現(xiàn)狀分析 7. 需求常見問題分析 8第2章. 軟件需求與需求工程 11. 軟件需求 11. 軟件需求定義 11. 需求的層次 11. 軟件需求的類型 13. 軟件需求的重要性 15. 優(yōu)秀需求的標準 16. 軟件需求工程 17第3章. 需求開發(fā) 19. 需求開發(fā)管理 19. 需求獲取 19. 需求分析 22. 需求評審 52第4章. 需求管理 55. 需求基線管理 55. 需求變更管理 55. 需求變更控制活動 57. 需求變更控制委員會 59. 需求變更波及分析 62. 需求穩(wěn)定性評估 65. 需求跟蹤 66. 需求跟蹤目的 66. 需求跟蹤能力矩陣 67. 需求跟蹤能力工具 71. 需求跟蹤能力過程 71. 需求后評估 72. 成本評估 73. 效益評估 73第1章. 軟件需求現(xiàn)狀與常見問題. 軟件需求現(xiàn)狀分析在信息化高速發(fā)展與行業(yè)競爭日趨激烈的今天，構建符合中國電信企業(yè)戰(zhàn)略的信息化系統(tǒng)是我們IT專業(yè)人員要解決好地關鍵課題。然而在軟件項目實施過程中，進度超期、經費超預算、變更頻繁的現(xiàn)象層出不窮，許多項目無法達到預期目標，歸根結底，軟件需求質量是問題的主要根源之一。它不像硬件的需求，是有形的、客觀的、可描述的、可檢測的。既然軟件需求如此重要，那么需求相關的哪些因素是導致項目失敗的根源？美國的第三方機構Standish Group 每隔幾年都會對軟件項目現(xiàn)狀進行分析與統(tǒng)計，其分析報告“CHAOS REPORT”①的研究結果顯示：%的項目徹底失敗，%的項目進度超期或成本超支，%。在表11中可以看出，十大成功因素中有三個直接與需求相關（已加粗顯示），%；而十大失敗因素中有五個直接與需求相關，%，可見需求對項目影響程度之高。1. 不完整的需求在日常工作中，該問題經常困擾著我們——“什么樣的需求是完整的呢？”如果沒有一個有效的“需求完整性評價標準”，那么這個問題將是無解。首先應回答一個鋪墊性的問題——“誰更有可能可以對需求的完整性進行評價？”。要想讓業(yè)務專家能夠更好地參與到完整性評價中，應該做到以下兩點：216。假若“需求規(guī)格說明書”中充斥著諸如數(shù)據(jù)字典、報表子系統(tǒng)、新增客戶等以技術動詞為主的字眼與結構，很有可能業(yè)務人員望而卻步。216。日常工作中常見的場景是用業(yè)務代表的簽字確認來代替需求驗證?？梢粋€企業(yè)中少有人能上通戰(zhàn)略下解具體操作，為了讓業(yè)務人員有效的驗證需求，需求文檔的樹型結構應面對不同的層面：決策層、管理層、操作層，將需求分成不同部分，讓合適的人驗證適當?shù)牟糠?。主要應對措施是充分研究業(yè)務代表的關注點、利益點，通過業(yè)務利益爭取使用者參與到需求活動中。究其原因，主要在于軟件的無形和軟件成本的不透明。4. 需求變更頻繁導致需求變更的原因很多，常見的因素包括：l 開發(fā)人員對待需求開發(fā)的態(tài)度不認真l 用戶參與不夠l 模棱兩可的需求。l 過于簡單的規(guī)格說明。有效控制變更應該注意采取合理的需求管理方法：l 需求分析階段盡可能采用原型或者用例方法明確用戶需求。l 采用良好的體系結構。詳細的方法請參見第3章節(jié)內容。這里所說的優(yōu)先級劃分不是“拍腦袋”的產物，而是真正基于業(yè)務領域知識來衡量需求的必要性和充分性，在此基礎上做出劃分。上述分析是需求工作中常見問題的解決建議，分析比較粗淺。第2章. 軟件需求與需求工程1.2.1.2.. 軟件需求. 軟件需求定義什么是軟件需求，這個看似簡單的問題并不好回答。但這樣的理解并不完整，本章將對一些與需求相關的關鍵概念進行闡述。軟件人員要準確理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉化到相應形式的需求規(guī)格說明的過程。. 需求的層次有時也可以將軟件需求按照層次來說明，包括業(yè)務需求、用戶需求、軟件需求、軟件需求規(guī)格等層次，它們的關系如下圖11所示。因為業(yè)務需求的提出人通常是企業(yè)的管理人員，它完全是從業(yè)務角度描述的，是指導軟件開發(fā)的高層需求。2. 用戶需求用戶需求是指軟件使用者的要求和軟件應滿足的用戶特性，一般是用戶協(xié)助提供。用戶需求是需求調研的產物，它具有以下特點：216。216。正因為如此，我們還需要對用戶需求（也叫原始需求）進行分析整理，從而整理出更加精確的需求說明。它是分析人員在對用戶需求進行分析、提煉、整理，從而生成指導開發(fā)的、更精確的軟件需求。軟件需求規(guī)格充分描述了軟件系統(tǒng)應具有的外部行為，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。所謂約束是指對開發(fā)人員在軟件產品設計和構造上的限制。多角度描述產品對用戶和開發(fā)人員都極為重要。. 軟件需求的類型軟件需求可以分為功能需求、非功能需求和設計約束三種類型。在傳統(tǒng)的方法論中，會以系統(tǒng)子系統(tǒng)模塊子模塊的層次結構來組織，但它更多的是按照程序的結構來梳理，會割裂用戶的使用場景。不管是RUP的用例方法還是XP的用戶故事，以及特征驅動開發(fā)的Feature,都是從這個角度進行梳理的。2. 非功能性需求非功能需求是一些限制性要求，是對實際使用環(huán)境所做的要求，例如性能要求、可靠性要求、安全性要求等。非功能需求方面常見的問題有兩個：一是信息傳遞的無效性；二是忽略了非功能需求的局部性。 信息傳遞的無效性：很多需求規(guī)格說明書中，會通過一個小章節(jié)來說明非功能需求，列出諸如高可靠性、高可用性、高擴展性等要求。本書的后續(xù)章節(jié)將說明解決方法。 忽略了非功能需求的局部性：我們經常會看到“所有查詢響應時間都應該小于5秒”的描述，但是當查詢稍長周期的數(shù)據(jù)量時這樣的要求可能無法實現(xiàn)。更科學的做法就是抓住具體的場景來描述。216。例如，必須采用J2EE技術；中間件必須采用WEBSPHERE等。 使用的軟硬件條件與環(huán)境在決定架構、選擇實現(xiàn)技術時會受到軟硬件設備的影響，如果忽略了此種因素會造成不必要的麻煩。用戶的環(huán)境也會對軟件開發(fā)造成影響，需求人員應該搜集此類信息。沒有一個合理的需求管理，將很難達到用戶