如何寫需求課件

如何寫需求申和平2013年11月軟件工程，從需求開始。如何寫需求申和平2013年11月軟件工程，從需求開始。1.需求知識概述1.1軟件需求的重要性1.2軟件需求基本概念1.3優(yōu)秀需求應具備特征1.4需求開發(fā)的主要困難1.5需求分析員應備能力2.軟件需求開發(fā)2.1需求獲取2.2需求分析2.3需求規(guī)格說明2.4需求驗證3.軟件需求管理3.1需求版本控制3.2需求變更控制3.3需求跟蹤控制目錄1.需求知識概述2.軟件需求開發(fā)3.軟件需求管理目錄典型的軟件開發(fā)典型的軟件開發(fā)軟件需求的重要性中國有句諺語：“好的開始就等于成功的一半”。項目遇困幾大原因需求是制定項目計劃的基礎。需求規(guī)格說明是軟件設計和軟件實現(xiàn)的基礎。需求規(guī)格說明是測試工作和用戶驗收的依據(jù)。需求規(guī)格說明是軟件維護工作的依據(jù)。河的源頭被污染，那么整條河也就被污染了。缺乏用戶的參與。（13%）不完整規(guī)格說明。（12%）不斷變更的需求。（12%）需求錯誤的代價軟件需求的重要性中國有句諺語：“好的開始就等于成功的一半”。我們往往并不清楚究竟該做什么，卻一直忙碌不停的開發(fā)。需求不清楚就進入編碼階段，期望以后修改，更多的情況下是編寫邊修改。軟件調(diào)節(jié)和改變是很靈活的，任何需求的變更都可以很容易的在軟件中反應出來。你是如此嗎？這些認識多來自極小項目的開發(fā)經(jīng)驗，當你面對一個中大型項目時？你是如此嗎？這些認識多來自極小項目的開發(fā)經(jīng)驗，當你面對一個中軟件需求的定義IEEE軟件工程標準詞匯表（1977）中的需求定義：用戶解決問題或達到目標所需的條件或權能。系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其他正式規(guī)定文檔所需具有的條件或權能。一種反應上述所描述的條件或權能的文檔說明。通俗地講，需求來源于用戶的一些需要，這些需要被分析、確認后形成完成的文檔，該文檔詳細的說明了產(chǎn)品必須或應當做什么。軟件需求的定義IEEE軟件工程標準詞匯表（1977）中的需求需求工程的定義所有與需求直接相關的活動通稱為需求工程。其可大致分為需求開發(fā)和需求管理兩個階段。其中需求開發(fā)主要產(chǎn)生需求規(guī)格說明，需求管理主要是根據(jù)需求的變化對需求規(guī)格說明的內(nèi)容及版本進行管理。需求工程的定義所有與需求直接相關的活動通稱為需求工程。其可大軟件需求的層次（1）軟件需求的層次（1）軟件需求的層次（2）業(yè)務需求表示組織機構(gòu)或客戶對系統(tǒng)或產(chǎn)品高層次的目標。它們在項目視圖與范圍文檔中予以說明。描述組織為什么要開發(fā)一個系統(tǒng)。用戶需求描述用戶的目標，或用戶要求系統(tǒng)必須完成的任務。用例、場景描述都是表達用戶需求的有效途徑。描述用戶使用系統(tǒng)能做什么。功能需求定義了開發(fā)人員必須要實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足業(yè)務需求。非功能需求描述了系統(tǒng)完成功能實現(xiàn)的補充約束條件。如系統(tǒng)必須遵從的標準、規(guī)范、合約、性能要求、設計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。軟件需求的層次（2）業(yè)務需求表示組織機構(gòu)或客戶對系統(tǒng)或產(chǎn)品高軟件需求的質(zhì)量屬性（1）外部質(zhì)量，對用戶很重要。正確性軟件按照需求正確執(zhí)行任務的能力。正確性無疑是第一重要的質(zhì)量屬性。健壯性是指在異常情況下軟件能夠正常運行的能力。健壯性有兩層含義，一是容錯能力，二是恢復能力?？煽啃允侵冈谝欢ǖ沫h(huán)境下和給定的時間內(nèi)，軟件不發(fā)生故障正常運行的概率。性能是指軟件的響應能力。既要經(jīng)過多長時間才能對某個事件做出響應，或者在某段時間內(nèi)軟件所能處理事件的個數(shù)。安全性是指防止軟件被非法入侵的能力。既屬于技術問題又屬于管理問題。易用性是指用戶使用軟件的容易程度。兼容性是指不同產(chǎn)品或者新老產(chǎn)品相互交換信息的能力。軟件需求的質(zhì)量屬性（1）外部質(zhì)量，對用戶很重要。正確性軟件按軟件需求的質(zhì)量屬性（2）內(nèi)部質(zhì)量，對開發(fā)者很重要。易理解性是指開發(fā)人員理解軟件產(chǎn)品的能力。意味著所有的工作成果要易讀易懂，可以提高團隊開發(fā)效率，降低維護成本。開發(fā)人員只有在自己思路清晰的時候才可能寫出讓別人易讀易懂的程序和文檔。可理解的東西通常是簡潔的?？蓽y試性是指測試軟件組件或集成產(chǎn)品時查找缺陷的簡易程度，又稱為可驗證性?？删S護性是指在軟件中糾正一個缺陷或做一次更改的簡易程度?？蓴U展性是指軟件適應變化的能力?？梢浦残允侵杠浖唤?jīng)修改或稍加修改就可以運行于不同軟硬件環(huán)境的能力。主要體現(xiàn)為代碼的可移植性?？蓮陀眯允侵敢粋€軟件的組成部分可以在同一個項目的不同地方甚至在不同的項目中重復使用的能力。有時不可避免地要對一些特定的屬性進行取舍。軟件需求的質(zhì)量屬性（2）內(nèi)部質(zhì)量，對開發(fā)者很重要。易理解性是優(yōu)秀需求應具備的特征完整性每項需求都必須將所要實現(xiàn)的功能描述清楚。正確性每一項需求都必須準確地陳述其要開發(fā)的功能，符合需求來源。可行性每項需求在已知環(huán)境的權能和限制下可實施?？啥喾饺藛T參與。必要性每項需求都能回溯至某項用戶需求。劃分優(yōu)先級給每項需求分配一個實施優(yōu)先級以指明它在產(chǎn)品中的重要程度。無二義性對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋。可驗證性每項需求能夠被驗證。驗證方法如測試用例、正規(guī)審查等。與實現(xiàn)無關性需求關注系統(tǒng)做什么，而不是怎么做。優(yōu)秀需求應具備的特征完整性每項需求都必須將所要實現(xiàn)的功能描述需求開發(fā)的主要困難與對策（1）用戶說不清楚需求問題：有些用戶不知道需求是什么，或?qū)π枨笾挥须鼥V的感覺，他當然說不清楚需求。還有些用戶雖然心里明白想要什么，但卻表達不清楚。策略：需求分析員不能以用戶說不清楚需求為借口而草率地對待需求開發(fā)，無論是什么原因?qū)е掠脩粽f不清楚需求，需求分析員必須設法搞清楚用戶真正的需求，這是需求分析員的職責，也是職業(yè)的挑戰(zhàn)。需求開發(fā)的主要困難與對策（1）用戶說不清楚需求需求開發(fā)的主要困難與對策（2）態(tài)度問題問題：很多開發(fā)人員習慣于被動地對待需求開發(fā)。每當遇到麻煩、挫折時，他們會找一堆用戶的毛病，認為需求是用戶的事情，不是我們的事情。策略：用戶說不清楚需求或者需求發(fā)生變更都是常見的問題，我們可以設法解決的。開發(fā)人員不應該把這些問題當成借口。需求分析員的職責就是在有限的時間內(nèi)獲取準確而細致的用戶需求，如果做不到就是失職，不要找借口。需求開發(fā)的主要困難與對策（2）態(tài)度問題需求開發(fā)的主要困難與對策（3）知識技能欠缺問題：需求分析員缺乏應用域知識，應用域的知識是無邊無際的，任何人都不可能是萬事通。需求分析員可能是某一領域的專家，當他接手陌生的業(yè)務時，他可能是個無知者。策略：要勇于實踐，不要逃避。還應當趕緊補習應用域知識，不論是通過自學還是培訓的方式。可能的話，最好請既懂軟件又懂應用域知識的行家來幫忙。需求開發(fā)的主要困難與對策（3）知識技能欠缺需求開發(fā)的主要困難與對策（4）雙方誤解需求問題：人們在交流的時候，經(jīng)常會發(fā)生問非所求、答非所問的事情。有時用戶會把開發(fā)人員的建議或答復想歪了，而用戶表達的需求，不同的開發(fā)人員可能有不同的理解。策略：如果需求分析員誤解了需求，那會導致后續(xù)的開發(fā)人員將錯就錯、白忙活。不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求，所以應當做好需求確認工作。需求開發(fā)的主要困難與對策（4）雙方誤解需求需求開發(fā)的主要困難與對策（5）開發(fā)人員寫不好需求文檔問題：需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。或者開發(fā)人員的寫作能力比較差，雖然在調(diào)查過程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來。策略：把需求調(diào)查工作做好，提高開發(fā)人員的寫作能力，多練習寫文檔。另外，企業(yè)提供合適的文檔模板以及比較好的示例文檔，也可有效降低寫作難度。需求開發(fā)的主要困難與對策（5）開發(fā)人員寫不好需求文檔需求開發(fā)的主要困難與對策（6）用戶需求變更頻繁問題：在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導致產(chǎn)品的部分內(nèi)容需要重新開發(fā)?；蛘哂捎谑袌鲎兓鴮е庐a(chǎn)品需求發(fā)生變更。策略：做好需求變更控制。需求變更通常會對項目的進度、人力資源、經(jīng)費產(chǎn)生很大的影響。需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。需求開發(fā)的主要困難與對策（6）用戶需求變更頻繁需求開發(fā)的主要困難與對策（7）合作關系問題：需求分析員不能與用戶建立良好的合作關系。對于一些競標項目，在合同未簽訂之前的需求開發(fā)工作尤為困難。用戶未必會買你的產(chǎn)品，他不會投入很多精力來協(xié)助你。策略：出色的需求分析員不僅要有過硬的專業(yè)知識，還要具備較強的交流和溝通能力。對于重大復雜的項目，不能完全期望雙方能夠自發(fā)地建立起良好地合作關系。要使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動。需求開發(fā)的主要困難與對策（7）合作關系需求分析員應備能力行業(yè)知識熟悉相關行業(yè)和領域的知識及產(chǎn)品。溝通能力善于雙向交流，知道如何有效傾聽和表達。分析能力能夠以不同的角度和方式思考問題。組織能力需要處理獲取和分析過程中收集到的大量雜亂的信息。寫作能力需求開發(fā)的最終產(chǎn)物是需求規(guī)格說明文檔。專業(yè)技術需要掌握如數(shù)據(jù)流圖、用例圖、實體關系圖等建模分析工具。提問技巧很多需求是通過面談和討論得到。觀察能力能夠從不經(jīng)意的閑談或觀察中發(fā)現(xiàn)重要信息。需求分析員應備能力行業(yè)知識熟悉相關行業(yè)和領域的知識及產(chǎn)品。溝2軟件需求開發(fā)2.1需求獲取2.2需求分析2.3需求規(guī)格說明2.4需求驗證2軟件需求開發(fā)2.1需求獲取需求獲取

需求獲取就是進行需求收集的一個過程或者活動。它從人員、資料和環(huán)境中得到系統(tǒng)開發(fā)所需要的相關信息。我將從以下幾個方面來講述。需求常見來源需求獲取內(nèi)容需求獲取常用方法需求獲取常見困難需求獲取實踐經(jīng)驗需求獲取需求獲取就是進行需求收集的一個過程或者活動。需求常見來源用戶提交的需求文檔。與用戶進行探討?，F(xiàn)有系統(tǒng)的問題報告和改進要求。觀察或體驗用戶工作。市場調(diào)查和用戶問卷調(diào)查。對同類產(chǎn)品或競品進行分析。對用戶的工作情景進行分析。行業(yè)專家的建議需求常見來源用戶提交的需求文檔。需求獲取的內(nèi)容明確業(yè)務需求明確項目范圍明確業(yè)務流程和業(yè)務規(guī)則明確數(shù)據(jù)定義明確軟件功能明確質(zhì)量屬性明確系統(tǒng)接口明確設計和實現(xiàn)約束需求獲取的內(nèi)容明確業(yè)務需求需求獲取常用方法

需求獲取方法很多。每種方法有其各自優(yōu)缺點，適用于不同的場合。需求獲取人員需要了解各種方法的使用場景及優(yōu)缺點，以便在不同的場合采取不同的方法開展需求獲取工作。1、用戶訪談2、原型法3、觀察法4、文檔分析5、需求專題討論6、用戶問卷調(diào)查需求獲取常用方法需求獲取方法很多。每種方法有其各自優(yōu)用戶訪談用戶訪談是實踐當中應用最為廣泛的需求獲取方法之一。優(yōu)點：簡單、直接、形式靈活、交流比較深入。缺點：占用時間長，信息存在片面性。應用場景：用戶訪談在所有的需求獲取中都被開發(fā)者廣泛使用，需要注意的是訪談的目標和話題根據(jù)用戶的不同而有所側(cè)重。用戶訪談用戶訪談是實踐當中應用最為廣泛的需求獲取方法之一。用戶訪談---話題類型（1）開放式話題封閉式話題被會見者對答復的選擇是開放和不受限制的，他們可能答復兩個詞，也可能答復兩段話。在希望得到豐富，具有一定深度和廣度的信息時，開放式問題比較合適。答案有基本的形式，被會見者的回答是受到限制的，如選擇題、判斷題等。例如：1、你對屌絲一詞有什么看法？例如：1、呼叫中心一月平均接到多少個電話？2、下列哪個信息對你最有用？用戶訪談---話題類型（1）開放式話題封閉式話題被會見者對答用戶訪談---話題類型（2）開放式話題封閉式話題優(yōu)點被會談者感覺更自在和感興趣；可獲得豐富的細節(jié)；允許更多的自發(fā)性；可以收集被會談者使用的詞匯；對沒采用的進一步的提問有啟迪作用；可以在沒有太多準備的情況下進行；節(jié)省時間；切中要點；保持對面談的控制；快速探討大范圍問題；得到貼切的數(shù)據(jù)；缺點可能產(chǎn)生太多不相干的細節(jié)；面談可能失控；會花費大量時間才能獲得有用的信息量；可能使會談者看上去沒有準備；會談者比較厭煩；得不到豐富的細節(jié)；不利于建立友好關系；用戶訪談---話題類型（2）開放式話題封閉式話題優(yōu)點被會談者用戶訪談---話題類型（3）開放式話題對比項封閉式話題低數(shù)據(jù)的可靠性高低使用的時間效率高低數(shù)據(jù)的精度高廣數(shù)據(jù)的廣度和深度窄多需要的面談技能少難分析的難易度易用戶訪談---話題類型（3）開放式話題對比項封閉式話題低數(shù)據(jù)用戶訪談---時間安排階段任務占用時間備注開場白陳述預先對問題的考慮和理解5-15分鐘聚焦本次訪談的話題，明確訪談的范圍和層次預先計劃問題尋找問題的答案25-30分鐘主體工作，關鍵部分即興問題擴大需求信息量20-30分鐘注意導向，不要跑題太遠總結(jié)總結(jié)訪談內(nèi)容5-10分鐘訪談者向被訪談者復述主要問題的答案用戶訪談盡量選擇相對封閉的環(huán)境，一次訪談的時間一般不要超過1小時。下面是很多書籍中提供的一個參考時間安排。用戶訪談---時間安排階段任務占用時間備注開場白陳述預先對問用戶訪談---記錄工作用戶訪談期間將會產(chǎn)生大量的信息，免不了記錄的工作。下面是很多經(jīng)典的案例為我們提供了可參考的記錄方式。記錄方式優(yōu)點缺點建議自己做筆記直接、簡單、靈活容易走神記重點要點，并確認專人做筆記精力集中在訪談上容易產(chǎn)生記錄偏差訪談結(jié)束時讓記錄人員向雙方做簡要陳述錄音免受記錄工作影響信息易失真記錄大綱和關鍵信息錄像免受記錄工作影響難以操作用戶訪談---記錄工作用戶訪談期間將會產(chǎn)生大量的信息，免不了用戶訪談---溝通技巧多數(shù)情況下，應該事先制作訪談問卷發(fā)給被訪談者，羅列出要問的主要問題。被訪談者事前有這樣的問卷，他有可能進行一些思考，不至于會談時無話可談或者無話不談。把握訪談方向，在整個訪談過程中，信息應該是從被訪談者流向訪談者，而不是相反。有資料認為，被訪談者與訪談者說話時間的比例應該是2:1。不要問過長的問題，較長的問題應該將其拆分，采用遞進的方法逐個解決。用戶訪談---溝通技巧多數(shù)情況下，應該事先制作訪談問卷發(fā)給被用戶訪談---提問順序訪談提問的順序應該按業(yè)務邏輯組織。面對每一組問題，注意借鑒歸納和演繹方式。金字塔結(jié)構(gòu)（歸納：特定問題開始，通用問題結(jié)束）被會見者需要對話題進行預熱，通過逐步引導使被會見者打開話匣子。會見者發(fā)現(xiàn)自己事先對事實的確認存在較大偏差。會見者看上去不情愿討論這個話題。漏斗結(jié)構(gòu)（演繹：通用問題開始，特定問題結(jié)束）漏斗結(jié)構(gòu)為開始一場面談提供了一種容易而輕松的途徑。被會見者對這個話題有情緒，并且需要自由表達這些情緒的時候。會見者事先對事實了解不多時。用這種方式組織面談能得出很多的詳細信息菱形結(jié)構(gòu)（歸納—演繹-歸納：特定問題開始，轉(zhuǎn)向通用問題，特定問題結(jié)束）使用菱形結(jié)構(gòu)的主要優(yōu)點是通過各種各樣的問題保持被會見者的興趣和注意力。一旦掌握了如何在正確的時間問正確的問題，就可以多樣地選擇問題的順序。用戶訪談---提問順序訪談提問的順序應該按業(yè)務邏輯組織。面對用戶訪談---計劃安排在用戶訪談前，要有精心的計劃安排，根據(jù)需求獲取所處的階段確定訪談的時間、人員和主題等，將訪談內(nèi)容事前告知被訪談人，避免訪談效率低下。針對不同的訪談人，要采用不同的方式和要點。訪談主題訪談要點期望部門訪談人訪談時間備注用簡短的話概述提取關鍵點指定理想的訪談對象用戶方聯(lián)絡人指定用戶方聯(lián)絡人指定用戶訪談計劃安排模板用戶訪談---計劃安排在用戶訪談前，要有精心的計劃安排，根據(jù)用戶訪談---過程小結(jié)準備訪談閱讀背景資料，確定面談主題、目標、問題和被會見者。注意記得和被會見者聯(lián)系并確認面談的安排，不要遲到，著裝正式。主持訪談開始盡量建立一個理想的氛圍和環(huán)境來促進會見者和被會見者之間的交流和溝通。1、簡要重申面談的目標。2、用一些非常一般的、輕松的、開放式的問題作為開始。3、準備好筆記本、錄音機或者其他記錄設備，并禮貌地詢問相關人員是否可以錄音或者錄像。過程中通過提問和傾聽來完成和被會見者的信息交流，按照計劃控制面談的進行，必要時進行適當?shù)恼{(diào)整。1、保持有禮貌的傾聽。2、保持面談主題、控制面談過程。3、觀察被會見者。結(jié)束時要表示感謝并回答被會見者提出的問題，保持與被會見者的親善和信任關系。1、面談應該在1小時內(nèi)結(jié)束，并非要在提出所有關心的問題后才能結(jié)束面談。2、總結(jié)談話的要點。3、感謝被會見者，并且給時間讓他們詢問一些他們自己關心的問題。處理訪談結(jié)果復查面談記錄，總結(jié)面談信息，整理出內(nèi)容要點，進行分類，整理成文檔。用戶訪談---過程小結(jié)準備訪談原型法---為什么要建立原型原型作為一種需求工具，可明確并完善需求。原型作為一種設計工具，可用它優(yōu)化系統(tǒng)易用性，評估可能的技術方案。原型作為一種構(gòu)造工具，是產(chǎn)品最初的功能實現(xiàn)，可發(fā)展為最終產(chǎn)品。使用原型，發(fā)現(xiàn)并解決需求中的二義性、不完整性和不確定性問題。直觀的原型，更易于理解，能更具體地思考問題。構(gòu)建原型的目標是降低項目風險。原型法---為什么要建立原型原型作為一種需求工具，可明確并完原型法---為什么要建立原型軟件開發(fā)早期，有時很難定義出確切的軟件需求，提供詳細的需求規(guī)格說明書。軟件系統(tǒng)的很多具體細節(jié)往往是隨著軟件系統(tǒng)的建立而逐步明確的。這樣，在需求分析階段，分析人員常常得花大量時間去捕捉一些非常模糊的想法，并花大量時間以這種模糊的認識為基礎去編寫包括很多細節(jié)內(nèi)容的需求規(guī)格說明書，因而需求規(guī)格說明書的一致性、準確性、正確性、有效性很難保證。常規(guī)的軟件開發(fā)各階段相互傳遞信息的唯一工具是文檔。

雖然文檔內(nèi)有很多形象的描述方法，如各種圖表等，但它們畢竟是實際系統(tǒng)的抽象。即使在軟件開發(fā)早期作出了明確的需求分析，其后每一個階段的開發(fā)人員都不得不再花大量時間，在一定程度上，通過閱讀文檔重溫前一階段系統(tǒng)人員的工作。同時，由于這些階段的系統(tǒng)人員一般不和客戶作直接交流，因而，可能出現(xiàn)的情況是，需求分析中已經(jīng)得到正確說明的問題，經(jīng)過這些階段中不同的系統(tǒng)人員的各種理解和加工后，在繼續(xù)傳遞的過程中發(fā)生。在系統(tǒng)人員和客戶面前，不存在一個實實在在的事物。

這個實體可以充分表達系統(tǒng)人員對問題空間有關概念的理解程度和對目標系統(tǒng)的初步考慮，客戶也可通過這個實體，闡明其對目標系統(tǒng)的要求和系統(tǒng)人員當前的一些理解錯誤。基于這些問題，信息系統(tǒng)開發(fā)需要更為實用的方法指導開發(fā)過程。原型法即是適應這種需要產(chǎn)生的一種信息系統(tǒng)開發(fā)方法。原型法---為什么要建立原型軟件開發(fā)早期，有時很難定義出確切原型法---好處原型可以激活用戶的思維，并促進需求對話。原型的早期反饋有助于涉眾對系統(tǒng)需求理解達成共識。增加開發(fā)者之間的交流，幫助確定技術解決方案的可行性。有效的識別風險和解決風險，幫助進行風險管理。提高用戶在軟件開發(fā)中的參與程度。幫助需求工程師及早解決需求的不確定性。原型法---好處原型可以激活用戶的思維，并促進需求對話。原型法---類別按照構(gòu)建技術分類水平原型方法：僅實現(xiàn)選定功能所有層次中的某些特定層次。垂直原型方法：實現(xiàn)選定功能的所有層次。按照使用方式分類演示原型：主要用在啟動項目階段，讓用戶相信系統(tǒng)的開發(fā)是可行的。一般原型：主要用在分析需求階段，用來闡明用戶界面或者系統(tǒng)功能。試驗原型：主要用在構(gòu)建系統(tǒng)階段，幫助開發(fā)者澄清構(gòu)建相關技術問題。按照開發(fā)方式分類拋棄式原型：用最快速度，花最小代價，適用于不確定的需求。演化式原型：質(zhì)量要求高，要易于擴展和改進，適用于清晰的需求。按照使用介質(zhì)分類書面原型：也稱低保真原型，是一種成本低、速度快且不涉及高深技術的方法。程序或工具原型：使用編程語言或?qū)I(yè)工具創(chuàng)建。

原型法---類別按照構(gòu)建技術分類原型法---風險用戶看到了一個正在運行的原型，得出產(chǎn)品幾乎已經(jīng)完成的結(jié)論，從而提出快速交付產(chǎn)品的不當要求。原型開發(fā)投入太多的工作，使得開發(fā)團隊消耗了過多的時間和成本。原型法---風險用戶看到了一個正在運行的原型，得出產(chǎn)品幾乎已原型法---創(chuàng)建原型遵循原則應該在項目計劃中包括創(chuàng)建原型的任務。廢棄型原型要盡量快速而經(jīng)濟，其中不應包括輸入數(shù)據(jù)有效性檢查、用于錯誤處理的代碼或代碼注釋文檔。對于已經(jīng)理解的需求不要建立原型，除非是要研究設計方案。在原型屏幕顯示和報告中使用看似真實的數(shù)據(jù)。不要期望用原型完全代替軟件需求規(guī)格說明。原型法---創(chuàng)建原型遵循原則應該在項目計劃中包括創(chuàng)建原型的任用戶問卷調(diào)查用戶調(diào)查在市場調(diào)查領域應用非常廣泛。優(yōu)點：調(diào)查面比較寬，用戶反饋多。缺點：不易深入。適用場景：所以當片面性矛盾比較突出時就可以采用用戶調(diào)查的方式。比如存在大樣本用戶或存在跨地域的用戶時。有時可以將用戶訪談和用戶調(diào)查結(jié)合使用。先調(diào)查后訪談：從問卷調(diào)查的結(jié)果中整理出一個關鍵點，然后選取一些用戶代表進行有針對性的訪談。先訪談后調(diào)查：選取一些典型的用戶，然后對訪談的結(jié)果進行整理。在這些基礎上設計調(diào)查問卷。通過調(diào)查來驗證用戶訪談的結(jié)果是否具有普遍性。用戶問卷調(diào)查用戶調(diào)查在市場調(diào)查領域應用非常廣泛。用戶問卷調(diào)查---調(diào)查問卷設計要點1、注意問題篇幅和布局通常認為問卷不要讓用戶在回答時花太多的時間，一般不超過20分鐘。換句話說，就是量不要超過3頁。問題排列應該先易后難。另外，要有邏輯相關性的考慮。跳躍太大的問卷，往往會干擾答卷人的思路。從而降低了答卷的質(zhì)量。2、注意問題類型的選擇盡量選擇開放性（簡答題）或半封閉（多選題）的題型，少用封閉性題型（判斷題）。研究表明，從信息收集的有效性來說，開放性問題效果最好。半封閉型問題次之，封閉型問題最差。用戶問卷調(diào)查---調(diào)查問卷設計要點1、注意問題篇幅和布局文檔分析法

文檔分析是專門針對文檔進行需求獲取的活動。其主要獲取對象包括相關產(chǎn)品的需求說明書、客戶需求文檔、相關數(shù)據(jù)及流程說明等。

其主要優(yōu)點是能夠詳細、直觀地對數(shù)據(jù)流細節(jié)進行了解和分析。缺點也比較明顯，企業(yè)機構(gòu)中，文檔量通常非常大，由此容易使需求獲取人員陷入文山書海中不能自拔，甚至引起誤導。文檔分析通常配合用戶訪談或者用戶調(diào)查期間開展。采用此策略的的目的是因為用戶訪談或者用戶調(diào)查難以獲得數(shù)據(jù)方面的詳細需求，你不能指望被訪談者或者被調(diào)查者能夠記住相關數(shù)據(jù)細節(jié)。

文檔分析是研究、分析、細化數(shù)據(jù)的重要手段。文檔分析法文檔分析是專門針對文檔進行需求獲取的活動。觀察法如果：用戶說的和做的一致嗎？用戶難以描述他們是如何做的？用戶描述的業(yè)務流程會否因為某些原因遺漏掉重要的信息？那么：看他們是怎么工作的。需求分析人員參與到他們的具體工作中，觀察或體驗業(yè)務操作過程及物理環(huán)境，根據(jù)實際的情況提問并記錄，記錄業(yè)務員操作過程及碰到的難題。觀察法對于理解業(yè)務流程和獲取真實的材料非常有效。觀察法如果：小組討論法小組討論是指將與項目某個問題相關的人員聚集在一起開會討論。優(yōu)勢是容易在內(nèi)部取得對方案的認同，有利于項目的開展，在討論會上每個相關人員都可發(fā)表自己的意見，保證了獲取信息的全面性。先確定好議題、內(nèi)容、主講人、參會人員、會議室、開會時間。事先將相關資料送達參與人員，讓參與人員開會前先了解會議的整體背景和需討論的問題，有利于會議的順利開展。保證每個人都有發(fā)言時間，注意控制會議時間。會后將會議紀要發(fā)送給參會人員，取得對結(jié)果的認同。小組討論法小組討論是指將與項目某個問題相關的人員聚集需求獲取常見困難用戶沒時間或不愿花太多時間與開發(fā)人員進行交流或討論。開發(fā)人員缺乏用戶的業(yè)務常識，雙方交流困難。用戶與開發(fā)人員的背景不同、立場不同。普通用戶缺乏概括性、綜合性的表述能力。沒有明確的用戶。需求獲取常見困難用戶沒時間或不愿花太多時間與開發(fā)人員進行交流需求獲取實踐經(jīng)驗需求獲取需要主動“獲取”是一個主動性詞匯，強調(diào)需求分析人員在整個過程中應該充分發(fā)揮主動性。主動表現(xiàn)為有計劃性，針對不同的用戶層次選擇不同的方法。了解相關業(yè)務知識對業(yè)務系統(tǒng)的知識理解，是需求獲取的基礎。缺乏這一點，將無從著手或沒有章法，難以發(fā)揮技巧的作用。捕獲用戶的隱性需求滿足用戶的顯性需求是底線，隱性需求是培養(yǎng)用戶忠誠度的最好武器，但隱形需求的度要把握好，并不是所有的需求都是受歡迎的。需求獲取實踐經(jīng)驗需求獲取需要主動需求獲取實踐經(jīng)驗不要奢望一次將用戶需求獲取一般情況，不要指望一次或幾次需求碰頭會就會將用戶需求全部獲取。實際情況是前幾次用戶提出的問題比較少，后面越來越多，你會受不了。理解業(yè)務場景非常重要用戶對需求的理解主要還是從自身的業(yè)務出發(fā)，他們能夠提出的需求是基本需求，若僅停留在這一點上，會給系統(tǒng)開發(fā)帶來許多問題。如能深入用戶的工作實際環(huán)境，感受實際場景，能大大減少需求變更的可能。需求獲取實踐經(jīng)驗不要奢望一次將用戶需求獲取需求獲取實踐經(jīng)驗需求往往需要協(xié)商不同業(yè)務層面（甚至相同業(yè)務層面）的用戶對同樣的概念或流程存在理解差異時，在需求整理時應將這些差異明確標識出來，并展示給用戶的高層領導，由他們決定如何消除這些差異，并將這些情況記錄。學會復述在用戶闡述了需求之后，用自己的語言再復述一遍，以確保溝通沒有失真。多問幾個為什么多問用戶幾個為什么，找到問答題的本質(zhì)，理解用戶的真實意圖和深層目標。需求獲取實踐經(jīng)驗需求往往需要協(xié)商2軟件需求開發(fā)2.1需求獲取2.2需求分析2.3需求規(guī)格說明2.4需求驗證2軟件需求開發(fā)2.1需求獲取需求分析目標（1）需求分析的目標是對獲取的需求進行分解、抽象，在此過程中消除需求矛盾、建立分析模型、創(chuàng)建解決方案，準確地回答系統(tǒng)必須做什么。需求分析的目標問題域描述整個領域現(xiàn)狀是這樣運作的現(xiàn)實世界規(guī)格說明要構(gòu)建的系統(tǒng)是這樣運作的計算世界需求用戶希望事情能這樣子運作問題域解系統(tǒng)需求分析目標（1）需求分析的目標是對獲取的需求進行分解、抽象需求分析目標（2）（1）分解分解是認識和解決復雜性事務的基本策略。將問題不斷分解為較小的問題，直到每個最低層的問題都足夠簡單。無論采用何種分析法，分解都是必須采用的手段。分解策略說明業(yè)務流程為主線是目前比較流行的方法，主要按照業(yè)務的角度考慮分解方法。此方法特別適合管理信息系統(tǒng)（MIS）、聯(lián)機事務處理系統(tǒng)。分解：目標系統(tǒng)主題域業(yè)務事件業(yè)務活動業(yè)務步驟。程序結(jié)構(gòu)為主線是需求分析最常用的分解方法。適合于問題域比較清晰，問題不算復雜的情況。分解：目標系統(tǒng)子系統(tǒng)功能模塊子模塊功能點?；跀?shù)據(jù)適合數(shù)據(jù)倉庫之類的項目。分解：目標系統(tǒng)主題域主題類邏輯數(shù)據(jù)物理數(shù)據(jù)?；趫鼍皩τ跊Q策支持系統(tǒng)、面向用戶的嵌入式系統(tǒng)分解：目標系統(tǒng)關注點場景集合使用場景任務。需求分析目標（2）（1）分解分解策略說明業(yè)務流程為主線是目前需求分析目標（3）（2）抽象分解是一種自頂向下的方法，當按照任何一種線索進行分解時。就會破壞其它線索的完整性。例如，如果以業(yè)務為線索，就會發(fā)現(xiàn)數(shù)據(jù)需求分解后會出現(xiàn)相互交疊的情況，也就是在多個業(yè)務事件中都涉及相同的類。此種情況出現(xiàn)時，可能會影響需求分析人員建立全面的理解，因此需要采用自底向上的方法進行抽象和提煉。例如將每個業(yè)務事件中的類進行抽象，抽取出共性的部分，建立針對整個系統(tǒng)的全局領域模型。需求分析目標（3）（2）抽象需求分析目標（4）（3）消除矛盾在分析過程中，顯然可能會發(fā)現(xiàn)有些需求是相互矛盾的、沖突的，由于是將收集的信息放在一個預先定義的結(jié)構(gòu)中發(fā)現(xiàn)這些矛盾的，因此對矛盾的影響范圍會有直觀的了解，也能夠知道它影響那些層面。尋找相應的人員，通過進一步需求獲取來消除矛盾。（4）建立分析模型通過軟件建模，幫助我們按照實際情況或按照我們需要的模式對系統(tǒng)進行可視化，提供一種詳細說明系統(tǒng)的結(jié)構(gòu)或者行為的方法，給出一個指導系統(tǒng)構(gòu)造的模板。對所有做出的決定實施文檔化。需求分析目標（4）（3）消除矛盾（4）建立分析模型需求分析方法（1）1、結(jié)構(gòu)化分析方法（SA）：采用自頂向下、逐層分解的分析方法來定義系統(tǒng)的需求。以數(shù)據(jù)和功能為中心。常用工具功能數(shù)據(jù)字典（DD）模型的核心，對數(shù)據(jù)流圖、實體關系圖、狀態(tài)變遷圖中的所有數(shù)據(jù)對象的描述。數(shù)據(jù)流圖（DFD）用于功能建模，描述系統(tǒng)中數(shù)據(jù)流程的圖形工具，它描述了將系統(tǒng)的邏輯輸入轉(zhuǎn)換為邏輯輸出所需的加工處理過程。實體關系圖（ERD）用于數(shù)據(jù)建模，描述數(shù)據(jù)的定義、結(jié)構(gòu)和關系。狀態(tài)變遷圖（STD）用于行為建模，描述系統(tǒng)接收哪些外部事件，以及在外部事件的作用下狀態(tài)遷移情況。函數(shù)過程需求分析方法（1）1、結(jié)構(gòu)化分析方法（SA）：采用自頂向下、需求分析方法（2）常用工具（UML）功能用例圖說明角色和使用場景之間的關系，描述用戶與系統(tǒng)如何交互。類圖描述業(yè)務實體、實體特性以及實體之間的關系活動圖說明業(yè)務流程，以及業(yè)務活動的步驟順序圖描述參與交互的對象及對象之間消息交換的順序。構(gòu)件圖描述構(gòu)件的結(jié)構(gòu)及他們之間的服務接口狀態(tài)圖描述事件如何改變對象生命周期2、面向?qū)ο蠓治龇椒ǎ∣OA）：利用面向?qū)ο蟮母拍詈头椒檐浖枨蠼ㄔ炷Ｐ汀Ｒ詫ο鬄橹行?。對象對象對象需求分析方法?）常用工具（UML）功能用例圖說明角色和使用需求分析方法（3）3、功能分解法：將系統(tǒng)看做若干功能模塊的集合，每個功能又可以分解為子功能，子功能還可繼續(xù)分解，分解的結(jié)果即是系統(tǒng)的雛形。常用建模工具功能功能分解圖在一個圖內(nèi)自上而下集中顯示系統(tǒng)的功能分解結(jié)構(gòu)，更加直觀的展現(xiàn)大量過程之間的層次關系。需求分析方法（3）3、功能分解法：將系統(tǒng)看做若干功能模塊的集2軟件需求開發(fā)2.1需求獲取2.2需求分析2.3需求規(guī)格說明2.4需求驗證2軟件需求開發(fā)2.1需求獲取需求規(guī)格說明書概述

需求獲取收集了需求信息，需求分析深入理解了需求信息并建立了能夠滿足用戶需求的解決方案。需求規(guī)格說明則是將需求獲取、需求分析的結(jié)果進行文檔化的過程。在軟件開發(fā)過程中，將分析的結(jié)果文檔化是不可或缺的任務，也稱為編寫規(guī)約活動。需求規(guī)格說明書的完成（撰寫完成、驗證完成）標志著軟件需求階段告一段落。并將作為下一個階段設（計開發(fā)階段）的輸入和重要依據(jù)。需求規(guī)格說明書概述需求獲取收集了需求信息，需求分析深需求規(guī)格說明書的作用需求規(guī)格說明書文檔可以成為各方人員之間有關軟件系統(tǒng)的協(xié)議基準。需求規(guī)格說明書文檔可以成為項目開發(fā)活動的一個重要依據(jù)。它可以成為軟件估算和項目進度安排的基礎，也可以成為開發(fā)人員判斷設計、測試等工作的進行是否正確的依據(jù)。需求規(guī)格說明書文檔可以成為有效的知識資產(chǎn)。該資產(chǎn)可以幫助新加入的團隊成員快速融入項目，可以幫助更好地將軟件產(chǎn)品移交給新客戶，也可以幫助開發(fā)者更好地進行其他類似項目或者后續(xù)增強項目的開發(fā)。需求規(guī)格說明書的作用需求規(guī)格說明書文檔可以成為各方人員之間有需求規(guī)格說明活動流圖需求規(guī)格說明活動流圖需求規(guī)格說明書寫作風格寫作風格說明自然語言使用結(jié)構(gòu)合理的自然語言來描述需求。優(yōu)點：易于編寫和閱讀，不需要掌握特定的技巧。缺點：不夠嚴謹，歧義性強，表達能力弱。圖形化模型在表述時能夠給讀者提供更強的視覺效果，同時能夠使問題更加聚焦。優(yōu)點：可視化、聚焦性、易于理解。缺點：編寫和閱讀的人都需要能夠正確地理解模型。形式化描述對于邏輯性很強，精度要求很高的場合，形式化描述是一種不錯的選擇。優(yōu)點：嚴謹、精確。缺點：編寫和閱讀的人都會感到很困難。建議：以自然語言為主，輔以圖形化模型，需要的地方少量使用形式化規(guī)格描述。需求規(guī)格說明書寫作風格寫作風格說明自然語言使用結(jié)構(gòu)合理的自然需求規(guī)格說明書的寫作

一般由項目經(jīng)理負責組織需求規(guī)格說明書的寫作。SRS的寫作沒有放之四海而皆準的標準。一般可以考慮按如下開展。制定模板：按照項目的具體應用環(huán)境、用戶情況、系統(tǒng)特點、公司通用模板構(gòu)建一個新模板（先制定一個模板，然后讓各方人員一起來討論完善）。寫作指南：當需求規(guī)格說明由多個人員共同完成時這是非常必要的，否則在合稿時將將會處于崩潰。因為每個人寫作的方式、文筆、對問題的理解都存在差異。需求規(guī)格說明書的寫作一般由項目經(jīng)理負責組織需求規(guī)格說關于寫作指南對文檔大綱盡量細化（某某負責哪些部分的撰寫，在什么時候完成）。對文字、圖表、標題等格式做出規(guī)約（例如不允許使用四級標題等）。定義術語表，避免術語不一致、錯誤術語、冗余術語、方言問題。避免歧義詞匯，例如可接受的、不應該、有效的、充分的、若干等。避免干擾文本，比如

“上一句話是指…”、這個、那個…..關于寫作指南對文檔大綱盡量細化（某某負責哪些部分的撰寫，在什優(yōu)秀需求規(guī)格說明書的特性特性說明正確性文檔內(nèi)的所有需求都具有正確性。無歧義文檔內(nèi)的所有需求都是無歧義的?？沈炞C文檔內(nèi)的所有需求都是可驗證的。完備性描述了所有的需求，包括功能、性能、約束、質(zhì)量屬性、對外接口及待解決問題。一致性不能同高層次的需求相沖突，同一層次的不同需求之間也不能互相沖突。優(yōu)先級根據(jù)重要性和穩(wěn)定性，建立需求的優(yōu)先級。可跟蹤可向前跟蹤、向后跟蹤?？尚薷?/p>