公司內(nèi)部需求分析培訓PPT

1、軟件需求馮馮 曦曦什么是需求？軟件需求的層次和分類需求的重要性需求工程簡介需要，要求，由需要而產(chǎn)生的要求。需要需要業(yè)務干系人(項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門)想要實現(xiàn)的愿景和目標最終用戶想要完成的任務要求要求業(yè)務干系人附加在愿景和目標上的約束最終用戶為順利完成任務提出的約束自身影響自身影響企業(yè)的生存和發(fā)展企業(yè)的產(chǎn)值和利潤員工的發(fā)展和收入利益鏈沖突沖突公司的綜合實力和干系人的最終目標利潤同成本不斷變化的需求對系統(tǒng)建設的影響需求雖然由客戶觸發(fā),但是需要結合自身綜合考慮,合理規(guī)避風險,合理開發(fā)什么是軟件需求？什么是軟件需求？IEEE（電氣和電子工程師協(xié)會）的

2、軟件工程標準詞匯表（1997年）中對需求的定義1. 用戶解決問題或達到目標所需的條件或權能(Capability)2. 系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式文檔所需具有的條件或權能3. 一種反映上面(1)或(2)所描述的條件或權能的文檔說明。需求是客觀的，它只告訴我們建設人員應該實現(xiàn)什么目標，而不會告訴我們怎么做，我們更不能憑借一點理解、想象和臆測而主觀的去設計和開發(fā)。文檔相當重要！為什么？文檔不只是單單做為一個需求記錄，文檔的核心作用是做到需求的真實記錄、保存，并指導后續(xù)產(chǎn)品開發(fā)，保證不會偏差太大。同時起到不同部門的溝通媒介作用，也可以對后續(xù)的需求變更進行預防。但是需求文檔的質(zhì)量必

3、須保證，要做到真實可靠，條理清晰，層次分明。2022-5-1業(yè)務需求表示組織或客戶高層次的目標。業(yè)務需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務需求描述了組織為什么要實現(xiàn)這個系統(tǒng)，即組織希望達到的目標。使用前景和范圍文檔來記錄業(yè)務需求，這份文檔有時也被稱作項目輪廓圖或市場需求文檔。具有以下特點：直覺，凌亂，片斷，模糊，無條理，甚至是自相矛盾，用戶需求用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統(tǒng)必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。功能

4、需求和非功能需求功能需求（functional requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務，滿足業(yè)務需求。我們需要在軟件需求說明書（SNS)中盡可能詳細的描述整個系統(tǒng)的行為，也就是功能需求。非功能需求是指軟件產(chǎn)品為滿足用戶業(yè)務需求而必須具有且除功能需求以外的特性，包括系統(tǒng)的性能、可靠性、可維護性、可擴充性和對技術和對業(yè)務的適應性等。業(yè)務需求用戶需求功能需求和非功能需求指導轉化業(yè)務需求與用戶需求之間不是一對一的關系，一個業(yè)務需求可能對應多個用戶需求，一個用戶需求可能滿足多個業(yè)務需求。一個用戶需求可能會涉及一個或多個功能需求，功能需求從開發(fā)人員的角度

5、描述系統(tǒng)行為，一個功能需求支持一個或多個用戶需求，非功能需求支持功能需求。分清楚那些是業(yè)務需求、哪些是用戶需求、哪些是功能性需求和非功能性需求對軟件的開發(fā)有著重大的指導意義，絕不可以以偏概全，錯誤地去揣摩用戶的心思。個人認為應該以業(yè)務需求為主線，以主線挖掘用戶需求，再以挖掘出的用戶需求去挖掘功能需求和非功能需求。2022-5-1在一般使用中，需求按照功能性功能性（行為的），非非功能性功能性（其它所有的行為），設計約束設計約束來分類。那么需求可以分成下面這些內(nèi)容：n功能需求n性能需求n環(huán)境需求n可靠性需求n安全保密要求n用戶界面需求n資源使用需求n成本消耗需求n開發(fā)進度需求n預先估計以后系統(tǒng)可能

6、達到的目標n執(zhí)行期約束2022-5-1Rational統(tǒng)一過程(RUP)是Rational軟件公司（現(xiàn)在Rational公司被IBM并購）創(chuàng)造的軟件工程方法。RUP描述了如何有效地利用商業(yè)的可靠的方法開發(fā)和部署軟件，是一種重量級過程（也被稱作厚方法學），因此特別適用于大型軟件團隊開發(fā)大型項目。Rational很著名的工具就是Rose，一種面向?qū)ο蟮慕y(tǒng)一建模語言的可視化建模工具。功能性（Functional）：特性、功能、安全性；可用性（Usability）：人性化因素、幫助、文檔；可靠性（Reliability）：故障頻率、可恢復性、可預測性；性能（Performance）：響應時間、吞吐量、

7、準確性、有效性、資源利用率；可支持性（Supportability）：適應性、可維護性、國際化、可配置性?！癋URPS+”中的“+”是指一些輔助性的和次要的因素實現(xiàn)（Implementation）：資源限制、語言和工具、硬件等；接口（Interface）；強加于外部系統(tǒng)接口之上的約束；操作（Operation）：對其操作設置的系統(tǒng)管理；包裝（Packaging）例如物理的包裝盒；授權（Legal）：許可證或其他方式。使用“FURPS+”分類方案（或其他分類方案）作為需求范圍的檢查列表是有效的，可以避免遺漏系統(tǒng)某些重要方面。其中某些需求可以統(tǒng)稱為質(zhì)量屬性（quality attribute）、質(zhì)

8、量需求（quality requirement）或系統(tǒng)的“某屬性”。這些需求包括：可用性、可靠性、性能和可支持性優(yōu)點：2022-5-12022-5-1用戶參與不足用戶需求擴展有岐義的需求鍍金問題過于抽象的需求忽略了用戶分類不準確的計劃模擬兩可的需求不必要的特性過于精簡的規(guī)格說明霧里看花需求說不清客戶對需求永遠只有朦朧的感覺隔靴搔癢需求說不準分析人員或客戶的理解有誤刻舟求劍需求說不全客戶的需求總是不斷的變動和增加諱疾忌醫(yī)需求不重視守缺抱殘需求分析方法 和工具缺乏2022-5-1ESPITI(歐洲軟件過程改進培訓倡議）所作的一個調(diào)查，3800個被調(diào)查者認為，軟件開發(fā)的主要問題、次要問題和不是問題的

9、問題如圖。一半以上的人認為，軟件的二個最大問題是：1、需求規(guī)格說明2、管理客戶需求相對而言，編碼不是問題1、需求規(guī)格說明 4、軟件和測試2、管理客戶需求 5、項目管理3、建檔6、編碼問題的重要性依次降低2022-5-1修復的相對成本修復的相對成本需求階段需求階段0.1-0.20.1-0.2設計設計0.50.5維護維護2020驗收測試驗收測試5 5單元測試單元測試2 2編碼編碼1 1“ 需求開發(fā)需求開發(fā)可能是軟件開發(fā)中最困難、最關鍵、最易出錯以可能是軟件開發(fā)中最困難、最關鍵、最易出錯以及最需要溝通的方面及最需要溝通的方面 ”2022-5-12022-5-12022-5-1需求是產(chǎn)品的根源，需求工

10、作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。（1）不含糊性：如果每一個需求只有唯一的一種解釋，那它是不含糊的；（2）完整性：如果需求包括了功能、性能、時間響應要求、限制、接口等屬性，不存在沒有界定的、以為是隱含或默認而實際存在認知差異的需求，是完整的；（3）可檢驗性：存在有限的、經(jīng)濟與技術都是可行的檢驗方法和程序，對需求的實現(xiàn)與否，進行檢驗，使得用戶和組織通過該檢驗，確認需求被按照需求規(guī)格說明實現(xiàn)；（4）一致性：需求作為一種要求是一致的，不存在系統(tǒng)內(nèi)相互沖突的需求要求；（5）可跟蹤性：需求可追蹤；（6）可使用性：可為產(chǎn)品的各階段，特別是維護階段，提供充分有

11、用的信息。2022-5-1需求工程是系統(tǒng)工程和軟件工程的一個交叉分支，涉及到軟件系統(tǒng)的目標、軟件系統(tǒng)提供的服務、軟件系統(tǒng)的約束和軟件系統(tǒng)運行的環(huán)境。它還涉及這些因素和系統(tǒng)的精確規(guī)格說明以及系統(tǒng)進化之間的關系。提供用戶在現(xiàn)實世界的需要和軟件能力之間的橋梁。2022-5-1需求工程需求工程2022-5-12022-5-12022-5-1需求獲取是需求工程的第一個環(huán)節(jié)，也是最重要并且比較困難的環(huán)節(jié)。它需要需求人員要有相關領域知識，并且擅長同客戶交流和溝通，有比較敏銳的嗅覺，善于同客戶凌亂的信息中采集到有用的部分，同時要有很好的大局觀，把握好需求的層次，不遺漏也不過于陷入繁瑣的需求無底洞。需求獲取常見

12、問題需求獲取常見問題缺乏領域知識,應用領域的問題常常是模糊的、不精確的；存在默認的知識,如難以描述的常識問題；存在多個知識源,且多知識源之間可能有沖突；客戶可能的偏見，如不能提供或不想告知你所需要了解的事情。2022-5-1研究應用背景，建立初始的知識框架；根據(jù)獲取的需要，采用必要的獲取方法和技巧；先行確定獲取的內(nèi)容和主題，設定場景；分析用戶的高（深）層目標，理解用戶的意圖；進行涉眾分析，針對涉眾的特點開展工作。2022-5-1n 在項目的范圍之內(nèi)n 所有為用戶創(chuàng)建解決系統(tǒng)必須的信息 需求 通常體現(xiàn)為用戶的觀點、看法、目標或者問題 問題域特性 需要注意的是不要忽略系統(tǒng)的環(huán)境和約束n 獲取的內(nèi)容

13、不是一次得到的，而是逐步積累的2022-5-1n 涉眾p 用戶p 客戶p 領域?qū)＜襭 市場人員、銷售人員等其他 用戶替代源n 相關產(chǎn)品p原有系統(tǒng)p 競爭產(chǎn)品p 協(xié)作產(chǎn)品（和解系統(tǒng)存在p 接口的其他軟件系統(tǒng)）n 硬數(shù)據(jù)p 登記表格、單據(jù)、報表等p 定量文檔p 備忘錄、日志等定性文檔n 重要文檔p 原有系統(tǒng)的規(guī)格說明p 競爭產(chǎn)品的規(guī)格說明p 協(xié)作產(chǎn)品的規(guī)格說明p 客戶的需求文檔（委托開p 發(fā)的規(guī)格說明、招標書）相關技術標準和法規(guī)n 相關法律、法規(guī)及規(guī)章制度p 行業(yè)規(guī)范、行業(yè)標準2022-5-12022-5-1n 傳統(tǒng)方法傳統(tǒng)方法 問卷調(diào)查、面談、硬數(shù)據(jù)分析、文檔檢查、需求剝離等n 集體獲取方法集體

14、獲取方法 頭腦風暴（Brainstorming）、專題討論會（Workshop）、JAD （應用程序開發(fā)聯(lián)系會議）等n 原型化方法原型化方法n 知識工程方法知識工程方法 任務分析（Task Analysis）、協(xié)議分析（Protocol Analysis）場記分析法、卡片分類法、分類表格技術和基于模型的知識獲取n 基于上下文的方法基于上下文的方法 觀察、民族志（Ethnography）和話語分析（ConversationAnalysis）2022-5-1n 務必讓所有的涉眾都表達出自己的意見。n 不要以抽象和模糊的需求作為結束。對抽象和模糊的需求，要進行細化，讓真正的需求顯露出來。n 使用多種方法表達需求信息。利用不同的分析技術為相同的需求進行建模，通過分析不同的關注點，考察需求是否完整。n 注意檢查邊界值和布爾邏輯。2022-5-1n 用戶想不出更多的用例；n 用戶想出的新用例都是導出用例（通過其他用例的結合可以推導出該用例）；n 用戶只是在重復已經(jīng)討論過的問題；n 新提出的特性、需求等都在項目范圍之外；n 新提出的需求優(yōu)先級都很低；n