《軟件工程》?精品課件合集第X章XXXX模塊3

需求第三章需求3.1什么是需求3.1什么是需求需求是目標軟件系統的根、和源。正確且恰當的需求是目標軟件系統成功的必要的、首要的、基本的條件，需求對目標軟件系統的成功起著至關重要的作用。需求是軟件過程的第一個階段，就是要確定目標軟件系統將具有哪些功能、將為用戶提供哪些服務、以及約束條件或要求等。3.1什么是需求擬解決的問題例如：解決某高校每學期全校師生所有課程的編排課表、解決人力資源管理中的工資管理、電子商務中的訂單管理問題、電子郵箱中的郵件管理問題、解決生產企業工作中的復雜的生產排程問題等等。相關的約束或條件，例如要求能夠支持10000個用戶同時訪問、能夠兼容于所有安卓手機等等。3.1什么是需求需求的目的就是要確定客戶到底想要want什么。需求的目的就是要確定客戶真正需要need什么。軟件項目失敗的主要原因之一就是不正確、不完整、不明確的需求。項目成果的首要因素則是正確的、完整的、明確的需求。3.1什么是需求開發方可以先“替”用戶挖掘需求、確定需求，先開發出成品，再找客戶。需求一定要來源于客戶和用戶。3.2需求的層次被動主動引領真正滿足用戶需求的軟件才會成功第三章需求3.3如何做需求3.3如何做需求獲取正確的、恰當的需求需要客戶方和開發方的共同努力和協作，需要實實在在、一步一步地做工作來獲得和明確需求。需求文檔RequirementsDocument應該是正式的、規范的，經客戶方和開發方、即甲乙雙方簽字后，與合同一起形成具有法律效力的文件。需求階段的工作稱之為需求工程RequirementsEngineering。3.3如何做需求需求階段的工作分為4個步驟：1、做準備2、需求調研3、形成需求文檔4、需求確認一、準備工作做需求的第一步是做好相應的準備工作，具體包括三項準備工作：1、確定此次需求調研的任務，包括討論的題目、內容；2、確定此次需求調研擬采用的方法；3、確定何時、何地、開發方和客戶方的哪些相關人員參加此次需求調研。1-1、確定調研任務每次調研之前，需求小組應該提前若干天與客戶方明確擬調研的議題、業務范圍和內容；需求小組要盡可能地在最短的時間內獲取最多的信息、更多確切的回答，因此針對調研任務，需求小組應該提前準備好擬調研和討論的問題清單。問題不易過大問題要盡量易于客戶回答，而且答案是明確的1-2、確定調研方法會談表格分析問卷調查錄像情境分析快速原型與專家會談分析現有的類似的產品從行業標準規章制度和政策法規中提取從互聯網上查找資料針對調研任務，需求小組應事先確定好擬采用的調研方法，以便需求小組和客戶方都做好相應的準備。1-3、確定3W時間地點人物（雙方）二、需求調研需求調研，即指需求獲取，是對客戶的需求進行挖掘、啟發、收集、記錄和整理的過程。二、需求調研需求調研記錄表調研題目

調研方法

開發方調研人員

被調研人員

調研時間

調研地點

調研內容記錄

需求調研，即指需求獲取，是對客戶的需求進行挖掘、啟發、收集、記錄和整理的過程。三、完成需求文檔項目名稱

項目描述對項目的簡單描述，包括項目背景、客戶與用戶、目的、基本概念等用戶介紹軟件產品面對的用戶詞匯表專業術語、縮略語清單功能性需求

非功能性需求修改記錄序號時間版本號修改人修改內容

文檔名

文檔編號

版本號

總頁數

文檔撰寫人

文檔撰寫時間

文檔檢查人

文檔檢查時間

開發方批準人

客戶發方批準人

開發方批準時間

客戶方批準時間

指開發方和客戶方雙方對需求的確認，以雙方在需求文檔上簽字、蓋章為標志。雙方確認的需求文檔可以作為開發方和客戶方之間的合同的一部分。四、需求確認需求的分類：功能性需求非功能性需求功能性需求FunctionalRequirements，指對目標軟件系統應該提供的業務功能或服務、系統如何對輸入做出反應，以及系統在特定條件下的業務行為的描述。功能性需求針對領域的業務功能、業務規則和業務流程，與業務領域高度相關。如，高校教學管理信息系統中教師查詢課表、學生打印成績單等。3.4功能性需求對功能性需求的描述要前后一致，即在整個需求文檔中，需求描述不能有前后矛盾的地方；要完備和詳細，就是說客戶所需的所有功能和服務都要描述出來，不能有遺漏，要做到所有人讀后都會有相同的理解。3.4功能性需求例如，網上商店系統中，關于操作購物籃的需求描述如下：顧客登錄后，即可獲得一個空的、可供使用的購物籃；允許用戶向購物籃中添加商品；允許用戶對購物籃中的每一種商品定義數量；允許顧客從購物籃中移除商品；允許顧客清空購物籃；允許顧客選擇運輸方式：陸運、或空運；……3.4功能性需求非功能性需求是指目標軟件系統除功能需求以外，為滿足用戶業務需求還必須具有的特性，如系統的性能、可靠性、健壯性、安全性、實用性、可維護性、可擴充性、容量、界面、接口、和所需要的軟硬件環境等。例如，某網上商店系統的性能要求是：要求系統能滿足10000個人同時訪問，且平均反應時間不能超過30秒；其可靠性要求是：要求系統能夠每周7天×24小時連續運行，年均非計劃宕機時間不能多于8小時。3.5非功能性需求要特別注意的是：非功能性需求，要避免使用帶有個人主觀感受和判斷的詞匯，如用戶友好的界面、快速的反應、方便的操作、足夠大的存儲空間等等。如：40秒的反應速度是快還是慢？3.5非功能性需求常用的定義非功能性需求的量度3.5非功能性需求1、速度請求響應時間屏幕刷新時間事務處理的速度……2、規模容納用戶數量，且通常與響應時間共同定義數據庫的容量要求可執行文件的大小……常用的定義非功能性需求的量度3.5非功能性需求3、健壯性系統對運行環境的要求失敗后重啟時間失敗中數據崩潰的概率有效輸入而獲得錯誤輸出的可能性的百分比無效輸入而獲得可接受的輸出的可能性的百分比……常用的定義非功能性需求的量度3.5非功能性需求4、可靠性故障頻率的度量，即指出現故障的平均間隔時間嚴重程度的度量……5、實用性成本學習和培訓時間用戶指南、提示……有些非功能性需求，如性能、安全性、健壯性、可靠性，通常會從總體上規范或約束系統的特性，可能比個別的功能性需求更加關鍵。有些關鍵的、重要的非功能性需求，能夠從根本上決定一個軟件系統是否能被客戶和用戶所接受。識別一個軟件系統的功能性需求是相對容易的，但是確定恰如其分的非功能性需求就需要較高的專業水平和經驗了。技術層面的非功能性需求將主要由整個系統的體系結構來實現和滿足。3.5非功能性需求快速原型(RapidPrototype)是一種非常有效的、快速獲取準確需求的方法。讓用戶看到、交互到、體會到將提供的核心的、主要的業務功能。快速原型應該包括目標軟件系統的主要功能的用戶界面。快速原型一定要快速搭建起來。快速原型界面上的數據和信息是寫死在代碼中的（hardcoded）。3.6快速原型快速原型案例為你所在學院的學生管理辦公室開發一套學生工作管理信息系統——新學期學生返校注冊管理3.6快速原型學生返校注冊界面3.6快速原型改進后的學生返校注冊界面3.6快速原型3.6快速原型3.6快速原型3.6快速原型需求面臨著諸多挑戰：開發方人員與客戶方人員的專業領域背景相差甚遠；語