軟件需求三部分

軟件需求工程（三）太原理工大學計算機學院張澤華

沒有什么比恰當的舉例更難的了。

——馬克吐溫（MarkTwain）要發(fā)明創(chuàng)造，你得有豐富的想象力和一堆廢物。

——托馬斯

愛迪生（ThomasEdison）

需求獲取與需求分析需求獲取的方法尋找客戶的需求（導出問題）理解用戶的需要定義系統(tǒng)管理客戶需求建模結構化分析面向對象的建模商業(yè)建模用例建模原型開發(fā)第五章需求獲取的方法獲取需求是一個確定和理解不同涉眾的需要和約束的過程。獲取需求的方法：面向目標，基于場景，面向方面，面向視點，基于知識。需求描述語言可分為三種：非形式化、半形式化和形式化語言。需求的來源需求獲取需求獲取應該識別項目相關人員的要求，解決不同項目相關人員之間的需求沖突。需求獲取的困難–用戶通常并不真正知道自己希望計算機系統(tǒng)做什么–用戶通常使用業(yè)務語言表達需求，開發(fā)人員缺乏相關的領域知識和經驗，難以準確理解這些需求–不同的用戶提出不同的需求，可能存在矛盾和沖突–管理者可能出于增加影響力的原因而提出特別的需求–由于經濟和業(yè)務環(huán)境的動態(tài)性，需求經常發(fā)生變更需求獲取的過程主要的獲取方法面向目標（Goal）的方法從面向對象到面向目標的范式，問題空間的需求（穩(wěn)定）和解空間的需求（變化）區(qū)分管理?；趫鼍埃⊿cenario）的方法*基于應用的特定情境描述用戶需求，常用基于用例的方法。面向方面（Aspect）的方法將功能性需求為基礎，可將非功能性需求作為方面的需求，的一種多視角處理方法。面向視點（Viewpoint）的方法用戶多視點，體現涉眾局部需求的整合?；谥R的方法需求描述語言非形式化語言主要是指自然語言和進行了一些結構化的類自然語言，在目前實踐中應用最為廣泛。形式化語言主要以數學與邏輯的形式對系統(tǒng)需求進行描述，例如Z、VDM、STATECHARTS、Petri網等。半形式化方法如圖、表等方式，或者有選擇的采用一些數學或邏輯的描述方式，試圖兼顧可理解性和描述的準確性，在一定程度上兼具形式化語言和非形式化語言的特征（包括其優(yōu)點和缺點），其代表例如PSL、SADT、UML等。獲取需求的案例我們將要開發(fā)一個在線圖書借閱系統(tǒng)系統(tǒng)。傳統(tǒng)的借書方式要求讀者親自來到圖書館，這顯得非常不方便，而且隨著藏書的增加和讀者群的增長，尤其而且大量的讀者到圖書館，使得圖書館的場地不足，工作人員也不夠了。所以想到借助網絡，讓讀者通過網絡借/還書，這樣可以省掉大量的場地維護和工作人員成本支出，同時計算機可以方便的檢索目錄，讓讀者可以足不出戶借到需要的書。為了把書送到借閱人手里，我們已經聯(lián)系了快遞公司，初步達成協(xié)議，由他們往返借閱人和圖書館之間，把圖書送出和收回。讀者在網上出示和驗證借書卡，找到他們需要的書，提交申請，圖書管理員確認后，就會通知快遞公司來取書，當讀者拿到書之后，快遞公司需要把讀者的簽單拿回來以證明讀者已經拿到了書。當然這個過程中，讀者是需要付費的。還書基本上也是同樣的過程。需求獲取方法第六章尋找客戶的需求（導出問題）

一致性：了解用戶需求的第一步是在有關問題的定義上和用戶達成一致。用戶陳述的問題往往是表面現象，我們有必要和用戶一起挖掘出問題背后的問題，即找出問題的根源，從而從根本上解決問題。確定系統(tǒng)的涉眾，除了開發(fā)團隊和用戶等直接涉眾，我們還要找到間接的涉眾。系統(tǒng)邊界確定了我們系統(tǒng)的內涵，即它究竟包括哪些功能，可以解決哪些問題。確定解決方案的約束條件。在問題定義上達成共識描述問題的模版

遵循原則：從業(yè)務（商業(yè)）需求到用戶需求。注意：用戶提出“需要”的特性并不總是與用戶利用新產品來處理他們的任務(task)時所需的功能相等價。了解問題產生的根本原因（一）

魚骨圖問題的溯因過程：定義描述問題，問題原因分類，原因的征兆分析。最后縮小確定首要領域選擇。了解問題產生的根本原因（二）帕累托圖（ParetoChart）通過pareto圖分析確認引起問題的主要因素。確定涉眾和用戶涉眾(stakeholder)，在軟件開發(fā)項目中主要是指和這個項目有密切相關利益的人，他們共同感興趣的就是需求分析階段。這些涉眾包括客戶、用戶、業(yè)務或需求分析員(負責收集客戶需求并編寫文檔，以及負責客戶與開發(fā)機構之間聯(lián)系溝通的人)、開發(fā)人員、測試人員、用戶文檔編寫者、項目管理者和客戶管理者。確定涉眾的問題舉例

這里所指的涉眾包括客戶方面的項目負責人和用戶，開發(fā)方面的需求分析人員和項目管理者。在線圖書借閱系統(tǒng)中的涉眾注意：有一些受產品影響的人并不一定是產品的直接使用者，而是通過報表或其它應用程序訪問你產品的數據和服務。這些非直接的或次級secondary的用戶也有他們的需求。用戶的需求和開發(fā)者之間的未必有直接的信息關聯(lián)和直接的交流。用戶需求的獲取路徑從目前的beta測試版或先前版本產品的使用者中收集需求意見。建立現存的長期客戶關系或組成一個核心用戶組，它是由目前產品的用戶組或競爭產品的用戶組組成的。如果建立起一個用戶組，必須明確，這些參與者是否真正代表了各個方面的用戶，而這些用戶的需求是否可以促進產品的開發(fā)。核心用戶組必須包含各種用戶類型，不僅包括知識淵博的用戶，還應包括缺乏經驗的用戶產品代表者產品代表者的需求文檔多個產品代表者確定系統(tǒng)的界限定義系統(tǒng)的關鍵首先是要給出系統(tǒng)的邊界。該邊界把我們的系統(tǒng)和外部世界一分為二，換言之，系統(tǒng)邊界確定了我們系統(tǒng)的內涵，即它究竟包括哪些功能，可以解決哪些問題。我們可以根據確定的系統(tǒng)邊界給出系統(tǒng)的環(huán)境模型。它指出了我們的系統(tǒng)以及其它和它交戶的系統(tǒng)之間的關系。確定解決方案的約束條件潛在的系統(tǒng)約束到期催還功能的約束分析在線圖書借閱系統(tǒng)的界限第7章需求獲取技術第7章理解用戶的需要有效而直接的用戶訪談技巧要求訪談者準備一個問題列表，目的是了解真實的問題和潛在的解決方案。專題討論會可以減少一部分需求沖突，繞開紛繁的情況得到需求列表，以此作為進一步分析的基礎。制作情節(jié)串聯(lián)板就是使用工具向用戶說明系統(tǒng)如何適應組織的需要，并表明系統(tǒng)將如何運轉。情節(jié)串聯(lián)板的類型包括被動式、主動式和交互式，其復雜度依次遞增。用戶訪談用戶面談–一種理解商業(yè)功能和商業(yè)規(guī)則的最有效方法面談過程需要認真的計劃和準備–面談之前?確立面談目的?確定要包括的相關用戶?確定參加會議的項目小組成員?建立要討論的問題和要點列表?復查有關文檔和資料?確立時間和地點?通知所有參加者有關會議的目的、時間和地點用戶訪談的五個階段有效而直接的用戶訪談技巧要求訪談者準備一個問題列表，目的是了解真實的問題和潛在的解決方案。為了盡可能獲得沒有偏見的答案，需要確保提出的問題與背景無關（ContextFree）。準備訪談計劃和安排訪談日程訪談開始和結束引導訪談后續(xù)的訪談整理工作–進行面談?衣著得體，準時到達?尋找異常和錯誤情況?深入調查細節(jié)?詳細記錄?指出和記錄下未回答條目和未解決問題–面談之后?復查筆記的準確性、完整性和可理解性?把所收集的信息轉化為適當的模型和文檔?確定需要進一步澄清的問題域?適當的時候向參加會議的每一個人發(fā)一封感謝信面談過程需要認真的計劃和準備開放性問題與封閉性問題在開始一個議題時，一般會用開放性的問題（什么，為什么，多么），便于被訪談者展開思路。隨著討論的深入，漸漸轉為提供結論的封閉性問題，這樣能幫助證證實你的理解。太多的封閉性問題會導致收集的信息不完整，太多的開放性問題可能導致需求分析者的理解失誤。1)需求的來源不同類型應用能從人員處獲取需求的比例隨受限程度不同而不同。應用受到的限制越少，能從人們那里獲得的需求比例越大。2)識別利益相關者（stakeholder）對項目承擔風險和享有利益的人即為利益相關者。他們是應用的“客戶”。如公司高層、項目經理、最終用戶、系統(tǒng)開發(fā)人員等。不同利益相關者之間的利益沖突會導致需求不一致。如果需求沖突不能調和，項目就會陷入困境，最后往往會被取消。即使所有利益相關者的需求一致，也可能由于實現代價高昂，需求不能得到完全滿足。了解用戶的真實需求..一般客戶希望得到一個產品，他們需要系統(tǒng)開發(fā)人員幫助，明確自己的需要。例如，有一個客戶愿望框架：“Encounter是一個角色扮演游戲，它能模擬被扮演人物的全部或部分活動，應對人們具有相當吸引力?！?.完整的客戶要求應當記錄在需求文檔的“概述”部分。但需求中還有一些問題需要由系統(tǒng)分析人員與客戶商量，以明確這些需求。例如，游戲是否只允許玩家扮演一個角色還是可以同時控制多個人物？當兩個人相遇時會發(fā)生什么事情？游戲是否可以聯(lián)網對戰(zhàn)等。了解用戶需求案例需求的調研方法①調研用戶的組織結構、崗位設置、職責定義，從功能上區(qū)分有多少個子系統(tǒng)，劃分系統(tǒng)的大致范圍，明確系統(tǒng)的目標。②調研每個子系統(tǒng)的工作流程、功能與處理規(guī)則，收集原始信息資料，用數據流來表示物流、資金流、信息流三者的關系。③對調研內容事先準備，針對不同管理層次的用戶詢問不同的問題，列出問題清單。將操作層、管理層、決策層的需求既聯(lián)系又區(qū)分開來，形成一個需求的層次。④對與用戶溝通的情況及時總結歸納，整理調研結果，初步構成需求基線。若基線符合要求，則需求獲取完成。需求的調研方法需求調研的主要手段發(fā)調查表；召開調查會；向用戶領域的專家個別咨詢；實地考察，跟蹤現場業(yè)務流程；查閱與待開發(fā)系統(tǒng)有關的資料；使用各種調查工具等。需求調研的主要手段問卷調查–可用于確認假設和收集統(tǒng)計傾向數據–問卷需要快速回答，允許匿名方式存在問題–相關的問題不能事先決定–問題背后的假設對答案造成偏頗，如這符合你的期望嗎？–難以探索一些新領域–難以繼續(xù)用戶的模糊響應在完成最初的面談和分析后，可作為一項協(xié)作技術可以收到良好的效果。調查問卷調查問卷使問卷表盡可能的簡短。通常，一個問卷表包含的問題不超過10-15個。估計回答問題需要的時間。確保問題是前后一致的，沒有讓人含混的理解為了保證不會理解含混，讓與回答者關系密切的人員來進行問卷調查，并保證他們對問題的理解是正確的。在制訂問題前，先確定你需要得到怎樣的答案分別列出所有可能的答案確保所有的需求能被問題覆蓋。最后，剔除掉與需求無關的問題?，F場觀察商業(yè)過程和工作流程–掌握用戶如何實際使用一個系統(tǒng)以及到底用戶需要哪些信息，最好的辦法是親自觀察用戶是如何完成實際工作的。?一般方法–對辦公室進行快速瀏覽，了解布局、設備要求和使用、工作流總體情況。–安排幾個小時觀察用戶是如何實際完成他們的工作，理解用戶實際使用計算機系統(tǒng)和處理事務的細節(jié)。–像用戶一樣接受訓練和做實際工作，發(fā)現關鍵問題和瓶頸。?注意：觀察可能使用戶緊張?，F場考察專題討論會常見的專題討論會需求專題討論會需求專題討論會–項目主要風險承擔人在短暫而緊湊的時間段內集中在一起，一般為1至2天，與會者可以在應用需求上達成共識、對操作過程盡快取得統(tǒng)一意見。優(yōu)點–協(xié)助建立一支高效的團隊，圍繞項目成功的目標；–所有的風險承擔人都暢所欲言；–促進風險承擔人和開發(fā)團隊之間達成共識；–揭露和解決那些妨礙項目成功的行政問題；–能夠很快地產生初步的系統(tǒng)定義。專題討論會現場情節(jié)串聯(lián)板情節(jié)串聯(lián)板的復雜程度與成本第8章定義系統(tǒng)項目范圍涉及三個要素：項目所要提交的功能，項目可用資源，實現項目可用的時間。讓客戶滿意并不意味著就要滿足客戶所有的需求。建立的項目需求基線必須滿足：至少對客戶來說，是可以接受的；在開發(fā)團隊看來，具有合理的成功可能性。前景文檔獲取用戶的需要、系統(tǒng)的特性以及項目的其它需求。它的范圍跨越需求金字塔的上兩級，在較高的抽象級別上定義問題和解決方案。

項目的范圍問題項目的可用資源：主要包括用于開發(fā)、測試、文檔編寫、質量保證及其他工作的勞動力和設備資源等。項目開發(fā)時間系統(tǒng)功能、時間和資源軟件需求工程太原理工大學軟件學院2015? 1-45項目視圖與范圍項目視圖把項目參與者定位到一個共同和明確的方向上。項目視圖描述了產品所涉及的各個方面和在完美環(huán)境中最終具有的功能。相反的，范圍描述了產品應包括的部分和不應包括的部分，確定了項目的局限性。范圍的說明在包括與不包括之間劃清了界線。項目的業(yè)務需求在視圖上和范圍上形成文檔，這些必須在創(chuàng)建項目之前起草。開發(fā)商業(yè)軟件的公司經常編寫市場需求文檔，其實這種文檔也是為了類似的目的，但這種文檔較為詳細地涉及關于目標市場部分的內容，這是為適應商業(yè)的需要。視圖和范圍的文檔為項目的主辦者或具有同等地位的人所擁有。業(yè)務需求是從各個不同的人那里收集來的，這些人對于為什么要從事該項目和該項目最終能為業(yè)務和客戶提供哪些價值有較清楚的了解。它們包括主辦者、客戶、開發(fā)公司的高級管理人員及項目的幻想者，例如產品的代表和市場部門人員。確定產品前景與項目范圍客戶要求的總比實際的要多簽訂合約的時候，項目范圍描述不清楚?？蛻艉晚椖拷M對寫成書面文件的需求理解不一致?？蛻艨傆性诮Y項之前把每一件事情都做得淋漓盡致的初衷。項目組人員總是無條件遷就客戶，客戶有求必應。

確立系統(tǒng)基線定義：逐項列舉的項目特性（系統(tǒng)功能），用以提交產品的特定版本?；€