軟件需求復習提綱_第1頁
軟件需求復習提綱_第2頁
軟件需求復習提綱_第3頁
軟件需求復習提綱_第4頁
軟件需求復習提綱_第5頁
已閱讀5頁,還剩3頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、軟件需求復習提綱第I部分 什么是軟件需求?為什么要實現(xiàn)軟件需求?哪些人應參與軟件需求?軟件或系統(tǒng)項目涉眾:客戶: 為達到其公司的業(yè)務目標而投資項目或購買產(chǎn)品。用戶:直接或間接與產(chǎn)品打交道,是客戶的一部分。需求分析員:負責編寫需求并傳達給開發(fā)團隊。開發(fā)人員:設(shè)計、實現(xiàn)和維護產(chǎn)品。測試人員:確定產(chǎn)品的行為是否與預計的相一致。文檔編制人員:負責編寫用戶手冊、培訓資料和系統(tǒng)幫助。項目經(jīng)理:制定項目計劃并帶領(lǐng)開發(fā)人員獲得成功。法律人員:確保產(chǎn)品符合所有相關(guān)法規(guī)。生產(chǎn)人員:制造包含該軟件的產(chǎn)品。市場營銷人員:技術(shù)支持及其他與產(chǎn)品和客戶打交道的人員。常見的幾種關(guān)于需求的定義說法: = 1 * GB2 需求是

2、“任何促成設(shè)計決策的因素”; = 2 * GB2 用戶為解決某個問題或達到某個目標而需具備的條件或能力。系統(tǒng)或系統(tǒng)組件為符合合同、標準、規(guī)范或其他正式文檔而必須滿足的條件或必須具備的能力。上述第一項或第二項中定義的條件和能力的文檔表達。 = 3 * GB2 需求是對應該實現(xiàn)什么功能的說明可以是對系統(tǒng)運行方式或系統(tǒng)特征與屬性的描述;還可能是對系統(tǒng)開發(fā)過程的約束。軟件需求包括3個不同的層次業(yè)務需求(表示組織或客戶高層次的目標)、用戶需求(用戶的目標,或用戶要求系統(tǒng)必須能完成的任務)和功能需求(規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能,用戶利用這些功能來完成任務,滿足業(yè)務需求)。除此之外,每個系統(tǒng)還有

3、各種非功能需求。軟件需求工程分為需求開發(fā)和需求管理兩部分需求開發(fā)的任務可進一步細分為獲取、分析、規(guī)格說明和確認。 需求管理的任務是“與客戶就軟件項目的需求達成并保持一致”需求管理包括下列活動:定義需求基線(某一時刻,對特定版本中已達成一致的需求內(nèi)容的描述)。審查需求變更請求,評估其可能產(chǎn)生的影響以決定是否批準。以可控的方式將批準的需求變更融入項目中。保持項目計劃與需求的同步。估計需求變更的影響,在此基礎(chǔ)上協(xié)商新的需求約定。跟蹤每項需求,找到與其對應的設(shè)計、源代碼和測試用例(test case)。在項目開發(fā)過程中,始終跟蹤需求的狀態(tài)和變更。鍍金問題:開發(fā)人員為產(chǎn)品添加了一項需求說明中沒有提到的功

4、能,他認為“用戶肯定會喜歡的”。這就是鍍金問題。開發(fā)人員和需求分析員不應擅自添加特性,應該把創(chuàng)意和備選方案提交給客戶,讓他們做決定;要避免鍍金問題,就應該追溯每項功能的來源,弄清楚為什么添加該功能。 客戶:廣義地講,客戶泛指直接或間接得益于產(chǎn)品的個人或組織。軟件的客戶包括那些提出軟件需求,購買、定義、使用軟件產(chǎn)品或選擇接受軟件功能的項目涉眾。低一層的需求用戶需求則應來自實際使用產(chǎn)品的人。這類用戶(通常被稱為“最終用戶”)構(gòu)成了另一類型的客戶。 對于信息系統(tǒng)、簽約開發(fā)或自己開發(fā)的項目,業(yè)務需求應來自投資項目人,而用戶需求則應來自產(chǎn)品的實際使用者??蛻舻臋?quán)利:軟件客戶的權(quán)利法案(見表2.1),共列

5、出了10項權(quán)利,理解其內(nèi)容()客戶的義務:軟件客戶的法案(見表2.2),列出了需求過程中客戶對需求分析員和開發(fā)人員承擔的10項義務。理解其內(nèi)容()關(guān)于簽字:不可能在項目初期就能明確所有的需求,需求肯定要隨時間的推移而發(fā)生變化。參與者必須對項目初期的簽字的準確含義應達成上述一致的理解。知識:所有將要成為分析員的團隊成員都應該接受需求工程方面的基本培訓。熟練的需求分析員應具備以下特點:耐心,思維條理性強,有良好的交際和溝通能力,理解產(chǎn)品應用領(lǐng)域,并且掌握豐富的需求工程技術(shù)。 定義應用領(lǐng)域?qū)I(yè)名稱的術(shù)語表可以減少誤解。需求獲?。捍_定用戶群和他們的特點將產(chǎn)品的用戶分成組,以避免出現(xiàn)某一用戶群的需求被忽

6、略的情況。為每類用戶選擇代言人為每類用戶選擇至少一位能夠準確反映其需求的代言人。建立典型用戶的中心小組把產(chǎn)品早期版本或同類產(chǎn)品的用戶代表召集起來,收集他們對正在開發(fā)的產(chǎn)品的功能和質(zhì)量特性的意見。 即使沒有明確指定,軟件項目組中也會有某個人會擔當需求分析員的角色,需求分析員職責含:是對項目涉眾的需求進行收集、分析、記錄和驗證等職責的主要承擔者。是用戶群體與軟件開發(fā)團隊間進行需求溝通的主要渠道。第一項工作是幫助業(yè)務或投資管理人、產(chǎn)品經(jīng)理或銷售經(jīng)理定義項目的業(yè)務需求。對收集到的需求進行分析,找出那些客戶沒有明確說明的需求。編寫需求規(guī)格說明 需求分析員必備的技能傾聽的技巧 要善于雙向交流,就必須知道如

7、何有效地傾聽。交談和提問的技巧 大部分需求是通過討論得到的,因此,需求分析員必須能夠與不同的個人或小組就需求展開討論。分析能力 優(yōu)秀的需求分析員能夠以不同的方式思考問題.協(xié)調(diào)能力 需求獲取過程中,對相關(guān)人員進行協(xié)調(diào)也是需求分析員必備的一項能力觀察能力 觀察力敏銳的需求分析員能夠從不經(jīng)意的閑談中發(fā)現(xiàn)重要的信息。寫作能力 需求開發(fā)提交的主要結(jié)果是書面的需求規(guī)格說明,用于在客戶、營銷人員、管理人員和技術(shù)人員之間傳遞信息。組織能力 需求分析員需要處理獲取和分析過程中收集到的大量雜亂的信息。建模能力 每個需求分析員都應該掌握從傳統(tǒng)的流程圖到結(jié)構(gòu)化的分析模型(數(shù)據(jù)流圖、實體關(guān)系圖之類),直至當今的統(tǒng)一建模

8、語言(UML)等多種分析工具。人際交往能力 需求分析員應具備讓彼此利益競爭的人們進行合作的能力。創(chuàng)造力 需求分析員不能像抄錄員那樣只記下客戶說過的每句話。需求分析員必備的知識:需求分析員還需具備從實踐經(jīng)驗中積累的廣博知識。其中最基本的是對當代需求管理技術(shù)的深刻理解,以及在各種不同的軟件開發(fā)生命周期環(huán)境中應用這些技術(shù)的能力。需求分析員需要將需求開發(fā)與管理活動貫穿于整個產(chǎn)品生命期中。掌握應用領(lǐng)域的知識、最大限度地減少與客戶間的誤解。開發(fā)人員要想成為需求分析員,需要多掌握一些業(yè)務領(lǐng)域的知識第二部分 軟件需求開發(fā) 項目的范圍定義了所提出的解決方案的概念和范圍。(1)第一個版本的范圍概述計劃在產(chǎn)品的第一

9、個版本中實現(xiàn)的主要特性。(2)各后續(xù)版本的范圍要采用階段性的開發(fā)方式,需要決定推遲實現(xiàn)哪些特性,并為后續(xù)的版本做出時間安排。(3)限制與排除定義項目包含的需求與不包含的需求之間的界線。保持范圍的適度正常情況下依據(jù)前景和范圍文檔決定需求范圍,但有時被提議的新需求不在范圍之內(nèi),卻很有價值,因而需要對項目范圍做出調(diào)整以容納這一新的需求。 要獲得客戶的需求,應采取以下步驟:確定產(chǎn)品的不同用戶類型。確定用戶需求的來源。挑選出每一類用戶和其他涉眾的代表并與他們一起工作。商定誰是項目需求的決策者。幾種典型的軟件需求來源:與潛在用戶進行交談和討論 要想知道某個新軟件的潛在用戶的需求,最直接的方式莫過于向用戶了

10、解。描述現(xiàn)有產(chǎn)品或競爭產(chǎn)品的文檔這類文檔可能也會描述產(chǎn)品必須遵循的企業(yè)或行業(yè)標準,以及法律和法規(guī)等。系統(tǒng)需求規(guī)格說明同時包含硬件和軟件的產(chǎn)品具有一個高級的系統(tǒng)需求規(guī)格說明,用于描述整個產(chǎn)品。現(xiàn)有系統(tǒng)的問題報告和改進要求 客戶服務和技術(shù)支持人員也是需求的重要來源。市場調(diào)查和用戶問卷調(diào)查 這類調(diào)查能夠從廣大的潛在用戶那里收集到大量的數(shù)據(jù)。觀察用戶如何工作讓需求分析員觀察現(xiàn)有系統(tǒng)的用戶或?qū)⒁瞥龅南到y(tǒng)的潛在用戶如何進行工作。用戶工作的情景分析 在確定用戶需要借助系統(tǒng)完成哪些工作之后,需求分析員就能推導出用戶完成這些工作必需的功能性需求。事件和響應 列出系統(tǒng)必須響應的外部事件和正確的響應。 需求獲取中

11、的注意事項只向很少的用戶代表收集意見,或者只聽取聲音最大、最固執(zhí)己見的客戶的意見,也是需求獲取過程中存在的問題。獲取用戶需求的工作可能導致對產(chǎn)品前景或項目范圍的修改。需求開發(fā)過程中產(chǎn)生的模型和界面草圖應該被視為可以促進有效溝通的設(shè)計建議,而不應成為對設(shè)計者的約束。必須讓用戶明白這些界面和原型只是用于說明,不一定是最終的解決方案。使用增量開發(fā)方法,把需求分解成低風險的更小的部分進行研究。 用例的好處使用用例能夠讓用戶更清楚地了解新系統(tǒng)可以提供的功能。用例法還有助于為需求劃分優(yōu)先級。優(yōu)先級最高的功能性需求源自優(yōu)先級最高的用例。優(yōu)先級高的用例具有以下特征:描述了系統(tǒng)實現(xiàn)的核心業(yè)務過程之一。很多用戶經(jīng)

12、常使用。由重點用戶類提出。提供了為符合規(guī)定所需的功能。其他系統(tǒng)功能依賴于該用例的存在。用例法還有技術(shù)方面的好處,能夠揭示重要的域?qū)ο?,以及相互間的職責。使用用例時應避免的問題用例過多。 用例過于復雜 。在用例中包含用戶界面設(shè)計 。 在用例中包含數(shù)據(jù)定義。用戶無法理解用例。新的業(yè)務流程。濫用包含和擴充關(guān)系。 業(yè)務規(guī)則是對業(yè)務的某個方面進行定義或約束的語句。業(yè)務規(guī)則包括5類:試舉出約束、動作觸發(fā)規(guī)則和計算的例子。事實(fact)就是對業(yè)務的真實陳述,常常描述重要業(yè)務術(shù)語間的關(guān)聯(lián)。約束(constraint)限制了系統(tǒng)或它的用戶可以執(zhí)行哪些操作。約束的例子包括:未滿18周歲的借款人必須由父母或其它其

13、他合法監(jiān)護人作為貸款的聯(lián)合簽署人。圖書館的借閱者最多可以同時借10本書。只有最近12個月內(nèi)接受過危險化學品使用方法培訓的用戶,才能申領(lǐng)屬于一級危險品的化學制品化學品。所有應用軟件都必須符合政府法規(guī)中有關(guān)方便視力較弱人士使用的規(guī)定。信件中可以不必寫出投保人4位以上的社會保險號。每24小時內(nèi),商業(yè)航空公司的機組人員必須至少得到連續(xù)8小時的休息。動作觸發(fā)規(guī)則:在特定條件下觸發(fā)某個動作的規(guī)則下面是一些動作觸發(fā)類業(yè)務規(guī)則的例子:如果化學品倉庫中有所需化學品,則將現(xiàn)有的化學品交給申領(lǐng)人。如果某瓶化學品到了失效日期,則通知其當前持有人。每季度的最后一天,按規(guī)定生成該季度化學品使用和處理情況的OSHA和EPA

14、報告。如果客戶訂購的書的作者有多部作品,則在接受訂單前向客戶推薦作者的其他作品。計算:有一類業(yè)務規(guī)則定義使用特定數(shù)學公式或算法進行的計算(computation)。比如表9.1 購買商品數(shù)量不同折扣也不同的例子推論(inference)是根據(jù)某個條件的真實性得出某些新事實的規(guī)則,有時也稱為推導出的知識。下面是一些推論的例子:如果到期30天后還沒有償還應付款,則該賬戶是在拖欠債務。如果接到訂單5天后,賣方還不能發(fā)送客戶訂購的商品,則表明該商品延遲交貨??赡苄纬杀ㄐ苑纸馕锏幕瘜W品被認為在出廠一年后過期。 需求開發(fā)的最終成果是,在客戶和開發(fā)人員對所要開發(fā)的產(chǎn)品達成共識后,編寫的具體的需求文檔??梢?/p>

15、采用以下幾種方式來表示軟件需求文檔 用結(jié)構(gòu)合理的自然語言來精心編寫需求文檔。圖形化模型 這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或者對象類及其關(guān)系。形式化規(guī)格說明使用數(shù)學上精確的形式邏輯語言來定義需求。 與文本相比,要交流某些類型的信息,使用示意圖的效率可能更好。示意圖還有助于掃清不同的團隊成員之間在語言和詞匯上的障礙。分析人員需要向其他涉眾解釋所用的模型和符號的用途。 產(chǎn)品的易用性、運行速度、出錯頻率,以及處理異常情況的能力。這些特性被稱為軟件質(zhì)量屬性,是系統(tǒng)非功能(也叫非行為)性需求的一部分(略) 為什么要設(shè)定需求優(yōu)先級設(shè)定優(yōu)先級是一種行之有效的方法,可以處理在

16、資源有限的情況下,應該優(yōu)先滿足哪些需求。為每一種功能建立相對優(yōu)先級后,就可以規(guī)劃軟件的開發(fā),以最低的成本提供最佳的產(chǎn)品。如果正在從事時間盒式(timeboxed)開發(fā)或增量開發(fā),那么設(shè)定優(yōu)先級就特別重要,因為在這些開發(fā)中,交付進度安排得很緊迫并且不可改變。客戶和開發(fā)人員都必須為設(shè)定需求優(yōu)先級提供信息。客戶總是賦予那些能給他們帶來最大的業(yè)務利益或易用性利益的需求最高的優(yōu)先級。 P181 圖15.1描繪了軟件開發(fā)的V字模型,它表明測試活動應該與相應的開發(fā)活動同時開始。這個模型表明,驗收測試以用戶需求為基礎(chǔ);系統(tǒng)測試以功能過性需求為基礎(chǔ);系統(tǒng)測試以系統(tǒng)的體系結(jié)構(gòu)為基礎(chǔ)。需求確認是需求開發(fā)過程的第4個

17、階段,前3個階段分別為需求獲取、需求分析和編寫需求規(guī)格說明需求確認活動應力圖確保以下幾點: 軟件需求規(guī)格說明正確描述了預期的滿足各方涉眾需要的系統(tǒng)能力和特征。從系統(tǒng)需求、業(yè)務規(guī)則或其他來源中正確地推導出軟件需求。需求是完整的和高質(zhì)量的。需求的表示在所有地方都是一致的。需求為繼續(xù)進行產(chǎn)品設(shè)計和構(gòu)造提供充分的基礎(chǔ)。需求評審包括非正式評審和正式評審非正式評審方法包括:同級桌面檢查(peer deskcheck) 輪查(passaround) 走查(walkthrough) 正式評審會生成一份報告,報告中指明具體材料、評審人員以及評審團隊認為產(chǎn)品是否可以接受,主要提交對發(fā)現(xiàn)的錯誤和提出的問題的總結(jié)。

18、對于缺少精確的需求文檔,那么維護人員就必須進行逆向工程,通過代碼來理解系統(tǒng)。技能水平對項目的成功或失敗有著至關(guān)重要的影響,那么實踐經(jīng)驗就可以減少在一個零起點項目中第一次應用用例的風險。由于許多軟件修改都會引發(fā)很大的連鎖反應,所以我們必須確保每次需求變更都要正確地傳給下游工作產(chǎn)品,審查就是檢查這種一致性的一種好方法。突發(fā)型項目的需求:由于突發(fā)型和快速變動的項目變得流行,所以產(chǎn)生了各種敏捷開發(fā)方法,這些方法強調(diào)將可用的功能快速地交付給用戶使用。這種敏捷開發(fā)方法對需求開發(fā)采用瘦身法,而對需求管理則采用非正式方法。敏捷開發(fā)的基本原理在于認為軟件變更既是不可避免的也是合乎需要的。(略) 第III部分 軟件需求管理 需求管理包括:控制對需求基線的變更。保持項目規(guī)劃與需求之間的一致??刂茊雾椥枨蠛托枨笪臋n的版本情況。跟蹤基線中需求的狀態(tài)。管理單個需求和其他項目工作產(chǎn)品之間的邏輯聯(lián)系鏈。對提出的新需求或?qū)σ炎兏男枨?,項目的響應方式有多種:推遲實現(xiàn)優(yōu)先級低的需求。 增派人手。短時間的突擊加班,最好是有償加班。為了滿足新功能,推遲產(chǎn)品的交付日期。保持產(chǎn)品交付日期不變,但在質(zhì)量上打些折扣。需求屬性(將每個需求想像成一個對象,它具有一些能將自身與其他需求區(qū)分開來的屬性):需求創(chuàng)建的日期。需求

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論