需求分析與解決方案設計

主講：吳明元2008.09需求分析和解決方案設計1/33第1章軟件需求基礎知識為何要需求分析

需求分析具有決策性、方向性、策略性作用，他在軟件開發(fā)過程中具有舉足輕重地位。因此，對需求分析應足夠重視，在一種大型軟件系統(tǒng)開發(fā)中，他作用要遠遠大于程序設計。22/33項目涉眾客戶:為達成其公司業(yè)務目標而投資項目或購買產品。顧客：直接或間接與產品打交道，是客戶一部分。需求分析員：負責編寫需求并傳達給開發(fā)團體。開發(fā)人員：設計、實現和維護產品。測試人員：確定產品行為是否與估計相一致。文檔編制人員：負責編寫顧客手冊、培訓資料和系統(tǒng)幫助。項目經理：制定項目計劃并率領開發(fā)人員取得成功。法律人員：確保產品符合所有有關法規(guī)。生產人員：制造包括該軟件產品。市場營銷:技術支持及其他與產品和客戶打交道人員。本章將幫助您：理解軟件需求工程某些主要術語。辨別需求開發(fā)與需求管理。保持對潛在與需求有關問題警覺性。理解完善需求應當具有特性。軟件或系統(tǒng)項目涉眾(stakeholder，產品或項目有關人員)利益之間互相作用在需求過程中體現得最為強烈。項目涉眾包括：33/331.1軟件需求定義

軟件行業(yè)存在這樣一種問題，用于描述需求工作術語沒有統(tǒng)一定義。對同一項需求，不一樣人會有不一樣描述，稱其為顧客需求、軟件需求、功能需求、系統(tǒng)需求、技術需求、業(yè)務需求或產品需求?？蛻魧π枨蠖x，在開發(fā)人員看來也許只是高級別產品概念；而開發(fā)人員需求概念對顧客來說也許就是詳細顧客界面設計。需求必須被統(tǒng)計成文檔，這一點很主要。44/331.1.1對需求不一樣解釋

IEEE軟件工程標準術語表將需求定義為:顧客為處理某個問題或達成某個目標而需具有條件或能力。系統(tǒng)或系統(tǒng)組件為符合協(xié)議、標準、規(guī)范或其他正式文檔而必須滿足條件或必須具有能力。上述第一項或第二項中定義條件和能力文檔體現。

注意:

不要一廂情愿地以為項目涉眾對需求理解是一致。應當事先給出定義，才能確保大家談論是同一種問題。

55/33需求分析定義需求分析是指理解顧客需求，就軟件功能與客戶達成一致，為問題包括信息、功能及系統(tǒng)行為建立模型，將顧客需求精確化、完全化、最后形成需求規(guī)格說明一種復雜過程。從廣義上理解：需求分析包括需求獲取、分析、規(guī)格說明、變更、驗證、管理一系列需求工程。狹義上理解：需求分析指需求分析、定義過程。66/331.1.2需求層次軟件需求包括3個不一樣層次——業(yè)務需求、顧客需求和功能需求:除此之外，每個系統(tǒng)尚有多種非功能需求。圖1.1中模型給出了多種需求關系示意圖。業(yè)務需求(Businessrequirement)表達組織或客戶高層次目標。顧客需求(userrequirement)描述是顧客目標，或顧客要求系統(tǒng)必須能完成任務。功能需求(funetionalrequirement)要求開發(fā)人員必須在產品中實現軟件功能，顧客利用這些功能來完成任務，滿足業(yè)務需求。圖1.177/33

1.1.3不屬于需求內容

需求規(guī)格說明中不包括(除已知約束外)設計和實現細節(jié)、項目標計劃信息，以及測試信息。項目中一般還包括其他類型需求，如開發(fā)環(huán)境需求，進度或預算限制，幫助新顧客跟上進度培訓需求，或者公布產品使其轉入支持環(huán)境需求。這些都屬于項目需求而不是產品需求。88/331.2需求開發(fā)與管理需求領域術語問題，有作者稱其為需求工程；也有人稱之為需求管理。把軟件需求工程劃分為需求開發(fā)和需求管理，如圖1.2所示。圖1.2軟件需求工程組成99/331.2.1需求開發(fā)需求開發(fā)可進一步細分為獲取(Elicitation)、分析(analysis)、規(guī)格說明(specification)和確認(Validation)。這些子學科涵蓋了為軟件和軟件相關產品收集、評估和記錄需求相關所有活動，包括：確定產品將要面向各類用戶。從各類用戶代表處收集需求。了解用戶任務和目標，以及這些任務要實現業(yè)務目標。分析從用戶處得到信息，將用戶任務目標與功能需求、非功能需求、業(yè)務規(guī)則、解決方案建議及其他無關信息區(qū)分開來。將頂層需求分配到系統(tǒng)構架內定義好軟件組件中。了解各質量屬性相對重要性。協(xié)商需求實現優(yōu)先級。將收集用戶需求表述為書面需求規(guī)格說明和模型。審閱需求文檔，以確保在認識上與用戶聲明需求相一致。應在開發(fā)小組接受需求之前解決所有分岐。1010/331.2.2需求管理需求管理任務是“與客戶就軟件項目標需求達成并保持一致”

。需求管理包括下列活動：定義需求基線(某一時刻，對特定版本中已達成一致需求內容描述)。審查需求變更祈求，評定其也許產生影響以決定是否同意。以可控方式將同意需求變更融入項目中。保持項目計劃與需求同步。估計需求變更影響，在此基礎上協(xié)商新需求商定。跟蹤每項需求，找到與其對應設計、源代碼和測試用例(testcase)。在項目開發(fā)過程中，始終跟蹤需求狀態(tài)和變更。1111/331.2.2需求管理圖1.3從另一種角度反應了需求開發(fā)與需求管理間區(qū)分。1212/33本次課結束思考題1.什么是需求分析？2.軟件需求參與人員有哪些？3.為何要需求分析？1313/331.3所有項目都有需求需求在軟件項目中主要地位：軟件系統(tǒng)開發(fā)過程中最難部分是對要開發(fā)什么作出精確判斷。所有概念性工作中最難是建立詳細技術需求，包括所有與顧客、機器和其他軟件系統(tǒng)接口。在開始開發(fā)軟件之前，往往無法確定所有需求。這種情況下，能夠采取迭代和增量辦法，每次實現一部分需求，得到顧客反饋后再進入下一循環(huán)。1414/33

1.4優(yōu)秀團體遇到糟糕

需求需求問題造成主要后果是返工——反復做您以為早已做好事情。返工成本占了總開發(fā)成本30%～50%，而對于返工情況，70%～80%是因需求錯誤引發(fā)。從圖1.4能夠看出，在項目末期才發(fā)覺缺陷，對其進行改正成本要比在缺陷剛產生很快時修改成本高得多。圖1.41515/331.4.1顧客參與不足開發(fā)人員往往也不重視顧客參與，原因是他們以為與顧客打交道不像寫代碼那么有趣，或者自以為已經懂得了顧客想要什么。顧客參與不足將造成不能在項目早期及時發(fā)覺需求中缺陷，從而延誤項目標完成。在整個項目開發(fā)過程中，開發(fā)團體必須始終與實際顧客直接合作，這種合作非常必要并且不可替代。1616/331.4.2顧客需求擴展由于開發(fā)過程中需求不停發(fā)展與增加，項目往往會落后于計劃進度并超出預算。出現這種情況是由于沒有根據對需求規(guī)模和復雜度實際評定來制定計劃，而不停修改需求又使情況變得更糟。問題責任部分在于顧客不停提出修改需求要求，部分在于開發(fā)人員處理這種要求方式。要控制項目范圍變化：首先應明確項目標業(yè)務目標、全局規(guī)劃、范圍、限制、成功標準以及產品估計用途。然后參照這一框架對所有新特性和需求變更進行評定。1717/331.4.3有岐義需求岐義體現為同一讀者能夠對一項需求申明作出多種解釋，或者不一樣讀者對同一需求產生不一樣理解。岐義會造成下列幾點：涉眾對產品懷有不一樣盼望。因此最后交付產品會讓部分人感到意外。有岐義需求使開發(fā)人員時間揮霍在處理無需處理問題上。有岐義需求造成測試人員與開發(fā)人員對產品功能理解不一樣，從而使測試人員也要揮霍時間來處理這些差異。消除歧義措施之一是讓代表不一樣觀點人對需求作正式檢查。1818/331.4.4鍍金問題開發(fā)人員為產品添加了一項需求說明中沒有提到功能，他以為“顧客肯定會喜歡”。這就是所謂“鍍金問題(goldplating)”。開發(fā)人員和需求分析員不應私自添加特性，應當把創(chuàng)意和備選方案提交給客戶，讓他們做決定。要避免鍍金問題，就應當追溯每項功能起源，弄清楚為何添加該功能。1919/331.4.5過于抽象需求營銷人員或經理經常喜歡只給出一種粗略說明，他們希望開發(fā)人員在開發(fā)過程中充實它。這種方式對研究性項目或需求尤其靈活項目或許管用，不過需要緊密合作團體，并且僅限于開發(fā)小型系統(tǒng)。大多數情況下，這種做法成果是使開發(fā)人員受挫，讓客戶失望。2020/331.4.6忽視了某類顧客顧客所使用產品特性、產品使用頻率以及顧客本身經驗水平不盡相同。因此，多數產品都擁有不一樣顧客群。假如一開始沒能找出產品所有主要顧客群，就會有某些顧客需求得不到滿足。確定所有顧客群后，還要確保取得各類顧客需求。2121/331.4.7不精確計劃不能充足理解需求，就會作出過于樂觀估計，最后不可避免地陷入超支泥潭。造成軟件成本估算失敗最主要原因包括頻繁變更需求、遺漏需求、未與顧客充足溝通、需求說明不精確，以及對需求分析不透徹等。2222/331.5優(yōu)質需求過程好處實現有效需求工程過程能夠讓組織受益匪淺。減少開發(fā)后期以及整個維護過程中無須要返工，可帶來極大回報。下面列出好處并不能完全量化，但確實存在：減少需求缺陷減少開發(fā)過程中返工減少無須要特性減少改善成本 加快開發(fā)進度提升溝通效率控制需求范圍變化項目更有序對系統(tǒng)測試評定更精確提升客戶和開發(fā)人員滿意度2323/331.6優(yōu)秀需求特點如何才能將好需求規(guī)格說明與那些有問題辨別開來？這一節(jié)首先對說明中單條需求(即需求陳說)特點進行討論，然后將介紹SRS（需求規(guī)格說明）作為整體應具有特點。假如想懂得您需求是否具有這些特點，最佳措施就是請幾位項目有關人員認真審閱您SRS。不一樣人會發(fā)覺不一樣問題。例如，需求分析人員和開發(fā)人員無法精確判斷完備性和正確性，而顧客則無法評價技術可行性。2424/331.6.1需求陳說特點每一項顧客需求、業(yè)務需求和功能需求都應具有下列性質。完整性每一項需求都必須完整地描述即將交付使用功能。正確性每一項需求都必須精確地描述將要開發(fā)功能?？尚行孕枨蟊仨毮軌蛟谙到y(tǒng)及其運行環(huán)境已知能力和約束條件內實現。必要性每一項需求統(tǒng)計功能都必須是顧客真正需要，或者是為符合外部系統(tǒng)需求或某一標準而必須具有功能。有優(yōu)先次序為每一項功能需求、特性或用例指定一種實現優(yōu)先級，以表白它在產品某一版本中主要程度。無歧義一項需求申明對所有讀者應當只有一種一致解釋，然而自然語言卻極易產生歧義?？沈炞C性看看您能否設計某些測試辦法或使用其他驗證辦法，如檢查或演示來判斷產品是否正確實現了需求。2525/331.6.2需求規(guī)格說明特點需求規(guī)格說明中所包括整體需求集還必須具有下列特性。完整性不能遺漏任何需求或必要信息。需求遺漏問題很難被發(fā)覺，由于它們并沒有列出來。一致性需求一致性是指需求不會與同一類型其他需求或更高層次業(yè)務、系統(tǒng)或顧客需求發(fā)生沖突。必須在開發(fā)前處理需求不一致問題。可修改性必須能夠對SRS作必要修訂，并能夠為每項需求維護修改歷史統(tǒng)計?？筛櫺孕枨蠹偃缡强筛櫍湍苷业剿鹪?、它對應設計單元、實現它源代碼以及用于驗證其是否被正確實現測試用例。2626/331.7需求分析任務、過程和辦法1.7.1需求分析任務簡言之,需求分析任務就是處理“做什么”問題,就是要全面地理解顧客各項要求,并精確地體現所接收顧客需求。包括下列幾個方面：確定對系統(tǒng)綜合要求分析系統(tǒng)數據要求導出系統(tǒng)邏輯模型修正系統(tǒng)開發(fā)計劃2727/331.7.2需求分析過程需求分析階段工作可深入分為：問題識別、分析與綜合、編寫規(guī)格說明和評審四個階段。(這些子項包括軟件類產品中需求搜集、評價、編寫文檔等所有活動。)問題識別就是從系統(tǒng)角度來理解軟件,確定對所開發(fā)系統(tǒng)綜合要求,并提出這些需求實現條件,以及需求應當達成標準.這些需求包括：功能需求(做什么),性能需求(要達成什么指標),環(huán)境需求(如機型,操作系統(tǒng)等),可靠性需求(不發(fā)生故障概率）,安全保密需求,顧客界面需求,資源使用需求(軟件運行是所需內存,CPU等),軟件成本消耗與開發(fā)進度需求,預先估計后來系統(tǒng)也許達成目標.分析與綜合逐漸細化所有軟件功能,找出系統(tǒng)各元素間聯系,接口特性和設計上限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最后,綜合成系統(tǒng)處理方案,給出要開發(fā)系統(tǒng)詳細邏輯模型(做什么模型)。制定規(guī)格說明書即編制文檔,描述需求文檔稱為軟件需求規(guī)格說明書.請注意,需求分析階段成果是需求規(guī)格說明書,向下一階段提交。評審對功能正確性，完整性和清楚性，以及其他需求給予評價。評審通過才可進行下一階段工作，不然重新進行需求分析。2828/331.7.3需求分析辦法需求分析辦法有很多.這里只強調原型化辦法，其他辦法如：構造化辦法，動態(tài)分析法等(個人以為,對初學者無須深究這些辦法，事實上很少用)在此不討論。原型化辦法就是盡也許快地建造一種粗糙系統(tǒng),這系統(tǒng)實現了目標系統(tǒng)某些或所有功能，不過這個系統(tǒng)也許在可靠性，界面友好性或其他方面上存在缺陷。建造這樣一種系統(tǒng)目標是為了考查某一方面可行性，如算法可行性，技術可行性，或考查是否滿足顧客需求等。如，為了考查是否滿足顧客要求，能夠用某些軟件工具迅速建造一種原型系統(tǒng)，這個系統(tǒng)只是一種界面，然后聽取顧客意見，改善這個原型。后來目標系統(tǒng)就在原型系統(tǒng)基礎上開發(fā)。2929/331.7.3需求分析辦法原型主要有三種類型:摸索型，試驗型，進化型。摸索型:目標是要弄清楚對目標系統(tǒng)要求,確定所希望特性,并探討多種方案可行性。試驗型:用于大規(guī)模開發(fā)和實現前,考評方案是否合適,規(guī)格說明是否可靠。進化型:目標不在于改善規(guī)格說明,而是將系統(tǒng)建造得易于變化,在改善原型過程中,逐漸將原型進化成最后系統(tǒng)。在使用原型化辦法時有兩種不一樣策略：廢棄策略，追加策略。廢棄策略:先建造