軟件工程第三章 軟件要求定義

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

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

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

解決老系統(tǒng)問(wèn)題老系統(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ù)查定義注：此時(shí)合同未簽，應(yīng)考慮本錢(qián)，不宜反復(fù)太屢次。5、導(dǎo)出和評(píng)價(jià)多種解法進(jìn)度表經(jīng)濟(jì)上合算技術(shù)上可行操作上可行技術(shù)上不可行用戶不可能操作不合算13可行性研究的具體步驟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ì)策粗略14文檔：可行性報(bào)告

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

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

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

?“喂，是Jack嗎？我是人力資源部的Tom,我們?cè)谑褂媚憔帉?xiě)的職員系統(tǒng)時(shí)遇到一個(gè)問(wèn)題，一個(gè)職員想把她的名字改成SparkleStarlight,而系統(tǒng)不允許，你能幫幫助嗎？〞“她嫁給了一個(gè)姓Starlight的人嗎？〞Jack問(wèn)道。?“不，她沒(méi)有結(jié)婚，而僅僅是要更改她的名字，〞Tom答復(fù)，“就是這問(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)求。很抱歉，只能下周才能修改。〞……

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

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

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

人工審查

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

——完整性、一致性基線4.技術(shù)審查和管理復(fù)審28需求分析的方法結(jié)構(gòu)化分析方法：由數(shù)據(jù)流和數(shù)據(jù)字典構(gòu)成，適于數(shù)據(jù)處理領(lǐng)域問(wèn)題。但該方法的一個(gè)難點(diǎn)是確定數(shù)據(jù)流之間的變換，而且數(shù)據(jù)字典的規(guī)模也是一個(gè)問(wèn)題，對(duì)數(shù)據(jù)結(jié)構(gòu)的強(qiáng)調(diào)很少。功能分解法：系統(tǒng)＝功能＋子功能＋功能接口。過(guò)程抽象觀點(diǎn)，很難與軟件設(shè)計(jì)明確別離?；c(diǎn)放在功能上，不穩(wěn)定，難以適用需求的變化。29需求分析的方法信息建模方法：從數(shù)據(jù)角度來(lái)對(duì)現(xiàn)實(shí)世界建模。根本工具是E-R圖，數(shù)據(jù)不封閉，每個(gè)實(shí)體和它的屬性的處理需求不是組合在同一實(shí)體中，沒(méi)有繼承性和消息傳遞機(jī)制來(lái)支持模型。是面向?qū)ο蠓治龅母住Ｃ嫦驅(qū)ο蟮姆治觯翰捎昧藢?shí)體、關(guān)系和屬性等信息模型分析中的概念，同時(shí)采用了封閉、類結(jié)構(gòu)和繼承性等面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言中的概念。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é)號(hào)職稱成績(jī)學(xué)分1NNM31本卷須知在需求分析時(shí)要注意用戶對(duì)軟件開(kāi)發(fā)的了解程度。防止造成兩種極端認(rèn)識(shí)。需求的變動(dòng)或新增是一個(gè)極為普遍的問(wèn)題，既然普遍，所以軟件開(kāi)發(fā)人員不僅應(yīng)該在心理上接受這種變動(dòng)，還應(yīng)該在需求分析時(shí)積極的開(kāi)掘需求。需求人員與用戶廣泛交流，從深度和廣度挖掘可能的需求，并應(yīng)形成標(biāo)準(zhǔn)的需求文檔，經(jīng)用戶確認(rèn)。如果為寫(xiě)文檔而寫(xiě)文檔，不進(jìn)行及時(shí)更新，甚至準(zhǔn)備在軟件開(kāi)發(fā)完成后再補(bǔ)文檔，這是絕對(duì)錯(cuò)誤的觀點(diǎn)。32可能錯(cuò)誤沒(méi)有足夠用戶從參與〔類型、數(shù)量〕開(kāi)發(fā)方與用戶溝通可能處于劣勢(shì)不要錦上添花，畫(huà)蛇添足不要寫(xiě)的過(guò)于簡(jiǎn)練，過(guò)于模糊；方案需求的