需求分析概述

1、需求分析概述一需求獲取及用例使用需求獲?。╮equirement。1也廿0門）是需求工程的主體。對于所建議的軟件產(chǎn)品，獲取需求是 一個確定和理解不同用戶類的需要和限制的過程。獲取用戶需求位于軟件需求三個層次的中 間一層。業(yè)務(wù)需求決定用戶需求，它描述了用戶利用系統(tǒng)需要完成的任務(wù)。從這些任務(wù)中， 分析者能獲得用于描述系統(tǒng)活動的特定的軟件功能需求，這些系統(tǒng)活動有助于用戶執(zhí)行他們 的任務(wù)。需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個必不可少 的結(jié)果是對項目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發(fā)者和客戶就 能探索出描述這些需求的多種解決方案。參與需求獲取者只有在

2、他們理解了問題之后才能開 始設(shè)計系統(tǒng)，否則，對需求定義的任何改進(jìn)，設(shè)計上都必須大量的返工。把需求獲取集中在 用戶任務(wù)上一而不是集中在用戶接口上一有助于防止開發(fā)組由于草率處理設(shè)計問題而造成 的失誤。需求獲取、分析、編寫需求規(guī)格說明和驗證并不遵循線性的順序，這些活動是相互隔開、 增量和反復(fù)的。當(dāng)你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息（需 求獲?。?。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需 求同可能的軟件需求相聯(lián)系（分析）。然后，你可以使客戶信息結(jié)構(gòu)化，并編寫成文檔和示意 圖（說明）。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤（驗證）。這四個

3、過程貫穿 著需求分析的整個階段。需求獲取可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯及最需要 交流的方面。需求獲取只有通過有效的客戶一開發(fā)者的合作才能成功。分析者必須建立一個 對問題進(jìn)行徹底探討的環(huán)境，而這些問題與產(chǎn)品有關(guān)。為了方便清晰地進(jìn)行交流，就要列出 重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需要一種 技術(shù)，利用這種技術(shù)不但考慮了問題的功能需求方面，還可討論項目的非功能需求。確定用 戶已經(jīng)理解：對于某些功能的討論并不意味著即將在產(chǎn)品中實現(xiàn)它。對于想到的需求必須集 中處理并設(shè)定優(yōu)先級，以避免一個不能帶來任何益處的無限大的項目。需求獲取是一個需要高度合作的活動，而并

4、不是客戶所說的需求的簡單譽(yù)本。作為一個 分析者，你必須透過客戶所提出的表面需求理解他們的真正需求。詢問一個可擴(kuò)充 （open-ended）的問題有助于你更好地理解用戶目前的業(yè)務(wù)過程并且知道新系統(tǒng)如何幫助或 改進(jìn)他們的工作。調(diào)查用戶任務(wù)可能遇到的變更，或者用戶需要使用系統(tǒng)其它可能的方式。 想像你自己在學(xué)習(xí)用戶的工作，你需要完成什么任務(wù)?你有什么問題?從這一角度來指導(dǎo)需求 的開發(fā)和利用。還有，探討例外的情況：什么會妨礙用戶順利完成任務(wù)?對系統(tǒng)錯誤情況的反映，用戶 是如何想的?詢問問題時，以“還有什么能”，”當(dāng)？時，將會發(fā)生什么”“你有沒有曾經(jīng)想 過”，“有沒有人曾經(jīng)”為開頭。記下每一個需求的來源，

5、這樣向下跟蹤直到發(fā)現(xiàn)特定的客 戶。有些時候，嘗試著問一些“愚蠢”的問題也有助于客戶打開話匣子。如果你直接要求客 戶寫出業(yè)務(wù)是如何實現(xiàn)的，客戶十有八九無法完成。但是如果你嘗試著問一些實際的問題， 例如：“以我的理解，你們收到訂單后，會.”?？蛻袅⒖叹蜁赋瞿愕腻e誤，并滔滔不絕的開始談?wù)摌I(yè)務(wù)，而你，就在一邊仔細(xì)的聆聽吧。這一招就叫做“拋磚引玉”。需求討論會上必須要使用筆記本電腦，還要指定一個打字熟練的人把所有的討論記錄下 來，記錄的同時還要做一定的整理。如果不這樣做，那么你結(jié)束會議的時候就會發(fā)現(xiàn)，所有 的討論只剩下一個模糊的印象，需求對你來說仍然是一件遙遠(yuǎn)的事情。在座談討論之后，記 下所討論的條目

6、(item)，并請參與討論的用戶評論并更正。及早并經(jīng)常進(jìn)行座談討論是需求 獲取成功的一個關(guān)鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進(jìn)行深入收 集和分析以消除任何沖突或不一致性。盡量把客戶所持的假設(shè)解釋清楚，特別是那些發(fā)生沖突的部分。從字里行間去理解以明確客 戶沒有表達(dá)清楚但又想加入的特性或特征。Gause和Weinberg(1989)提出使用“上下文無關(guān) 問題”一這是一個高層次的問題，它可以獲取業(yè)務(wù)問題和可能的解決方案的全部信息?？蛻?對這些問題的回答諸如“產(chǎn)品要求怎樣的精確度”或“你能幫我解釋一下你為什么不同意某 人的回答嗎? ”這些回答可以更直接地認(rèn)識問題，而這是封閉(clo

7、se-end)問題所不能做到的。需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟件解決方案中合理 的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發(fā)者和客戶之間采用了更 多的交流方式(Kiel and Carmel 1995)。與單個客戶或潛在的用戶組一起座談，對于業(yè)務(wù)軟件 包或信息管理系統(tǒng)(MIS)的應(yīng)用來說是一種傳統(tǒng)的需求來源。直接聘請用戶進(jìn)行獲取需求的 過程是為項目獲得支持和買入(buy-in)的一種方式。盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執(zhí)行任務(wù)時作出決策的過程， 并提取出潛在的邏輯關(guān)系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。在需求獲取的

8、過程中，你可能會發(fā)現(xiàn)對項目范圍的定義存在誤差，不是太大就是太小。 如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業(yè)務(wù)和客戶的值，此時獲 取過程將會拖延。如果項目范圍太小，那么客戶將會提出很重要的但又在當(dāng)前產(chǎn)品范圍之外 的需求。當(dāng)前的范圍太小，以致不能提供一個令人滿意的產(chǎn)品。需求的獲取將導(dǎo)致修改項目 的范圍和任務(wù)，但作出這樣具有深遠(yuǎn)影響的改變，一定要小心謹(jǐn)慎。正如經(jīng)常所說的，需求主要是關(guān)于系統(tǒng)做什么，而解決方案如何實現(xiàn)是屬于設(shè)計的范圍。 這樣說雖然很簡潔，但似乎過于簡單化。需求的獲取應(yīng)該把重點放在“做什么”上，但在分 析和設(shè)計之間還是存在一定的距離。你可以使用假設(shè)“怎么做”來分類并改

9、善你對用戶需求 的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達(dá)得更加清楚，然 后提供一個尋找錯誤和遺漏的辦法。把你在需求開發(fā)階段所形成的模型和屏幕效果看成是方 便高效交流的概念性建議，而不應(yīng)該看成是對設(shè)計者選擇的一種限制。需求獲取討論會中如果參與者過多，就會減慢進(jìn)度。人數(shù)大致控制在5到7人是最好的。 這些人包括客戶、系統(tǒng)設(shè)計者、開發(fā)者和可視化設(shè)計者等主要工程角色。相反地，從極少的 代表那里收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將 導(dǎo)致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數(shù)用戶的需要。最好的權(quán)衡 在于選擇一些授權(quán)為他們的用戶類發(fā)

10、言的產(chǎn)品代表者，他們也被同組用戶類的其它代表所支 持。沒有一個簡單、清楚的信號暗示你什么時候已完成需求獲取。當(dāng)客戶和開發(fā)者與他們的 同事聊天、閱讀工業(yè)和商業(yè)上的文獻(xiàn)及在早上沐浴時思考時，他們都將對潛在產(chǎn)品產(chǎn)生新的 構(gòu)思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按 其重要性的順序來確定使用實例的。如果用戶提出新的使用實例，但你可以從其它使用實例的相關(guān)功能需求中獲得這些 新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的 其它使用實例的可選過程。如果用戶開始重復(fù)原先

11、討論過的問題，此時，也許你就完成了收集需求的工作。如果所提出的新需求比你已確定的需求的優(yōu)先級都低時，也許你就完成了收集需求 的工作。如果用戶提出對將來產(chǎn)品的要求，而不是現(xiàn)在我們討論的特定產(chǎn)品，也許你就完成 了收集需求的工作。以上知識大致上討論需求分析應(yīng)該如何做，實際上對于需求分析的方法有很多很多，已經(jīng) 形成了一定的理論，當(dāng)然這種理論比較偏向與方法學(xué)，而方法學(xué)的應(yīng)用主要還是要靠個人。 所以，大家在實際應(yīng)用的時候，不妨結(jié)合自己的實際，有選擇性的采用一些方法，那你就是 成功的。多年來，分析者總是利用情節(jié)或經(jīng)歷來描述用戶和軟件系統(tǒng)的交互方式，從而獲取需求 (McGraw and Harbison 19

12、97)。Ivar Jacobson(1992)把這種看法系統(tǒng)地闡述成用例(用例)的方法 進(jìn)行需求獲取和建模。雖然用例來源于面向?qū)ο蟮拈_發(fā)環(huán)境，但是它也能應(yīng)用在具有許多開 發(fā)方法的項目中，因為用戶并不關(guān)心你是怎樣開發(fā)你的軟件。而最重要的，用例的觀點和思 維過程帶給需求開發(fā)的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統(tǒng)做 什么遠(yuǎn)遠(yuǎn)強(qiáng)于詢問用戶希望系統(tǒng)為他們做什么這一傳統(tǒng)方法。用例的重要功能是用畫用例圖的功能來鑒別和劃分系統(tǒng)功能。它把系統(tǒng)分成角色(actor) 和用例(用例)。角色(actor)表示系統(tǒng)用戶能扮演的角色(role)。這些用戶可能是人，可能是其 他的計算機(jī)一些硬件或者甚至

13、是其它軟件系統(tǒng)，唯一的標(biāo)準(zhǔn)是它們必須要在被劃分進(jìn)用例的 系統(tǒng)部分以外。它們必須能刺激系統(tǒng)部分并接收返回。用例描述了當(dāng)角色給系統(tǒng)特定的刺激 時系統(tǒng)的活動。這些活動被文本描述。它描述了觸發(fā)用例的刺激的本質(zhì)，輸入和輸出到其他 活動者，和轉(zhuǎn)換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能 的錯誤和系統(tǒng)應(yīng)采取的補(bǔ)救措施。這樣說可能會非常復(fù)雜，其實一個用例描述了系統(tǒng)和一個角色(actor)的交互順序。用例 被定義成系統(tǒng)執(zhí)行的一系列動作，動作執(zhí)行的結(jié)果能被指定角色察覺到。用例可以用例捕獲某些用戶可見的需求，實現(xiàn)一個具體的用戶目標(biāo)。用例由角色激活，并提供確切的值給角色。用例可大可小，但它必

14、須是對一個具體的用戶目標(biāo)實現(xiàn)的完整描述。在UML中，用例 表示為一個橢圓。角色是指用戶在系統(tǒng)中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可 能有許多角色實例(例如有很多個銷售員)，但就該系統(tǒng)而言，他們均起著同一種作用，扮演 著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級營銷 人員既可以是貿(mào)易經(jīng)理，也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理 角色時，應(yīng)考慮其作用，而不是人或工作名稱，這一點是很重要的。我們使用不帶箭頭的線段將角色與用例連接到一起，表示兩者之間交換信息，稱之為通 信聯(lián)系。角色觸發(fā)用例，并與用例進(jìn)行信息交換。單個角色可與多個用例聯(lián)系;反過來，一 個用例可與多個角色聯(lián)系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例 中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡 管執(zhí)行的，但角色未必是人。例如，角色也可以是一個外界系統(tǒng)，該外界系統(tǒng)可能需要從當(dāng) 前系統(tǒng)中獲取信息，與當(dāng)前系統(tǒng)有進(jìn)行交互。一個用例可能包括完成某項任務(wù)的許多邏輯相關(guān)任務(wù)和交互順序。因此，一個用例是相 關(guān)的用法說明的集合，并且一個說明(scenario)是用例的實例。這種關(guān)系就像是類和對象的關(guān) 系。在用例中，一個說明被視為事件的普