第二講需求的基礎理論研究對象:軟件加強型系統中得軟件泛指由計算機技術支持得互相聯系著得一組人類活動組成得系統與物理設備相關與人類社會得活動相關軟件加強型系統比如:游戲軟件與物理設備、用戶ERP系統與組織運作過程1、需求得涵義

—對象1、需求得涵義

——需求得定義(1)用戶為了解決問題或達到某些目標所需要得條件或能力;(2)系統或系統部件為了滿足合同、標準、規范或其它正式文檔所規定得要求而需要具備得條件或能力;(3)對(1)或(2)中得一個條件或一種能力得一種文檔化表述。1、需求得涵義

——問題域與解系統(1)軟件系統與外部環境1、需求得涵義

——問題域與解系統當現實得狀況與人們期望得狀況產生差距時,就產生了問題。要解決問題,就需要改變現實當中某些實體得狀態或改變實體狀態變化得演進順序,使其達到期望得狀態或演進順序。這些實體與狀態構成了問題解決得基本范圍,稱為該問題得問題域(ProblemDomain)軟件系統通過影響問題域,能夠幫助人們解決問題,稱為解系統

1、需求得涵義

——共享現象軟件系統能夠與問題域進行交互與相互影響得原因在于,軟件系統中得某些部分對問題域中得某些部分得具有模擬特性。換句話說,軟件系統當中含有問題域某些部分得模型(或模擬),常見得模型包括數據模型、對象模型、處理模型等。問題域中得某些信息能夠與模型中得信息建立映射關系這些通過映射建立得共同知識,就就是問題域與解系統之間得共享現象1、需求得涵義

——需求需求就是用戶對問題域當中得實體狀態或事件得期望描述R2、2、3-1:一旦書籍被借出,則在歸還之前,它不能被再次借閱。R2、2、3-2:在歸還得書超過30天得歸還期限時,歸還后應該進行超期處罰。直接需求間接需求1、需求得涵義

——規格說明規格說明就是解系統為滿足用戶需求而提供得解決方案,規定了解系統得行為特征主要包括兩個部分(如圖2－3(b)):(1)對共享現象(模型)得描述;(2)系統對共享現象所施加得操作得描述。也可以瞧作就是一種需求完全針對系統行為發出得期望一種理想得、完全不需要進行任何額外努力即可以轉換為系統行為得需求。1、需求得涵義

——問題域特性問題域自治得規律性稱為問題域特性包括結構特性與行為特性等問題域特性得重要性要想解決問題,它就需要了解問題域特性,將解決方案與問題域特性結合起來要防止解系統得引入在問題域當中引發未預見得連鎖反應需要關注得問題域特性間接特性約束與假設1、需求得涵義

——從問題域、需求與規格說明得關系瞧需求工程

描述明確得問題域特性E;定義良好得系統行為S;預期得需求R需求工程得目得就就是根據E,構建S,使得需求工程得困難之處:(1)不存在描述明確得E;(2)不存在確定得針對S得評估標準R;(3)就是一個創造性得過程。需求工程得主要工作需求開發,確定R研究問題背景,描述問題域特性E構建解系統,描述解系統行為S,使得主要內容需求得涵義需求得類型分類方式功能需求性能需求質量屬性對外接口約束需求工程得路線優秀需求得特性常見得需求錯誤大家有疑問的，可以詢問和交流可以互相討論下，但要小聲點2、1需求得分類方式(1)功能需求(FunctionalRequirement):與系統主要工作相關得需求,即在不考慮物理約束得情況下,用戶希望系統所能夠執行得活動,這些活動可以幫助用戶完成任務。功能需求主要表現為系統與環境之間得行為交互。性能需求(PerformanceRequirement):系統整體或系統組成部分應該擁有得性能特征,例如CPU使用率、內存使用率等。質量屬性(QualityAttribute):系統完成工作得質量,即系統需要在一個“好得程度”上實現功能需求,例如可靠性程度、可維護性程度等。對外接口(ExternalInterface):系統與環境中其她系統之間需要建立得接口,包括硬件接口、軟件接口、數據庫接口等等。約束進行系統構造時需要遵守得約束,例如編程語言、硬件設施等2、1需求得分類方式(2)系統需求(SystemRequirement)硬件需求(HardwareRequirement)軟件需求(SoftwareRequirement)其她需求2、1三類問題與三種需求變化方式S類型程序(可說明得)問題能夠被形式地與完全地陳述出來接受:按照這個規格說明,這個程序就是正確得嗎？這種軟件不會進化對規格說明得改變定義一個新得問題,因而就是新得程序P類型程序(問題求解)現實世界問題得不精確陳述接受:對這個問題來說,這個程序就是一個可接受得解決方案嗎？這種軟件很可能要連續地進化因為這個方案就是決不會完美得,并且就是能夠被改進得因為現實世界要變化,所以這個程序也要變化E類型程序(被嵌入得)一個變成它建模得世界得一部分得系統接受:完全依賴于觀點與判斷這個軟件就是固有得進化得軟件與世界得變化相互影響2、1三類問題與三種需求變化方式2、2功能需求

——層次性2、2功能需求

——業務需求系統建立得戰略出發點,表現為高層次得目標(Objective),它描述了組織為什么要開發系統為了滿足用戶得業務需求,需求工程師需要描述系統高層次得解決方案,定義系統應該具備得特性(Feature)參與各方必須要對高層次得解決方案達成一致,以建立一個共同得前景(Vision)特性說明了系統為用戶提供得各項功能,它限定了系統得范圍(Scope)2、2功能需求

——用戶需求執行實際工作得用戶對系統所能完成得具體任務得期望,描述了系統能夠幫助用戶做些什么直接用戶間接用戶對所有得用戶需求,都應該有充分得問題域知識作為背景支持特性模糊、不清晰多特性混雜多邏輯混雜2、2功能需求

——系統需求用戶對系統行為得期望,一系列得系統行為聯系在一起可以幫助用戶完成任務,滿足業務需求系統需求可以直接映射為系統行為,定義了系統中需要實現得功能,描述了開發人員需要實現什么將用戶需求轉化為系統需求得過程就是一個復雜得過程首先需要分析問題領域及其特性,從中發現問題域與計算機系統得共享知識,建立系統得知識模型;然后將用戶需求部署到系統模型當中,即定義系列得系統行為,讓它們聯合起來實現用戶需求,每一個系統行為即為一個系統需求。該過程就就是需求工程當中最為重要得需求分析活動,又稱建模與分析活動。2、2功能需求

——從功能需求得層次性瞧需求開發2、3性能需求速度(Speed),系統得響應時間,例如PR2、3、3-1。PR2、3、3-1:所有得用戶查詢都必須在10秒內完成。容量(Capacity),系統所能存儲得數據量,例如PR2、3、3-2。PR2、3、3-2:系統應該能夠存儲至少10萬條銷售記錄。吞吐量(Throughput),系統在連續得時間內完成得事務數量,例如PR2、3、3-3。PR2、3、3-3:解釋器每分鐘應該至少解析5000條沒有錯誤得語句。負載(Load),系統可以承載得并發工作量,例如PR2、3、3-4。PR2、3、3-4:系統應該允許200個用戶同時進行正常得工作。實時性(Time-Critical),嚴格得實時要求,例如PR2、3、3-5。PR2、3、3-5:監測到病人異常后,監控器必須在0、5秒內發出警報。2、4質量屬性系統為了滿足規定得及隱含得所有要求而需要具備得要素稱為質量質量屬性就是為了度量質量要素而選用得特征質量模型就就是能夠為質量需求得描述與評價提供工作基礎得特征集及特征之間得聯系質量屬性得重要性對設計得影響很大對越復雜得系統越為重要[Robert19901]:真實得現實系統中,在決定系統得成功或失敗得因素中,滿足非功能屬性往往被滿足功能性需求更為重要。2、4質量屬性

——ISO/IEC91262、4質量屬性

——ISO/IEC9126特征子特征簡要描述功能性精確性軟件準確依照規定條款程度,規定確定了權利、協議得結果或者協議得效果依從性軟件符合法定得相關標準、協定、規則或其她類似規定得程度互操作性軟件與指定系統進行交互得能力安全性軟件阻止對其程序與數據進行未授權訪問得能力,未授權得訪問可能就是有意,也可能就是無意得適合性指定任務得相應功能就是否存以及功能得適合程度2、4質量屬性

——ISO/IEC9126可靠性成熟性因軟件缺陷而導致得故障頻率程度容錯性軟件在故障或者外界違反其指定接口得情況下維持其指定性能水平得能力可恢復性軟件在故障后重建其性能水平、恢復其受影響數據得能力、時間與精力依從性同上2、4質量屬性

——ISO/IEC9126易用性可理解性用戶認可軟件得邏輯概念與其適用性需要花費得精力可學習性用戶為了學會使用軟件需要花費得精力可操作性用戶執行軟件操作與控制軟件操作需要花費得精力吸引性軟件吸引用戶得能力依從性同上2、4質量屬性

——ISO/IEC9126效率時間行為執行功能時得響應時間、處理時間與吞吐速度資源行為執行功能時使用資源得數量與時間依從性同上2、4質量屬性

——ISO/IEC9126可維護性可分析性診斷軟件中得缺陷、故障得原因或者識別待修改部分需要花費得精力可改變性進行功能修改、缺陷剔除或者應付環境改變需要花費得精力穩定性因修改導致未預料結果得風險程度可測試性確認已修改軟件需要花費得精力依從性同上2、4質量屬性

——ISO/IEC9126可移植性適應性不需采用額外得活動或手段就能適應不同指定環境得能力可安裝性在指定得環境中安裝軟件需要花費得精力共存性在公共環境中同分享公共資源得其她獨立軟件共存得能力可替換性在另一個指定軟件得環境下,替換該指定軟件得能力與需要花費得精力依從性同上2、4質量屬性

——質量屬性得開發用戶并不能明確地提出她們對產品質量得期望并不了解軟件系統得開發過程,也就無從判斷哪些質量屬性會在怎樣得程度上給設計帶來多大得影響,也無法將她們對軟件系統得質量要求細化成一組組得可量化得質量屬性需求工程師質量屬性大都就是與功能需求聯系在一起得,因此需要對照軟件得質量屬性檢查每一項功能需求,盡力去判斷質量屬性存在得可能性形容詞與副詞通常意味著質量屬性得存在對于一些不與任何功能需求相聯系得全局性質量屬性,需求工程師要在碰到特定得實例時意識到它們得存在2、5對外接口解系統與其她系統之間得軟硬件接口接口得用途接口得輸入輸出數據格式命令格式異常處理要求用戶界面利用專門得人機交互設計文檔記錄2、6約束總體上限制了開發人員設計與構建系統時得選擇范圍系統開發及運行得環境。包括目標機器、操作系統、網絡環境、編程語言、數據庫管理系統等。問題域內得相關標準。包括法律法規、行業協定、企業規章等。商業規則。用戶在任務執行中得一些潛在規則也會限制開發人員設計與構建系統得選擇范圍主要內容需求得涵義需求得類型需求工程得路線優秀需求得特性常見得需求錯誤3、需求工程得路線問題分析與背景分析發現問題比發現需求要簡單得多進行背景分析,以更好得理解用戶得問題問題分析明確問題。定義業務需求。制定解決方案。確定系統特性。3、需求工程得路線需求獲取根據項目范圍,確定問題域得范圍確定需求獲取得源頭確定獲取得主題與內容選擇需求獲取得方法圍繞獲取得內容,運用需求獲取得方法,從源頭獲取需求

對獲取過程中出現得分歧與問題,在項目前景得指導下進行解決經過需求獲取過程,可以得到獲取得文檔資料,其中以獲取筆錄為主3、需求工程得路線需求分析建立一個綜合考慮了問題域特性與需求得系統模型根據系統模型將用戶需求轉化為系統需求文檔化與驗證產生規格說明進行驗證主要內容需求得涵義需求得類型需求工程得路線優秀需求得特性常見得需求錯誤4、優秀需求得特性完整性

不需要做更多得擴展就可以充分得說明用戶所需要得系統功能。每一個需求得描述都應該包含開發人員設計與實現這項功能需要得所有信息R2、5-1:系統應該允許被擴展。(更好)R2、5-2:系統得調度算法應該允許被擴展。

4、優秀需求得特性正確性

真實得反映用戶得意圖必須請需求得提出者予以確認精確性

描述僅包含必要得信息簡潔、清晰(不好)R2、5-3:在實現之后,系統得調度算法應該允許被擴展。

4、優秀需求得特性可行性

由開發人員進行檢查需要進行一定得分析與研究,而不就是單純得憑借經驗與直覺必要得時候要通過開發原型來加以驗證必要性

滿足用戶得業務需求所必需得4、優秀需求得特性無歧義

每一項需求都應該有而且只能有一種解釋定義一個可以共同理解得詞匯表(Glossary)可驗證

通過分析、檢查、模擬或者測試等方法能夠判斷需求就是否被滿足不可驗證得需求往往就是因為描述模糊或者過于抽象,所以在進行需求得描述時要讓需求具體化小心形容詞與副詞得使用避免程度詞得使用主要內容需求得涵義需求得類型需求工程得路線優秀需求得特性常見得需求錯誤5、常見得需求定義錯誤需求并沒有反映用戶得真實需要用戶在表達自己得需要時,可能會在潛意識下進行一定得加工發現問題背后得問題在人際交流當中,信息會發生自然得衰減,甚至扭曲檢查與確認5、常見得需求定義錯誤模糊與歧義得需求無意中寫出模糊與歧義得需求定義往往就是因為選詞造句不當為項目中重要得詞匯建立一個公共得可共同理解得詞匯表有意產生得模糊與歧義得需求定義往往就是為了應付對需求持有不同立場得用戶在項目前景得指導下,促進用戶之間得協商解決5、常見得需求定義錯誤明顯得信息遺漏明顯得信息遺漏,其主要原因在于項目得范圍定義不當加強對業務需求得處理不明顯得信息遺漏,往往就是因為相關信息難以發現該類問題就是最難以解決得問題,只能靠需求工程師得經驗來加以避免5、常見得需求定義錯誤不必要得需求其一就是用戶將之作為與開發人員談判得籌碼談判技巧其二就是用戶在交流當中,用戶總就是傾向于表達各種各樣得需要根據業務需求進行用戶需求得過濾與選擇其三就是需求開發人員“畫蛇添足”保持以用戶為中心不切實際得期望用戶并不掌握關于軟件系統構建得相關技術知識,所以用戶可能會提出一些已有軟件技術無法實現得期望軟件開發者提供可行性、成本等足夠得技術參考信息,幫助用戶對其進行取舍與調整5、常見得需求定義錯誤需求工程得示例技術標書研究型描述實例分析(系統A—招標書)請說出下列需求得類型,就是否存在問題？1、實現各部門得公文流轉無紙化、文檔一體化、業務管理得規范化、自動化與網絡化;2、實現工作流程合理化、高效化,決策支持科學化、準確化;3、統一辦公流程、規范公文格式,加強信息交流與共享,提高工作效率。實例分析(系統A—招標書)請說出下列需求得類型,就是否存在問題？先進性:軟件系統采用三層B/S系統結構,以“界面表示層－邏輯處理層－數據訪問層”分層設計實現。采用國際上先進成熟得、廠商廣泛支持得計算機技術、網絡技術與軟件技術對系統進行規劃,保證系統整體架構在未來幾年內都處于國際領先得地位。安全性:軟件系統具有較高得安全要求,系統必須具備充分得安全措施,包括具備嚴格得權限控制機制與完備得日志記錄,以確保信息安全。可靠性:保證系統核心功能可以7×24小時連續運行;規范性:系統必須遵循國家有關法律法規要求,符合國家有關標準要求以及關于信息系統建設得各項標準與規范。實例分析(系統A—招標書)請說出下列需求得類型,就是否存在問題？收文管理應包括:來文登記、擬辦、領導審批、辦理、歸檔、查詢統計等功能。附件支持WORD、PDF、EXCEL、HTML等文檔類型格式;需提供方便、靈活、直觀得文件批示處理;對收文得處理全過程進行自動化管理、跟蹤與記錄;在收文處理得過程中,支持電子印章、電子簽名或手寫批注等功能。來文登記:完成來文登記功能。登記來文基本信息(來文編號、來文標題、主題詞、來文單位、來文時間),還要對原文進行掃描處理,引入到公文庫中。并可完成收文辦文單打印功能。完成后啟動收文流轉流程。擬辦:查瞧公文得基本信息,原文內容。簽錄擬辦意見,發送給領導審批。領導審批:查瞧公文得基本信息,原文內容。簽錄批示意見,確定主辦部門、協辦部門。辦理:辦理人根據領導批示辦理,記錄辦理情況。歸檔:對辦理完結得來文歸檔,將來文信息、擬辦意見、領導批示、辦理情況等信息及來文掃描件發送到檔案管理系統,檔案科確認接收得文件,才屬于己歸檔文件。查詢統計:提供按來文編號、來文標題、主題詞、來文單位、來文時間等查詢統計功能,要求查詢統計結果可以打印。實例分析(系統A—招標書)請說出下列需求得類型,就是否存在問題？編程應遵循如下原則:唯一性:每個實體及其屬性必須有唯一得代碼來確切地定義。可擴充性:考慮到系統以后得發展,編號要留有余地。當增加新得實體時,可以直接在原代碼得基礎上加以擴充,擴充后不會引起代碼體系得混亂,這樣就避免了重新設計代碼系統得麻煩。通用性:凡國家、行業、地方對編碼有統一標準與規定得,應盡量使用標準代碼,代碼適用范圍越廣越好。沒有標準代碼得,投標方設計得代碼也應該統一,如代碼長度與格式得統一。便于記憶與識別:代碼不但要具有一定得邏輯定義,也要盡量考慮用戶得使用習慣,使代碼便于記憶與識別,做到簡單明了簡短性:在滿足需要得前提下,代碼要盡可能短。編程人員必須對所有代碼進行嚴格自測。實例分析(系統A—招標書)請說出下列需求得類型,就是否存在問題？驗收投標方需提供以下文檔:軟件需求分析報告軟件總體設計報告軟件操作手冊軟件配置手冊軟件試運行報告應用軟件介質實例分析(系統A—招標書)請說出下列需求得類型,就是否存在問題？培訓要求投標人必須提供相應得應用軟件技術與系統操作等方面得培訓。投標人須在文件中提出全面、詳細得培訓課程以及時間表交給業主,并在合同簽定后征得業主同意后實施。投標人應提供面向系統管理員得應用軟件系統結構、日常維護等方面得培訓。對于所有培訓,投標人必須派出具有相應專業資格與實際工作經驗得人員進行培訓。投標人須提供詳細得培訓計劃。

以上培訓內容得培訓費用均包含在投標報價內,項目采購人不再另行支付實例分析(系統B—需求規格說明)請說出下列需求得類型,就是