【正文】 u Should precautions be taken against fire, water damage, or theft?Types of Requirements2023年 9月 28日 6時 52分4Quality Assuranceu What are the requirements for reliability, availability, maintainability, security, and the other quality attributes?u How must the characteristics of the system be demonstrated to others?u Must the system detect and isolate faults?u What is the prescribed mean time between failures?u Is there a maximum time allowed for restarting the system after a failure?u How can the system incorporate changes to the design?u Will maintenance merely correct errors or will it also include improving the system?u What efficiency measures will apply to resource usage and response time?u How easy should it be to move the system from one location to another or from one type of puter to another?Types of Requirements2023年 9月 28日 6時 52分Characteristics of Requirements4Are the requirements correct? 正確4Are the requirements consistent?一致4Are the requirements plete?完整4Are the requirements realistic?現實4Does each requirement describe something that is needed by the customer?必需？4Are the requirements verifiable?可證明4Are the requirements traceable?可跟蹤2023年 9月 28日 6時 52分Problems of Software Requirements4Stakeholders don’t know what they really want.4Stakeholders express requirements in their own terms.4Different stakeholders may have some conflicting requirements.4Organisational and political factors may influence the system requirements.4The requirements change during the development process. New stakeholders may emerge.4Requirements specification is too simple.Requirements problems result in 4060% software problems.2023年 9月 28日 6時 52分Requirements Development4確定產品所期望的用戶類；4獲取每個用戶類的需求；4了解實際用戶任務和目標以及這些任務所支持的業(yè)務需求；4分析源于用戶的信息，以區(qū)別用戶任務需求、功能需求、業(yè)務規(guī)則、質量屬性、建議解決方法和附加信息；4將系統(tǒng)級需求分為若干子系統(tǒng)，并將需求中的一部分分配給軟件組件；4了解相關質量屬性的重要性；4商討實施優(yōu)先級的劃分；4將所收集的用戶需求編寫成規(guī)格說明和模型；4評審需求規(guī)格說明，確保對用戶需求達到共同的理解與認識，并在整個開發(fā)小組接受說明之前將問題都弄清楚。2023年 9月 28日 6時 52分如何進行需求分析 應該了解什么 4To elicit the client’s needs, the members of the requirements team must be familiar with the application domain.(熟悉客戶領域知識）4To build a glossary(術語表） 用正確的術語進行正確的交流4應該先了解宏觀的問題，再了解細節(jié)的問題。 u客戶表達的需求，不同的分析人員可能有不同的理解。以便在進行系統(tǒng)設計時，將軟件的核心建筑在穩(wěn)定的需求上，否則將會吃盡苦頭。如果客戶全不懂軟件，但信任軟件開發(fā)方，這事也好辦。determining what client wants2023年 9月 28日 6時 52分需求分析的重要性4開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。 4Requirements elicitation（ 需求獲取 ）： The process of discovering the client’s requirements.4Requirements analysis(需求分析） ： The process of refining and extending the initial requirements determined.2023年 9月 28日 6時 52分Requirements Definition4Requirements Definition（需求定義）uCustomeroriented descriptions of the system’s functions and constraints on its operation（功能描述與操作約束）uA requirement is a feature of the system or a description of something the system is capable of doing in order to fulfill the system’s purpose.實現2023年 9月 28日 6時 52分Requirements DefinitionIEEEl用戶解決問題或達到目的所需的條件或能力。4OVER2023年 9月 28日 6時 52分 Specification需求分析4不論是為客戶做軟件項目還是為自己做軟件產品，都要進行需求分析。博士到了軟件公司有什么用呢？我想不出有什么用，只知道他們挺值得可憐的：從碩士讀到博士出頭，這六七年時間，真本事沒學多少，倒學會 “ 眼高手低 ”甚至 “ 弄虛作假 ” ；2023年 9月 28日 6時 52分推薦行動方針4可行性分析的關鍵是提出是否繼續(xù)進行這項開發(fā)工程。 舉重若輕 的那類 “ 人才 ” 可以做領導， 舉輕若重 的那類人才適合做軟件開發(fā)人員。2023年 9月 28日 6時 52分人有句名言： “ 人分四類 —— 人物，人才，人手，人渣。4政策對軟件公司的生存與發(fā)展影響非常大。國內第一批賣計算機的、做系統(tǒng)集成的公司發(fā)了財，別人眼紅了也擠進來，這個行業(yè)的平均利潤也就下降了。 4技術可行性分析可以簡單地表述為： 做得了嗎？做得好嗎？做得快嗎？ 2023年 9月 28日 6時 52分社會環(huán)境 4社會環(huán)境的可行性至少包括兩種因素：市場與政策。 4（ 3） 軟件的生產率如何？ 如果生產率低下，能賺到的錢就少，并且會逐漸喪失競爭力。如果在項目開發(fā)過程中遇到難以克服的技術問題，麻煩就大了。2023年 9月 28日 6時 52分2023年 9月 28日 6時 52分 投資回收期4所謂投資回收期就是使累計的經濟效益等于最初投資所需要的時間。反之，如果 n年后能收入 F元線，那么這些錢的現在價值是 :P=F/（ 1+i） nl修改一個已有庫存清單系統(tǒng)，使它能在每天送給采購員一份定貨報表。 可以根據自己的歷史數據或行業(yè)模型決定所需的資源并落實到項目計劃。4DOC D是項目持續(xù)時間 (以月計 ) ＝ 有的公司某些費用并沒有計入項目成本中，而是按管理費用等分攤。等式中的常數和信息域值的加權因子是根據經驗確定的。u 出版社： 清華大學出版社2023年 9月 28日 6時 52分功能點分析法4功能點分析法 (FPA： function point analysis)是在需求分析階段基于系統(tǒng)功能的一種規(guī)模估算方法，是基于應用軟件的外部、內部特性以及軟件性能的一種間接的規(guī)模測量。 2023年 9月 28日 6時 52分參考書籍4軟件成本估算： COCOMO II模型方法u出版社?。?機械工業(yè)出版社 4最常用的辦法是按開發(fā)階段劃分任務。每一個不同的查詢都要計算。u用戶輸出數 ： 計算每個用戶輸出，它們向用戶提供面向應用的信息。uuu4開發(fā)策略2023年 9月 28日 6時 52分 系統(tǒng)規(guī)模4 代碼行技術 面向規(guī)模的估計（代碼行 KLOC）u （ 13）如果公司的風水不好，會有很多莫名其妙的管理費。 （ 10）公司人員培訓費用。 （ 7）軟件開發(fā)人員與行政人員的工資。 （ 3）計算機、打印機、網絡等硬件設備。2023年 9月 28日 6時 52分4經濟 u經濟可行性分析主要包括： “ 成本 —— 收益 ” 分析和 “ 短期 —— 長遠利益 ” 分析。u分析員應該從他建議的系統(tǒng)邏輯模型出發(fā)，導出若干個較高層次的（較抽象的）物理解法供比較和選擇。2023年 9月 28日 6時 52分u分析員應該和用戶一起再次復查 問題定義、工程規(guī)模和目標 ，這次復查應該把數據流圖和數據字典作為討論的基礎。千萬不要花費太多時間去了解和描繪現有系統(tǒng)的實現細節(jié)，例如，除非是為了闡明一個特別關鍵的算法，否則不需要根據程序代碼畫出程序流程圖。 研究現行系統(tǒng)（人工 /舊軟件 )，描繪系統(tǒng)流程圖，審核。資源有效性資源有效性167。經濟實力經濟實力167。必須分析幾種主要的可能解法的利弊，從而判斷原定的系統(tǒng)目標和規(guī)模是否現實，系統(tǒng)完成后所能帶來的效益是否大到值得投資開發(fā)這個系統(tǒng)的程度。2023年 9月 28日 6時 52分二、可行性研究4這個階段要回答的關鍵問題是： “ 對于上一個階段所確定的問題有可行的解決辦法或值得做嗎？ 可行性研究比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。u任何管理者如果忘記了軟件工程是 人的智力密集 的勞動，他就永遠不可能在項目管理上得到成功；u任何管理者如果在項目開發(fā)早期沒有支持有效的用戶通信，他有可能為 錯誤的問題 建造一個不錯的解決方案。這就使基于過程的設計 不易被理解 ；且 功能 變化往往引起結構變化較大， 穩(wěn)定性不好 。成本 /效益分析推薦的系統(tǒng)結構；2023年 9月 28日 6時 52分結構分析設計過程階段 關鍵問題 結束標準總體設計 概括地說，應該如何解決這個問題？可能的解法：王少華武漢大學國際軟件學院空間信息與數字工程研究中心工程立項、可行性分析工程立項、可行性分析與需求獲取與需求獲取2023/5/4結構化分析設計過程階段 關鍵問題 結束標準問題定義 問題是什么？ 關于規(guī)模和目標的報告書可行性研究有可行的解嗎？ 系統(tǒng)的高層邏輯模型數據流圖成本 /效益分析需求分析 系統(tǒng)必須做什么？系統(tǒng)的邏輯模型數據流圖數據字典算法描述4系統(tǒng)有明確的邊界定義，且系統(tǒng)結構依賴于系統(tǒng)邊界的定義，這樣的系統(tǒng) 不易擴充和修改 。u最后，對 過程 不在意的管理者可能冒把有效的技術方法和工具插入到真空中的風險。4做還是不做？4聯想集團領導人柳傳志 曾說： “ 沒錢賺的事我們不干；有錢賺但投不起錢的事不干；有錢賺也投得起錢但沒有可靠的人選，這樣的事也不干。4一般說來，可行性研究的成本只是預期的工程總成本的 5%10%。經濟效益經濟效益社會可行性社會可行性167。開發(fā)風險開發(fā)風險操作可行性操作可行性167。u現有的系統(tǒng)必然有某些缺點，新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。2023年 9月 28日 6時 52分 .優(yōu)秀的設計過程通常總是從現有的物理系統(tǒng)出發(fā)，導出現有系統(tǒng)的 邏輯模型 ，再參考現有系統(tǒng)的邏輯模型，設想目標系統(tǒng)的邏輯模型，最后根據目標系統(tǒng)的邏輯模型建造新的物理系統(tǒng)，并進行可行性評價（ 4方面）u分析員能夠使用 數據流圖 描繪數據在系統(tǒng)中流動和處理的情況，從中概括地表達出他對新系統(tǒng)的設想。4可行性研究的前四個步驟實質上構成一個循環(huán)。u其次可以考慮操作方面的可行性。 4成本 收益分析最容易理解，如果成