| ||||
| 需求獲取(requirement elicitation)是需求工程的主體。對于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不同用戶(hù)類(lèi)的需要和限制的過(guò)程。獲取用戶(hù)需求位于軟件需求三個(gè)層次的中間一層。業(yè)務(wù)需求決定用戶(hù)需求，它描述了用戶(hù)利用系統需要完成的任務(wù)。從這些任務(wù)中，分析者能獲得用于描述系統活動(dòng)的特定的軟件功能需求，這些系統活動(dòng)有助于用戶(hù)執行他們的任務(wù)。 需求獲取是在問(wèn)題及其最終解決方案之間架設橋梁的第一步。獲取需求的一個(gè)必不可少的結果是對項目中描述的客戶(hù)需求的普遍理解。一旦理解了需求，分析者、開(kāi)發(fā)者和客戶(hù)就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問(wèn)題之后才能開(kāi)始設計系統，否則，對需求定義的任何改進(jìn)，設計上都必須大量的返工。把需求獲取集中在用戶(hù)任務(wù)上—而不是集中在用戶(hù)接口上—有助于防止開(kāi)發(fā)組由于草率處理設計問(wèn)題而造成的失誤。 需求獲取、分析、編寫(xiě)需求規格說(shuō)明和驗證并不遵循線(xiàn)性的順序，這些活動(dòng)是相互隔開(kāi)、增量和反復的。當你和客戶(hù)合作時(shí)，你就將會(huì )問(wèn)一些問(wèn)題，并且取得他們所提供的信息（需求獲?。?。同時(shí)，你將處理這些信息以理解它們，并把它們分成不同的類(lèi)別，還要把客戶(hù)需求同可能的軟件需求相聯(lián)系（分析）。然后，你可以使客戶(hù)信息結構化，并編寫(xiě)成文檔和示意圖（說(shuō)明）。下一步，就可以讓客戶(hù)代表評審文檔并糾正存在的錯誤（驗證）。這四個(gè)過(guò)程貫穿著(zhù)需求分析的整個(gè)階段。 需求獲取可能是軟件開(kāi)發(fā)中最困難、最關(guān)鍵、最易出錯及最需要交流的方面。需求獲取只有通過(guò)有效的客戶(hù)—開(kāi)發(fā)者的合作才能成功。分析者必須建立一個(gè)對問(wèn)題進(jìn)行徹底探討的環(huán)境，而這些問(wèn)題與產(chǎn)品有關(guān)。為了方便清晰地進(jìn)行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問(wèn)題的全面考察需要一種技術(shù)，利用這種技術(shù)不但考慮了問(wèn)題的功能需求方面，還可討論項目的非功能需求。確定用戶(hù)已經(jīng)理解：對于某些功能的討論并不意味著(zhù)即將在產(chǎn)品中實(shí)現它。對于想到的需求必須集中處理并設定優(yōu)先級，以避免一個(gè)不能帶來(lái)任何益處的無(wú)限大的項目。 需求獲取是一個(gè)需要高度合作的活動(dòng)，而并不是客戶(hù)所說(shuō)的需求的簡(jiǎn)單謄本。作為一個(gè)分析者，你必須透過(guò)客戶(hù)所提出的表面需求理解他們的真正需求。詢(xún)問(wèn)一個(gè)可擴充（open-ended）的問(wèn)題有助于你更好地理解用戶(hù)目前的業(yè)務(wù)過(guò)程并且知道新系統如何幫助或改進(jìn)他們的工作。調查用戶(hù)任務(wù)可能遇到的變更，或者用戶(hù)需要使用系統其它可能的方式。想像你自己在學(xué)習用戶(hù)的工作，你需要完成什么任務(wù)？你有什么問(wèn)題？從這一角度來(lái)指導需求的開(kāi)發(fā)和利用。 還有，探討例外的情況：什么會(huì )妨礙用戶(hù)順利完成任務(wù)？對系統錯誤情況的反映，用戶(hù)是如何想的？詢(xún)問(wèn)問(wèn)題時(shí)，以“還有什么能” ,”當?時(shí)，將會(huì )發(fā)生什么”“你有沒(méi)有曾經(jīng)想過(guò)” ,“有沒(méi)有人曾經(jīng)”為開(kāi)頭。記下每一個(gè)需求的來(lái)源，這樣向下跟蹤直到發(fā)現特定的客戶(hù)。 有些時(shí)候，嘗試著(zhù)問(wèn)一些“愚蠢”的問(wèn)題也有助于客戶(hù)打開(kāi)話(huà)匣子。如果你直接要求客戶(hù)寫(xiě)出業(yè)務(wù)是如何實(shí)現的，客戶(hù)十有八九無(wú)法完成。但是如果你嘗試著(zhù)問(wèn)一些實(shí)際的問(wèn)題，例如：“以我的理解，你們收到訂單后，會(huì )...”?？蛻?hù)立刻就會(huì )指出你的錯誤，并滔滔不絕的開(kāi)始談?wù)摌I(yè)務(wù)，而你，就在一邊仔細的聆聽(tīng)吧。這一招就叫做“拋磚引玉”。 需求討論會(huì )上必須要使用筆記本電腦，還要指定一個(gè)打字熟練的人把所有的討論記錄下來(lái)，記錄的同時(shí)還要做一定的整理。如果不這樣做，那么你結束會(huì )議的時(shí)候就會(huì )發(fā)現，所有的討論只剩下一個(gè)模糊的印象，需求對你來(lái)說(shuō)仍然是一件遙遠的事情。在座談?dòng)懻撝?，記下所討論的條目(item)，并請參與討論的用戶(hù)評論并更正。及早并經(jīng)常進(jìn)行座談?dòng)懻撌切枨螳@取成功的一個(gè)關(guān)鍵途徑，因為只有提供需求的人才能確定是否真正獲取需求。進(jìn)行深入收集和分析以消除任何沖突或不一致性。 盡量把客戶(hù)所持的假設解釋清楚，特別是那些發(fā)生沖突的部分。從字里行間去理解以明確客戶(hù)沒(méi)有表達清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文無(wú)關(guān)問(wèn)題”—這是一個(gè)高層次的問(wèn)題，它可以獲取業(yè)務(wù)問(wèn)題和可能的解決方案的全部信息?？蛻?hù)對這些問(wèn)題的回答諸如“產(chǎn)品要求怎樣的精確度”或“你能幫我解釋一下你為什么不同意某人的回答嗎？”這些回答可以更直接地認識問(wèn)題，而這是封閉（close-end）問(wèn)題所不能做到的。 需求獲取利用了所有可用的信息來(lái)源，這些信息描述了問(wèn)題域或在軟件解決方案中合理的特性。一個(gè)研究表明：比起不成功的項目，一個(gè)成功的項目在開(kāi)發(fā)者和客戶(hù)之間采用了更多的交流方式（Kiel and Carmel 1995）。與單個(gè)客戶(hù)或潛在的用戶(hù)組一起座談，對于業(yè)務(wù)軟件包或信息管理系統（MIS）的應用來(lái)說(shuō)是一種傳統的需求來(lái)源。直接聘請用戶(hù)進(jìn)行獲取需求的過(guò)程是為項目獲得支持和買(mǎi)入（buy-in）的一種方式。 盡量理解用戶(hù)用于表述他們需求的思維過(guò)程。充分研究用戶(hù)執行任務(wù)時(shí)作出決策的過(guò)程，并提取出潛在的邏輯關(guān)系。流程圖和決策樹(shù)是描述這些邏輯決策途徑的好方法。 在需求獲取的過(guò)程中，你可能會(huì )發(fā)現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業(yè)務(wù)和客戶(hù)的值，此時(shí)獲取過(guò)程將會(huì )拖延。如果項目范圍太小，那么客戶(hù)將會(huì )提出很重要的但又在當前產(chǎn)品范圍之外的需求。當前的范圍太小，以致不能提供一個(gè)令人滿(mǎn)意的產(chǎn)品。需求的獲取將導致修改項目的范圍和任務(wù)，但作出這樣具有深遠影響的改變，一定要小心謹慎。 正如經(jīng)常所說(shuō)的，需求主要是關(guān)于系統做什么，而解決方案如何實(shí)現是屬于設計的范圍。這樣說(shuō)雖然很簡(jiǎn)潔，但似乎過(guò)于簡(jiǎn)單化。需求的獲取應該把重點(diǎn)放在“做什么”上，但在分析和設計之間還是存在一定的距離。你可以使用假設“怎么做”來(lái)分類(lèi)并改善你對用戶(hù)需求的理解。在需求的獲取過(guò)程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然后提供一個(gè)尋找錯誤和遺漏的辦法。把你在需求開(kāi)發(fā)階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。 需求獲取討論會(huì )中如果參與者過(guò)多，就會(huì )減慢進(jìn)度。人數大致控制在5到7人是最好的。這些人包括客戶(hù)、系統設計者、開(kāi)發(fā)者和可視化設計者等主要工程角色。相反地，從極少的代表那里收集信息或者只聽(tīng)到呼聲最高、最有輿論影響的用戶(hù)的聲音，也會(huì )造成問(wèn)題。這將導致忽視特定用戶(hù)類(lèi)的重要的需求，或者其需求不能代表絕大多數用戶(hù)的需要。最好的權衡在于選擇一些授權為他們的用戶(hù)類(lèi)發(fā)言的產(chǎn)品代表者，他們也被同組用戶(hù)類(lèi)的其它代表所支持。 沒(méi)有一個(gè)簡(jiǎn)單、清楚的信號暗示你什么時(shí)候已完成需求獲取。當客戶(hù)和開(kāi)發(fā)者與他們的同事聊天、閱讀工業(yè)和商業(yè)上的文獻及在早上沐浴時(shí)思考時(shí)，他們都將對潛在產(chǎn)品產(chǎn)生新的構思。你不可能全面收集需求，但是下列的提示將會(huì )暗示你在需求獲取的過(guò)程中的返回點(diǎn)。 1. 如果用戶(hù)不能想出更多的使用實(shí)例，也許你就完成了收集需求的工作。用戶(hù)總是按其重要性的順序來(lái)確定使用實(shí)例的。 2. 如果用戶(hù)提出新的使用實(shí)例，但你可以從其它使用實(shí)例的相關(guān)功能需求中獲得這些新的使用實(shí)例，這時(shí)也許你就完成了收集需求的工作。這些新的使用實(shí)例可能是你已獲取的其它使用實(shí)例的可選過(guò)程。 3. 如果用戶(hù)開(kāi)始重復原先討論過(guò)的問(wèn)題，此時(shí)，也許你就完成了收集需求的工作。 4. 如果所提出的新需求比你已確定的需求的優(yōu)先級都低時(shí)，也許你就完成了收集需求的工作。 5. 如果用戶(hù)提出對將來(lái)產(chǎn)品的要求，而不是現在我們討論的特定產(chǎn)品，也許你就完成了收集需求的工作。 以上知識大致上討論需求分析應該如何做，實(shí)際上對于需求分析的方法有很多很多，已經(jīng)形成了一定的理論，當然這種理論比較偏向與方法學(xué)，而方法學(xué)的應用主要還是要靠個(gè)人。所以，大家在實(shí)際應用的時(shí)候，不妨結合自己的實(shí)際，有選擇性的采用一些方法，那你就是成功的。 多年來(lái)，分析者總是利用情節或經(jīng)歷來(lái)描述用戶(hù)和軟件系統的交互方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進(jìn)行需求獲取和建模。雖然用例來(lái)源于面向對象的開(kāi)發(fā)環(huán)境，但是它也能應用在具有許多開(kāi)發(fā)方法的項目中，因為用戶(hù)并不關(guān)心你是怎樣開(kāi)發(fā)你的軟件。而最重要的，用例的觀(guān)點(diǎn)和思維過(guò)程帶給需求開(kāi)發(fā)的改變比起是否畫(huà)正式的用例圖顯得更為重要。注意用戶(hù)要利用系統做什么遠遠強于詢(xún)問(wèn)用戶(hù)希望系統為他們做什么這一傳統方法。 用例的重要功能是用畫(huà)用例圖的功能來(lái)鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶(hù)能扮演的角色（role）。這些用戶(hù)可能是人，可能是其他的計算機一些硬件或者甚至是其它軟件系統，唯一的標準是它們必須要在被劃分進(jìn)用例的系統部分以外。它們必須能刺激系統部分并接收返回。用例描述了當角色給系統特定的刺激時(shí)系統的活動(dòng)。這些活動(dòng)被文本描述。它描述了觸發(fā)用例的刺激的本質(zhì)，輸入和輸出到其他活動(dòng)者，和轉換輸入到輸出的活動(dòng)。用例文本通常也描述每一個(gè)活動(dòng)在特殊的活動(dòng)線(xiàn)時(shí)可能的錯誤和系統應采取的補救措施。 這樣說(shuō)可能會(huì )非常復雜，其實(shí)一個(gè)用例描述了系統和一個(gè)角色（actor）的交互順序。用例被定義成系統執行的一系列動(dòng)作，動(dòng)作執行的結果能被指定角色察覺(jué)到。用例可以: · 用例捕獲某些用戶(hù)可見(jiàn)的需求，實(shí)現一個(gè)具體的用戶(hù)目標。 · 用例由角色激活，并提供確切的值給角色。 · 用例可大可小，但它必須是對一個(gè)具體的用戶(hù)目標實(shí)現的完整描述。在UML中，用例表示為一個(gè)橢圓。 角色是指用戶(hù)在系統中所扮演的角色。其圖形化的表示是一個(gè)小人。在某些組織中很可能有許多角色實(shí)例（例如有很多個(gè)銷(xiāo)售員），但就該系統而言，他們均起著(zhù)同一種作用，扮演著(zhù)相同的角色，所以用一個(gè)角色表示。一個(gè)用戶(hù)也可以扮演多種角色。例如，一個(gè)高級營(yíng)銷(xiāo)人員既可以是貿易經(jīng)理，也可以是普通的營(yíng)銷(xiāo)人員；一個(gè)營(yíng)銷(xiāo)人員也可以是售貨員。在處理角色時(shí)，應考慮其作用，而不是人或工作名稱(chēng)，這一點(diǎn)是很重要的。 我們使用不帶箭頭的線(xiàn)段將角色與用例連接到一起，表示兩者之間交換信息，稱(chēng)之為通信聯(lián)系。角色觸發(fā)用例，并與用例進(jìn)行信息交換。單個(gè)角色可與多個(gè)用例聯(lián)系；反過(guò)來(lái)，一個(gè)用例可與多個(gè)角色聯(lián)系。對同一個(gè)用例而言，不同角色有著(zhù)不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類(lèi)似人的圖形來(lái)表示，盡管執行的，但角色未必是人。例如，角色也可以是一個(gè)外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進(jìn)行交互。 一個(gè)用例可能包括完成某項任務(wù)的許多邏輯相關(guān)任務(wù)和交互順序。因此，一個(gè)用例是相關(guān)的用法說(shuō)明的集合，并且一個(gè)說(shuō)明（scenario）是用例的實(shí)例。這種關(guān)系就像是類(lèi)和對象的關(guān)系。在用例中，一個(gè)說(shuō)明被視為事件的普通過(guò)程(normal course)，也叫作主過(guò)程，基本過(guò)程，普通流，或“滿(mǎn)意之路” (happy path)。在描述普通過(guò)程時(shí)列出執行者和系統之間相互交互或對話(huà)的順序。當這種交互結束時(shí)，執行者也達到了預期的目的。 在用例中的其它說(shuō)明可以描述為可選過(guò)程(alternative coruse)?？蛇x過(guò)程也可促進(jìn)成功地完成任務(wù)，但它們代表了任務(wù)的細節或用于完成任務(wù)的途徑的變化部分。在交互序列中，普通過(guò)程可以在一些決策點(diǎn)上分解成可選過(guò)程，然后再重新匯成一個(gè)普通過(guò)程。 |
聯(lián)系客服
