資源描述:
《需求分析與定義》由會員上傳分享,免費在線閱讀,更多相關(guān)內(nèi)容在工程資料-天天文庫。
1、需求分析與定義1.軟件需求:軟件需求分為三人部分:1)、功能需求:指系統(tǒng)需耍完成那些事情,即向用戶提供那些功能。2)、非功能需求:指產(chǎn)品所具備的品質(zhì)和屬性,比如可靠性、擴展性、響應時間、性能等等。。。3)、設(shè)計約束:也稱條件約束、補充規(guī)則。比如用戶要安裝該產(chǎn)品他需要有什么樣的必備條件。(系統(tǒng)対操作系統(tǒng)的要求、硬件環(huán)境的要求等等????.)2.需求調(diào)査與問題定義:在做需求調(diào)查時需要做到兩W一H即What>Where>How2)、What-一應該收集什么信息2)、Where-…從什么地方收集3)、How——用什么機制或技術(shù)來收集3.需求分析需求分析通常包括六個方面:1)、繪制系統(tǒng)上
2、下文范圍關(guān)系圖:主要川于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型,他可以為需求確定一個范IfloH實就是DFD的0層圖。2)、創(chuàng)建用戶接口原型:這里我們可以把他看成是用戶操作的一個雛形,什么意思呢就是我們通常所說的界面用戶通過一系列的操作完成他想達到的效果的接口。3)、分析需求的可行性:這個需求我們應該用什么技術(shù)解決,他實現(xiàn)后的性能怎么樣,是否與其他需求相重合或是矛盾,這里一定要注意不要把系統(tǒng)的這個盂求怎么用代碼實現(xiàn)想進去。在需求分析時應多注意需求木身是否有用不必考慮怎么實現(xiàn)。4)、確定需求的優(yōu)先級:對采用滿意度/不滿意度指標來說明(滿意度表示當需求被實現(xiàn)時用戶的滿意程度
3、;不滿意度取值同理)5)、為需求建立模型:這里可以用UML創(chuàng)建用例圖或是E-R圖再加上少屋的文字描述。6)、使用質(zhì)量功能調(diào)配(QFD):這里我的理解是分析員根據(jù)需求的理解發(fā)現(xiàn)隱藏需求而這些需求是用戶也沒冇想到的需求,系統(tǒng)實現(xiàn)后會給川戶一個驚喜,而沒實現(xiàn)川戶也不會有抱怨。4?需求分析方法現(xiàn)在比較流行的軟件需求分析方法有4利其中3種理論比較成熟。1)>結(jié)構(gòu)化分析方法(StrueturedAnalysis,SA):這個大家想必很熟悉了不在復述。2)、軟系統(tǒng)方法:這只是過度性的方法論他的出現(xiàn)只是證明結(jié)構(gòu)化分析方法的一些不足。因為結(jié)構(gòu)化分析方法采用的相對形式化的模型不僅少社會觀格格不入,
4、而且在解決“不確定性”時顯得十分無力。3)、面向?qū)ο蠓治龇椒ǎ∣bjectOrientedAnalysis,00A):這也是我下文想講的分析方法4)、面向問題域的分析(ProblemDomainOrientedAnalysis,PDOA):00A也存在著很多不足,但PDOA現(xiàn)在正在研究屮所以未被廣泛應川。這里需要注意的是:在軟件開發(fā)屮有很多需求分析方法他們沒有好壞之分只要你運用得當照樣可以做出一個很好的系統(tǒng),依據(jù)個人對某個方法的理解用自己最擅長的方法是最明智的選擇。5.血向?qū)澫笮枨蠓治觯?0A)而向?qū)ο筮@個概念很簡單但也很復雜我在這里不做深入探討。我將從實際出發(fā)來和人家-起探討
5、下在實際開發(fā)中我們應該怎么做。00A的精髓在于世間萬物均為對彖采川00A方法在整個過程中包括2個工作任務:建立一個反應問題域靜態(tài)關(guān)系的概念模型,就是我們通常所說的類圖;另一個反應系統(tǒng)行為的動態(tài)模型,即用例模型那么我們在實際開發(fā)中到底怎么做呢?1)建立域模型尋找類:在尋找類時有多種方法典型的是根據(jù)需求文檔用“名詞動詞法”來尋找,找出備選類后再從中尋找出真正的類。(注意在用此方法時切記不要咬文嚼字專牛角尖在這里花費很長的時間)確定類之間的關(guān)聯(lián):這個過程是迭代的我們需要理清址這些類之間的關(guān)系如關(guān)聯(lián)、繼承、聚合等然后通過UML記錄下來。類Z間的關(guān)系不是一下子就能確定下來的是要慢慢完善的
6、為類添加職責:這里就可以理解成為類添加所需要的屬性和方法。域模型的詳細度:這里不做太多要求可以寫的很詳細也可以寫的簡單寫,可以把握好一個原則:只要能有利于團隊更好的開發(fā)就是好模型。2)建立川例模型什么是用例:用例實例是在系統(tǒng)中執(zhí)行的一系列動作,這些動作將生成對特定參與者可見的價值結(jié)果。(用例實例就是常說的“使用場景“)一個用例定義一纟fl用例實例。識別參與者:川例主要是為了訃客戶直觀的理解需求那么這里參與者是必不可少的這樣才能形象的勾M出系統(tǒng)某個特定場景下的流程。注意參與者不僅可以是人也可以是其他的事物如(其他系統(tǒng)、碩件設(shè)備、吋鐘等等)合并需求獲得的川例繪制用例圖(如果對用例圖
7、不清楚請參考UML相關(guān)文章)細化用例描述用例描述可以包括以下幾個部分:用例名稱簡耍說明事件流:是該用例要完成的工作步驟非功能需求前置條件后置條件擴展點優(yōu)先級別3)要想做好需求分析光上血的用例是不夠的還有寫建模技術(shù)也要有如:協(xié)作圖、順序圖和狀態(tài)圖協(xié)作圖:是一種用以顯示對象如何被協(xié)調(diào)在一起執(zhí)行用例的圖,用來識別協(xié)作完成給定業(yè)務的對彖。順序圖:是一種丿IJ以顯示用例對象之間消息順序的圖,他與協(xié)作圖表達的信息是一樣的知識顯示的方式有差別。順序圖以圖形化的方式強調(diào)消息的順序,而非協(xié)作對象間的順序。他和