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

4可行性研究〔FeasibilityStudy〕可行性研究的目的就是用最小的代價在盡可能短的時間內(nèi)確定該軟件工程是否能夠開發(fā)，是否值得開發(fā)，最后給決策者提供做與不做的依據(jù)。

可行性研究實(shí)質(zhì)上是要進(jìn)行一次簡化、壓縮了的需求分析和設(shè)計過程，要在較高層次上以抽象的方式進(jìn)行需求分析和設(shè)計過程。5可行性研究的任務(wù)首先需要進(jìn)行概要的分析研究，初步確定工程的規(guī)模和目標(biāo)，確定工程的約束和限制。然后進(jìn)行簡要的需求分析，抽象出該工程的邏輯結(jié)構(gòu)，建立邏輯模型。最后從邏輯模型出發(fā)，經(jīng)過壓縮的設(shè)計，探索出假設(shè)干種可供選擇的主要解決方法，對每種解決方法都要從以下三方面研究它的可行性。技術(shù)可行性經(jīng)濟(jì)可行性社會可行性6技術(shù)可行性在現(xiàn)有資源條件下，工程能否實(shí)現(xiàn)，風(fēng)險有多大〔技術(shù)、資源是否成熟〕。社會可行性是否存在侵權(quán)、軟件操作方式是否適合用戶所在組織、現(xiàn)有管理制度、人員素質(zhì)是否可行？7經(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ì)效益等于最初的投資費(fèi)用所需的時間。純收入：就是在整個生存周期之內(nèi)的累計經(jīng)濟(jì)效益〔折合成現(xiàn)在值〕與投資之差。8提示不是解決問題，而是確定是否可解\值得解所以不要花過多精力，占總本錢的510%例：實(shí)踐性大作業(yè)——3方面考慮：技術(shù)上----2～3學(xué)生,7周,電腦,開發(fā)經(jīng)驗(yàn)，決心，風(fēng)險〔影響其它課程〕......社會上----產(chǎn)品有沒有人用經(jīng)濟(jì)上----預(yù)算,盈利,...…9可行性研究的具體步驟1、確定工程規(guī)模和目標(biāo)，明確限制和約束。我們認(rèn)為用戶要的用戶要的2、研究老系統(tǒng)

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

新系統(tǒng)效益

老系統(tǒng)效益10可行性研究的具體步驟3、導(dǎo)出高層邏輯模型(conceptualdesign)…………抽象實(shí)現(xiàn)改進(jìn)老系統(tǒng)模型新模型新系統(tǒng)應(yīng)該告訴用戶“What〞而不是“How〞11系統(tǒng)流程圖〔事務(wù)圖〕高層邏輯模型12可行性研究的具體步驟3、邏輯模型4、復(fù)查和重新定義1、復(fù)查定義注：此時合同未簽，應(yīng)考慮本錢，不宜反復(fù)太屢次。5、導(dǎo)出和評價多種解法進(jìn)度表經(jīng)濟(jì)上合算技術(shù)上可行操作上可行技術(shù)上不可行用戶不可能操作不合算13可行性研究的具體步驟6、推薦行動方針YesorNo?NoYesWhy?Whichoneisthebest?Why?(cost/benefit)8、審查、存檔7、編寫可行性報告（開發(fā)計劃）

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

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

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

風(fēng)險分析及對策粗略14文檔：可行性報告

參考GB8567－88中的可行性研究報告，進(jìn)行適當(dāng)裁剪。15工程開發(fā)方案是對開發(fā)工程的費(fèi)用、時間、進(jìn)度、人員組織、硬件設(shè)備的配置、軟件開發(fā)環(huán)境和運(yùn)行環(huán)境的配置等進(jìn)行說明和規(guī)劃。是工程管理人員對工程進(jìn)行管理的依據(jù)，據(jù)此對工程的費(fèi)用、進(jìn)度和資源進(jìn)行控制和管理。工具：Project1617本卷須知標(biāo)書：我國對軟件本錢認(rèn)識缺乏人月不能互換：需求的變更、人員的流動、環(huán)境的變化；困難：就是缺乏數(shù)據(jù)估計，導(dǎo)致估計不科學(xué)；估算工程復(fù)雜度〔熟悉程度〕、規(guī)模

18軟件需求分析：“做什么？〞

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

?“喂，是Jack嗎？我是人力資源部的Tom,我們在使用你編寫的職員系統(tǒng)時遇到一個問題，一個職員想把她的名字改成SparkleStarlight,而系統(tǒng)不允許，你能幫幫助嗎？〞“她嫁給了一個姓Starlight的人嗎？〞Jack問道。?“不，她沒有結(jié)婚，而僅僅是要更改她的名字，〞Tom答復(fù)，“就是這問題，好象我們只能在婚姻狀況改變時才能更改姓名。〞“當(dāng)然這樣，我從沒想到誰會莫名其妙地更改姓名，我也不記得你曾告訴我系統(tǒng)需要處理這樣的事情。〞Jack說。?Tom說：“我想你當(dāng)然知道每個人只要愿意都可以隨時合法更改其姓名。但不管怎樣，你在本周五之前解決這問題，否那么Sparkle不能支付她的帳單。〞“這不是我的錯！我現(xiàn)在正忙著做一個新的系統(tǒng)，還要做一些別的需求變更請求。很抱歉，只能下周才能修改。〞……

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

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

——理解、分解、表達(dá)、評審whf:劃分系統(tǒng)所有1.問題識別：雙方確定問題的綜合需求。?功能需求：系統(tǒng)必須做什么？ ?性能需求 ：做得怎樣？例：responsetime,memory,back-upmemory,……?環(huán)境需求 ：運(yùn)行環(huán)境、軟硬件配置等。?用戶界面需求?可靠性、平安性、保密性、可移植性和可維護(hù)性等方面的需求。?將來可能提出的要求共同理解！24軟件需求的任務(wù)2.分析與綜合:導(dǎo)出軟件的邏輯模型。對獲取的需求進(jìn)行一致性的分析檢查，在分析、綜合中逐步細(xì)化軟件功能，劃分成各個子功能。也對數(shù)據(jù)域進(jìn)行分解，分配到各個子功能上，并用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。25軟件需求的任務(wù)3.編寫文檔：?編寫需求說明書 ?編寫初步用戶使用手冊?編寫確認(rèn)測試方案?修改完善工程開發(fā)方案26需求文檔用戶需求報告需求規(guī)格說明書對外的，驗(yàn)收依據(jù)對內(nèi)的，設(shè)計依據(jù)是合同的產(chǎn)物是立項(xiàng)建議書的產(chǎn)物由用戶需求報告可產(chǎn)生需求規(guī)格說明書當(dāng)前系統(tǒng)，目標(biāo)系統(tǒng)目標(biāo)系統(tǒng)（數(shù)據(jù)字典，算法分析）27軟件需求的任務(wù)驗(yàn)證需求的一致性驗(yàn)證需求的完整性驗(yàn)證需求的現(xiàn)實(shí)性驗(yàn)證需求的有效性方法：

人工審查

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

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

用連接相關(guān)實(shí)體的菱形框表示。屬性：實(shí)體或聯(lián)系所具有的性質(zhì)。用橢圓形或圓角矩形表示。教師學(xué)生課程教學(xué)學(xué)號職稱成績學(xué)分1NNM31本卷須知在需求分析時要注意用戶對軟件開發(fā)的了解程度。防止造成兩種極端認(rèn)識。需求的變動或新增是一個極為普遍的問題，既然普遍，所以軟件開發(fā)人員不僅應(yīng)該在心理上接受這種變動，還應(yīng)該在需求分析時積極的開掘需求。需求人員與用戶廣泛交流，從深度和廣度挖掘可能的需求，并應(yīng)形成標(biāo)準(zhǔn)的需求文檔，經(jīng)用戶確認(rèn)。如果為寫文檔而寫文檔，不進(jìn)行及時更新，甚至準(zhǔn)備在軟件開發(fā)完成后再補(bǔ)文檔，這是絕對錯誤的觀點(diǎn)。32可能錯誤沒有足夠用戶從參與〔類型、數(shù)量〕開發(fā)方與用戶溝通可能處于劣勢不要錦上添花，畫蛇添足不要寫的過于簡練，過于模糊；方案需求的