如何寫需求課件

如何寫需求2013年11月軟件工程，從需求開始。1.需求知識概述1.1軟件需求的重要性1.2軟件需求基本概念1.3優(yōu)秀需求應(yīng)具備特征1.4需求開發(fā)的主要困難1.5需求分析員應(yīng)備能力2.軟件需求開發(fā)2.1需求獲取2.2需求分析2.3需求規(guī)格說明2.4需求驗(yàn)證3.軟件需求管理3.1需求版本控制3.2需求變更控制3.3需求跟蹤控制目錄典型的軟件開發(fā)我們往往并不清楚究竟該做什么，卻一直忙碌不停的開發(fā)。需求不清楚就進(jìn)入編碼階段，期望以后修改，更多的情況下是編寫邊修改。軟件調(diào)節(jié)和改變是很靈活的，任何需求的變更都可以很容易的在軟件中反應(yīng)出來。你是如此嗎？這些認(rèn)識多來自極小項(xiàng)目的開發(fā)經(jīng)驗(yàn)，當(dāng)你面對一個(gè)中大型項(xiàng)目時(shí)？軟件需求的定義IEEE軟件工程標(biāo)準(zhǔn)詞匯表（1977）中的需求定義：用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能。系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或權(quán)能。一種反應(yīng)上述所描述的條件或權(quán)能的文檔說明。通俗地講，需求來源于用戶的一些需要，這些需要被分析、確認(rèn)后形成完成的文檔，該文檔詳細(xì)的說明了產(chǎn)品必須或應(yīng)當(dāng)做什么。需求工程的定義所有與需求直接相關(guān)的活動通稱為需求工程。其可大致分為需求開發(fā)和需求管理兩個(gè)階段。其中需求開發(fā)主要產(chǎn)生需求規(guī)格說明，需求管理主要是根據(jù)需求的變化對需求規(guī)格說明的內(nèi)容及版本進(jìn)行管理。軟件需求的層次（1）軟件需求的質(zhì)量屬性（1）外部質(zhì)量，對用戶很重要。正確性軟件按照需求正確執(zhí)行任務(wù)的能力。正確性無疑是第一重要的質(zhì)量屬性。健壯性是指在異常情況下軟件能夠正常運(yùn)行的能力。健壯性有兩層含義，一是容錯(cuò)能力，二是恢復(fù)能力?？煽啃允侵冈谝欢ǖ沫h(huán)境下和給定的時(shí)間內(nèi)，軟件不發(fā)生故障正常運(yùn)行的概率。性能是指軟件的響應(yīng)能力。既要經(jīng)過多長時(shí)間才能對某個(gè)事件做出響應(yīng)，或者在某段時(shí)間內(nèi)軟件所能處理事件的個(gè)數(shù)。安全性是指防止軟件被非法入侵的能力。既屬于技術(shù)問題又屬于管理問題。易用性是指用戶使用軟件的容易程度。兼容性是指不同產(chǎn)品或者新老產(chǎn)品相互交換信息的能力。優(yōu)秀需求應(yīng)具備的特征完整性每項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚。正確性每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能，符合需求來源。可行性每項(xiàng)需求在已知環(huán)境的權(quán)能和限制下可實(shí)施?？啥喾饺藛T參與。必要性每項(xiàng)需求都能回溯至某項(xiàng)用戶需求。劃分優(yōu)先級給每項(xiàng)需求分配一個(gè)實(shí)施優(yōu)先級以指明它在產(chǎn)品中的重要程度。無二義性對所有需求說明的讀者都只能有一個(gè)明確統(tǒng)一的解釋。可驗(yàn)證性每項(xiàng)需求能夠被驗(yàn)證。驗(yàn)證方法如測試用例、正規(guī)審查等。與實(shí)現(xiàn)無關(guān)性需求關(guān)注系統(tǒng)做什么，而不是怎么做。需求開發(fā)的主要困難與對策（2）態(tài)度問題問題：很多開發(fā)人員習(xí)慣于被動地對待需求開發(fā)。每當(dāng)遇到麻煩、挫折時(shí)，他們會找一堆用戶的毛病，認(rèn)為需求是用戶的事情，不是我們的事情。策略：用戶說不清楚需求或者需求發(fā)生變更都是常見的問題，我們可以設(shè)法解決的。開發(fā)人員不應(yīng)該把這些問題當(dāng)成借口。需求分析員的職責(zé)就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求，如果做不到就是失職，不要找借口。需求開發(fā)的主要困難與對策（3）知識技能欠缺問題：需求分析員缺乏應(yīng)用域知識，應(yīng)用域的知識是無邊無際的，任何人都不可能是萬事通。需求分析員可能是某一領(lǐng)域的專家，當(dāng)他接手陌生的業(yè)務(wù)時(shí)，他可能是個(gè)無知者。策略：要勇于實(shí)踐，不要逃避。還應(yīng)當(dāng)趕緊補(bǔ)習(xí)應(yīng)用域知識，不論是通過自學(xué)還是培訓(xùn)的方式。可能的話，最好請既懂軟件又懂應(yīng)用域知識的行家來幫忙。需求開發(fā)的主要困難與對策（4）雙方誤解需求問題：人們在交流的時(shí)候，經(jīng)常會發(fā)生問非所求、答非所問的事情。有時(shí)用戶會把開發(fā)人員的建議或答復(fù)想歪了，而用戶表達(dá)的需求，不同的開發(fā)人員可能有不同的理解。策略：如果需求分析員誤解了需求，那會導(dǎo)致后續(xù)的開發(fā)人員將錯(cuò)就錯(cuò)、白忙活。不論是復(fù)雜的項(xiàng)目還是簡單的項(xiàng)目，需求分析員和用戶都有可能誤解需求，所以應(yīng)當(dāng)做好需求確認(rèn)工作。需求開發(fā)的主要困難與對策（5）開發(fā)人員寫不好需求文檔問題：需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔?；蛘唛_發(fā)人員的寫作能力比較差，雖然在調(diào)查過程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來。策略：把需求調(diào)查工作做好，提高開發(fā)人員的寫作能力，多練習(xí)寫文檔。另外，企業(yè)提供合適的文檔模板以及比較好的示例文檔，也可有效降低寫作難度。需求開發(fā)的主要困難與對策（6）用戶需求變更頻繁問題：在項(xiàng)目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)?；蛘哂捎谑袌鲎兓鴮?dǎo)致產(chǎn)品需求發(fā)生變更。策略：做好需求變更控制。需求變更通常會對項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響。需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂。需求分析員應(yīng)備能力行業(yè)知識熟悉相關(guān)行業(yè)和領(lǐng)域的知識及產(chǎn)品。溝通能力善于雙向交流，知道如何有效傾聽和表達(dá)。分析能力能夠以不同的角度和方式思考問題。組織能力需要處理獲取和分析過程中收集到的大量雜亂的信息。寫作能力需求開發(fā)的最終產(chǎn)物是需求規(guī)格說明文檔。專業(yè)技術(shù)需要掌握如數(shù)據(jù)流圖、用例圖、實(shí)體關(guān)系圖等建模分析工具。提問技巧很多需求是通過面談和討論得到。觀察能力能夠從不經(jīng)意的閑談或觀察中發(fā)現(xiàn)重要信息。2軟件需求開發(fā)2.1需求獲取2.2需求分析2.3需求規(guī)格說明2.4需求驗(yàn)證需求常見來源用戶提交的需求文檔。與用戶進(jìn)行探討?，F(xiàn)有系統(tǒng)的問題報(bào)告和改進(jìn)要求。觀察或體驗(yàn)用戶工作。市場調(diào)查和用戶問卷調(diào)查。對同類產(chǎn)品或競品進(jìn)行分析。對用戶的工作情景進(jìn)行分析。行業(yè)專家的建議需求獲取的內(nèi)容明確業(yè)務(wù)需求明確項(xiàng)目范圍明確業(yè)務(wù)流程和業(yè)務(wù)規(guī)則明確數(shù)據(jù)定義明確軟件功能明確質(zhì)量屬性明確系統(tǒng)接口明確設(shè)計(jì)和實(shí)現(xiàn)約束用戶訪談用戶訪談是實(shí)踐當(dāng)中應(yīng)用最為廣泛的需求獲取方法之一。優(yōu)點(diǎn)：簡單、直接、形式靈活、交流比較深入。缺點(diǎn)：占用時(shí)間長，信息存在片面性。應(yīng)用場景：用戶訪談在所有的需求獲取中都被開發(fā)者廣泛使用，需要注意的是訪談的目標(biāo)和話題根據(jù)用戶的不同而有所側(cè)重。用戶訪談---話題類型（1）開放式話題封閉式話題被會見者對答復(fù)的選擇是開放和不受限制的，他們可能答復(fù)兩個(gè)詞，也可能答復(fù)兩段話。在希望得到豐富，具有一定深度和廣度的信息時(shí)，開放式問題比較合適。答案有基本的形式，被會見者的回答是受到限制的，如選擇題、判斷題等。例如：1、你對屌絲一詞有什么看法？例如：1、呼叫中心一月平均接到多少個(gè)電話？2、下列哪個(gè)信息對你最有用？用戶訪談---話題類型（2）開放式話題封閉式話題優(yōu)點(diǎn)被會談?wù)吒杏X更自在和感興趣；可獲得豐富的細(xì)節(jié)；允許更多的自發(fā)性；可以收集被會談?wù)呤褂玫脑~匯；對沒采用的進(jìn)一步的提問有啟迪作用；可以在沒有太多準(zhǔn)備的情況下進(jìn)行；節(jié)省時(shí)間；切中要點(diǎn)；保持對面談的控制；快速探討大范圍問題；得到貼切的數(shù)據(jù)；缺點(diǎn)可能產(chǎn)生太多不相干的細(xì)節(jié)；面談可能失控；會花費(fèi)大量時(shí)間才能獲得有用的信息量；可能使會談?wù)呖瓷先]有準(zhǔn)備；會談?wù)弑容^厭煩；得不到豐富的細(xì)節(jié)；不利于建立友好關(guān)系；用戶訪談---時(shí)間安排階段任務(wù)占用時(shí)間備注開場白陳述預(yù)先對問題的考慮和理解5-15分鐘聚焦本次訪談的話題，明確訪談的范圍和層次預(yù)先計(jì)劃問題尋找問題的答案25-30分鐘主體工作，關(guān)鍵部分即興問題擴(kuò)大需求信息量20-30分鐘注意導(dǎo)向，不要跑題太遠(yuǎn)總結(jié)總結(jié)訪談內(nèi)容5-10分鐘訪談?wù)呦虮辉L談?wù)邚?fù)述主要問題的答案用戶訪談盡量選擇相對封閉的環(huán)境，一次訪談的時(shí)間一般不要超過1小時(shí)。下面是很多書籍中提供的一個(gè)參考時(shí)間安排。用戶訪談---記錄工作用戶訪談期間將會產(chǎn)生大量的信息，免不了記錄的工作。下面是很多經(jīng)典的案例為我們提供了可參考的記錄方式。記錄方式優(yōu)點(diǎn)缺點(diǎn)建議自己做筆記直接、簡單、靈活容易走神記重點(diǎn)要點(diǎn)，并確認(rèn)專人做筆記精力集中在訪談上容易產(chǎn)生記錄偏差訪談結(jié)束時(shí)讓記錄人員向雙方做簡要陳述錄音免受記錄工作影響信息易失真記錄大綱和關(guān)鍵信息錄像免受記錄工作影響難以操作用戶訪談---溝通技巧多數(shù)情況下，應(yīng)該事先制作訪談問卷發(fā)給被訪談?wù)?，羅列出要問的主要問題。被訪談?wù)呤虑坝羞@樣的問卷，他有可能進(jìn)行一些思考，不至于會談時(shí)無話可談或者無話不談。把握訪談方向，在整個(gè)訪談過程中，信息應(yīng)該是從被訪談?wù)吡飨蛟L談?wù)?，而不是相反。有資料認(rèn)為，被訪談?wù)吲c訪談?wù)哒f話時(shí)間的比例應(yīng)該是2:1。不要問過長的問題，較長的問題應(yīng)該將其拆分，采用遞進(jìn)的方法逐個(gè)解決。用戶訪談---提問順序訪談提問的順序應(yīng)該按業(yè)務(wù)邏輯組織。面對每一組問題，注意借鑒歸納和演繹方式。金字塔結(jié)構(gòu)（歸納：特定問題開始，通用問題結(jié)束）被會見者需要對話題進(jìn)行預(yù)熱，通過逐步引導(dǎo)使被會見者打開話匣子。會見者發(fā)現(xiàn)自己事先對事實(shí)的確認(rèn)存在較大偏差。會見者看上去不情愿討論這個(gè)話題。漏斗結(jié)構(gòu)（演繹：通用問題開始，特定問題結(jié)束）漏斗結(jié)構(gòu)為開始一場面談提供了一種容易而輕松的途徑。被會見者對這個(gè)話題有情緒，并且需要自由表達(dá)這些情緒的時(shí)候。會見者事先對事實(shí)了解不多時(shí)。用這種方式組織面談能得出很多的詳細(xì)信息菱形結(jié)構(gòu)（歸納—演繹-歸納：特定問題開始，轉(zhuǎn)向通用問題，特定問題結(jié)束）使用菱形結(jié)構(gòu)的主要優(yōu)點(diǎn)是通過各種各樣的問題保持被會見者的興趣和注意力。一旦掌握了如何在正確的時(shí)間問正確的問題，就可以多樣地選擇問題的順序。用戶訪談---計(jì)劃安排在用戶訪談前，要有精心的計(jì)劃安排，根據(jù)需求獲取所處的階段確定訪談的時(shí)間、人員和主題等，將訪談內(nèi)容事前告知被訪談人，避免訪談效率低下。針對不同的訪談人，要采用不同的方式和要點(diǎn)。訪談主題訪談要點(diǎn)期望部門訪談人訪談時(shí)間備注用簡短的話概述提取關(guān)鍵點(diǎn)指定理想的訪談對象用戶方聯(lián)絡(luò)人指定用戶方聯(lián)絡(luò)人指定用戶訪談計(jì)劃安排模板用戶訪談---過程小結(jié)準(zhǔn)備訪談閱讀背景資料，確定面談主題、目標(biāo)、問題和被會見者。注意記得和被會見者聯(lián)系并確認(rèn)面談的安排，不要遲到，著裝正式。主持訪談開始盡量建立一個(gè)理想的氛圍和環(huán)境來促進(jìn)會見者和被會見者之間的交流和溝通。1、簡要重申面談的目標(biāo)。2、用一些非常一般的、輕松的、開放式的問題作為開始。3、準(zhǔn)備好筆記本、錄音機(jī)或者其他記錄設(shè)備，并禮貌地詢問相關(guān)人員是否可以錄音或者錄像。過程中通過提問和傾聽來完成和被會見者的信息交流，按照計(jì)劃控制面談的進(jìn)行，必要時(shí)進(jìn)行適當(dāng)?shù)恼{(diào)整。1、保持有禮貌的傾聽。2、保持面談主題、控制面談過程。3、觀察被會見者。結(jié)束時(shí)要表示感謝并回答被會見者提出的問題，保持與被會見者的親善和信任關(guān)系。1、面談應(yīng)該在1小時(shí)內(nèi)結(jié)束，并非要在提出所有關(guān)心的問題后才能結(jié)束面談。2、總結(jié)談話的要點(diǎn)。3、感謝被會見者，并且給時(shí)間讓他們詢問一些他們自己關(guān)心的問題。處理訪談結(jié)果復(fù)查面談記錄，總結(jié)面談信息，整理出內(nèi)容要點(diǎn)，進(jìn)行分類，整理成文檔。原型法---為什么要建立原型原型作為一種需求工具，可明確并完善需求。原型作為一種設(shè)計(jì)工具，可用它優(yōu)化系統(tǒng)易用性，評估可能的技術(shù)方案。原型作為一種構(gòu)造工具，是產(chǎn)品最初的功能實(shí)現(xiàn)，可發(fā)展為最終產(chǎn)品。使用原型，發(fā)現(xiàn)并解決需求中的二義性、不完整性和不確定性問題。直觀的原型，更易于理解，能更具體地思考問題。構(gòu)建原型的目標(biāo)是降低項(xiàng)目風(fēng)險(xiǎn)。原型法---為什么要建立原型軟件開發(fā)早期，有時(shí)很難定義出確切的軟件需求，提供詳細(xì)的需求規(guī)格說明書。軟件系統(tǒng)的很多具體細(xì)節(jié)往往是隨著軟件系統(tǒng)的建立而逐步明確的。這樣，在需求分析階段，分析人員常常得花大量時(shí)間去捕捉一些非常模糊的想法，并花大量時(shí)間以這種模糊的認(rèn)識為基礎(chǔ)去編寫包括很多細(xì)節(jié)內(nèi)容的需求規(guī)格說明書，因而需求規(guī)格說明書的一致性、準(zhǔn)確性、正確性、有效性很難保證。常規(guī)的軟件開發(fā)各階段相互傳遞信息的唯一工具是文檔。

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

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

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

文檔分析是專門針對文檔進(jìn)行需求獲取的活動。其主要獲取對象包括相關(guān)產(chǎn)品的需求說明書、客戶需求文檔、相關(guān)數(shù)據(jù)及流程說明等。其主要優(yōu)點(diǎn)是能夠詳細(xì)、直觀地對數(shù)據(jù)流細(xì)節(jié)進(jìn)行了解和分析。缺點(diǎn)也比較明顯，企業(yè)機(jī)構(gòu)中，文檔量通常非常大，由此容易使需求獲取人員陷入文山書海中不能自拔，甚至引起誤導(dǎo)。文檔分析通常配合用戶訪談或者用戶調(diào)查期間開展。采用此策略的的目的是因?yàn)橛脩粼L談或者用戶調(diào)查難以獲得數(shù)據(jù)方面的詳細(xì)需求，你不能指望被訪談?wù)呋蛘弑徽{(diào)查者能夠記住相關(guān)數(shù)據(jù)細(xì)節(jié)。

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

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

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

“上一句話是指…”、這個(gè)、那個(gè)…..優(yōu)秀需求規(guī)格說明書的特性特性說明正確性文檔內(nèi)的所有需求都具有正確性。無歧義文檔內(nèi)的所有需求都是無歧義的?？沈?yàn)證文檔內(nèi)的所有需求都是可驗(yàn)證的。完備性描述了所有的需求，包括功能、性能、約束、質(zhì)量屬性、對外接口及待解決問題。一致性不能同高層次的需求相沖突，同一層次的不同需求之間也不能互相沖突。優(yōu)先級根據(jù)重要性和穩(wěn)定性，建立需求的優(yōu)先級?？筛櫩上蚯案?、向后跟蹤?？尚薷乃慕Y(jié)構(gòu)和風(fēng)格使得人們可以對其中任一需求進(jìn)行容易地、完整地、一致地修改，同時(shí)還不會影響文檔現(xiàn)有的結(jié)構(gòu)和風(fēng)格。這要求文檔有著條理分明并且易于使用的組織方式（不應(yīng)該采用技術(shù)為導(dǎo)向，應(yīng)該采用業(yè)務(wù)為導(dǎo)向來組織）。沒有重復(fù)冗余。獨(dú)立表達(dá)每個(gè)需求，而不是和其他需求混在一起。2軟件需求開發(fā)2.1需求獲