軟件要求定義

第三講軟件要求定義1學(xué)習(xí)內(nèi)容可行性研究項(xiàng)目開(kāi)發(fā)計(jì)劃軟件需求分析2項(xiàng)目來(lái)源合同：為別人做；立項(xiàng)：為自己做；失?。簾o(wú)盈利－》賠錢(qián)－》聲譽(yù)影響－》官司失敗：盡賠錢(qián)－》公司倒閉－》東山再起難！學(xué)到的遠(yuǎn)比失去的多！

3可行性研究（

FeasibilityStudy）

可行性研究的目的就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定該軟件項(xiàng)目是否能夠開(kāi)發(fā)，是否值得開(kāi)發(fā)，最后給決策者提供做與不做的依據(jù)?？尚行匝芯繉?shí)質(zhì)上是要進(jìn)行一次簡(jiǎn)化、壓縮了的需求分析和設(shè)計(jì)過(guò)程，要在較高層次上以抽象的方式進(jìn)行需求分析和設(shè)計(jì)過(guò)程。4可行性研究的任務(wù)

首先需要進(jìn)行概要的分析研究，初步確定項(xiàng)目的規(guī)模和目標(biāo)，確定項(xiàng)目的約束和限制。

然后進(jìn)行簡(jiǎn)要的需求分析，抽象出該項(xiàng)目的邏輯結(jié)構(gòu)，建立邏輯模型。

最后從邏輯模型出發(fā)，經(jīng)過(guò)壓縮的設(shè)計(jì)，探索出若干種可供選擇的主要解決辦法，對(duì)每種解決方法都要從以下三方面研究它的可行性。技術(shù)可行性經(jīng)濟(jì)可行性社會(huì)可行性5技術(shù)可行性在現(xiàn)有資源條件下，項(xiàng)目能否實(shí)現(xiàn)，風(fēng)險(xiǎn)有多大（技術(shù)、資源是否成熟）。社會(huì)可行性是否存在侵權(quán)、軟件操作方式是否適合用戶(hù)所在組織、現(xiàn)有管理制度、人員素質(zhì)是否可行？6經(jīng)濟(jì)可行性（成本—效益分析）

成本—效益分析首先是估算將要開(kāi)發(fā)的系統(tǒng)的開(kāi)發(fā)成本，然后與可能取得的效益進(jìn)行比較和權(quán)衡。效益分有形效益和無(wú)形效益。有形效益可以用貨幣的時(shí)間價(jià)值、投資回收期和純收入等指標(biāo)進(jìn)行度量；無(wú)形效益主要從性質(zhì)上、心理上進(jìn)行衡量，很難直接進(jìn)行量的比較。貨幣的時(shí)間價(jià)值：年利率為i，投資為P，則n年后可得錢(qián)數(shù)為F。

F=P·(1+i)n投資回收期：就是使累計(jì)的經(jīng)濟(jì)效益等于最初的投資費(fèi)用所需的時(shí)間。純收入：就是在整個(gè)生存周期之內(nèi)的累計(jì)經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差。7提示不是解決問(wèn)題，而是確定是否可解\值得解所以不要花過(guò)多精力，占總成本的510%例：實(shí)踐性大作業(yè)——3方面考慮：技術(shù)上----4～6學(xué)生,12周,電腦,開(kāi)發(fā)經(jīng)驗(yàn)，決心，風(fēng)險(xiǎn)（影響其它課程）......

社會(huì)上----產(chǎn)品有沒(méi)有人用

經(jīng)濟(jì)上----預(yù)算,盈利,...…8可行性研究的具體步驟1、確定項(xiàng)目規(guī)模和目標(biāo)，明確限制和約束。我們認(rèn)為用戶(hù)要的用戶(hù)要的2、研究老系統(tǒng)

解決老系統(tǒng)問(wèn)題老系統(tǒng)功能新增功能注：注意了解與其它系統(tǒng)的接口。

新系統(tǒng)效益老系統(tǒng)效益9可行性研究的具體步驟3、導(dǎo)出高層邏輯模型(conceptualdesign)…………抽象實(shí)現(xiàn)改進(jìn)老系統(tǒng)模型新模型新系統(tǒng)應(yīng)該告訴用戶(hù)“What”而不是“How”10可行性研究的具體步驟

3、邏輯模型4、復(fù)查和重新定義1、復(fù)查定義注：此時(shí)合同未簽，應(yīng)考慮成本，不宜反復(fù)太多次。5、導(dǎo)出和評(píng)價(jià)多種解法進(jìn)度表經(jīng)濟(jì)上合算技術(shù)上可行操作上可行技術(shù)上不可行用戶(hù)不可能操作不合算11可行性研究的具體步驟6、推薦行動(dòng)方針YesorNo?NoYesWhy?Whichoneisthebest?Why?(cost/benefit)8、審查、存檔7、編寫(xiě)可行性報(bào)告（開(kāi)發(fā)計(jì)劃）

任務(wù)分解，確定負(fù)責(zé)人

大致進(jìn)度規(guī)劃

財(cái)務(wù)預(yù)算

風(fēng)險(xiǎn)分析及對(duì)策粗略12文檔：可行性報(bào)告參考GB8567－88中的可行性研究報(bào)告，進(jìn)行適當(dāng)裁剪。13項(xiàng)目開(kāi)發(fā)計(jì)劃

是對(duì)開(kāi)發(fā)項(xiàng)目的費(fèi)用、時(shí)間、進(jìn)度、人員組織、硬件設(shè)備的配置、軟件開(kāi)發(fā)環(huán)境和運(yùn)行環(huán)境的配置等進(jìn)行說(shuō)明和規(guī)劃。是項(xiàng)目管理人員對(duì)項(xiàng)目進(jìn)行管理的依據(jù)，據(jù)此對(duì)項(xiàng)目的費(fèi)用、進(jìn)度和資源進(jìn)行控制和管理。工具：ProjectMicrosoftProject（或MSP）是由微軟開(kāi)發(fā)銷(xiāo)售的項(xiàng)目管理軟件程序。軟件設(shè)計(jì)目的在于協(xié)助項(xiàng)目經(jīng)理發(fā)展計(jì)劃、為任務(wù)分配資源、跟蹤進(jìn)度、管理預(yù)算和分析工作量。1415注意事項(xiàng)標(biāo)書(shū)：我國(guó)對(duì)軟件成本認(rèn)識(shí)不足困難：就是缺乏數(shù)據(jù)估計(jì)，導(dǎo)致估計(jì)不科學(xué)；應(yīng)根據(jù)項(xiàng)目復(fù)雜度、熟悉程度、規(guī)模等科學(xué)計(jì)劃。尤其在時(shí)間計(jì)劃上，要牢牢記住，人數(shù)與工作日不能簡(jiǎn)單互換。因?yàn)槿藛T的增加與流動(dòng)必然要增加培訓(xùn)、交流所占用的時(shí)間和資源，也就會(huì)影響項(xiàng)目的進(jìn)度，所以計(jì)劃時(shí)必須考慮。要留有緩沖時(shí)間，將緩沖時(shí)間用到不確定的事情上。

16軟件需求分析：“做什么？”

需求分析的過(guò)程是開(kāi)發(fā)人員與用戶(hù)共同協(xié)商，明確系統(tǒng)的全部功能、性能以及運(yùn)行規(guī)格，并且使用軟件開(kāi)發(fā)人員和用戶(hù)都能理解的語(yǔ)言準(zhǔn)確地表達(dá)出來(lái)，即完成需求規(guī)格說(shuō)明的過(guò)程。17軟件需求重要性例子

?“喂，是Jack嗎？我是人力資源部的Tom,我們?cè)谑褂媚憔帉?xiě)的職員系統(tǒng)時(shí)遇到一個(gè)問(wèn)題，一個(gè)職員想把她的名字改成SparkleStarlight,而系統(tǒng)不允許，你能幫幫忙嗎？”“她嫁給了一個(gè)姓Starlight的人嗎？”Jack問(wèn)道。?“不，她沒(méi)有結(jié)婚，而僅僅是要更改她的名字，”Tom回答，“就是這問(wèn)題，好象我們只能在婚姻狀況改變時(shí)才能更改姓名?！薄爱?dāng)然這樣，我從沒(méi)想到誰(shuí)會(huì)莫名其妙地更改姓名，我也不記得你曾告訴我系統(tǒng)需要處理這樣的事情。”Jack說(shuō)。?

Tom說(shuō)：“我想你當(dāng)然知道每個(gè)人只要愿意都可以隨時(shí)合法更改其姓名。但不管怎樣，你在本周五之前解決這問(wèn)題，否則Sparkle不能支付她的帳單?！薄斑@不是我的錯(cuò)！我現(xiàn)在正忙著做一個(gè)新的系統(tǒng)，還要做一些別的需求變更請(qǐng)求。很抱歉，只能下周才能修改。”……

18故事帶給我們的啟示……

影響：作為客戶(hù)，很惱火，因?yàn)檐浖到y(tǒng)不能進(jìn)行一項(xiàng)基本的操作。哪怕開(kāi)發(fā)者給其解決了，也不會(huì)感謝他。作為開(kāi)發(fā)者，也很煩人，迫使你增加了當(dāng)前的工作，又要你優(yōu)先處理。原因：由于收集、編寫(xiě)、協(xié)商、修改需求的過(guò)程中存在失誤造成的。解決辦法：重視需求分析，派經(jīng)驗(yàn)豐富的人員做，最大程度的減少類(lèi)似情況發(fā)生。19需求分析的特點(diǎn)老問(wèn)題：?問(wèn)題的復(fù)雜性?交流障礙（講究技巧和原則）?分析不完備性和不一致性?需求易變性（動(dòng)態(tài)性）派經(jīng)驗(yàn)豐富的人去干！系統(tǒng)分析員20軟件需求的任務(wù)

——理解、分解、表達(dá)、評(píng)審1.理解(問(wèn)題識(shí)別)：雙方確定問(wèn)題的綜合需求。?功能需求：系統(tǒng)必須做什么？

?性能需求 ：做得怎樣？例：responsetime,memory,back-upmemory,……?環(huán)境需求 ：運(yùn)行環(huán)境、軟硬件配置等。?用戶(hù)界面需求?可靠性、安全性、保密性、可移植性和可維護(hù)性等方面的需求。?將來(lái)可能提出的要求共同理解！21軟件需求的任務(wù)2.分解(分析與綜合):導(dǎo)出軟件的邏輯模型。對(duì)獲取的需求進(jìn)行一致性的分析檢查，在分析、綜合中逐步細(xì)化軟件功能，劃分成各個(gè)子功能。也對(duì)數(shù)據(jù)域進(jìn)行分解，分配到各個(gè)子功能上，并用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。22軟件需求的任務(wù)3.表達(dá)(編寫(xiě)文檔)：?編寫(xiě)需求說(shuō)明書(shū)

?編寫(xiě)初步用戶(hù)使用手冊(cè)?編寫(xiě)確認(rèn)測(cè)試計(jì)劃

?修改完善項(xiàng)目開(kāi)發(fā)計(jì)劃23需求文檔用戶(hù)需求報(bào)告需求規(guī)格說(shuō)明書(shū)對(duì)外的，驗(yàn)收依據(jù)對(duì)內(nèi)的，設(shè)計(jì)依據(jù)是合同的產(chǎn)物是立項(xiàng)建議書(shū)的產(chǎn)物由用戶(hù)需求報(bào)告可產(chǎn)生需求規(guī)格說(shuō)明書(shū)當(dāng)前系統(tǒng)，目標(biāo)系統(tǒng)目標(biāo)系統(tǒng)（數(shù)據(jù)字典，算法分析）24軟件需求的任務(wù)驗(yàn)證需求的一致性驗(yàn)證需求的完整性驗(yàn)證需求的現(xiàn)實(shí)性驗(yàn)證需求的有效性方法：

人工審查

開(kāi)發(fā)原型系統(tǒng)－探索型使用軟件工具

——完整性、一致性基線(xiàn)4.評(píng)審(技術(shù)審查和管理復(fù)審)25需求分析的方法結(jié)構(gòu)化分析方法：由數(shù)據(jù)流和數(shù)據(jù)字典構(gòu)成，適于數(shù)據(jù)處理領(lǐng)域問(wèn)題。該方法是對(duì)現(xiàn)實(shí)世界中的數(shù)據(jù)流進(jìn)行分析，把數(shù)據(jù)流映射到分析結(jié)果中。但該方法的一個(gè)難點(diǎn)是確定數(shù)據(jù)流之間的變換，而且數(shù)據(jù)字典的規(guī)模也是一個(gè)問(wèn)題，對(duì)數(shù)據(jù)結(jié)構(gòu)的強(qiáng)調(diào)很少。功能分解法：系統(tǒng)＝功能＋子功能＋功能接口。本質(zhì)是用過(guò)程抽象的觀點(diǎn)看待系統(tǒng)需求，很難與軟件設(shè)計(jì)明確分離?；c(diǎn)放在功能上，不穩(wěn)定，難以適用需求的變化。26需求分析的方法信息建模方法：從數(shù)據(jù)角度來(lái)對(duì)現(xiàn)實(shí)世界建模?；竟ぞ呤荅-R圖，數(shù)據(jù)不封閉，每個(gè)實(shí)體和它的屬性的處理需求不是組合在同一實(shí)體中，沒(méi)有繼承性和消息傳遞機(jī)制來(lái)支持模型。是面向?qū)ο蠓治龅幕A(chǔ)。面向?qū)ο蠓治龇ǎ翰捎昧藢?shí)體、關(guān)系和屬性等信息模型分析中的概念，同時(shí)采用了封閉、類(lèi)結(jié)構(gòu)和繼承性等面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言中的概念。27ER模型（Entity-RelationshipApproach）實(shí)體：客觀世界中存在且可相互區(qū)分的事物。用矩形框代表。聯(lián)系：事物間是有聯(lián)系的。(1:1、1:N、M:N)

用連接相關(guān)實(shí)體的菱形框表示。屬性：實(shí)體或聯(lián)系所具有的性質(zhì)。用橢圓形或圓角矩形表示。教師學(xué)生課程教學(xué)學(xué)號(hào)職稱(chēng)成績(jī)學(xué)分1NNM28注意事項(xiàng)在需求分析時(shí)要注意用戶(hù)對(duì)軟件開(kāi)發(fā)的了解程度。避免造成兩種極端認(rèn)識(shí)。需求的變動(dòng)或新增是一個(gè)極為普遍的問(wèn)題，既然普遍，所以軟件開(kāi)發(fā)人員不僅應(yīng)該在心理上接受這種變動(dòng)，還應(yīng)該在需求分析時(shí)積極的發(fā)掘需求。需求人員與用戶(hù)廣泛交流，從深度和廣度挖掘可能的需求，并應(yīng)形成規(guī)范的需求文檔，經(jīng)用戶(hù)確認(rèn)。如果為寫(xiě)文檔而寫(xiě)文檔，不進(jìn)行及時(shí)更新，甚至準(zhǔn)備在軟件開(kāi)發(fā)完成后再補(bǔ)文檔，這是絕對(duì)錯(cuò)誤的觀點(diǎn)。29可能錯(cuò)誤沒(méi)