重點放在“做什么”上,但在分析和設計之間還是存在一定的距離。你可以使用假設“怎么做”來分類并改善你對用戶需求的理解。在需求的獲取過程中,分析模型、屏幕圖形和原型可以使概念表達得更加清楚,然后提供一個尋找錯誤和遺漏的辦法。把你在需求開發(fā)階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議,而不應該看成是對設計者選擇的一種限制。需求獲取討論會中如果參與者過多,就會減慢進度。人數(shù)大致控制在5到7人是最好的。這些人包括客戶、系統(tǒng)設計者、開發(fā)者和可視化設計者等主要工程角色。相反地,從極少的代表那里收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音,也會造成問題。這將導致忽視特定用戶類的重要的需求,或者其需求不能代表絕大多數(shù)用戶的需要。最?好的權(quán)衡在于選擇一些授權(quán)為他們的用戶類發(fā)言的產(chǎn)品代表者,他們也被同組用戶類的其它代表所支持。沒有一個簡單、清楚的信號暗示你什么時候已完成需求獲取。當客戶和開發(fā)者與他們的同事聊天、閱讀工業(yè)和商業(yè)上的文獻及在早上沐浴時思考時,他們都將對潛在產(chǎn)品產(chǎn)生新的構(gòu)思。你不可能全面收集需求,但是下列的提示將會暗示你在需求獲取的過程中的返回點。
1. 如果用戶不能想出更多的使用實例,也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的?!?BR> 2. 如果用戶提出新的使用實例,但你可以從其它使用實例的相關(guān)功能需求中獲得這些新的使用實例,這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程?!?BR> 3. 如果用戶開始重復原先討論過的問題,此時,也許你就完成了收集需求的工作。
4. 如果所提出的新需求比你已確定的需求的優(yōu)先級都低時,也許你就完成了收集需求的工作。
5. 如果用戶提出對將來產(chǎn)品的要求,而不是現(xiàn)在我們討論的特定產(chǎn)品,也許你就完成了收集需求的工作?!?BR> 以上知識大致上討論需求分析應該如何做,實際上對于需求分析的方法有很多很多,已經(jīng)形成了一定的用例在需求分析中的使用。
多年來,分析者總是利用情節(jié)或經(jīng)歷來描述用戶和軟件系統(tǒng)的交互方式,從而獲取需求(McGrawandHarbison1997)。IvarJacobson(1992)把這種看法系統(tǒng)地闡述成用例(用例)的方法進行需求獲取和建模。雖然用例來源于面向?qū)ο蟮拈_發(fā)環(huán)境,但是它也能應用在具有許多開發(fā)方法的項目中,因為用戶并不關(guān)心你是怎樣開發(fā)你的件。而最重要的,用例的觀點和思維過程帶給需求開發(fā)的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統(tǒng)做什么遠遠強于詢問用戶希望系統(tǒng)為他們做什么這一傳統(tǒng)方法。用例的重要功能是用畫用例圖的功能來鑒別和劃分系統(tǒng)功能。它把系統(tǒng)分成角色(actor)和用例(用例)。角色(actor)表示系統(tǒng)用戶能扮演的角色(role)。這些用戶可能是人,可能是其他的計算機一些硬件或者甚至是其它軟件系統(tǒng),唯一的標準是它們必須要在被劃分進用例的系統(tǒng)部分以外。它們必須能刺激系統(tǒng)部分并接收返回。用例描述了當角色給系統(tǒng)特定的刺激時系統(tǒng)的活動。這些活動被文本描述。它描述了觸發(fā)用例的刺激的本質(zhì),輸入和輸出到其他活動者,和轉(zhuǎn)換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統(tǒng)應采取的補救措施。這樣說可能會非常復雜,其實一個用例描述了系統(tǒng)和一個角色(actor)的交互順序。用例被定義成系統(tǒng)執(zhí)行的一系列動作,動作執(zhí)行的結(jié)果能被指定角色察覺到。用例可以:用例捕獲某些用戶可見的需求,實現(xiàn)一個具體的用戶目標。用例由角色激活,并提供確切的值給角色。用例可大可小,但它必須是對一個具體的用戶目標實現(xiàn)的完整描述。在UML中,用例表示
項目經(jīng)理勝任力免費測評PMQ上線啦!快來測測你排多少名吧~
http://www.vanceur.cn/pmqhd/index.html