軟件要求定義

軟件要求定義學(xué)習(xí)內(nèi)容可行性研究項目開發(fā)計劃軟件需求分析第2頁,共34頁，2024年2月25日，星期天項目來源合同：為別人做；立項：為自己做；失敗：無盈利－》賠錢－》聲譽(yù)影響－》官司失?。罕M賠錢－》公司倒閉－》東山再起難！學(xué)到的遠(yuǎn)比失去的多！

第3頁,共34頁，2024年2月25日，星期天可行性研究（

FeasibilityStudy）

可行性研究的目的就是用最小的代價在盡可能短的時間內(nèi)確定該軟件項目是否能夠開發(fā)，是否值得開發(fā)，最后給決策者提供做與不做的依據(jù)?？尚行匝芯繉嵸|(zhì)上是要進(jìn)行一次簡化、壓縮了的需求分析和設(shè)計過程，要在較高層次上以抽象的方式進(jìn)行需求分析和設(shè)計過程。第4頁,共34頁，2024年2月25日，星期天可行性研究的任務(wù)

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

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

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

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

F=P·(1+n·i)不計復(fù)利投資回收期：就是使累計的經(jīng)濟(jì)效益等于最初的投資費用所需的時間。純收入：就是在整個生存周期之內(nèi)的累計經(jīng)濟(jì)效益（折合成現(xiàn)在值）與投資之差。第7頁,共34頁，2024年2月25日，星期天提示不是解決問題，而是確定是否可解\值得解所以不要花過多精力，占總成本的510%例：實踐性大作業(yè)——3方面考慮：

技術(shù)上----2～3學(xué)生,7周,電腦,開發(fā)經(jīng)驗，決心，風(fēng)險（影響其它課程）......

社會上----產(chǎn)品有沒有人用

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

解決老系統(tǒng)問題老系統(tǒng)功能新增功能

注：

注意了解與其它系統(tǒng)的接口。

新系統(tǒng)效益老系統(tǒng)效益第9頁,共34頁，2024年2月25日，星期天可行性研究的具體步驟3、導(dǎo)出高層邏輯模型(conceptualdesign)…………抽象實現(xiàn)改進(jìn)老系統(tǒng)模型新模型新系統(tǒng)應(yīng)該告訴用戶“What”而不是“How”第10頁,共34頁，2024年2月25日，星期天系統(tǒng)流程圖（事務(wù)圖）高層邏輯模型第11頁,共34頁，2024年2月25日，星期天可行性研究的具體步驟

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

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

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

財務(wù)預(yù)算

風(fēng)險分析及對策粗略第13頁,共34頁，2024年2月25日，星期天文檔：可行性報告參考GB8567－88中的可行性研究報告，進(jìn)行適當(dāng)裁剪。第14頁,共34頁，2024年2月25日，星期天項目開發(fā)計劃

是對開發(fā)項目的費用、時間、進(jìn)度、人員組織、硬件設(shè)備的配置、軟件開發(fā)環(huán)境和運行環(huán)境的配置等進(jìn)行說明和規(guī)劃。是項目管理人員對項目進(jìn)行管理的依據(jù)，據(jù)此對項目的費用、進(jìn)度和資源進(jìn)行控制和管理。工具：Project第15頁,共34頁，2024年2月25日，星期天第16頁,共34頁，2024年2月25日，星期天注意事項標(biāo)書：我國對軟件成本認(rèn)識不足人月不能互換：需求的變更、人員的流動、環(huán)境的變化；困難：就是缺乏數(shù)據(jù)估計，導(dǎo)致估計不科學(xué)；估算項目復(fù)雜度（熟悉程度）、規(guī)模

第17頁,共34頁，2024年2月25日，星期天軟件需求分析：“做什么？”

需求分析的過程是開發(fā)人員與用戶共同協(xié)商，明確系統(tǒng)的全部功能、性能以及運行規(guī)格，并且使用軟件開發(fā)人員和用戶都能理解的語言準(zhǔn)確地表達(dá)出來，即完成需求規(guī)格說明的過程。第18頁,共34頁，2024年2月25日，星期天軟件需求重要性例子

?“喂，是Jack嗎？我是人力資源部的Tom,我們在使用你編寫的職員系統(tǒng)時遇到一個問題，一個職員想把她的名字改成SparkleStarlight,而系統(tǒng)不允許，你能幫幫忙嗎？”

“她嫁給了一個姓Starlight的人嗎？”Jack問道。?“不，她沒有結(jié)婚，而僅僅是要更改她的名字，”Tom回答，“就是這問題，好象我們只能在婚姻狀況改變時才能更改姓名。”

“當(dāng)然這樣，我從沒想到誰會莫名其妙地更改姓名，我也不記得你曾告訴我系統(tǒng)需要處理這樣的事情?！盝ack說。?

Tom說：“我想你當(dāng)然知道每個人只要愿意都可以隨時合法更改其姓名。但不管怎樣，你在本周五之前解決這問題，否則Sparkle不能支付她的帳單。”

“這不是我的錯！我現(xiàn)在正忙著做一個新的系統(tǒng)，還要做一些別的需求變更請求。很抱歉，只能下周才能修改?！薄?/p>

第19頁,共34頁，2024年2月25日，星期天故事帶給我們的啟示……

影響：作為客戶，很惱火，因為軟件系統(tǒng)不能進(jìn)行一項基本的操作。哪怕開發(fā)者給其解決了，也不會感謝他。作為開發(fā)者，也很煩人，迫使你增加了當(dāng)前的工作，又要你優(yōu)先處理。原因：由于收集、編寫、協(xié)商、修改需求過程的手續(xù)或方法失誤帶來的。這里是非正式信息的收集、未確定或不明確的功能、未發(fā)現(xiàn)或未經(jīng)交流的假設(shè)、不完善的需求文檔，以及突發(fā)的需求變更過程所造成的。解決辦法：重視需求分析，派經(jīng)驗豐富的人員做，最大程度的減少類似情況發(fā)生。第20頁,共34頁，2024年2月25日，星期天定值整定原則1：按與相鄰接地距離保護(hù)配合整定；原則2：按相鄰零序電流保護(hù)配合整定；1231與2配；1與3配；方案1：原則－>相鄰線方案2：相鄰線－>原則第21頁,共34頁，2024年2月25日，星期天需求分析的特點老問題：?問題的復(fù)雜性?交流障礙（講究技巧和原則）?不完備性和不一致性?需求易變性（動態(tài)性）派經(jīng)驗豐富的人去干！系統(tǒng)分析員第22頁,共34頁，2024年2月25日，星期天軟件需求的任務(wù)

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

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

?編寫初步用戶使用手冊?編寫確認(rèn)測試計劃

?修改完善項目開發(fā)計劃第25頁,共34頁，2024年2月25日，星期天需求文檔用戶需求報告需求規(guī)格說明書對外的，驗收依據(jù)對內(nèi)的，設(shè)計依據(jù)是合同的產(chǎn)物是立項建議書的產(chǎn)物由用戶需求報告可產(chǎn)生需求規(guī)格說明書當(dāng)前系統(tǒng)，目標(biāo)系統(tǒng)目標(biāo)系統(tǒng)（數(shù)據(jù)字典，算法分析）第26頁,共34頁，2024年2月25日，星期天軟件需求的任務(wù)驗證需求的一致性驗證需求的完整性驗證需求的現(xiàn)實性驗證需求的有效性方法：

人工審查

開發(fā)原型系統(tǒng)－探索型

使用軟件工具

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

用連接相關(guān)實體的菱形框表示。屬性：實體或聯(lián)系所具有的性質(zhì)。用橢圓形或圓角矩形表示。教師學(xué)生課程教學(xué)學(xué)號職稱成績學(xué)分1NNM第30頁,共34頁，2024年2月25日，星期天注意事項在需求分析時要注意用戶對軟件開發(fā)的了解程度。避免造成兩種極端認(rèn)識。需求的變動或新增是一個極為普遍的問題，既然普遍，所以軟件開發(fā)人員不僅應(yīng)該在心理上接受這種變動，還應(yīng)該在需求分析時積極的發(fā)掘需求。需求人員與用戶廣泛交流，從深度和廣度挖掘可能的需求，并應(yīng)形成規(guī)范的需求文檔，經(jīng)用戶確認(rèn)。如果為寫文檔而寫文檔，不進(jìn)行及時更新，甚至準(zhǔn)備在軟件開發(fā)完成后再補(bǔ)文檔，這是絕對錯誤的觀點。第31頁,共34頁，2024年2月25日，星期天可能錯誤沒有足夠用戶從參與（類型、數(shù)量）開發(fā)方與用戶溝通可能處于劣勢不要