第一篇：軟件人才的崗位需求分析與求職技巧

軟件人才崗位需求與生涯規(guī)劃

軟件人才崗位需求與生涯規(guī)劃

主講人：印度國(guó)家信息學(xué)院（NIIT）中國(guó)區(qū)高級(jí)市場(chǎng)經(jīng)理 江一峰

主講人介紹：江一峰，男，先后在北大青鳥、印度國(guó)家信息學(xué)院（NIIT）從事管理工作，具有十多年IT行業(yè)從業(yè)經(jīng)驗(yàn)，現(xiàn)任印度國(guó)家信息學(xué)院（NIIT）中國(guó)區(qū)高級(jí)市場(chǎng)經(jīng)理。參加人：計(jì)算機(jī)專業(yè)學(xué)生

主要內(nèi)容：軟件人才的崗位需求分析與求職技巧

第一部分：軟件人才崗位職責(zé)與崗位需求

一． 初級(jí)程序員/軟件測(cè)試員：根據(jù)程序規(guī)格說(shuō)明書，開發(fā)指定模塊的代碼，需要掌握精通某一種開發(fā)語(yǔ)言，如java/.net；需要熟悉某種數(shù)據(jù)庫(kù)；需要有測(cè)試自己代碼的能力，會(huì)寫技術(shù)文檔。月薪：1800-3800

二． 中級(jí)程序員：做部分模塊的設(shè)計(jì)工作，也做一些初級(jí)程序員/軟件測(cè)試員的工作。3800--5800

三． 高級(jí)程序員/系統(tǒng)設(shè)計(jì)師：主要負(fù)責(zé)一個(gè)系統(tǒng)的許多模塊的設(shè)計(jì)工作，然后知道初級(jí)程序員/軟件測(cè)試員做好他們的工作。5800-8000

四． 系統(tǒng)分析員：和客戶溝通，收集客戶的需求信息，制訂軟件需求規(guī)格說(shuō)明書，交付給系統(tǒng)設(shè)計(jì)師，讓他們?cè)O(shè)計(jì)模塊。8000-13000

五． 項(xiàng)目小組長(zhǎng)/項(xiàng)目經(jīng)理：負(fù)責(zé)整個(gè)項(xiàng)目的時(shí)間管理，進(jìn)度管理，質(zhì)量管理和成本管理。

六． 系統(tǒng)架夠師：負(fù)責(zé)一個(gè)大型項(xiàng)目的技術(shù)選型，比如選擇什么樣的軟件開發(fā)工具，什么樣的架夠去實(shí)現(xiàn)這個(gè)系統(tǒng)，他相當(dāng)于繪制藍(lán)圖的總工程師。13000—未知數(shù)

第二部分：IT職場(chǎng)新人求職的“三種素質(zhì)”和“三個(gè)能力”

一、雖然IT業(yè)招聘需求居于榜首，可知名IT公司門檻頗高，等閑之輩不能進(jìn)入。職場(chǎng)新人，特別是應(yīng)屆畢業(yè)生要進(jìn)入名企工作，需要符合哪些要求呢？

從微軟跳槽到Google的李開復(fù)的見解，雖然不能當(dāng)作IT人才選拔的普遍標(biāo)準(zhǔn)，不過(guò)多少代表了部分跨國(guó)公司的擇才傾向，新人從中可得到一些啟示。

1、正直誠(chéng)信，恪守職業(yè)道德。

李開復(fù)認(rèn)為，“才能高并不代表給公司的回報(bào)也高，人品有問題的人，往往是才能越高，帶給公司的災(zāi)難也更大”。比如有的應(yīng)聘者表示能提供原公司產(chǎn)品的核心技術(shù)，這樣的員工肯定不被錄取。李開復(fù)就曾用“你如何犧牲個(gè)人而讓團(tuán)隊(duì)獲勝”這個(gè)問題來(lái)考察人品。

2、不要求對(duì)語(yǔ)言、平臺(tái)的掌握，更看重對(duì)算法的理解。

很多IT企業(yè)要求應(yīng)聘者掌握計(jì)算機(jī)語(yǔ)言和諸多平臺(tái)的操作技能，而李開復(fù)則看重對(duì)算法的理解，他說(shuō)對(duì)IT技術(shù)的理解，比如對(duì)算法的理解，對(duì)架構(gòu)的掌

主講人：印度國(guó)家信息學(xué)院（NIIT）中國(guó)區(qū)高級(jí)市場(chǎng)經(jīng)理 江一峰

主講人介紹：江一峰，男，先后在北大青鳥、印度國(guó)家信息學(xué)院（NIIT）從事管理工作，具有十多年IT行業(yè)從業(yè)經(jīng)驗(yàn)，現(xiàn)任印度國(guó)家信息學(xué)院（NIIT）中國(guó)區(qū)高級(jí)市場(chǎng)經(jīng)理。參加人：計(jì)算機(jī)專業(yè)學(xué)生

主要內(nèi)容：軟件人才的崗位需求分析與求職技巧

第一部分：軟件人才崗位職責(zé)與崗位需求

一． 初級(jí)程序員/軟件測(cè)試員：根據(jù)程序規(guī)格說(shuō)明書，開發(fā)指定模塊的代碼，需要掌握精通某一種開發(fā)語(yǔ)言，如java/.net；需要熟悉某種數(shù)據(jù)庫(kù)；需要有測(cè)試自己代碼的能力，會(huì)寫技術(shù)文檔。月薪：1800-3800

二． 中級(jí)程序員：做部分模塊的設(shè)計(jì)工作，也做一些初級(jí)程序員/軟件測(cè)試員的工作。3800--5800

三． 高級(jí)程序員/系統(tǒng)設(shè)計(jì)師：主要負(fù)責(zé)一個(gè)系統(tǒng)的許多模塊的設(shè)計(jì)工作，然

后知道初級(jí)程序員/軟件測(cè)試員做好他們的工作。5800-8000

四． 系統(tǒng)分析員：和客戶溝通，收集客戶的需求信息，制訂軟件需求規(guī)格說(shuō)

明書，交付給系統(tǒng)設(shè)計(jì)師，讓他們?cè)O(shè)計(jì)模塊。8000-13000

五． 項(xiàng)目小組長(zhǎng)/項(xiàng)目經(jīng)理：負(fù)責(zé)整個(gè)項(xiàng)目的時(shí)間管理，進(jìn)度管理，質(zhì)量管理

和成本管理。

六． 系統(tǒng)架夠師：負(fù)責(zé)一個(gè)大型項(xiàng)目的技術(shù)選型，比如選擇什么樣的軟件開

發(fā)工具，什么樣的架夠去實(shí)現(xiàn)這個(gè)系統(tǒng)，他相當(dāng)于繪制藍(lán)圖的總工程師。13000—未知數(shù)

第二部分：IT職場(chǎng)新人求職的“三種素質(zhì)”和“三個(gè)能力”

一、雖然IT業(yè)招聘需求居于榜首，可知名IT公司門檻頗高，等閑之輩不能進(jìn)入。職場(chǎng)新人，特別是應(yīng)屆畢業(yè)生要進(jìn)入名企工作，需要符合哪些要求呢？

從微軟跳槽到Google的李開復(fù)的見解，雖然不能當(dāng)作IT人才選拔的普遍標(biāo)準(zhǔn)，不過(guò)多少代表了部分跨國(guó)公司的擇才傾向，新人從中可得到一些啟示。

1、正直誠(chéng)信，恪守職業(yè)道德。

李開復(fù)認(rèn)為，“才能高并不代表給公司的回報(bào)也高，人品有問題的人，往往是才能越高，帶給公司的災(zāi)難也更大”。比如有的應(yīng)聘者表示能提供原公司產(chǎn)品的核心技術(shù)，這樣的員工肯定不被錄取。李開復(fù)就曾用“你如何犧牲個(gè)人而讓團(tuán)隊(duì)獲勝”這個(gè)問題來(lái)考察人品。

2、不要求對(duì)語(yǔ)言、平臺(tái)的掌握，更看重對(duì)算法的理解。

很多IT企業(yè)要求應(yīng)聘者掌握計(jì)算機(jī)語(yǔ)言和諸多平臺(tái)的操作技能，而李開復(fù)則看重對(duì)算法的理解，他說(shuō)對(duì)IT技術(shù)的理解，比如對(duì)算法的理解，對(duì)架構(gòu)的掌握等，從某種程度決定了能在專業(yè)道路上走多遠(yuǎn)。他要尋找的是有“做改變世界的工程師”夢(mèng)想、渴望找到自我提升的舞臺(tái)、對(duì)IT業(yè)有認(rèn)識(shí)和感情的年輕人，而

不僅僅是把IT作為謀生手段的計(jì)算機(jī)專業(yè)畢業(yè)生。他不在乎招聘的人會(huì)不會(huì)某種語(yǔ)言或系統(tǒng)，不在乎是否“數(shù)學(xué)很棒”，因?yàn)檫@些都是可學(xué)習(xí)的。

3、看重潛力而不看重過(guò)去的成績(jī)。

李開復(fù)不要求應(yīng)聘者有多么優(yōu)秀的過(guò)去，只看重應(yīng)聘者的溝通能力、思維方式、理解能力等可挖掘的潛力。

二、進(jìn)入行業(yè)后，發(fā)展困惑會(huì)接踵而來(lái)。一方面，高新技術(shù)的蓬勃興起、知識(shí)的爆炸式增長(zhǎng)要求IT人在沉重的工作負(fù)荷之外，還需永無(wú)止境地充電更新；另一方面，無(wú)數(shù)優(yōu)秀員工同臺(tái)競(jìng)技，如何脫穎而出成了很多人的煩惱?？射J職業(yè)顧問劉方對(duì)IT從業(yè)者的現(xiàn)狀進(jìn)行了專門調(diào)查，她指出，IT人要發(fā)展，必須走出“從技術(shù)到技術(shù)”的怪圈，關(guān)注三方面的成長(zhǎng)：

1、提升表達(dá)溝通能力。據(jù)調(diào)查，中國(guó)IT從業(yè)者中有64.3%的人每天面對(duì)電腦的時(shí)間在8小時(shí)以上，因此大多數(shù)人像個(gè)編碼“機(jī)器”，只專注于技術(shù)領(lǐng)域的工作，缺少人與人之間的溝通交流。但企業(yè)方表示，他們看重的員工不一定要在技術(shù)上有超強(qiáng)能力，但一定要掌握溝通協(xié)調(diào)技巧，善于聽取客戶的意見和反饋，做好上傳下達(dá)工作，這樣才有可能被提拔，坐上管理者的位子。因此IT人不妨多鍛煉自己的溝通技能，在人際交往上活躍一些。

2、加強(qiáng)團(tuán)隊(duì)合作精神。國(guó)內(nèi)IT人才注重凸顯個(gè)人能力，缺乏必要的團(tuán)隊(duì)合作能力以及目標(biāo)管理能力。然而很多項(xiàng)目都需要依靠團(tuán)隊(duì)的力量，再優(yōu)秀的“單兵”也很難獨(dú)立作戰(zhàn)，更不用說(shuō)成為一名優(yōu)秀的管理者和領(lǐng)導(dǎo)者了。只有接受團(tuán)隊(duì)合作這樣的企業(yè)文化和行業(yè)核心價(jià)值理念，才能走得更遠(yuǎn)。

3、增強(qiáng)工作主動(dòng)性和參與性。無(wú)論是軟件開發(fā)還是項(xiàng)目管理，國(guó)內(nèi)員工大多只是做好份內(nèi)事或完成交派任務(wù)，很少能主動(dòng)發(fā)現(xiàn)問題。其實(shí)，只有擁有更高眼界，才能謀取大發(fā)展。當(dāng)唐駿還是微軟一名普通程序員時(shí)，就從公司發(fā)展的角度考慮，向老板提議開發(fā)了中文版windows，最終使他從幾萬(wàn)名工程師中脫穎而出，成為部門經(jīng)理。正如他所說(shuō)，“雖然是程序員，但自己不能只把自己當(dāng)程序員，你可以為老板和公司著想。調(diào)查研究后，帶著解決方案去找老板，就會(huì)得到老板的重視和信任?！?/p>

第三：職業(yè)規(guī)劃與職業(yè)前景

隨著IT業(yè)的逐漸成熟，業(yè)內(nèi)人員結(jié)構(gòu)呈現(xiàn)出“兩極分化”局面。一方面，底層操作人員供大于求；另一方面，精通外語(yǔ)、經(jīng)驗(yàn)豐富的技術(shù)總監(jiān)或項(xiàng)目經(jīng)理，以及有技術(shù)背景的銷售經(jīng)理等人才高薪難覓。而大批工作多年的IT人普遍感覺到，隨著年齡增長(zhǎng)，在學(xué)習(xí)能力、反應(yīng)速度、工作效率上漸漸和年輕人拉開距離，競(jìng)爭(zhēng)力在削弱。如何沖破瓶頸，成為市場(chǎng)緊缺的高薪IT人才？職業(yè)顧問劉方提出兩點(diǎn)建議：

1、趁早做好職業(yè)規(guī)劃。一般做了5－8年技術(shù)類工作的員工，會(huì)逐步形成固定封閉的思維模式和工作風(fēng)格，再考慮轉(zhuǎn)型就會(huì)困難許多。這類人員可以向銷售、IT培訓(xùn)、項(xiàng)目管理、管理等幾個(gè)方向轉(zhuǎn)型，建議優(yōu)秀的年輕技術(shù)人員盡早規(guī)劃，有意識(shí)地逐步向目標(biāo)崗位靠攏。

2、有意識(shí)提升管理能力。獵頭表示，國(guó)內(nèi)缺乏的是管理能力和專業(yè)知識(shí)技能并駕齊驅(qū)的IT人才。掌握核心技術(shù)又有全局掌控能力的項(xiàng)目管理人才，特別是懂得運(yùn)用目標(biāo)管理技術(shù)的項(xiàng)目管理人才非常難找；職業(yè)顧問表示，IT界優(yōu)秀的管理者都必須懂技術(shù)，掌握核心技能的人才向管理崗位轉(zhuǎn)型有優(yōu)勢(shì)，因而提升管理能力成了轉(zhuǎn)型關(guān)鍵。他們可以從純技術(shù)崗位，逐步向技術(shù)測(cè)試、售前/后技術(shù)支持等開放式崗位過(guò)渡，最后成為一名項(xiàng)目管理者；一名優(yōu)秀的項(xiàng)目經(jīng)理有機(jī)會(huì)向高層進(jìn)一步發(fā)展。

第二篇：軟件需求-案例分析

1、問題描述

許多醫(yī)院存在高峰期掛號(hào)排隊(duì)時(shí)間長(zhǎng)，就診等待時(shí)間長(zhǎng)，倒號(hào)現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個(gè)網(wǎng)上預(yù)約掛號(hào)系統(tǒng)，通過(guò)推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時(shí)間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對(duì)系統(tǒng)進(jìn)行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、該系統(tǒng)所涉及的用戶

本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類。而且該三類用戶各自的特征和所要面對(duì)的情景也是截然不同的。

對(duì)于患者來(lái)說(shuō)，他們?cè)谀挲g、計(jì)算機(jī)使用能力等方面存在較大差異，但面對(duì)的情景都一樣，就是要預(yù)約掛號(hào)，掛號(hào)成功過(guò)后就診。

對(duì)于醫(yī)生來(lái)說(shuō)，普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識(shí)，有一定的計(jì)算機(jī)使用能力。所面對(duì)的情景有查看掛號(hào)信息，確定要就診的病人。

對(duì)于管理員來(lái)說(shuō)，他們負(fù)責(zé)對(duì)出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。

不同的用戶，對(duì)系統(tǒng)的要求也不相同?；颊呦Ｍㄟ^(guò)完成注冊(cè)和登錄后能夠進(jìn)行掛號(hào)預(yù)約，查詢醫(yī)生的出診信息和個(gè)人預(yù)約信息，并且能夠在規(guī)定的時(shí)間內(nèi)完成掛號(hào)預(yù)約或者取消已有的預(yù)約；醫(yī)生則希望能夠在登錄系統(tǒng)后可以查看病人的預(yù)約情況；而管理員希望可以修改出診信息和調(diào)整預(yù)約掛號(hào)。這些都是功能性的需求。

同時(shí)對(duì)于所有用戶都希望該系統(tǒng)是易用的，而且能夠?qū)ψ约旱男畔⑵鸬奖Ｗo(hù)即系統(tǒng)安全性的要求，還有比如說(shuō)系統(tǒng)的性能比較高效，能夠及時(shí)處理自己的預(yù)約申請(qǐng)。當(dāng)然開發(fā)系統(tǒng)的成本如果也能較低就更好了。這些都是非功能需求。

2.2、情景描述的主要成分

? 目標(biāo)和關(guān)鍵成功因素

預(yù)約掛號(hào)情景的目標(biāo)是“讓患者能夠及時(shí)的掛號(hào)，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊(cè)賬號(hào)，患者能夠登錄賬號(hào)，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查詢出診信息。關(guān)鍵成功因素，要保證系統(tǒng)能夠24小時(shí)正常穩(wěn)定的運(yùn)行，系統(tǒng)里的信息要是實(shí)時(shí)變化的，即可以預(yù)約的醫(yī)生要和實(shí)際在值班的醫(yī)生要匹配，不能出現(xiàn)掛上號(hào)了卻沒有醫(yī)生就診的情況。

? 物理上下文和邏輯上下文 物理上下文：醫(yī)院用于掛號(hào)的計(jì)算機(jī)可以正常的使用，情景中的可以被預(yù)約的醫(yī)生應(yīng)該是在醫(yī)院值班的；而對(duì)于患者可以選擇在醫(yī)院進(jìn)行預(yù)約，也可選擇在家中進(jìn)行預(yù)約，只要在預(yù)約時(shí)間內(nèi)能到達(dá)醫(yī)院就可。邏輯上下文：事件發(fā)生的條件是患者在系統(tǒng)中進(jìn)行了預(yù)約，然后管理員會(huì)根據(jù)現(xiàn)有的資源（可以預(yù)約的醫(yī)生）對(duì)預(yù)約進(jìn)行處理，如果同意，下一步就是醫(yī)生就診；如果沒有可以預(yù)約的醫(yī)生或合適的時(shí)間，患者的預(yù)約就不成功，患者需要重新選擇醫(yī)生或時(shí)間進(jìn)行預(yù)約。

? 組成情景的主要事件和活動(dòng) 主要事件：患者預(yù)約掛號(hào)，管理員對(duì)預(yù)約掛號(hào)的處理，醫(yī)生就診。主要活動(dòng)：患者注冊(cè)、登錄系統(tǒng)，患者在系統(tǒng)中查詢可以預(yù)約的醫(yī)生和時(shí)間，患者取消已有預(yù)約，患者進(jìn)行就診；管理員接受或拒絕預(yù)約，管理員分配醫(yī)生；醫(yī)生查詢預(yù)約信息。

? 涉及的執(zhí)行者和其他參與者

執(zhí)行者：醫(yī)院的醫(yī)生，預(yù)約掛號(hào)系統(tǒng)的管理員。其他參與者：醫(yī)院的相關(guān)人員，比如患者，前臺(tái)咨詢員等。

? 要使用的信息和資源 要使用的信息和資源包括，可以預(yù)約的醫(yī)生數(shù)量，所在科室等，醫(yī)院中的設(shè)備，病房等。? 要考慮的約束條件和要使用的規(guī)則 約束條件：同一醫(yī)生同一時(shí)間段內(nèi)只能接受一名患者的預(yù)約，根據(jù)醫(yī)療設(shè)備的屬性決定是否要排他性的使用。

3、情景需求分析的步驟

需求規(guī)格說(shuō)明輸入過(guò)程需求目標(biāo)列表1.目標(biāo)分析系統(tǒng)模型目標(biāo),目的使用情景用戶問題實(shí)例2.輸入事件分析初始系統(tǒng)模型用戶,環(huán)境事件情景腳本4.輸出需求分析3.刻畫系統(tǒng)輸出情景結(jié)構(gòu)模型系統(tǒng)輸出類型信息需求5.社會(huì)影響分析Agent目標(biāo)6.涉眾分析需求規(guī)格說(shuō)明

3.1 目標(biāo)分析

在第2部分情景描述的主要成分中已經(jīng)對(duì)目標(biāo)進(jìn)行了分析，即：預(yù)約掛號(hào)情景的目標(biāo)是“讓患者能夠及時(shí)的掛號(hào)，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊(cè)賬號(hào)，患者能夠登錄賬號(hào)，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查詢出診信息。3.2 輸入事件分析

對(duì)于該系統(tǒng)的輸入事件可能會(huì)包括如下情況：初始使用該系統(tǒng)的用戶需要先注冊(cè)，而對(duì)于已經(jīng)注冊(cè)的用戶在使用系統(tǒng)預(yù)約掛號(hào)時(shí)首先要登錄系統(tǒng)。這是最基本的兩個(gè)輸入事件。3.3 刻畫系統(tǒng)輸出

對(duì)于系統(tǒng)輸出我們要考慮系統(tǒng)輸出的形式，比如消息顯示，對(duì)話框等形式。不如用戶在登錄系統(tǒng)是輸入的用戶名和密碼不匹配的時(shí)候要給出對(duì)應(yīng)的提示信息，比如用戶名未注冊(cè)或密碼不對(duì)等。在提交預(yù)約掛號(hào)申請(qǐng)后系統(tǒng)也應(yīng)給出預(yù)約成功與否的提示。3.4輸出需求分析

對(duì)于輸出需求要根據(jù)用戶的輸入給出對(duì)應(yīng)的輸出。比如用戶輸入查詢請(qǐng)求，那么系統(tǒng)應(yīng)該能夠給出詳細(xì)的信息。系統(tǒng)只給出對(duì)應(yīng)的輸出還不夠，同時(shí)要考慮輸出的信息是否合適。比如用戶要查詢眼科醫(yī)生的資料，系統(tǒng)的輸出就應(yīng)該只是眼科醫(yī)生的信息，而沒有必要把所有醫(yī)生的信息都輸出。3.5 社會(huì)影響分析

在進(jìn)行社會(huì)影響分析時(shí)要同時(shí)考慮到積極和消極兩個(gè)方面的問題。系統(tǒng)是否可以提高效率，減少人員的工作量。同時(shí)也要考慮過(guò)多的自動(dòng)化是否會(huì)削弱人對(duì)整個(gè)系統(tǒng)的意識(shí)，導(dǎo)致人對(duì)意外處理的能力降低，比如系統(tǒng)臨時(shí)出現(xiàn)問題，是否有一套應(yīng)急措施使醫(yī)院日常工作能夠正常的進(jìn)行。

4、需求說(shuō)明文檔

基于之前構(gòu)建的模型，并參照IEEE 830-1998標(biāo)準(zhǔn)模板，撰寫的系統(tǒng)需求說(shuō)明文檔如下。

4.1 引言

引言部分將對(duì)本文檔的編寫目的、系統(tǒng)的開發(fā)目的、名詞定義以及參考資料進(jìn)行說(shuō)明，并對(duì)文檔的后續(xù)內(nèi)容進(jìn)行概述。4.1.1 編寫目的

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)是基于Web開發(fā)技術(shù)完成的網(wǎng)站。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對(duì)系統(tǒng)進(jìn)行需求建模和分析是十分必要的。因此，基于之前構(gòu)建的各類模型，撰寫系統(tǒng)的需求說(shuō)明文檔，并將其作為后續(xù)項(xiàng)目設(shè)計(jì)、項(xiàng)目開發(fā)和項(xiàng)目測(cè)試的指導(dǎo)。

本文檔連同之前構(gòu)建的模型，可用來(lái)與客戶進(jìn)一步明確需求，同時(shí)可供項(xiàng)目經(jīng)理、設(shè)計(jì)人員、開發(fā)人員參考。4.1.2 系統(tǒng)目的

許多醫(yī)院存在高峰期掛號(hào)排隊(duì)時(shí)間長(zhǎng)，就診等待時(shí)間長(zhǎng)，倒號(hào)現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個(gè)網(wǎng)上預(yù)約掛號(hào)系統(tǒng)，通過(guò)推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時(shí)間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。4.1.3 名詞定義 ? 患者預(yù)約系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于為患者提供預(yù)約掛號(hào)、信息查詢等功能。? 醫(yī)生工作查詢系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于為醫(yī)生提供各時(shí)段預(yù)約患者的信息。? 醫(yī)務(wù)管理系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于為管理員提供出診信息修改、預(yù)約掛號(hào)調(diào)整等功能。? 賬號(hào)控制系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于用戶賬號(hào)的注冊(cè)及登錄控制。? 安全保障系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于保障系統(tǒng)的程序、網(wǎng)絡(luò)及數(shù)據(jù)庫(kù)安全。4.1.4 參考資料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吳雙兵,劉偉.網(wǎng)上預(yù)約掛號(hào)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].醫(yī)學(xué)信息學(xué)雜志, 2015, 36(1):36-39.4.1.5 文檔概述

需求說(shuō)明文檔主要分為三個(gè)部分。本節(jié)屬于引言部分，主要用于對(duì)文檔本身進(jìn)行定義和描述。文檔的第二部分為系統(tǒng)的整體描述，包括系統(tǒng)的預(yù)期目標(biāo)、限制條件以及用戶的需求、特征。文檔的第三部分是需求說(shuō)明，包含對(duì)系統(tǒng)需求的明確定義。

4.2 整體描述

本節(jié)將對(duì)系統(tǒng)預(yù)期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進(jìn)行說(shuō)明。

4.2.1 系統(tǒng)預(yù)期

為了方便用戶在不需安裝任何軟件的情況下使用系統(tǒng)，本系統(tǒng)整體采用B/S結(jié)構(gòu)，用戶可以通過(guò)瀏覽器對(duì)其進(jìn)行訪問。4.2.2 用戶需求

參照之前完成的目標(biāo)模型，對(duì)用戶的需求進(jìn)行整理和定義。由于系統(tǒng)整體較為復(fù)雜，因此本小節(jié)只包含已構(gòu)建目標(biāo)模型的功能性需求和非功能性需求。? 功能性需求

1.患者進(jìn)行預(yù)約選擇

為了實(shí)現(xiàn)患者進(jìn)行預(yù)約選擇的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有患者預(yù)約頁(yè)面以及預(yù)約按鈕：

系統(tǒng)的預(yù)約頁(yè)面可以顯示未來(lái)1至3天的出診醫(yī)生及其所有可被預(yù)約的出診時(shí)段。其中，尚未被預(yù)約的時(shí)段擁有預(yù)約按鈕；已被預(yù)約的時(shí)段無(wú)法被其他患者預(yù)約，因此無(wú)預(yù)約按鈕。（2）系統(tǒng)接收到預(yù)約請(qǐng)求：

當(dāng)患者點(diǎn)擊預(yù)約按鈕，系統(tǒng)可以接收到預(yù)約請(qǐng)求。（3）患者被告知預(yù)約選擇結(jié)果：

系統(tǒng)可以對(duì)患者是否預(yù)約成功進(jìn)行判定，如果成功則跳轉(zhuǎn)至信息確認(rèn)頁(yè)面，否則彈出對(duì)話框給予患者相應(yīng)提示。2.患者確認(rèn)預(yù)約信息

為了實(shí)現(xiàn)患者確認(rèn)預(yù)約信息的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有預(yù)約信息確認(rèn)頁(yè)面以及預(yù)約提交按鈕：

系統(tǒng)的預(yù)約信息確認(rèn)頁(yè)面會(huì)顯示預(yù)約的醫(yī)生和時(shí)段，患者的個(gè)人信息，以及預(yù)約提交按鈕，患者可以在提交預(yù)約前核對(duì)這些信息。（2）系統(tǒng)接收到預(yù)約提交請(qǐng)求：

當(dāng)患者點(diǎn)擊提交按鈕，系統(tǒng)可以接收到預(yù)約提交請(qǐng)求。（3）患者被告知預(yù)約提交結(jié)果：

系統(tǒng)可以對(duì)預(yù)約是否提交成功進(jìn)行判定，并彈出對(duì)話框給予患者相應(yīng)提示。? 非功能性需求 1.安全的系統(tǒng)

為了保證預(yù)約掛號(hào)系統(tǒng)的安全性，系統(tǒng)應(yīng)完成的需求如下。（1）用戶程序安全：

系統(tǒng)應(yīng)明確區(qū)分不同類別用戶的權(quán)限。并且在用戶登錄時(shí)，輸入的密碼不可見、不可復(fù)制。（2）系統(tǒng)網(wǎng)絡(luò)安全：

系統(tǒng)應(yīng)采取安全的網(wǎng)絡(luò)傳輸協(xié)議，網(wǎng)絡(luò)數(shù)據(jù)在被傳輸前應(yīng)進(jìn)行加密。（3）數(shù)據(jù)庫(kù)安全：

數(shù)據(jù)庫(kù)中存儲(chǔ)的數(shù)據(jù)應(yīng)具備完整性，且密碼應(yīng)在加密后被存儲(chǔ)到數(shù)據(jù)庫(kù)中。此外，數(shù)據(jù)庫(kù)中的數(shù)據(jù)應(yīng)該可以被備份和恢復(fù)。2.低成本的系統(tǒng) 為了保證預(yù)約掛號(hào)系統(tǒng)的低成本，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)開發(fā)成本低：

開發(fā)團(tuán)隊(duì)?wèi)?yīng)具備合理的項(xiàng)目管理，且在開發(fā)前應(yīng)盡可能明確系統(tǒng)的需求。（2）系統(tǒng)運(yùn)營(yíng)成本低：

系統(tǒng)在運(yùn)行過(guò)程中，應(yīng)該盡可能少的占用資源。（3）系統(tǒng)維護(hù)成本低：

系統(tǒng)應(yīng)該健壯可靠，出現(xiàn)問題后應(yīng)該易于修復(fù)，且系統(tǒng)的功能應(yīng)該易于擴(kuò)展?？紤]到系統(tǒng)健壯可靠與系統(tǒng)開發(fā)成本低存在一定的沖突，因此需要進(jìn)行一定的權(quán)衡。4.2.3 用戶特征

本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類，其特征如下。? 患者

個(gè)體間在年齡、計(jì)算機(jī)使用能力等方面存在較大差異。? 醫(yī)生

普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識(shí)，有一定的計(jì)算機(jī)使用能力。? 管理員

負(fù)責(zé)對(duì)出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。4.2.4 條件與限制

為了保證系統(tǒng)的可移植性和可擴(kuò)展性，本系統(tǒng)應(yīng)使用Java語(yǔ)言進(jìn)行開發(fā)。4.2.5 假定與依賴

本系統(tǒng)假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統(tǒng)的引導(dǎo)和提示下正常使用系統(tǒng)。4.2.6 需求分配

由于文檔中并未列出系統(tǒng)的全部需求，因此無(wú)法對(duì)所有需求進(jìn)行優(yōu)先級(jí)排序。但已經(jīng)列出的均為系統(tǒng)較為核心的功能性需求和非功能性需求，應(yīng)具有高優(yōu)先級(jí)。

4.3 需求說(shuō)明

需求說(shuō)明部分將參照之前完成的模型，對(duì)系統(tǒng)結(jié)構(gòu)、對(duì)象模型以及操作過(guò)程模型進(jìn)行詳細(xì)描述。

4.3.1 系統(tǒng)結(jié)構(gòu)

本部分將主要參照?qǐng)D 3-1所示的責(zé)任模型，根據(jù)主體對(duì)需求進(jìn)行劃分?？紤]到系統(tǒng)較為復(fù)雜，因此只列出主體“患者預(yù)約系統(tǒng)”的相關(guān)需求。? 患者預(yù)約系統(tǒng)

系統(tǒng)擁有患者預(yù)約頁(yè)面以及預(yù)約按鈕。

系統(tǒng)接收到預(yù)約請(qǐng)求。

患者被告知預(yù)約選擇結(jié)果。

系統(tǒng)擁有預(yù)約信息確認(rèn)頁(yè)面及預(yù)約提交按鈕。

系統(tǒng)接收到預(yù)約提交請(qǐng)求。

患者被告知預(yù)約提交的結(jié)果。4.3.2 對(duì)象模型

本部分將主要對(duì)圖 4-1所示的對(duì)象模型的結(jié)構(gòu)進(jìn)行解釋。

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)可以被詳細(xì)劃分為患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)、賬號(hào)控制系統(tǒng)、安全保障系統(tǒng)等五個(gè)子系統(tǒng)?；颊哳A(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)的使用者分別為患者、醫(yī)生和管理員，這些用戶通過(guò)系統(tǒng)提供的頁(yè)面與系統(tǒng)進(jìn)行交互。

對(duì)象模型中所涉及的名詞在4.1.3小節(jié)中有具體解釋。4.3.3 操作過(guò)程模型

本部分將主要對(duì)圖 5-1，圖 5-3和圖 5-4所示的操作過(guò)程模型進(jìn)行說(shuō)明，并以表格的形式列出各操作過(guò)程的參與主體及對(duì)應(yīng)需求。? 患者進(jìn)行預(yù)約選擇

患者點(diǎn)擊預(yù)約按鈕后，患者預(yù)約系統(tǒng)會(huì)收到患者的預(yù)約請(qǐng)求，并觸發(fā)預(yù)約驗(yàn)證操作，得到預(yù)約驗(yàn)證結(jié)果。接下來(lái)，患者預(yù)約系統(tǒng)會(huì)以得出的預(yù)約結(jié)果為基礎(chǔ)，進(jìn)行預(yù)約結(jié)果判定，進(jìn)而執(zhí)行頁(yè)面跳轉(zhuǎn)或消息框彈出操作。? 患者確認(rèn)預(yù)約信息

患者點(diǎn)擊提交按鈕后，患者預(yù)約系統(tǒng)會(huì)收到患者的預(yù)約提交請(qǐng)求，并觸發(fā)預(yù)約提交操作。接下來(lái)，患者預(yù)約系統(tǒng)會(huì)根據(jù)提交結(jié)果彈出包含相應(yīng)信息的提示框。

以上部分涉及到的操作過(guò)程及與之對(duì)應(yīng)的主體、需求如下表所示。

以上部分涉及到的操作過(guò)程及與之對(duì)應(yīng)的主體、需求如表 4-1所示。

操作 預(yù)約驗(yàn)證 參與主體

對(duì)應(yīng)需求

患者預(yù)約系統(tǒng) 系統(tǒng)接收到預(yù)約請(qǐng)求，患者被告知預(yù)約選擇結(jié)果

預(yù)約結(jié)果判定 患者預(yù)約系統(tǒng) 患者被告知預(yù)約選擇結(jié)果 預(yù)約提交 患者預(yù)約系統(tǒng) 系統(tǒng)接收到預(yù)約提交請(qǐng)求，患者被告知預(yù)約提交結(jié)果

第三篇：軟件需求分析報(bào)告

軟件需求分析

軟件需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的限制和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其它有效性需求。進(jìn)行需求分析時(shí)，應(yīng)注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想象，并盡量將分析進(jìn)度提交給用戶。在不進(jìn)行直接指導(dǎo)的前提下，讓用戶進(jìn)行檢查與評(píng)價(jià)。從而達(dá)到需求分析的準(zhǔn)確性。分析員通過(guò)需求分析，逐步細(xì)化對(duì)軟件的要求，描述軟件要處理的數(shù)據(jù)域，并給軟件開發(fā)提供一種可轉(zhuǎn)化為數(shù)據(jù)設(shè)計(jì)、結(jié)構(gòu)設(shè)計(jì)和過(guò)程設(shè)計(jì)的數(shù)據(jù)和功能表示。在軟件完成后，制定的軟件規(guī)格說(shuō)明還要為評(píng)價(jià)軟件質(zhì)量提供依據(jù)。

需求分析的任務(wù)

開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開發(fā)什么。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò)，將最終會(huì)給系統(tǒng)帶來(lái)極大損害的部分，并且以后再對(duì)它進(jìn)行修改也極為困難。目前，國(guó)內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個(gè)系統(tǒng)并立運(yùn)行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。對(duì)于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個(gè)大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對(duì)于我們開發(fā)人員來(lái)說(shuō)，并沒有編寫出客戶認(rèn)可的需求文檔，我們?nèi)绾沃理?xiàng)目于何時(shí)結(jié)束？而如果我們不知道什么對(duì)客戶來(lái)說(shuō)是重要的，那我們又如何能使客戶感到滿意呢？然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫(kù)、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當(dāng)然你可能偶爾勿需文檔說(shuō)明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過(guò)重寫一份需求文檔的代價(jià)，這些血的教訓(xùn)正在國(guó)內(nèi)的軟件開發(fā)者身上發(fā)生。近來(lái)，我遇到一個(gè)開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計(jì)算機(jī)輔助軟件。不幸的是，當(dāng)他們開發(fā)完這個(gè)工具后，發(fā)現(xiàn)這個(gè)工具不能打印出源代碼文件，使用者當(dāng)然希望有這個(gè)功能。結(jié)果這個(gè)小組只好手工抄寫源代碼文檔以供代碼檢查。這說(shuō)明那怕需求明確無(wú)誤并構(gòu)思準(zhǔn)確，如果我們沒有編寫文檔，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了。相反的情況，我曾見一個(gè)要集成到“錯(cuò)誤跟蹤系統(tǒng)”中的簡(jiǎn)單界面寫了一頁(yè)需求說(shuō)明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時(shí)發(fā)現(xiàn)簡(jiǎn)單的一張需求清單竟是如此有用。他們依據(jù)需求對(duì)系統(tǒng)進(jìn)行測(cè)試時(shí)，此系統(tǒng)不僅非常清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯(cuò)誤。事實(shí)上，需求文檔在開發(fā)過(guò)程中一直起指導(dǎo)作用。需求的類型

下面這些定義是需求工程領(lǐng)域中常見術(shù)語(yǔ)的定義。軟件需求包括三個(gè)不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。1．業(yè)務(wù)需求（business requirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說(shuō)明。2．用戶需求(user requirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本說(shuō)明中予以說(shuō)明。3．功能需求(functional requirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。在軟件需求規(guī)格說(shuō)明書（SRS）中說(shuō)明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說(shuō)明在開發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對(duì)一個(gè)大型系統(tǒng)來(lái)說(shuō)，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）。作為功能需求的補(bǔ)充，軟件需求規(guī)格說(shuō)明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過(guò)多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反

映產(chǎn)品功能。多角度描述產(chǎn)品對(duì)用戶和開發(fā)人員都極為重要。下面以一個(gè)字處理程序?yàn)槔齺?lái)說(shuō)明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”，該產(chǎn)品的包裝盒封面上可能會(huì)標(biāo)明這是個(gè)滿足業(yè)務(wù)需求的拼寫檢查器。而對(duì)應(yīng)的用戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過(guò)一個(gè)提供的替換項(xiàng)列表來(lái)供選擇替換拼錯(cuò)的詞”。同時(shí)，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯(cuò)詞的操作；顯示提供替換詞的對(duì)話框以及實(shí)現(xiàn)整個(gè)文檔范圍的替換。從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測(cè)試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說(shuō)明你究竟想開發(fā)什么。項(xiàng)目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。

第四篇：軟件測(cè)試需求分析與定義方法

軟件測(cè)試需求分析與定義方法

如何確定測(cè)試工作的范圍？

對(duì)于一個(gè)存在生命周期的軟件產(chǎn)品來(lái)說(shuō)，它的開發(fā)和測(cè)試往往都不是一次性的，因?yàn)殡S著新的需求的出現(xiàn)，以及對(duì)原有版本的改進(jìn)，新的版本會(huì)不斷的發(fā)布（即使對(duì)于一些以客戶定制方式運(yùn)作的項(xiàng)目，在開發(fā)過(guò)程中以及發(fā)布后的維護(hù)期內(nèi)，也會(huì)產(chǎn)生眾多的內(nèi)部版本）。隨著版本的迭代，我們的測(cè)試工作也會(huì)一直繼續(xù)下去。而在每一次迭代時(shí)，可能在整個(gè)工作階段的開始就受到一些因素的影響，比如市場(chǎng)需求、既定的發(fā)布時(shí)間、并發(fā)的工作導(dǎo)致的資源緊張等等，使我們不得不考慮對(duì)軟件質(zhì)量要求的適度，最終使得我們?cè)诿總€(gè)階段的測(cè)試工作的要求或者說(shuō)所涉及到的內(nèi)容有可能是不同的。這種變化，最終將會(huì)影響到測(cè)試需求的確定。那么到底該如何確定每次迭代是測(cè)試工作的范圍呢？在筆者的實(shí)踐中，通常把測(cè)試工作范圍的確定，等價(jià)的認(rèn)為是軟件需求的確定。

不過(guò)現(xiàn)在有一個(gè)很實(shí)際的問題是這樣：軟件需求在開發(fā)過(guò)程中不斷發(fā)生變化，有時(shí)候到了后期還會(huì)有新的需求添加進(jìn)來(lái)，還有些需求在交付內(nèi)部測(cè)試版本之后又發(fā)現(xiàn)原來(lái)的需求本身就存在缺陷，之后再次返工，在軟件最終發(fā)布之前，怎么可能確定的下來(lái)呢。啊，這些都是讓我們的開發(fā)人員和測(cè)試人員極其頭痛的事情。到底應(yīng)該怎樣在頻繁變更的需求中確定哪些部分是我們?cè)谀硞€(gè)階段要測(cè)試的內(nèi)容呢？或者說(shuō)通過(guò)什么樣的方法可以改善我們上面提到的那些問題呢？一個(gè)實(shí)際的做法就是實(shí)現(xiàn)軟件需求的版本化控制。（用軟件需求的版本化控制來(lái)解決軟件需求的頻繁變更）既然說(shuō)到了這里，就不免要說(shuō)些題外話。筆者一直都認(rèn)為軟件需求是開發(fā)工作和測(cè)試工作在制定計(jì)劃、開展工作時(shí)所共同參照的源頭和依據(jù)，而我們只有在源頭上控制好，才能保證下面工作的平穩(wěn)開展。如果希望某個(gè)階段工作的進(jìn)度和內(nèi)容可以明確的定義下來(lái)，就必須要考慮軟件需求的版本化控制。這里所提到的“軟件需求的版本化控制”，是指在一個(gè)軟件產(chǎn)品的生命周期中，當(dāng)要進(jìn)行一個(gè)新版本的迭代時(shí)，要盡早的確定這個(gè)版本中將要實(shí)現(xiàn)的需求，并同上個(gè)版本做出比較，哪些內(nèi)容是新增的，哪些內(nèi)容是被調(diào)整過(guò)的。在該階段工作開始之初的工作會(huì)議上，明確的向所有需要了解軟件需求的涉眾傳達(dá)這部分信息。而如果在該版本的開發(fā)過(guò)程中不斷的出現(xiàn)需求變更的情況，則應(yīng)該根據(jù)市場(chǎng)策略、已公布的發(fā)布時(shí)間、客戶需求、實(shí)現(xiàn)的代價(jià)、難易程度以及對(duì)現(xiàn)有工作的影響等方面，對(duì)需求進(jìn)行適度劃分，嚴(yán)格定義當(dāng)前版本中需要實(shí)現(xiàn)的需求，而其他部分，則作為未來(lái)版本的軟件需求進(jìn)行考慮。如果有的朋友認(rèn)為上面的內(nèi)容還是太理論化，需要一個(gè)更實(shí)際的、可操作的方法。那么只能說(shuō)，對(duì)于需求的變更，以及因?yàn)樾枨笞兏鸬脑O(shè)計(jì)的變更，必須要早發(fā)現(xiàn)，早討論，早決定，早調(diào)整。這可能更多的要依靠一個(gè)團(tuán)隊(duì)中相關(guān)負(fù)責(zé)人員的主動(dòng)工作來(lái)保證，而不是依靠一個(gè)明確的方法。注意，這里的一個(gè)關(guān)鍵是，對(duì)于軟件需求，同樣需要嚴(yán)格按照版本進(jìn)行管理，或者說(shuō)使用“基線”進(jìn)行管理。如何整理測(cè)試需求？一旦當(dāng)前階段測(cè)試工作的范圍確定下來(lái)，我們就可以開始考慮測(cè)試需求的整理——也就是明確的定義現(xiàn)階段要“測(cè)什么”。測(cè)試需求的確定將為我們制定進(jìn)度時(shí)間表、分配資源以及如何確定某個(gè)階段測(cè)試工作是否完成提供一個(gè)可供衡量的標(biāo)準(zhǔn)。當(dāng)然，還有更重要的一點(diǎn)，已被確定的測(cè)試需求是我們進(jìn)行測(cè)試用例設(shè)計(jì)和考慮測(cè)試覆蓋的依據(jù)。整理測(cè)試需求的第一步，就是要“測(cè)試需求”。測(cè)試需求？對(duì)，不知道您是否想到，這里的“測(cè)試需求”中的“測(cè)試”是一個(gè)動(dòng)詞，指的是對(duì)軟件需求本身的檢查。

??？這不是已經(jīng)超出了測(cè)試工作的范圍了嗎？測(cè)試人員不是應(yīng)該只關(guān)心軟件的實(shí)現(xiàn)同需求是否相符嗎？這樣對(duì)測(cè)試人員要求未免太高了?！@是筆者過(guò)去同一些朋友談到測(cè)試人員必須對(duì)需求進(jìn)行檢查時(shí)聽到的一些不同的聲音。在這里，首先要明確一個(gè)問題，就是軟件測(cè)試的工作到底做什么？

在《軟件測(cè)試》（Ron Patton〔美〕，中文版由機(jī)械工業(yè)出版社出版，這本書是測(cè)試新手入門的經(jīng)典教材）一書的第10頁(yè)，有一個(gè)明確而簡(jiǎn)潔的定義：軟件測(cè)試員的目標(biāo)是找到軟件缺陷，盡可能早一些，并確保其得以修復(fù)。

瞧！這里說(shuō)要“盡可能早”的“找到軟件缺陷”。那這“盡可能早”要早到什么時(shí)候呢？

不知道大家對(duì)《軟件工程》這本書還有什么印象。至少在筆者看過(guò)的多個(gè)不同版本的軟件工程方面的書中，對(duì)于軟件缺陷都會(huì)有一段類似的描述：缺陷發(fā)現(xiàn)的越早，則修復(fù)這個(gè)缺陷的代價(jià)就越小，在需求、設(shè)計(jì)、編碼、測(cè)試、發(fā)布等不同的階段，發(fā)現(xiàn)缺陷后修復(fù)的代價(jià)都會(huì)比在前一個(gè)階段修復(fù)的代價(jià)提高10倍（參見下圖）。這樣看來(lái)，上面問題的答案自然就變成了“禿子頭上的虱子”：從需求階段開始！從“測(cè)試需求”開始！

注意，筆者這里的觀點(diǎn)并不是說(shuō)可以取消團(tuán)隊(duì)中的“需求評(píng)審會(huì)議”，這里并不存在沖突。筆者所希望講述的，是測(cè)試人員應(yīng)該如何看待軟件需求，而并不是把“需求評(píng)審會(huì)議”所承擔(dān)的責(zé)任攬到自己身上。?在論壇上也偶爾看到有的朋友問：如何測(cè)試需求呢？每次看到這樣的提問，筆者內(nèi)心就禁不住的一陣激動(dòng)，因?yàn)橐恢币詠?lái)，討論這方面問題的朋友的確少之又少。

在筆者的實(shí)際工作中，對(duì)軟件需求的檢查包括兩個(gè)方面的內(nèi)容。

一是對(duì)軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內(nèi)容是真實(shí)可靠的。在進(jìn)行這部分工作時(shí)，不要迷信所謂的“都是用戶提出的真實(shí)的需求”，因?yàn)槲覀儽仨毧紤]，提出這些需求的涉眾，是否真的可以正確的描述自己的需求？我們的需求人員是否真的可以正確的理解用戶的需求？有沒有一些被用戶認(rèn)為在業(yè)務(wù)處理上是理所當(dāng)然、極其平常的事情，而沒有作為需求提出來(lái)？有沒有一些被用戶認(rèn)為他們過(guò)去使用的軟件已經(jīng)提供了相應(yīng)的功能，所以認(rèn)為我們也應(yīng)當(dāng)提供，而沒有提出來(lái)的？關(guān)于這個(gè)問題，也曾經(jīng)有朋友提過(guò)不同的看法，認(rèn)為這樣對(duì)測(cè)試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業(yè)的業(yè)務(wù)。但筆者還是固執(zhí)的認(rèn)為，作為測(cè)試人員，還是需要對(duì)軟件產(chǎn)品所涉及的行業(yè)的業(yè)務(wù)有一個(gè)全面的、深入的了解——當(dāng)然，這不是對(duì)一個(gè)剛剛?cè)腴T的測(cè)試者的要求，但是如果想稱為一個(gè)優(yōu)秀的測(cè)試者，是難免要付出這部分努力的。

二是要保證軟件需求的可測(cè)試性。對(duì)于“可測(cè)試性”，筆者的概念是：對(duì)于一條軟件需求或者一個(gè)需要實(shí)現(xiàn)的特性，必須存在一個(gè)可以明確預(yù)知的結(jié)果，并且可以通過(guò)設(shè)計(jì)一個(gè)可以重復(fù)的過(guò)程來(lái)對(duì)這個(gè)明確的結(jié)果進(jìn)行驗(yàn)證。說(shuō)的具體一點(diǎn)，就是要保證所有的需要實(shí)現(xiàn)的需求都是可以用某種方法來(lái)明確的判斷是否符合需求文檔中的描述。如果對(duì)于某條需求或某個(gè)特性，無(wú)法通過(guò)一個(gè)明確的方法來(lái)進(jìn)行驗(yàn)證，或者無(wú)法預(yù)知它的結(jié)果，那么就意味著這條需求的描述存在缺陷，應(yīng)該請(qǐng)需求人員對(duì)需求文檔進(jìn)行修改或補(bǔ)充——我們有理由相信，如果作為測(cè)試人員對(duì)需求無(wú)法產(chǎn)生準(zhǔn)確的理解，那么開發(fā)人員也同樣無(wú)法對(duì)同一條需求產(chǎn)生準(zhǔn)確的理解。對(duì)于一條確定的軟件需求理解的二義性，是在不規(guī)范的開發(fā)過(guò)程中導(dǎo)致返工的一個(gè)主要原因。如果認(rèn)為有必要，那應(yīng)該在“需求評(píng)審會(huì)議”上確認(rèn)所有涉眾對(duì)需求的理解是一致的。當(dāng)然，對(duì)于如何提高軟件需求的質(zhì)量，在網(wǎng)絡(luò)上或者已經(jīng)出版的書刊中都已經(jīng)有了很多更加具體、實(shí)用的方法，如果有興趣，大家也可以找來(lái)參考。不過(guò)，如果您是一位測(cè)試者，那么上面這部分內(nèi)容對(duì)您仍然是非常有用的。相信您只要在工作中進(jìn)行嘗試，慢慢的體會(huì)，一定會(huì)發(fā)現(xiàn)這種方法給您帶來(lái)的好處。?現(xiàn)在當(dāng)前的測(cè)試工作范圍已經(jīng)確定，相應(yīng)版本的軟件需求也通過(guò)了評(píng)審，我們就可以在這個(gè)已經(jīng)確定的范圍內(nèi)進(jìn)行測(cè)試需求的整理。我們手頭上可以參考的東西，通常會(huì)有軟件需求規(guī)約（以下簡(jiǎn)稱SRS）和用例（以下簡(jiǎn)稱UC）——當(dāng)然，也可能是一份包含UC的SRS。通過(guò)對(duì)SRS和UC的閱讀，我們可以從文檔對(duì)特性和業(yè)務(wù)流程的描述中獲得對(duì)軟件所涉及的業(yè)務(wù)的一個(gè)基本的認(rèn)識(shí)。比如用戶在處理實(shí)際業(yè)務(wù)時(shí)都要作些什么，多個(gè)業(yè)務(wù)之間的先后順序是怎樣的，用戶在處理業(yè)務(wù)是對(duì)于哪些地方有特別的要求，等等。這部分規(guī)則，將成為我們的測(cè)試需求中最基本的一部分。

至于測(cè)試需求的表現(xiàn)形式，筆者認(rèn)為大家都可以根據(jù)自己的需要進(jìn)行設(shè)計(jì)，而沒有必要把思路限制在到底使用表格方式還是使用文本方式，只要把握一個(gè)原則就行了：在一條測(cè)試需求中，用容易理解的自然語(yǔ)言，明確的描述一項(xiàng)需要測(cè)試的內(nèi)容。對(duì)于多項(xiàng)測(cè)試內(nèi)容，應(yīng)盡可能的剝離開來(lái)，保證一條測(cè)試需求只包含一項(xiàng)測(cè)試內(nèi)容。

另外，大家也可能注意到了，在軟件開發(fā)過(guò)程的這個(gè)階段，通常是沒有用戶界面（以下簡(jiǎn)稱UI）可供參考的——雖然RUP中對(duì)于需求階段的工作描述包括了UI設(shè)計(jì)的部分，但很多時(shí)候在這個(gè)階段還是無(wú)法提供一個(gè)確定的UI的——也就是說(shuō)我們這時(shí)獲得的測(cè)試需求，將是完全基于業(yè)務(wù)的，而并不包括基于UI的那部分規(guī)則，是同軟件的最終具體實(shí)現(xiàn)相獨(dú)立的。

隨著開發(fā)工作的繼續(xù)，開發(fā)部門的架構(gòu)設(shè)計(jì)文檔和詳細(xì)設(shè)計(jì)文檔也將陸續(xù)提交，這時(shí)候，我們可以根據(jù)設(shè)計(jì)文檔來(lái)對(duì)已有的測(cè)試需求進(jìn)行增補(bǔ)。注意，這里我們對(duì)于設(shè)計(jì)文檔中提到的內(nèi)容要有選擇的采用，只有同SRS或UC中已經(jīng)定義的部分相符的內(nèi)容，才可以用來(lái)調(diào)整我們的測(cè)試需求。而同軟件需求不相符的部分，則需要同設(shè)計(jì)人員和需求人員一起討論，確定下以哪一方作為基準(zhǔn)，決定是否需要調(diào)整軟件需求，然后對(duì)測(cè)試需求進(jìn)行相應(yīng)的增補(bǔ)或者調(diào)整。比如對(duì)于一些算法，需要考慮設(shè)計(jì)文檔中定義的，同系統(tǒng)實(shí)現(xiàn)相關(guān)的那些計(jì)算公式，是否同軟件需求中描述的算法表達(dá)的是否是同一個(gè)意思？而對(duì)于一些約束或者業(yè)務(wù)規(guī)則，設(shè)計(jì)文檔中描述的是否同需求中的相應(yīng)部分一致？呵呵，看完上面這部分內(nèi)容，恐怕又有一部分朋友暈倒在地了，而沒有暈倒的那部分朋友也要提出異議：??？！你這不是又包含了對(duì)開發(fā)人員所作的設(shè)計(jì)工作的檢查嗎？！剛剛讓我們檢查需求，現(xiàn)在又讓我們檢查設(shè)計(jì)，真的把我們當(dāng)成全才了！沒辦法，為了讓軟件交到我們手上的時(shí)候只包含盡量少的缺陷，大家只能再辛苦一下了。我們的工作不應(yīng)當(dāng)僅僅限制在軟件交付后盡力找到存在的缺陷，而更應(yīng)該努力及早發(fā)現(xiàn)軟件缺陷出現(xiàn)的苗頭，盡量預(yù)防缺陷的出現(xiàn)。雖然并不是說(shuō)在所有的團(tuán)隊(duì)中都應(yīng)該由測(cè)試人員承擔(dān)“測(cè)試需求”和“測(cè)試設(shè)計(jì)”的工作，但是測(cè)試人員對(duì)這些工作起到的作用，是其他團(tuán)隊(duì)中的其他角色所無(wú)法替代的。開發(fā)部門完成編碼實(shí)現(xiàn)工作，提交供內(nèi)部測(cè)試的應(yīng)用程序時(shí)，測(cè)試人員手頭上應(yīng)該已經(jīng)準(zhǔn)備好了絕大部分測(cè)試用例和測(cè)試數(shù)據(jù)，測(cè)試部門將開始執(zhí)行測(cè)試。通常在我們執(zhí)行測(cè)試的過(guò)程中，即使我們已經(jīng)從“通過(guò)測(cè)試”和“失敗測(cè)試”兩個(gè)不同的角度準(zhǔn)備了非常充分的測(cè)試用例和測(cè)試數(shù)據(jù)，但總是有些缺陷的出現(xiàn)是出乎我們意料的，或者說(shuō)是已有的測(cè)試需求和測(cè)試用例未能覆蓋的。那么，對(duì)于這部分缺陷，也應(yīng)當(dāng)添加到測(cè)試需求中，并設(shè)計(jì)相應(yīng)的測(cè)試用例，以便于下次版本迭代時(shí)進(jìn)行參考。OK，相信說(shuō)到這里，各位看客也應(yīng)該可以理解我的觀點(diǎn)了：對(duì)于一個(gè)長(zhǎng)期發(fā)展的團(tuán)隊(duì)或者持續(xù)開發(fā)的產(chǎn)品，它的所有東西都是要不斷積累的、不斷迭代的。無(wú)論對(duì)于軟件需求還是測(cè)試需求，不僅僅是在一個(gè)版本的開發(fā)過(guò)程中，在不同的階段進(jìn)行迭代，在產(chǎn)品的整個(gè)生命周期中的不同版本間，也是不斷迭代和積累的。

第五篇：軟件需求分析考試資料

1、需求分析的最終結(jié)果是需求規(guī)格說(shuō)明書。

2、需求分析中開發(fā)人員要從用戶那里解決的最重要的問題是讓軟件做什么。

3、需求規(guī)格說(shuō)明書中的內(nèi)容不應(yīng)該包括對(duì)算法的詳細(xì)過(guò)程的描述。

4、需求規(guī)格說(shuō)明書的作用不應(yīng)包括軟件可行性研究的依據(jù)。

5、關(guān)于面向?qū)ο蠓椒ㄖ邢⒌臄⑹?，不正確的是操作系統(tǒng)不斷向應(yīng)用程序發(fā)送消息，但應(yīng)

用程序不能向操作系統(tǒng)發(fā)送消息。

6、面向?qū)ο蠹夹g(shù)中，對(duì)象是類的實(shí)例，對(duì)象有三種成分標(biāo)識(shí)、屬性、方法（或操作）

7、軟件需求分析階段的工作，可以分成以下四個(gè)方面對(duì)問題的識(shí)別、分析與綜合、制定規(guī)

格說(shuō)明以及需求分析評(píng)審。

8、軟件需求規(guī)格說(shuō)明書的內(nèi)容不應(yīng)該包括對(duì)算法的詳細(xì)過(guò)程的描述。

9、產(chǎn)品特性可以稱為質(zhì)量屬性，在眾多質(zhì)量屬性，對(duì)于開發(fā)人員來(lái)說(shuō)重要的屬性有哪些？

可維護(hù)性、可移植性、可重用性、可測(cè)試性

10、求包括11個(gè)方面的內(nèi)容，其中網(wǎng)絡(luò)和操作系統(tǒng)的要求屬于環(huán)境需求，如何隔離用戶之間的數(shù)據(jù)屬于安全保密需求，執(zhí)行速度、相應(yīng)時(shí)間及吞吐量屬于性能需求，規(guī)定系統(tǒng)平均出錯(cuò)時(shí)間屬于質(zhì)量保證。

11、需求分析過(guò)程應(yīng)該建立3中模型，他們分別是數(shù)據(jù)模型、功能模型、行為模型，以下幾種圖形中，數(shù)據(jù)流圖（DFD）屬于功能模型，實(shí)體-聯(lián)系圖（ERD）屬于數(shù)據(jù)模型，狀態(tài)轉(zhuǎn)換圖（STD）屬于行為模型。

12、常用的需求分析方法有：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA），面向?qū)ο蟮姆治龅姆治龇椒ǎ∣OA），下列(D)不是結(jié)構(gòu)化分析方法的圖形工具。

A 決策樹B 數(shù)據(jù)流圖C數(shù)據(jù)字典D快速原型

13、軟件開發(fā)中，原型是軟件的一個(gè)早期可運(yùn)行的版本，它反映最終系統(tǒng)的部分重要特性，其中，探索型和實(shí)驗(yàn)型用完可以丟棄，而進(jìn)化型圍繞原型修改、增加。

14、數(shù)據(jù)流圖用于描述數(shù)據(jù)的處理過(guò)程。

15、DFD 的基本符號(hào)不包括下列哪種？（A）。

A 數(shù)據(jù)字典B 加工C 外部實(shí)體D 數(shù)據(jù)流E 數(shù)據(jù)存儲(chǔ)文件

16、DD的主要字典條目包括以下哪種（E）

A 數(shù)據(jù)流B文件C 數(shù)據(jù)項(xiàng)D加工E以上都是

17、常用的動(dòng)態(tài)分析方法不包括以下哪種（B）

A 狀態(tài)遷移圖B 層次方框圖C 時(shí)序圖D Petri網(wǎng)

18、需求分析階段的文檔包括以下哪些（E）

A 軟件需求規(guī)格說(shuō)明書B 數(shù)據(jù)要求說(shuō)明書C 初步的用戶手冊(cè)D 修改、完善與確定開發(fā)實(shí)施計(jì)劃E 以上都是

19、需求驗(yàn)證應(yīng)該從下述幾個(gè)方面進(jìn)行驗(yàn)證：（C）

A 可靠性、可用性、易用性、重用性B 可維護(hù)性、可移植性、可重用性、可測(cè)試性

C 一致性、現(xiàn)實(shí)性、完整性、有效性 D 功能性、非功能性

20、風(fēng)險(xiǎn)管理的要素包括哪些（D）

A 風(fēng)險(xiǎn)評(píng)價(jià)B 風(fēng)險(xiǎn)避免C 風(fēng)險(xiǎn)控制D 以上都是

21、下列描述中錯(cuò)誤的是（D）

A 每一個(gè)集成的需求變更必須能跟蹤控制到一個(gè)經(jīng)核準(zhǔn)的變更請(qǐng)求。

B 變更過(guò)程應(yīng)該做成文檔，盡可能簡(jiǎn)單，當(dāng)然首要的是有效性。

C 所有需求變更必須遵循過(guò)程，按照此過(guò)程，如果一個(gè)變更需求未被采納，則其后過(guò)程不再予以考慮。

D 可以從數(shù)據(jù)庫(kù)中刪除或修改變更請(qǐng)求的原始文檔。

二、填空題

1、需求分析階段產(chǎn)生的最重要的文檔是（需求分析說(shuō)明書）。

2、需求分析的主要任務(wù)是（要回答“軟件必須做什么？”）。

3、需求分析階段，分析人員要確定對(duì)問題的綜合需求，其中最主要的是(功能需求)需求。

4、需求分析階段研究的對(duì)象是軟件項(xiàng)目的(用戶要求)。

5、軟件生命周期：?jiǎn)栴}分析、可行性研究、需求分析、總體設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和單元測(cè)試、綜合測(cè)試、軟件維護(hù)。

6、信息系統(tǒng)必須實(shí)現(xiàn)的功能，或者說(shuō)信息系統(tǒng)必須具備的屬性和質(zhì)量稱為（系統(tǒng)需求（需求））

7、（模型）是為了理解事物而對(duì)事物做出的一種抽象，是對(duì)事物的一種無(wú)歧義的書面描述通常，由一組圖形符號(hào)和組織這些符號(hào)的規(guī)則組成。

8、軟件需求分析階段的目的是澄清用戶的要求，并把雙方共同的理解明確地表達(dá)成一份書面文檔——（軟件需求規(guī)格說(shuō)明書。

9、軟件需求分類，分為（功能性）需求和（非功能性）需求。

10、需求分析的步驟包括（需求獲?。ⅲǚ治鼋＃?、文檔編寫。。

三、名詞解釋

第一、二空缺。

3、需求工程：整個(gè)軟件需求范圍內(nèi)所進(jìn)行的活動(dòng)稱為需求過(guò)程，需求工程包括需求開發(fā)和需求管理兩部分，需求開發(fā)包括問題獲取、分析、編寫規(guī)格說(shuō)明和驗(yàn)證。

4、業(yè)務(wù)模型：業(yè)務(wù)模型是理解是理解一個(gè)組織業(yè)務(wù)過(guò)程的技術(shù)，可以用業(yè)務(wù)用例模型和業(yè)務(wù)對(duì)象模型來(lái)表達(dá)業(yè)務(wù)模型，業(yè)務(wù)用例模型分別是分別從與業(yè)務(wù)過(guò)程和客戶對(duì)應(yīng)的業(yè)務(wù)用例和業(yè)務(wù)參與者的角度來(lái)描述企業(yè)的業(yè)務(wù)過(guò)程；業(yè)務(wù)對(duì)象模型描述了如何由一組工作人員使用一些業(yè)務(wù)實(shí)體和工作單元來(lái)實(shí)現(xiàn)每個(gè)業(yè)務(wù)用例。

5、原型開發(fā)方法：一個(gè)軟件原型是所提出的新產(chǎn)品的部分市縣，使用原型有三個(gè)主要目的：

1）明確并完善需求，2）探索設(shè)計(jì)選擇方案，3）發(fā)展成為最終的產(chǎn)品，建立原型的主要原因是為了解決在產(chǎn)品開發(fā)的早期階段不確定的問題，原型可分為拋棄型原型和進(jìn)化型原型。

6、數(shù)據(jù)字典：一個(gè)定義應(yīng)用程序中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的含義、類型、數(shù)據(jù)大小、格式、度量單位、精度以及允許取值范圍的共享倉(cāng)庫(kù)。

四、簡(jiǎn)答題

1、生命周期模型是什么？常見的生命周期模型有哪幾種？

答：對(duì)軟件開發(fā)流程的一種描述：為解決問題所定義的策略；對(duì)典型開發(fā)活動(dòng)的抽象。常見的生命周期模型：Waterfall，Prototyping，Phased，Spiral（瀑布模型、快速原型模型、增量模型,螺旋模型）

2、為什么要使用生命周期模型？

答：幫助開發(fā)組了解他們?cè)陂_發(fā)項(xiàng)目的活動(dòng)、資源和限制；幫助項(xiàng)目了解在開發(fā)過(guò)程中的不一致，丟失，冗余等情況，把注意力集中在開發(fā)最終產(chǎn)品上；幫助項(xiàng)目組剪裁開發(fā)過(guò)程——沒有基礎(chǔ)就無(wú)從剪裁。

3、waterfall的優(yōu)勢(shì)是什么？

答：具有良好定義的里程碑，利于向不熟悉軟件開發(fā)的客戶講解流程；幫助開發(fā)人員理解需要做的事情；清楚地描述下階段開始前需要的中間產(chǎn)品；是很多其他LC模型的基礎(chǔ)。

4、需求分析階段的基本人物是什么？

答：需求分析階段的基本任務(wù)是：

（1）問題識(shí)別：雙方對(duì)問題的綜合需求；a.功能需求 b.性能需求c.環(huán)境需求d.用戶界面

需求。

（2）分析與綜合，到處軟件的邏輯模型。

（3）編寫文檔。

五、問答題

1、軟件過(guò)程的概念及分類，基本過(guò)程包含些什么及每個(gè)過(guò)程的具體內(nèi)容。

答：軟件過(guò)程也稱為軟件生存周期過(guò)程或軟件過(guò)程組，是指軟件生存周期中的一系列相關(guān)過(guò)程，過(guò)程就是過(guò)程的集合，活動(dòng)是任務(wù)的集合，人物則起到把輸入加工成輸出的作用?；顒?dòng)的執(zhí)行可以是順序的、迭代的（重復(fù)的）、并行的、嵌套的或是有條件引發(fā)的。

軟件過(guò)程可以分為三類：基本過(guò)程、支持過(guò)程和組織過(guò)程。

基本過(guò)程包括：

1）獲取過(guò)程：（項(xiàng)目委托方）確定需求；招標(biāo)；簽訂合同；對(duì)供應(yīng)方的監(jiān)督；驗(yàn)收完成。

2）供應(yīng)過(guò)程：（項(xiàng)目承包方）理解需求；投標(biāo)；簽訂合同；計(jì)劃；實(shí)施；控制；評(píng)審評(píng)

價(jià)；交付。

3）開發(fā)過(guò)程：（軟件開發(fā)人員）過(guò)程實(shí)施準(zhǔn)備；系統(tǒng)需求分析；系統(tǒng)結(jié)構(gòu)設(shè)計(jì)；軟件需

求分析；軟件體系結(jié)構(gòu)設(shè)計(jì)；軟件詳細(xì)設(shè)計(jì)；軟件編碼測(cè)試；軟件集成；軟件合格測(cè)試；系統(tǒng)集成；系統(tǒng)合格測(cè)試；軟件安裝；驗(yàn)收支持。

4）運(yùn)行過(guò)程：（用戶）運(yùn)行準(zhǔn)備；運(yùn)行測(cè)試；產(chǎn)品轉(zhuǎn)移；運(yùn)行；運(yùn)行支持；運(yùn)行評(píng)價(jià)。

5）維護(hù)過(guò)程：（維護(hù)人員）過(guò)程實(shí)施準(zhǔn)備；問題分析和修改設(shè)計(jì)；修改實(shí)施；對(duì)維護(hù)的評(píng)審和驗(yàn)收；軟件移植；軟件退役。

2、簡(jiǎn)述軟件需求工程分為哪幾類？其中需求獲取和需求規(guī)約的目的和任務(wù)。

答：軟件需求工程細(xì)分為：需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗(yàn)證和需求管理六個(gè)階段。

需求獲?。合到y(tǒng)分析人員通過(guò)與用戶的交流，對(duì)現(xiàn)有系統(tǒng)的觀察及任務(wù)進(jìn)行分析，確定系統(tǒng)或產(chǎn)品范圍的限制性描述、與系統(tǒng)或產(chǎn)品有關(guān)的人員及特征列表、系統(tǒng)的技術(shù)環(huán)境的描述、系統(tǒng)功能的列表及應(yīng)用于每個(gè)需求的領(lǐng)域限制、一組描述不同運(yùn)行條件下系統(tǒng)或產(chǎn)品使用狀況的應(yīng)用場(chǎng)景以及為更好地定義需求而開發(fā)的任意原型。

需求規(guī)約：軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過(guò)建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說(shuō)明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)的各種要求。需求規(guī)約作為用戶和開發(fā)組之間的一個(gè)協(xié)議，在之后的軟件工程各個(gè)階段發(fā)揮重要作用。

3、簡(jiǎn)述軟件體系結(jié)構(gòu)的概念及基于B/S體系結(jié)構(gòu)的實(shí)現(xiàn)方式。

答：軟件體系結(jié)構(gòu)：軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件，處理構(gòu)件負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行加工，數(shù)據(jù)構(gòu)件是被加工的信息，連接構(gòu)件把體系結(jié)構(gòu)的不同部分組合連接起來(lái)。

B/S結(jié)構(gòu)：瀏覽器（客戶機(jī)）—WEB服務(wù)器—數(shù)據(jù)庫(kù)服務(wù)器

B/S體系結(jié)構(gòu)的實(shí)現(xiàn)方式：B/S模式下的客戶機(jī)只需安裝瀏覽器軟件，無(wú)須開發(fā)前端應(yīng)用程序；中間層的WEB應(yīng)用服務(wù)器，主要的數(shù)據(jù)計(jì)算和應(yīng)用都在此完成，因此對(duì)中間層服務(wù)器的要求較高；后臺(tái)數(shù)據(jù)庫(kù)服務(wù)器主要完成數(shù)據(jù)的管理。

4、用戶界面設(shè)計(jì)三個(gè)的任務(wù)和目的答：用戶界面設(shè)計(jì)在工作流程上分為結(jié)構(gòu)設(shè)計(jì)、交互設(shè)計(jì)、視覺設(shè)計(jì)三個(gè)部分。

1)結(jié)構(gòu)設(shè)計(jì)：結(jié)構(gòu)設(shè)計(jì)也稱概念設(shè)計(jì)，是界面設(shè)計(jì)的骨架，通過(guò)用戶研究和任務(wù)分析，制定出產(chǎn)品的整體架構(gòu)，基于紙質(zhì)的低保真原型可提供用戶測(cè)試并進(jìn)行完善，在結(jié)

構(gòu)設(shè)計(jì)中，目錄體系的邏輯分類和語(yǔ)詞定義是用戶易于理解和操作的重要前提。

2)交互設(shè)計(jì)：交互設(shè)計(jì)的目的是使產(chǎn)品讓用戶能簡(jiǎn)單使用，任何產(chǎn)品功能的實(shí)現(xiàn)都是

通過(guò)人和機(jī)器的交互來(lái)完成的。因此，人的因素應(yīng)作為設(shè)計(jì)的核心被體現(xiàn)出來(lái)。

3)視覺設(shè)計(jì)：在結(jié)構(gòu)設(shè)計(jì)的基礎(chǔ)上，參照目標(biāo)群體的心理模型和任務(wù)達(dá)成進(jìn)行視覺設(shè)

計(jì)，包括色彩、字體、頁(yè)面等，視覺設(shè)計(jì)要達(dá)到用戶愉悅使用的目的。

5、需求規(guī)格說(shuō)明文檔的作者及表現(xiàn)手段

答：作者：

項(xiàng)目管理者：組織安排、提供條件。

需求工程師：負(fù)責(zé)人、主導(dǎo)人。

文檔寫作人員：有時(shí)會(huì)采用，節(jié)省需求工程師的時(shí)間

涉眾（用戶）：驗(yàn)證人

表現(xiàn)手段：

非形式化：自然語(yǔ)言、限制性文本

半形式化：結(jié)構(gòu)化文本（偽碼/結(jié)構(gòu)化英語(yǔ)）、模型語(yǔ)言（圖、表）

形式化：形式化語(yǔ)言（數(shù)學(xué)語(yǔ)言：BNF）

6、數(shù)據(jù)庫(kù)設(shè)計(jì)的內(nèi)容及常用方法

答：數(shù)據(jù)庫(kù)設(shè)計(jì)包括數(shù)據(jù)庫(kù)的結(jié)構(gòu)設(shè)計(jì)和數(shù)據(jù)庫(kù)的行為設(shè)計(jì)。

1）數(shù)據(jù)庫(kù)的結(jié)構(gòu)設(shè)計(jì)

數(shù)據(jù)庫(kù)的結(jié)構(gòu)設(shè)計(jì)指是根據(jù)給定的應(yīng)用環(huán)境，進(jìn)行數(shù)據(jù)庫(kù)的模式或子模式的設(shè)計(jì)。它包括數(shù)據(jù)庫(kù)的概念設(shè)計(jì)、邏輯設(shè)計(jì)和物理設(shè)計(jì)，數(shù)據(jù)庫(kù)模式是各應(yīng)用程序共享的結(jié)構(gòu)，是靜態(tài)的、穩(wěn)定的，一經(jīng)形成后通常情況下是不容易改變的，所以結(jié)構(gòu)設(shè)計(jì)又稱為靜態(tài)模型設(shè)計(jì)。

2）數(shù)據(jù)庫(kù)的行為設(shè)計(jì)

數(shù)據(jù)庫(kù)的行為設(shè)計(jì)是指確定數(shù)據(jù)庫(kù)用戶的行為和動(dòng)作，而在數(shù)據(jù)庫(kù)系統(tǒng)中，用戶的行為和動(dòng)作指用戶對(duì)數(shù)據(jù)庫(kù)的操縱，這些要通過(guò)應(yīng)用程序來(lái)實(shí)現(xiàn)，所以數(shù)據(jù)庫(kù)的行為設(shè)計(jì)就是應(yīng)用程序的設(shè)計(jì)。用戶的行為總是使數(shù)據(jù)庫(kù)的內(nèi)容發(fā)生變化，所以行為設(shè)計(jì)是動(dòng)態(tài)的，行為設(shè)計(jì)又稱為動(dòng)態(tài)模型設(shè)計(jì)。

數(shù)據(jù)庫(kù)常用設(shè)計(jì)方法：直觀設(shè)計(jì)法、規(guī)范設(shè)計(jì)法、計(jì)算機(jī)輔助設(shè)計(jì)法、自動(dòng)化設(shè)計(jì)法。

7、如何正確看待客戶？

答：即使最終用戶不是上帝，也算是上帝的親戚，同樣怠慢不得

如果項(xiàng)目規(guī)模比較大，那么開發(fā)方與最終用戶的來(lái)往就比較多。如從最終用戶那里獲取詳細(xì)的需求，請(qǐng)最終用戶試驗(yàn)軟件，對(duì)最終用戶進(jìn)行培訓(xùn)等等。

8、概括說(shuō)明如何進(jìn)行需求分析？

答：（1）需求分析是指需求開發(fā)過(guò)程中，對(duì)所獲取的需求信息進(jìn)行分析，及時(shí)排除錯(cuò)誤和彌補(bǔ)不足，確保需求文檔正確地反映用戶的真實(shí)意圖。

（2）分析方法大體有兩類：“回答分析法”和“建模分析法”。

第一：?jiǎn)柎鸱治龇椒ê芎?jiǎn)單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了，一個(gè)人可以“自問自答”地分析需求，幾個(gè)人分析需求則稱為“研討”，問答分析最重要的問題是：“是什么”和“為什么”，其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎?需求是必要的嗎？需求可實(shí)現(xiàn)嗎？需求可驗(yàn)證嗎？需求的優(yōu)先級(jí)確定了嗎？

第二：建模分析法：在需求開發(fā)過(guò)程中，對(duì)于某些類型的信息，用圖形表示要比文本表示更加有效，所以將圖形與文本結(jié)合起來(lái)描述需求是很自然的方法。需求建模就是指用圖形符號(hào)來(lái)表示、刻畫需求，需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用、建議將模型存放在需求文檔的附錄中，便于正文引用。建模分析方法主要有兩大類：“結(jié)構(gòu)化分析法“和”面向?qū)ο蠓治龇椒ā啊?/p>