軟件需求分析

軟件需求分析

教學(xué)內(nèi)容

軟件需求概述

架構(gòu)師與需求

軟件需求面臨的主要困難

需求工程

需求獲取技術(shù)

需求分類(lèi)和結(jié)構(gòu)化

需求建模

編寫(xiě)軟件需求規(guī)格說(shuō)明書(shū)

需求確認(rèn)

需求跟蹤技術(shù)

需求變更控制

教學(xué)內(nèi)容

軟件需求概述

u經(jīng)典的“四拍”

決策時(shí)拍腦袋——就這么定了

指揮時(shí)拍胸脯——保證沒(méi)問(wèn)題

失誤時(shí)拍大腿——我怎么木想到

追查時(shí)拍屁股——老子不干了

軟件需求概述

u需求分析的重要性

軟件需求概述

u

根據(jù)StandishGroup對(duì)23000個(gè)項(xiàng)目進(jìn)行的研究結(jié)果表明，28%的項(xiàng)目徹底失敗，46%的項(xiàng)目超出u在于這些高達(dá)74%的不成功項(xiàng)目中，有約60%的失敗是源于需求問(wèn)題u也就是說(shuō)，有近45%的項(xiàng)目最終因?yàn)樾枨蟮膯?wèn)題最終導(dǎo)致失敗成功

軟件需求概述

原因：

需求不明確

FACT:軟件項(xiàng)目中40%-60%的問(wèn)題都是在需求分析階段埋下的禍根，需求錯(cuò)誤消耗整個(gè)項(xiàng)目預(yù)算的30%-50%

不充分的計(jì)劃和過(guò)于樂(lè)觀的評(píng)估

盲目采用新技術(shù)

管理方法缺乏或不恰當(dāng)

團(tuán)隊(duì)組織不當(dāng)

人際關(guān)系因素

軟件需求概述

錯(cuò)誤的架構(gòu)項(xiàng)目徹底失敗

項(xiàng)目進(jìn)度拖延

項(xiàng)目成本增加

項(xiàng)目質(zhì)量失控

系統(tǒng)生命縮短

……

軟件需求概述

導(dǎo)致的后果某家互聯(lián)網(wǎng)公司產(chǎn)

品經(jīng)理提需求，要

求app開(kāi)發(fā)人員可以

做到軟件根據(jù)用戶

的手機(jī)殼來(lái)改變軟

件主題顏色。需求問(wèn)題

軟件需求概述

需求分析需求分析人員的位置

軟件需求概述

誰(shuí)需要

什么樣的

東西？

需求的內(nèi)容

軟件需求概述

需求的基本概念需求的主體需求的形式

軟件需求概述

馬斯洛人類(lèi)需求層次理論Maslow,

A.H.

(1943).

A

theory

of

human

motivation.Psychological

Review

50(4)

370–96.

需求的基本概念

IEEE

(1997)

(1)用戶解決問(wèn)題或達(dá)到目標(biāo)所需的條件或能力

(2)

系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文

檔所需具有的條件或能力

(3)一種反映上面（

1

）或（2）所描述的條件或能力的文檔說(shuō)明

SommervilleandSawyer

(1997)

需求是指明必須實(shí)現(xiàn)什么的規(guī)格說(shuō)明。它描述了系統(tǒng)的行為、

特性或?qū)傩裕窃陂_(kāi)發(fā)過(guò)程中對(duì)系統(tǒng)的約束。

軟件需求概述

客戶、最終用戶&

間接用戶

客戶：客戶是掏錢(qián)買(mǎi)軟件的人，所以他是“上帝”。與客戶打交道的主要目的是：一是獲取需求，二是簽訂合同

最終用戶：即使最終用戶不是上帝，也算是“上帝”的

“親戚”，同樣怠慢不得

間接用戶：重視“間接用戶”，千萬(wàn)別“大意失荊州”indirect

user.someonewhodoesnotactually

usea

product

butwho

is

directlyaffectedby

the

product'susability.

Forinstance,atelemarketerorcustomerserviceagent

mayworkwithsoftwarewhileinteractingwith

acustomer,andthecustomerwould

bean

indirect

user,affected

bythe

useoftheapplication.先生很抱歉，這個(gè)我們系統(tǒng)查不到的先生很抱歉，我們后臺(tái)沒(méi)有這個(gè)權(quán)限先生很抱歉，系統(tǒng)需要您提交一份能

夠證明您爸爸是你父親的PDF文檔。。。

軟件需求概述

需求的重要性

Frederick

Brooks在他1987年經(jīng)典文章《沒(méi)有銀彈》

(NoSilver

Bullet)

中闡述了需求的重要性：

開(kāi)發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。最困難的

概念性工作是編寫(xiě)出詳細(xì)的需求。

軟件需求概述

軟件需求概述

軟件需求概述

軟件需求流程

軟件需求概述

需求分類(lèi)用例文檔項(xiàng)目視圖/范圍文檔用戶需求

功能需求▲其它非功能

需求設(shè)計(jì)約束▲SRS質(zhì)量屬性非功能需求業(yè)務(wù)需求系統(tǒng)需求義本身就是業(yè)務(wù)需求

背景描述：XX保險(xiǎn)公司希望充分利用日益完善通信技術(shù)，在

原有的辦公系統(tǒng)的基礎(chǔ)上進(jìn)行擴(kuò)展，使得在外的業(yè)務(wù)人員能夠及時(shí)

地獲得客戶、業(yè)務(wù)相關(guān)的動(dòng)態(tài)信息，與同時(shí)，

還要實(shí)現(xiàn)企部

的即時(shí)通信。

業(yè)務(wù)需求/目標(biāo)

：通過(guò)該系統(tǒng)的實(shí)施，

人工保費(fèi)續(xù)繳

、

投保手續(xù)

辦理兩項(xiàng)業(yè)務(wù)運(yùn)轉(zhuǎn)周期縮短10％以上，使

業(yè)內(nèi)部溝通效率善，以幫助企業(yè)運(yùn)轉(zhuǎn)效率得以提高。

業(yè)務(wù)需求

反映組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常問(wèn)題定電影《非誠(chéng)勿擾2》中，秦奮為了表達(dá)對(duì)笑笑

的真愛(ài)，做了一份300萬(wàn)終身壽險(xiǎn)，唯一受益人是笑笑。秦奮比笑笑大20歲，這個(gè)男人有情（qian）有愛(ài)（qian）有擔(dān)當(dāng)（qian）。情人節(jié)想買(mǎi)份保險(xiǎn)指定情人為受益人，卻被告知沒(méi)有拿結(jié)婚證不能這樣買(mǎi)。理財(cái)師提醒，電影《非誠(chéng)勿擾Ⅱ》中的送高額保險(xiǎn)的情節(jié)其實(shí)是誤導(dǎo)了觀眾。軟件需求概述

描述用戶使用產(chǎn)品要完成什么任務(wù)、

如何完成的需求

通常在問(wèn)題定義的基礎(chǔ)上進(jìn)用戶訪談

、

調(diào)查，對(duì)用戶使

用的場(chǎng)景進(jìn)行整理，從而建立從用戶角度的需求。

用戶有不同類(lèi)型：

用例：對(duì)用戶需求進(jìn)行描述和組織

例：對(duì)快到期的客戶，系統(tǒng)將通過(guò)短信將續(xù)保信息發(fā)給

該客戶的代理人

軟件需求概述

用戶需求信息系統(tǒng)、人常用者

、

偶用者管理型

、

事務(wù)型決策層、使用層

軟件需求概述

系統(tǒng)需求

從系統(tǒng)的角度來(lái)說(shuō)明軟件的需求

包括用特性（feature）

說(shuō)明的功能需求、

質(zhì)量屬性，以及其他

非功能需求，

還有設(shè)計(jì)約束等。

功能需求

系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的

功能，產(chǎn)品必須執(zhí)行的動(dòng)作

需求的主體，需求的本質(zhì)

零散（需求項(xiàng)）

整理（特性、用例）

小結(jié)

業(yè)務(wù)需求：領(lǐng)域?qū)＜?/p>

用戶需求：用戶

系統(tǒng)需求：開(kāi)發(fā)人員

功能需求：架構(gòu)師

軟件需求概述

項(xiàng)目視圖/范圍文檔用戶需求用例文

檔

功能需求▲其它非功能

需求▲SRS質(zhì)量屬性設(shè)計(jì)約束非功能需求業(yè)務(wù)需求系統(tǒng)需求

非功能需求

指產(chǎn)品必須具備的屬性或品質(zhì)，如正確性、

可靠性、性

能、容錯(cuò)性和可擴(kuò)展性等。

設(shè)計(jì)約束

也稱為“

限制條件”或“補(bǔ)充規(guī)約”，通常是對(duì)解決方

案的一些約束說(shuō)明

。例如必須采用國(guó)有自主知識(shí)產(chǎn)權(quán)的

數(shù)據(jù)庫(kù)系統(tǒng)，必須運(yùn)行在UNIX操作系統(tǒng)之下等。

軟件需求概述

架構(gòu)師與需求

來(lái)看幾個(gè)例子。。。需求進(jìn)

架構(gòu)出架構(gòu)師與需求1.The

Requirements

Statement2.

Emerging

Requirements4.Six

Months

Later3.

Redesign

架構(gòu)師與需求

架構(gòu)師是客戶需求和開(kāi)發(fā)者之間的橋梁

架構(gòu)師的工作職責(zé)是在一個(gè)軟件項(xiàng)目開(kāi)發(fā)過(guò)程中，將客戶的需求轉(zhuǎn)換

為規(guī)范的開(kāi)發(fā)計(jì)劃和文本，

并制定這個(gè)項(xiàng)目的總體架構(gòu)，

指導(dǎo)整個(gè)開(kāi)

發(fā)團(tuán)隊(duì)完成這個(gè)計(jì)劃

架構(gòu)師需要參與項(xiàng)目開(kāi)發(fā)的全部過(guò)程，

負(fù)責(zé)在整個(gè)項(xiàng)目中對(duì)技術(shù)活動(dòng)

和技術(shù)說(shuō)明進(jìn)行指導(dǎo)和協(xié)調(diào)

架構(gòu)師的主要任務(wù)不是從事具體的項(xiàng)目程序的編寫(xiě)，

而是從事更高層

次的開(kāi)發(fā)架構(gòu)工作

架構(gòu)師必須對(duì)開(kāi)發(fā)技術(shù)非常了解，

并且需要有良好的組織管理能力一個(gè)架構(gòu)師的工作好壞決定了整個(gè)項(xiàng)目開(kāi)發(fā)的成敗

架構(gòu)師與需求

架構(gòu)師與需求

一線架構(gòu)師的六個(gè)經(jīng)典困惑

將系統(tǒng)劃分模塊，如何更合理？

大系統(tǒng)架構(gòu)設(shè)計(jì)，如何起步？

總覺(jué)得需求很糟糕，影響了架構(gòu)設(shè)計(jì)？

非功能需求是重要，但要如何設(shè)計(jì)？

架構(gòu)新手：缺乏指導(dǎo)，架構(gòu)設(shè)計(jì)不知所措。

架構(gòu)老手：缺乏總結(jié)，仍“怕”下一個(gè)項(xiàng)目。架構(gòu)師與需求把握需求特點(diǎn)，確定架構(gòu)驅(qū)動(dòng)力根據(jù)重大需求，確定概念架構(gòu)細(xì)化架構(gòu)設(shè)計(jì)，關(guān)注不同視圖

架構(gòu)師與需求

架構(gòu)師必須熟悉需求

知識(shí)技能問(wèn)題

領(lǐng)域知識(shí)

學(xué)習(xí)

培訓(xùn)

軟件需求面臨的主要

困難

態(tài)度問(wèn)題

用戶說(shuō)不清楚需求或者需求發(fā)生變更—常見(jiàn)的問(wèn)題

不能把這些問(wèn)題當(dāng)成了借口

需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致

的用戶需求

軟件需求面臨的主要

困難

合作關(guān)系

如果需求分析員不能與用戶建立良好的合作關(guān)系，那么

他們?cè)谛枨箝_(kāi)發(fā)過(guò)程中會(huì)很疲憊

對(duì)于一些競(jìng)標(biāo)項(xiàng)目，在合同未簽訂之前的需求開(kāi)發(fā)工作

尤為困難。用戶未必會(huì)買(mǎi)你的產(chǎn)品，他不會(huì)投入很多精

力來(lái)協(xié)助進(jìn)行需求開(kāi)發(fā)

需求分析員不是銷(xiāo)售人員，他們不可能象銷(xiāo)售人員那樣

通過(guò)某些手段籠絡(luò)住用戶就能成功

。

出色的需求分析員

不僅要有過(guò)硬的專(zhuān)業(yè)知識(shí)，還要具備較強(qiáng)的交流、

溝通

能力

軟件需求面臨的主要

困難

合作關(guān)系（續(xù)）

開(kāi)發(fā)方和用戶方在開(kāi)展需求開(kāi)發(fā)之前，雙方協(xié)商并撰寫(xiě)

“用戶在需求工程中的權(quán)利與義務(wù)”，即以協(xié)議的方式確定合作關(guān)系。

如果條件允許的話，

開(kāi)發(fā)方最好為用戶舉辦關(guān)于需求工

程的培訓(xùn)

，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求

工程中的各項(xiàng)活動(dòng)。

軟件需求面臨的主要

困難

合作關(guān)系（續(xù)）

用戶在需求工程中的“權(quán)利”

1.有權(quán)要求開(kāi)發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。

2.有權(quán)要求開(kāi)發(fā)方采用用戶熟悉的語(yǔ)言來(lái)描述需求，即開(kāi)發(fā)方

必須提供用戶看得懂得需求文檔。

3.有權(quán)審查需求文檔，

并對(duì)有爭(zhēng)議的需求作出決策

。

如果認(rèn)為

需求文檔不能準(zhǔn)確地反映用戶真實(shí)的意愿，

可以拒絕在需求文

檔上簽字。

4.如果用戶想要變更需求，有權(quán)要求開(kāi)發(fā)方對(duì)該變更將產(chǎn)生的

影響作出真實(shí)可信的評(píng)估，以便用戶決定是否變更需求。

軟件需求面臨的主要

困難

合作關(guān)系（續(xù)）

用戶在需求工程中的“義務(wù)”

1.

以積極友善的態(tài)度與開(kāi)發(fā)方人員交流、

協(xié)作

，盡可能地為開(kāi)

發(fā)方人員提供工作和生活上的便利。

2.樂(lè)意接受需求分析員的采訪，在不泄漏機(jī)密的前提下盡可能

地回答需求分析員的問(wèn)題。

3.在不泄漏機(jī)密的前提下，

盡可能地向需求分析員提供與需求

相關(guān)的材料。

4.

與需求分析員共同評(píng)審需求文檔，確保需求文檔準(zhǔn)確地反映

用戶真實(shí)的意愿。

軟件需求面臨的主要

困難

用戶說(shuō)不清楚需求

普遍現(xiàn)象，讓開(kāi)發(fā)人員頭痛的大問(wèn)題

有些用戶雖然心里明白想要什么，但卻說(shuō)不清楚需求

需求分析人員必須設(shè)法搞清楚用戶真正的需求，這是需

求分析員的職責(zé)，也是職業(yè)的挑戰(zhàn)

軟件需求面臨的主要

困難請(qǐng)幫我設(shè)計(jì)一個(gè)

五顏六色的黑

用戶經(jīng)常變更需求

需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很

大的影響，這是軟件開(kāi)發(fā)中非常畏懼的問(wèn)題

需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂，因此需求變更控制是需求工程的重要活動(dòng)

軟件需求面臨的主要

困難

雙方誤解需求

不論是復(fù)雜的項(xiàng)目還是簡(jiǎn)單的項(xiàng)目，需求分析員和用戶

都有可能誤解需求

需求確認(rèn)工作（屬于需求管理）必不可少

軟件需求面臨的主要

困難

開(kāi)發(fā)人員寫(xiě)不好需求文檔

開(kāi)發(fā)人員寫(xiě)作能力比較差，雖然在調(diào)查過(guò)程中已經(jīng)獲得

了不少需求信息，

卻寫(xiě)不出好的需求文檔來(lái)

。

可以毫不

夸張地說(shuō)，

國(guó)內(nèi)90％以上的軟件開(kāi)發(fā)人員，寫(xiě)作能力遠(yuǎn)

不及開(kāi)發(fā)能力

提高開(kāi)發(fā)人員寫(xiě)作能力的根本辦法就是多練習(xí)寫(xiě)文檔，

熟能生巧

。

另外，應(yīng)當(dāng)提供合適的文檔模板以及比較好

的示例文檔，盡可能地降低寫(xiě)作難度

軟件需求面臨的主要

困難

軟件需求面臨的主要

困難如何解決？

需求工程關(guān)注軟件系統(tǒng)所應(yīng)予實(shí)現(xiàn)的現(xiàn)實(shí)世界目標(biāo)、軟件系統(tǒng)的功能和軟件系統(tǒng)應(yīng)當(dāng)遵守的約束，同時(shí)它也關(guān)注以上因素和準(zhǔn)確的軟件行為規(guī)格說(shuō)明之間的聯(lián)系，關(guān)注以上因素與其隨時(shí)間或跨產(chǎn)品族而演化之后的相關(guān)因

素之間的聯(lián)系。

需求工程中的活動(dòng)可分為兩大類(lèi)：

需求開(kāi)發(fā)

需求管理

需求工程

什么是需求工程

所有與需求直接相關(guān)的活動(dòng)通稱為需求工程。

需求工程

需求工程結(jié)構(gòu)圖

需求開(kāi)發(fā)過(guò)程域

需求開(kāi)發(fā)的目的是通過(guò)調(diào)查與分析，獲取用戶需求并定

義產(chǎn)品需求

需求調(diào)查：通過(guò)各種途徑獲取用戶的需求信息（原始材料）

，產(chǎn)

生《需求陳述》

。

需求分析：對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，

刻畫(huà)細(xì)節(jié)等

。

常見(jiàn)的需求分析方法有

“問(wèn)答分析法”和“建模分析法”兩類(lèi)。

需求定義：根據(jù)需求調(diào)查和需求分析的結(jié)果，

進(jìn)一步定義準(zhǔn)確無(wú)

誤的產(chǎn)品需求，產(chǎn)生《軟件需求規(guī)格說(shuō)明書(shū)》

。系統(tǒng)設(shè)計(jì)人員將

依據(jù)《軟件需求規(guī)格說(shuō)明書(shū)》

開(kāi)展系統(tǒng)設(shè)計(jì)工作。

需求工程

需求管理過(guò)程域

需求管理的目的是在客戶與開(kāi)發(fā)方之間建立對(duì)需求的共

同理解，維護(hù)需求與其它工作成果的一致性，

并控制需

求的變更。

需求確認(rèn)：開(kāi)發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，

雙方對(duì)需求

達(dá)成共識(shí)后作出書(shū)面承諾，使需求文檔具有商業(yè)合同效果。

需求跟蹤：通過(guò)比較需求文檔與后續(xù)工作成果之間的對(duì)應(yīng)關(guān)系，

建立維護(hù)

“需求跟蹤矩陣”

，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開(kāi)發(fā)。

需求變更控制：依據(jù)

“變更申請(qǐng)－審批－更改－重新確認(rèn)”的流

程處理需求變更，

防止需求變更失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。

需求工程

需求工程

需求工程結(jié)構(gòu)圖

需求獲取是需求工程的主體

對(duì)于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不

同用戶類(lèi)的需要和限制的過(guò)程

需求獲取是在問(wèn)題及其最終解決方案之間架設(shè)橋梁的第

一步

需求獲取可能是軟件開(kāi)發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)

及最需要交流的方面

需求獲取是一個(gè)需要高度合作的活動(dòng)，而并不是客戶所

說(shuō)需求的簡(jiǎn)單拷貝

需求獲取技術(shù)

需求獲取技術(shù)

如何獲取需求《軟件需求規(guī)格說(shuō)明書(shū)》需求分析需求定義需求采集!}!開(kāi)發(fā)商方法論用戶引導(dǎo)

獲取需求第一步需求采集的定義

調(diào)查問(wèn)卷

座談

考察、培訓(xùn)

橫向：各業(yè)務(wù)

科室

縱向：省、部

標(biāo)準(zhǔn)規(guī)范

經(jīng)驗(yàn)：核心平

臺(tái)、同行業(yè)其

他城市、現(xiàn)有

系統(tǒng)

系統(tǒng)建設(shè)目標(biāo)

業(yè)務(wù)項(xiàng)

業(yè)務(wù)流程

非功能需求

需求獲取技術(shù)

從哪里采集？怎么采集？采集什么內(nèi)容？需求分析需求定義需求采集123

需求獲取技術(shù)

討論：需求從哪里來(lái)？系統(tǒng)（其他類(lèi)似系統(tǒng)，其他應(yīng)用，?)人（決策者，使用者，?)物（文件，單據(jù)，報(bào)表，?)

需求獲取技術(shù)

不同層次的用戶，需求也存在不同

需求的來(lái)源

訪問(wèn)并與有潛力的用戶探討

市場(chǎng)調(diào)查和用戶問(wèn)卷調(diào)查

觀察正在工作的用戶

用戶任務(wù)的內(nèi)容分析

相關(guān)文件及文檔，包括手冊(cè)、文書(shū)、

表格和報(bào)表等

把對(duì)目前的競(jìng)爭(zhēng)產(chǎn)品的描述寫(xiě)成文檔

對(duì)當(dāng)前系統(tǒng)的問(wèn)題報(bào)告和增強(qiáng)要求

需求獲取技術(shù)

獲取需求的方法

面談（訪談）

問(wèn)卷調(diào)查

會(huì)議（需求討論會(huì)、重點(diǎn)問(wèn)題討論會(huì)、業(yè)務(wù)專(zhuān)題討論會(huì)、

設(shè)計(jì)專(zhuān)題討論會(huì)）

文檔研究

任務(wù)示范（觀察）

用例與角色扮演

原型設(shè)計(jì)（小規(guī)模試驗(yàn)）

研究類(lèi)似公司

需求獲取技術(shù)

面談

訪談適合于了解域中的當(dāng)前工作以及當(dāng)前問(wèn)題

作為主要的獲取技術(shù)

局限就是需求獲取障礙

訪談?dòng)?jì)劃與問(wèn)題清單（訪談模板）

技巧：錄音筆

需求獲取技術(shù)

需求獲取技術(shù)

面談

開(kāi)放式問(wèn)題（Open-Ended）

封閉式問(wèn)題（Closed）

面談-開(kāi)放式問(wèn)題

被會(huì)見(jiàn)者對(duì)答復(fù)的選擇可以是開(kāi)放和不受限制的，他們

可能答復(fù)兩個(gè)詞，也可能答復(fù)兩段話

在希望得到豐富（具有一定深度和廣度）信息時(shí)，

開(kāi)放

式問(wèn)題比較合適

例如：

“你覺(jué)得把所有的經(jīng)理都置于一個(gè)內(nèi)聯(lián)網(wǎng)內(nèi)怎么樣？”

“請(qǐng)解釋你是如何做進(jìn)度決策的？”

“對(duì)公司中企業(yè)對(duì)企業(yè)電子商務(wù)的當(dāng)前狀態(tài)有何看法？”

需求獲取技術(shù)

開(kāi)放式問(wèn)題的優(yōu)缺點(diǎn)優(yōu)點(diǎn)

讓被會(huì)見(jiàn)者感到自在；

讓被會(huì)見(jiàn)者更感興趣；

會(huì)見(jiàn)者可以收集被會(huì)見(jiàn)者使用的詞匯和習(xí)慣；

提供豐富的細(xì)節(jié)；

容許更多的自發(fā)性；

會(huì)見(jiàn)者可以在沒(méi)有太多準(zhǔn)

備的情況下進(jìn)行面談。缺點(diǎn)

可能會(huì)產(chǎn)生太多不相干的

細(xì)節(jié)；

面談可能失控；

開(kāi)放式的回答會(huì)花費(fèi)大量

的時(shí)間才能獲得有用的信

息量；

可能會(huì)使會(huì)見(jiàn)者看上去沒(méi)

有準(zhǔn)備。

需求獲取技術(shù)

面談-封閉式問(wèn)題

答案有基本的形式，被會(huì)見(jiàn)者的回答是受到限制的

例如：

“項(xiàng)目存儲(chǔ)庫(kù)每個(gè)星期更新多少次？”

“

電話中心一個(gè)月平均收到多少個(gè)電話？”

“下列信息中哪個(gè)對(duì)你最有用：

（

1）

填好的客戶投訴單；

（

2

）訪問(wèn)web站點(diǎn)的客戶的電子郵件投訴；

（

3）

與客戶面對(duì)面的

交流

；（4）

退回的貨物。”

“列出頭兩項(xiàng)需要優(yōu)先考慮的改善技術(shù)基礎(chǔ)設(shè)施的事項(xiàng)。”

需求獲取技術(shù)

封閉式問(wèn)題的優(yōu)缺點(diǎn)優(yōu)點(diǎn)

節(jié)省時(shí)間；

切中要點(diǎn)；

保持對(duì)面談的控制；

快速探討大范圍問(wèn)題；

得到貼切的數(shù)據(jù)缺點(diǎn)

使得被會(huì)見(jiàn)者厭煩；

得不到豐富的細(xì)節(jié)；

失去主要思想；

不能建立和面談?wù)叩挠押藐P(guān)系

需求獲取技術(shù)

需求獲取技術(shù)

面談數(shù)據(jù)的可靠性數(shù)據(jù)的精度廣度和深度使用時(shí)間的效率低

低

低

廣

多

難高

高

高

窄

少

易需要的面談技能封閉式問(wèn)題開(kāi)放式問(wèn)題分析的難易度

面談的談話結(jié)構(gòu)

金字塔型

漏斗型

菱形

需求獲取技術(shù)

你碰到的防火墻問(wèn)題有什么

特殊性

你想過(guò)用其他方法來(lái)改善公司數(shù)據(jù)的安全性嗎需求獲取技術(shù)

面談的談話結(jié)構(gòu)總之，你是怎樣看待數(shù)據(jù)的安

全性和訪問(wèn)Internet的重要性的你認(rèn)為怎樣才能使這

里的安全性更有效

金字塔結(jié)構(gòu)你對(duì)新的基于Web的采購(gòu)系

統(tǒng)有何看法實(shí)現(xiàn)它將會(huì)牽扯到哪些部門(mén)在站點(diǎn)上能買(mǎi)到什么商品Web站點(diǎn)是否遺漏了必需的商品

需求獲取技術(shù)

面談的談話結(jié)構(gòu)

漏斗結(jié)構(gòu)

面談的談話結(jié)構(gòu)

菱形結(jié)構(gòu)

作為Web站點(diǎn)管理員，你認(rèn)為使用信

息的價(jià)值是什么需求獲取技術(shù)通過(guò)使用這項(xiàng)服務(wù)，你發(fā)現(xiàn)終端用戶在你的站點(diǎn)

上的行為最令你感到驚訝的兩條是什么為獲得此項(xiàng)服務(wù)，你在Web站點(diǎn)增加了什么樣的推廣活動(dòng)Cookie是度量終端用戶使用站點(diǎn)的更好的方法嗎你所使用的免費(fèi)Web站點(diǎn)使用服務(wù)跟蹤哪五種信息

面談報(bào)告

應(yīng)該盡快復(fù)查面談?dòng)涗洠?/p>

總結(jié)面談信息，完成面談報(bào)告

需求獲取技術(shù)

u

實(shí)例分析

員，他受委任去與

Back工人，營(yíng)銷(xiāo)5人。

解答：（

1）選擇面談對(duì)象的時(shí)候采用隨機(jī)抽樣，從5個(gè)階層以及生

產(chǎn)、會(huì)計(jì)、營(yíng)銷(xiāo)、系統(tǒng)、物流各選擇2-3名客戶參與面談；高

層管理均要參加面談。因?yàn)樵谶x擇面談的時(shí)候要力爭(zhēng)均衡地后順序。跟高層管理人員進(jìn)行面談，采用漏斗結(jié)構(gòu)，因?yàn)楦?/p>

個(gè)高層管理人員對(duì)各自管理

的層次從大體上有準(zhǔn)確的把握，有助于開(kāi)發(fā)人員首先獲取對(duì)項(xiàng)目的廣度方面的認(rèn)識(shí)，也能獲

取一些較為詳細(xì)的信息。跟具體部門(mén)人員進(jìn)行面談，采用菱

形(必要時(shí)，

金字塔)結(jié)構(gòu)，因?yàn)檫@種面談?shì)^為具體，問(wèn)題常為

封閉式問(wèn)題，這樣有助于分析人員獲得深度認(rèn)識(shí)。面談基本規(guī)則：（

1）先業(yè)務(wù)需求，后用戶需求，所以先領(lǐng)導(dǎo)后普通（2）開(kāi)始漏斗，領(lǐng)導(dǎo)漏斗（3）普通用戶菱形，必要時(shí)金字塔需求獲取技術(shù)

面談

需求獲取技術(shù)

問(wèn)卷調(diào)查

當(dāng)潛在使用者太多采用問(wèn)卷調(diào)

查方

問(wèn)卷調(diào)查適合于大型企計(jì)，因?yàn)?/p>

它所涉及的使用員無(wú)法逐一親自調(diào)查使用者需求

如何進(jìn)行調(diào)查對(duì)象劃

分、問(wèn)卷總結(jié)等

需求專(zhuān)題討論會(huì)

一種適用于任何情景的技術(shù)

頭腦風(fēng)暴

如何計(jì)劃并實(shí)施需求專(zhuān)題討論會(huì)

專(zhuān)題討論會(huì)準(zhǔn)備

實(shí)施

總結(jié)

需求獲取技術(shù)

研究企業(yè)內(nèi)部的規(guī)章制企業(yè)或部門(mén)報(bào)表、工作流程（手冊(cè)）

是了解企業(yè)工作流程的第一步工作

一般來(lái)講企業(yè)組織內(nèi)部很少完整的文件資料來(lái)詳細(xì)描述清楚企

流程的

貌，同作流程

已經(jīng)經(jīng)過(guò)多次

改

，而文件往往沒(méi)有及時(shí)更新，因此用

這種方法收集需求信息常有過(guò)時(shí)之慮

需求獲取技術(shù)

文檔研究

文檔研究

數(shù)據(jù)表格

反映了組織的信息流

收集正在使用的每張空白表格表格

、

填寫(xiě)和分發(fā)說(shuō)明

對(duì)比填寫(xiě)好的表格–

表格中是否有從來(lái)都不填寫(xiě)的數(shù)據(jù)項(xiàng)；–

應(yīng)該收到表格的人是否真的收到了；–

他們是否按照正常程序使用、存儲(chǔ)和丟棄表格

–

等等

需求獲取技術(shù)

需求獲取技術(shù)-文檔研究

統(tǒng)計(jì)報(bào)表

反映了組織過(guò)去的主要業(yè)務(wù)和業(yè)務(wù)目標(biāo)

統(tǒng)計(jì)規(guī)則也是一種豐富的知識(shí)，統(tǒng)計(jì)項(xiàng)分解為細(xì)節(jié)業(yè)務(wù)數(shù)據(jù)的

過(guò)程往往也就是組織目標(biāo)分解到具體業(yè)務(wù)的過(guò)程

根據(jù)實(shí)際工作填寫(xiě)過(guò)的統(tǒng)計(jì)報(bào)表，

就可以發(fā)現(xiàn)組織實(shí)際的業(yè)務(wù)

執(zhí)行狀況，

從中發(fā)現(xiàn)組織面臨的具體問(wèn)題

需求獲取技術(shù)

需求獲取技術(shù)-文檔研究

組織描述文檔

組織結(jié)構(gòu)圖：幫助發(fā)現(xiàn)項(xiàng)目的關(guān)鍵涉眾

門(mén)戶網(wǎng)站

：反映組織的業(yè)務(wù)開(kāi)展?fàn)顩r

業(yè)務(wù)指導(dǎo)文檔

工作指南和規(guī)章手冊(cè)：解釋業(yè)務(wù)的詳細(xì)執(zhí)行過(guò)程，反映業(yè)務(wù)的具體細(xì)節(jié)

業(yè)務(wù)備忘

反映業(yè)務(wù)的實(shí)際執(zhí)行情況

形成對(duì)組織工作過(guò)程的清晰理解

需求獲取技術(shù)

能大大地增加對(duì)當(dāng)前工作和部分相關(guān)問(wèn)題的了解，

觀察

現(xiàn)場(chǎng)證所可

觀察也

觀察收集資料的正確性和補(bǔ)充觀察所獲得的資料比查閱資料正確性要高，也能驗(yàn)以獲得第一手的資料的能作為其它鍵問(wèn)題火焰信息轉(zhuǎn)爐煉鋼終點(diǎn)預(yù)報(bào)系統(tǒng)

需求獲取技術(shù)

用例和角色扮演

用例描述了用戶和系統(tǒng)之間的交互，其重點(diǎn)是系統(tǒng)為用

需求獲取技術(shù)

戶做什么。

原型開(kāi)發(fā)

軟件需求原型是軟件系統(tǒng)的部分實(shí)現(xiàn)，構(gòu)建該原型幫助

開(kāi)發(fā)人員、用戶以及客戶更好地理解系統(tǒng)的需求

為

“模糊”需求建立原型

需求獲取技術(shù)

需求陳述

需求陳述是一份文檔，陳述用戶對(duì)軟件的期望和需要，

并對(duì)可能的規(guī)格要求加以說(shuō)明。

需求陳述用來(lái)明確軟件的用途，

它不僅要說(shuō)明軟件有什

么用，還要在宏觀層次上明確軟件應(yīng)具備的特性。

需求獲取技術(shù)

需求獲取技術(shù)

需求陳述核心內(nèi)容

開(kāi)發(fā)該軟件的動(dòng)機(jī)（愿景）

是什么？

該項(xiàng)目的主要涉眾是誰(shuí)？

希望該軟件具備哪些主要功能和特性？

附加內(nèi)容：

組織機(jī)構(gòu)描述

軟件開(kāi)發(fā)計(jì)劃

風(fēng)險(xiǎn)王大夫在小鎮(zhèn)上開(kāi)了一家牙科診所。他有一個(gè)牙科助手，一個(gè)牙科保健員和

一個(gè)接待員

。

王大夫需要一個(gè)軟件系統(tǒng)來(lái)管理預(yù)約。當(dāng)病人打電話預(yù)約時(shí)，接待員將查閱預(yù)約登記表，如果病人申請(qǐng)的就診時(shí)間

與已定下的預(yù)約時(shí)間沖突，則接待員建議一個(gè)就診時(shí)間以安排病人盡早得到

診治；如果病人同意建議的就診時(shí)間，接待員將輸入約定時(shí)間和病人的名字

。系統(tǒng)將核實(shí)病人的名字并提供記錄病人數(shù)據(jù)，數(shù)據(jù)包括病人的病歷號(hào)等

。在每次治療或清洗后，助手或保健員將記錄相應(yīng)的預(yù)約診治已經(jīng)完成，如果

必要的話會(huì)安排病人下一次再來(lái)。系統(tǒng)能夠按病人姓名和按日期進(jìn)行查詢，能夠顯示記錄的病人數(shù)據(jù)和預(yù)約信息。接待員可以取消預(yù)約

。

可以打印出前兩天預(yù)約尚未接診的病人清單。系統(tǒng)可以從病人記錄中獲取病人的電話號(hào)碼。接待員還可以帶引出關(guān)于所有病人的每天和每周的工作安排。需求獲取技術(shù)

需求陳述舉個(gè)例子

需求獲取技術(shù)

需求陳述用例圖

挖掘隱性需求

顯性需求：直接由需求主體聲稱，可以從需求調(diào)查中直

接得到的需求；

隱性需求：可能沒(méi)有人會(huì)直接提出，而是有賴于需求分

析員進(jìn)行挖掘、分析和推導(dǎo)的需求。

需求獲取技術(shù)

需求工程

需求工程結(jié)構(gòu)圖

需求理解的大局觀

任何需求都可定位于業(yè)務(wù)級(jí)需求、用戶級(jí)需求和開(kāi)發(fā)級(jí)

需求這三個(gè)需求層次的某一層

必屬于功能

、質(zhì)量

、

約束這三類(lèi)需求的某一類(lèi)

需求分類(lèi)和結(jié)構(gòu)化

需求分類(lèi)和結(jié)構(gòu)化

需求分類(lèi)軟件設(shè)計(jì)描述原始問(wèn)題描述用戶需求系統(tǒng)需求原始問(wèn)題空間解決方案空間

需求分類(lèi)

功能需求：更多體現(xiàn)各級(jí)直接目標(biāo)要求

質(zhì)量屬性：運(yùn)行期質(zhì)量+開(kāi)發(fā)期質(zhì)量

約束需求：業(yè)務(wù)環(huán)境因素+使用環(huán)境因素+構(gòu)建環(huán)境因

素+

技術(shù)環(huán)境因素

需求分類(lèi)和結(jié)構(gòu)化

需求的層次化

業(yè)務(wù)級(jí)需求：包含客戶或出資者要達(dá)到的業(yè)務(wù)目標(biāo)、預(yù)期投資、工期要求，以及要符合哪些標(biāo)準(zhǔn)、對(duì)哪些遺留

系統(tǒng)進(jìn)行整合等約束條件。

用戶級(jí)需求：用戶使用系統(tǒng)來(lái)輔助完成哪些工作？對(duì)質(zhì)

量有何要求？用戶群及所處的使用環(huán)境方面有何特殊要

求

？

開(kāi)發(fā)級(jí)需求：開(kāi)發(fā)人員需要實(shí)現(xiàn)什么？開(kāi)發(fā)期間、維護(hù)期間有何質(zhì)量考慮？開(kāi)發(fā)團(tuán)隊(duì)的哪些情況會(huì)反過(guò)來(lái)影響

架構(gòu)

？

需求分類(lèi)和結(jié)構(gòu)化

FlyJewelry是一個(gè)小珠寶零售商。在過(guò)去的兩年里，

FlyJewelry在它的

商業(yè)方面經(jīng)歷了極大的發(fā)展，

可是，

它的財(cái)務(wù)業(yè)績(jī)卻與它的發(fā)展不

同步

。

現(xiàn)在的事務(wù)處理系統(tǒng)部分手動(dòng)

、

部分自動(dòng)，不能有效地追蹤

客戶賬單和收據(jù)，

FlyJewelry難以確定為什么它的成本這么高。

此外

,FlyJewelry頻繁地實(shí)行特價(jià)以吸引顧客，

它不知道這些特價(jià)是否有

利可圖，是否帶來(lái)其他的銷(xiāo)售

。

FlyJewelry也想增加回頭客，所以它

需要一個(gè)客戶數(shù)據(jù)庫(kù)

。

FlyJewelry想開(kāi)發(fā)一個(gè)新的銷(xiāo)售和財(cái)務(wù)處理系

統(tǒng)以幫助解決這些問(wèn)題。解答：業(yè)務(wù)需求如下：BR1：實(shí)現(xiàn)客戶賬單和收據(jù)的有效追蹤；BR2：實(shí)現(xiàn)產(chǎn)品特價(jià)時(shí)的利潤(rùn)和相關(guān)銷(xiāo)售情況檢查

；BR3：實(shí)現(xiàn)一個(gè)客戶數(shù)據(jù)庫(kù)。

需求的層次化：

案例分析

根據(jù)下列描述，說(shuō)明新系統(tǒng)的業(yè)務(wù)需求有哪些?需求分類(lèi)和結(jié)構(gòu)化

需求分類(lèi)和結(jié)構(gòu)化

二維需求矩陣

二維需求矩陣實(shí)例

需求分類(lèi)和結(jié)構(gòu)化

需求模型分類(lèi)

用例建模

(UC)

數(shù)據(jù)流圖模型

(DFD)

數(shù)據(jù)建模模型

(ER)

需求建模是優(yōu)秀軟件開(kāi)發(fā)的核心部分之一

需求建模

Unified

Modeling

Language統(tǒng)一建模語(yǔ)言統(tǒng)一建模語(yǔ)言統(tǒng)一建模語(yǔ)言

用例建模技術(shù)

UML結(jié)構(gòu)視圖實(shí)現(xiàn)視圖行為視圖環(huán)境視圖?UML是一種直觀化、明確化、構(gòu)建和文檔化軟件系統(tǒng)產(chǎn)物的通用可視化建模語(yǔ)言用戶視圖：以用戶的觀點(diǎn)表示系統(tǒng)的目標(biāo)，它是所有視圖的核心，該

視圖描述系統(tǒng)的需求。用戶視圖通過(guò)用例圖來(lái)呈現(xiàn)。

用例建模技術(shù)

視用戶圖

用例建模（

Use

Case

Modeling）

使用用例的方法來(lái)描述系統(tǒng)的功能需求

促進(jìn)并鼓勵(lì)了用戶參與

用例建模主要包括：

用例圖(UseCase

Diagram)

用例描述文檔

(UseCaseSpecification)

用例建模技術(shù)

執(zhí)行者用例圖用例文檔（規(guī)約）

用例建模技術(shù)

用例圖用例模型

補(bǔ)充規(guī)約全局性功能、非功能需術(shù)語(yǔ)表求u

某酒店訂房系統(tǒng)描述如下：

(1)顧客可以在線預(yù)訂，也可以直接去酒店通過(guò)前臺(tái)服務(wù)員預(yù)訂；

(2)前臺(tái)服務(wù)員可以利用系統(tǒng)直接在前臺(tái)預(yù)訂房間；

(3)不管采用哪種預(yù)訂方式，都需要在預(yù)訂時(shí)支付相應(yīng)訂金；

(4)前臺(tái)預(yù)訂可以通過(guò)現(xiàn)金或信用卡的形式進(jìn)行訂金支付，

但是網(wǎng)

上預(yù)訂只能通過(guò)信用卡進(jìn)行支付；

(5)利用信用卡進(jìn)行支付時(shí)需要和信用卡系統(tǒng)進(jìn)行通信；

(6)客房部經(jīng)理可以隨時(shí)查看客房預(yù)訂情況和每日收款情況。u

構(gòu)造該系統(tǒng)的用例模型。繪制用例圖u第一步：識(shí)別執(zhí)行者

(1)顧客

可以在線預(yù)訂，也可以直接去酒店通過(guò)

前臺(tái)服務(wù)員預(yù)訂；

(2)前臺(tái)服務(wù)員可以利用系統(tǒng)直接在前臺(tái)預(yù)訂房間；

(3)

不管采用哪種預(yù)訂方式，都需要在預(yù)訂時(shí)支付相應(yīng)訂金；

(4)前臺(tái)預(yù)訂可以通過(guò)現(xiàn)金或信用卡的形式進(jìn)行訂金支付，但是網(wǎng)

上預(yù)訂只能通過(guò)信用卡進(jìn)行支付；

(5)利用信用卡進(jìn)行支付時(shí)需要和信用卡系統(tǒng)

進(jìn)行通信；

(6)客房部經(jīng)理可以隨時(shí)查看客房預(yù)訂情況和每日收款情況。

繪制用例圖

u第二步：識(shí)別用例

(1)顧客

可以在線預(yù)訂，也可以直接去酒店通過(guò)

前臺(tái)服務(wù)員預(yù)訂；

(2)前臺(tái)服務(wù)員可以利用系統(tǒng)直接在前臺(tái)預(yù)訂房間；

(3)

不管采用哪種預(yù)訂方式，都需要在預(yù)訂時(shí)支付相應(yīng)訂金；

(4)前臺(tái)預(yù)訂可以通過(guò)現(xiàn)金或信用卡的形式進(jìn)行訂金支付，但是網(wǎng)

上預(yù)訂只能通過(guò)信用卡進(jìn)行支付；

(5)利用信用卡進(jìn)行支付時(shí)需要和信用卡系統(tǒng)

進(jìn)行通信；

(6)客房部經(jīng)理可以隨時(shí)

查看客房預(yù)訂情況

和每日收款情況。

繪制用例圖

繪制用例圖

u第三步：繪制用例圖

用例編號(hào)

用例名

執(zhí)行者

前置條件

后置條件

涉眾利益

基本路徑

1

…

..

××××

2

……

××××

3

…

..

××××

擴(kuò)展路徑

2a.

××××

:

2a1

…

.

×××××

字段列表

業(yè)務(wù)規(guī)則

非功能需求

設(shè)計(jì)約束書(shū)寫(xiě)用例文檔

用例的內(nèi)容

基本路徑

通過(guò)控制流程圖分離出主要的用例

書(shū)寫(xiě)用例文檔

把基本路徑單獨(dú)分離，

凸現(xiàn)用例的核心價(jià)值。核心的核心：

客戶最想看到、最關(guān)心的路徑

書(shū)寫(xiě)用例文檔

基本路徑書(shū)寫(xiě)準(zhǔn)則

只書(shū)寫(xiě)“可觀測(cè)”的（說(shuō)人話）

使用主動(dòng)語(yǔ)句

句子必須以執(zhí)行者或系統(tǒng)作為主語(yǔ)

每一句都要朝目標(biāo)邁進(jìn)

分支和循環(huán)

不要涉及界面細(xì)節(jié)

書(shū)寫(xiě)用例文檔

基本路徑系統(tǒng)通過(guò)ADO建立數(shù)據(jù)庫(kù)連接，傳送SQL查詢語(yǔ)句，從“零件”表查詢

…系統(tǒng)按照查詢條件搜索零件只書(shū)寫(xiě)“可觀測(cè)”的對(duì)錯(cuò)

書(shū)寫(xiě)用例文檔

基本路徑歐文從貝克漢姆處得到傳球，守門(mén)

員…貝克漢姆傳球給歐文，歐文射門(mén)，

守門(mén)員撲救…

.使用主動(dòng)語(yǔ)句錯(cuò)

對(duì)系統(tǒng)從會(huì)員處獲取用戶名和密碼會(huì)員提交用戶名和密碼用戶名和密碼被驗(yàn)證系統(tǒng)驗(yàn)證用戶名和密碼

書(shū)寫(xiě)用例文檔

使用主動(dòng)語(yǔ)句

基本路徑對(duì)對(duì)錯(cuò)錯(cuò)

書(shū)寫(xiě)用例文檔

基本路徑用戶提交表單

地址戶戶戶用用用每一句都要朝目標(biāo)邁進(jìn)

“

”

查…

詢條件入別鈕輸類(lèi)按中擇確文框應(yīng)拉擊相下點(diǎn)在從員員員會(huì)會(huì)會(huì)

書(shū)寫(xiě)用例文檔

基本路徑不要涉及界面細(xì)節(jié)

書(shū)寫(xiě)用例文檔

用例文檔實(shí)例

用例模型完成之后，需要對(duì)用例模型進(jìn)行檢

查

，

看看是否有遺漏或錯(cuò)誤之處。主要可以

從以下幾個(gè)方面來(lái)進(jìn)行檢查：

功能需求的完備性

模型是否易于理解

是否存在不一致性

避免語(yǔ)義二義性

檢查用例模型

用例1用例2用例3用例4用例5…需求1●●需求2●需求3需求4●需求5●●…

檢查用例模型

用例檢查表

需求建模是優(yōu)秀軟件開(kāi)發(fā)的核心部分之一

需求模型分類(lèi)

用例建模

(UC)

數(shù)據(jù)流圖模型

(DFD)

數(shù)據(jù)建模模型

(ER)

需求建模

數(shù)據(jù)流圖(Data

Flow

Diagram,

DFD)是結(jié)構(gòu)化方法中用于表示系統(tǒng)邏輯模型的一種工具，

它以圖形的

方式描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的過(guò)程。圖書(shū)管理員

數(shù)據(jù)流圖

讀者系統(tǒng)時(shí)鐘讀者信息圖書(shū)情況讀者情況

非法請(qǐng)求信息

圖書(shū)管理系統(tǒng)管理工作請(qǐng)求單查詢請(qǐng)求信息當(dāng)前日期罰款單

自外向內(nèi)，

自頂向下，逐層細(xì)化，

完善求精

數(shù)據(jù)流圖

數(shù)據(jù)流圖

讀者情況

非法查詢請(qǐng)求信息

2處理查詢請(qǐng)求▲

圖書(shū)目錄文件借書(shū)文件3登記讀者信息1處理管理請(qǐng)求非法管理工作請(qǐng)求信息

罰款單

管理工作請(qǐng)求單查詢請(qǐng)求信息讀者信息讀者文件圖書(shū)情況當(dāng)前日期

概念模型用于對(duì)實(shí)體-聯(lián)系進(jìn)行建模

Entity-Relation

Modeling

在ER圖中包含三個(gè)圖形符號(hào)，分別表示

實(shí)體：矩形框

屬性：

圓形

聯(lián)系：線

概念模型

學(xué)生課程

m

學(xué)習(xí)

n

成績(jī)課程名姓名教師班級(jí)年齡學(xué)分學(xué)號(hào)性別課程號(hào)

概念模型

醫(yī)院門(mén)診系統(tǒng)局部ER圖收銀員掛號(hào)單

*

收費(fèi)

1

*

1醫(yī)師門(mén)診處方1

1

開(kāi)處方

*

數(shù)量

單價(jià)*

*出診

生成

收費(fèi)藥品庫(kù)存<>

明細(xì)

11*

需求工程

需求工程結(jié)構(gòu)圖

軟件需求規(guī)格說(shuō)明書(shū)

(SRS)

需求分析的主要成果：軟件需求規(guī)格說(shuō)明書(shū)

(Software

RequirementSpecification,SRS)

為用戶、需求分析人員、系統(tǒng)設(shè)計(jì)人員

、

開(kāi)發(fā)人員及測(cè)

試人員之間相互理解和交流提供了方便

是系統(tǒng)設(shè)計(jì)、

實(shí)現(xiàn)

、

測(cè)試和驗(yàn)收的主要依據(jù)

需要及時(shí)更新

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)for(i=0;i=i+1;i++){print

i;}規(guī)格說(shuō)明書(shū)

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

兩個(gè)世界三種設(shè)計(jì)問(wèn)題域

機(jī)器域程序需求

正確性

需求規(guī)格說(shuō)明書(shū)應(yīng)當(dāng)正確地反映用戶的真實(shí)意圖，“正

確”是《軟件需求規(guī)格說(shuō)明書(shū)》最重要的屬性。

如果“

不正確”僅僅是由于錯(cuò)別字造成的，那么多檢查幾遍文

檔就能解決問(wèn)題。

真正的困難是開(kāi)發(fā)者和用戶自己都不

明白用戶究竟“想要什么”和“不要什么”。

為確保需

求是正確的，

開(kāi)發(fā)方和用戶必須對(duì)《軟件需求規(guī)格說(shuō)明

書(shū)》進(jìn)行確認(rèn)。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

清楚性

清楚的需求讓人易讀易懂，不在于文檔的厚度

。

清楚的

反義詞是“難讀”、“難理解”。

可以采用反問(wèn)的方式來(lái)判斷需求文檔是否清楚：

文檔的結(jié)構(gòu)、段落是否亂七八糟？

上下文是否不連貫？

文檔的語(yǔ)句是否含糊其詞

、

羅里羅嗦？每句話都是對(duì)的，

但是看了半天是否還不明白需求究竟是什么

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

每個(gè)需求只有唯人可能有不同的理解，那么這句話就有二義性。如果需

求存在二義性，將會(huì)導(dǎo)致人們誤解需求而開(kāi)發(fā)出偏離需

求的產(chǎn)品。

在編寫(xiě)模棱兩可。悲歡離合總無(wú)情。一任階前、點(diǎn)滴到天明

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)放棄美麗的女人讓人心碎我們不首先使用核武器咬死了獵人的狗

無(wú)二義性

一致性（Consistency）

指《軟件需求規(guī)格說(shuō)明書(shū)》

中各個(gè)需求之間不會(huì)發(fā)生矛

盾

。

矛盾常常潛伏在需求文檔的上下文中。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

必要性

《軟件需求規(guī)格說(shuō)明書(shū)》

中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)

都是必要的。必要”往前一步，要么是“畫(huà)蛇添足”要

么是“錦上添花”。

“

畫(huà)蛇添足”會(huì)導(dǎo)致開(kāi)發(fā)人員多干一些吃力不討好的工

作。所以要盡量剔除“

畫(huà)蛇添足”的需求。

“錦上添花”可能會(huì)讓用戶獲得比期望更多的喜悅，但

是眼前用戶不會(huì)為此多付錢(qián)。

開(kāi)發(fā)者應(yīng)當(dāng)集中精力先完

成必要的需求，如果條件允許則再做“錦上添花”的需求。

為了避免主次顛倒，應(yīng)在《軟件需求規(guī)格說(shuō)明書(shū)》

中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級(jí)。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

完備性

《軟件需求規(guī)格說(shuō)明書(shū)》

中沒(méi)有遺漏一些必要的需求。

人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一

些不起眼的但卻是必需的功能。

不完備的《軟件需求規(guī)格說(shuō)明書(shū)》將產(chǎn)生功能不完整的

軟件，用戶在使用該軟件時(shí)可能無(wú)法完成預(yù)期的任務(wù)。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

可實(shí)現(xiàn)性

《軟件需求規(guī)格說(shuō)明書(shū)》

中各項(xiàng)需求對(duì)開(kāi)發(fā)方應(yīng)當(dāng)都是可實(shí)現(xiàn)的。

“可實(shí)現(xiàn)”不僅意味著在技術(shù)上是可行的，

并且滿足時(shí)間、

費(fèi)用、

質(zhì)量等約束。

營(yíng)銷(xiāo)人員和用戶談生意時(shí)，

為了能拿到“單子”，他們往往對(duì)用戶

提出的需求“來(lái)者不拒”。

吹牛雖然不犯法，

但是經(jīng)過(guò)雙方確認(rèn)的《軟件需求規(guī)格說(shuō)明書(shū)》相當(dāng)于商業(yè)合同，如果開(kāi)發(fā)方不能夠?qū)崿F(xiàn)

《軟件需求規(guī)格說(shuō)明書(shū)》

中的內(nèi)容，

那就是違約。

對(duì)于合同項(xiàng)目，

如果開(kāi)發(fā)方不能確信某些需求是否可實(shí)現(xiàn)，

則應(yīng)事

先與用戶協(xié)商，

達(dá)成一致的處理意見(jiàn)，

避免將來(lái)發(fā)生商業(yè)糾紛。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

可驗(yàn)證性

《軟件需求規(guī)格說(shuō)明書(shū)》

中的各項(xiàng)需求對(duì)用戶方而言應(yīng)

當(dāng)都是可驗(yàn)證的（

Verifiable）

。

如果需求是不可驗(yàn)證的

,那么用戶就無(wú)法驗(yàn)收軟件，可能會(huì)發(fā)生商業(yè)糾紛。

例如，摩天大樓的一項(xiàng)需求是“抗十二級(jí)臺(tái)風(fēng)”，這個(gè)

需求看起來(lái)堂而皇之，但是如何驗(yàn)證呢？當(dāng)摩天大樓完

工后驗(yàn)收時(shí)，用戶又不是巫師，他怎能造個(gè)十二級(jí)臺(tái)風(fēng)來(lái)試驗(yàn)？如果雙方都認(rèn)可

“采用計(jì)算機(jī)模擬十二級(jí)臺(tái)風(fēng)

”等效于實(shí)際測(cè)試，那么這項(xiàng)需求就是“可驗(yàn)證”的。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

確定優(yōu)先級(jí)

理論上講，軟件的所有需求都應(yīng)當(dāng)被實(shí)現(xiàn)

。但是在現(xiàn)實(shí)

之中，項(xiàng)目存在“進(jìn)度

、

費(fèi)用、人力資源”等限制。在

項(xiàng)目剛開(kāi)始的時(shí)候，

開(kāi)發(fā)方和客戶比較樂(lè)觀，什么都要

做

，可是做著做著，人們常常會(huì)面臨“進(jìn)度延誤、

費(fèi)用

超支、人員不足”等問(wèn)題，這時(shí)就亂套了。

先做優(yōu)先級(jí)高的需求，后做（甚至放棄）優(yōu)先級(jí)低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。需求的優(yōu)先級(jí)其實(shí)就是需求“輕重緩急”

的分級(jí)表述，例如劃分為“高、中、

低”三級(jí)

。

一般地，

由用戶和開(kāi)發(fā)方共同確定需求的優(yōu)

先級(jí)。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

闡述“做什么”而不是“怎么做”

《軟件需求規(guī)格說(shuō)明書(shū)》

的重點(diǎn)是闡述“做什么”，而

不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階

段的事情。

很多軟件公司里，

開(kāi)發(fā)人員常常身兼數(shù)職，可能把需求開(kāi)發(fā)、系統(tǒng)設(shè)計(jì)、編程等工作從頭做到尾。所以他們?cè)?/p>

調(diào)查、分析、定義需求時(shí)，

自然會(huì)想到“怎么做”，

這

并沒(méi)有什么過(guò)錯(cuò)。

如果在調(diào)查、定義需求時(shí)想好了“怎

么做”，當(dāng)然應(yīng)該寫(xiě)下來(lái)，否則豈不浪費(fèi)！關(guān)鍵是不要

將“怎么做”寫(xiě)到需求規(guī)格說(shuō)明書(shū)里面，記錄在其它文

檔里就行了。

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

編寫(xiě)軟件需求規(guī)格說(shuō)

明書(shū)

目錄結(jié)構(gòu)

需求工程

需求工程結(jié)構(gòu)圖

需求確認(rèn)是指開(kāi)發(fā)方和客戶方共同對(duì)《軟件

需求規(guī)格說(shuō)明書(shū)》

進(jìn)行評(píng)審，

雙方對(duì)需求達(dá)

成共識(shí)后作出承諾。需求確認(rèn)包含兩個(gè)重要

工作

：“需求評(píng)審”和“需求承諾”。

需求確認(rèn)

需求評(píng)審面臨的困難

需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏

味，也比較費(fèi)腦子

。

剛開(kāi)始評(píng)審時(shí)，大家都比較認(rèn)真，

越到后頭越馬虎。

需求評(píng)審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開(kāi)會(huì)并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒(méi)有必要把所有事情擠在一塊做，需求開(kāi)發(fā)是循序漸進(jìn)的過(guò)程，需求

評(píng)審也可以分段進(jìn)行

。

這樣每次評(píng)審的時(shí)間比較短，參加評(píng)審的人員也少一些，組織會(huì)議就比較容易。

需求確認(rèn)

需求評(píng)審的注意要點(diǎn)

開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)“跑題”，導(dǎo)致評(píng)審效率很低。有

時(shí)越扯越遠(yuǎn)，評(píng)審會(huì)議變成了聊天會(huì)議。主持人應(yīng)當(dāng)控

制話題，避免大家討論與主題無(wú)關(guān)的東西。

開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議

。

適當(dāng)?shù)臓?zhēng)議有利于澄清

問(wèn)題

，然而當(dāng)爭(zhēng)議變?yōu)闋?zhēng)吵時(shí)就壞事了：爭(zhēng)吵不僅對(duì)評(píng)

審工作沒(méi)有好處，而且會(huì)無(wú)意中傷害同事們的感情。

“堅(jiān)持真理”還是“固執(zhí)己見(jiàn)”：不要一棍子打死別人

的觀點(diǎn)，

嘗試著讓自己站在他人的立場(chǎng)思考問(wèn)題，這樣

會(huì)找到比較滿意的答案。

需求確認(rèn)

需求承諾

需求承諾是指開(kāi)發(fā)方和客戶方的責(zé)任人對(duì)通過(guò)了正式技術(shù)評(píng)審的《軟件需求規(guī)格說(shuō)明書(shū)》作出承諾，該承諾具有商業(yè)合同的效果。需求承諾的模板如下：本《軟件需求規(guī)格說(shuō)明書(shū)》建立在雙方對(duì)需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開(kāi)發(fā)工作根據(jù)該《軟件需求規(guī)格說(shuō)明書(shū)》開(kāi)展

。如果需

求發(fā)生變化，我們將按照

“變更控制規(guī)程”執(zhí)行

。我明白需求的變更

將導(dǎo)致雙方重新協(xié)商成本、

資源和進(jìn)度等。甲方簽字乙方簽字

需求確認(rèn)

需求工程

需求工程結(jié)構(gòu)圖

需求跟蹤概述

需求跟蹤的目的是建立與維護(hù)

“需求-設(shè)計(jì)-編程-測(cè)試”

之間的一致性，確保所有的工作成果符合用戶需求。

需求跟蹤有兩種方式：

正向跟蹤

。

檢查《軟件需求規(guī)格說(shuō)明書(shū)》

中的每個(gè)需求是否都

能在后繼工作成果中找到對(duì)應(yīng)點(diǎn)。

逆向跟蹤

。

檢查設(shè)計(jì)文檔

、

代