軟件需求分析

軟件需求分析

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

軟件需求概述

架構(gòu)師與需求

軟件需求面臨的主要困難

需求工程

需求獲取技術(shù)

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

需求建模

編寫軟件需求規(guī)格說明書

需求確認(rèn)

需求跟蹤技術(shù)

需求變更控制

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

軟件需求概述

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

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

指揮時(shí)拍胸脯——保證沒問題

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

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

軟件需求概述

u需求分析的重要性

軟件需求概述

u

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

軟件需求概述

原因：

需求不明確

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

不充分的計(jì)劃和過于樂觀的評估

盲目采用新技術(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開發(fā)人員可以

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

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

件主題顏色。需求問題

軟件需求概述

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

軟件需求概述

誰需要

什么樣的

東西？

需求的內(nèi)容

軟件需求概述

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

軟件需求概述

馬斯洛人類需求層次理論Maslow,

A.H.

(1943).

A

theory

of

human

motivation.Psychological

Review

50(4)

370–96.

需求的基本概念

IEEE

(1997)

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

(2)

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

檔所需具有的條件或能力

(3)一種反映上面（

1

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

SommervilleandSawyer

(1997)

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

特性或?qū)傩?，是在開發(fā)過程中對系統(tǒng)的約束。

軟件需求概述

客戶、最終用戶&

間接用戶

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

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

“親戚”，同樣怠慢不得

間接用戶：重視“間接用戶”，千萬別“大意失荊州”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)沒有這個(gè)權(quán)限先生很抱歉，系統(tǒng)需要您提交一份能

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

軟件需求概述

需求的重要性

Frederick

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

(NoSilver

Bullet)

中闡述了需求的重要性：

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

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

軟件需求概述

軟件需求概述

軟件需求概述

軟件需求流程

軟件需求概述

需求分類用例文檔項(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)

：通過該系統(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)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常問題定電影《非誠勿擾2》中，秦奮為了表達(dá)對笑笑

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

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

如何完成的需求

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

、

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

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

用戶有不同類型：

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

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

該客戶的代理人

軟件需求概述

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

、

偶用者管理型

、

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

軟件需求概述

系統(tǒng)需求

從系統(tǒng)的角度來說明軟件的需求

包括用特性（feature）

說明的功能需求、

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

非功能需求，

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

功能需求

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

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

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

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

整理（特性、用例）

小結(jié)

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

用戶需求：用戶

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

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

軟件需求概述

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

檔

功能需求▲其它非功能

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

非功能需求

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

可靠性、性

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

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

也稱為“

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

案的一些約束說明

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

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

軟件需求概述

架構(gòu)師與需求

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

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

Requirements

Statement2.

Emerging

Requirements4.Six

Months

Later3.

Redesign

架構(gòu)師與需求

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

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

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

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

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

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

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

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

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

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

而是從事更高層

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

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

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

架構(gòu)師與需求

架構(gòu)師與需求

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

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

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

總覺得需求很糟糕，影響了架構(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í)技能問題

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

學(xué)習(xí)

培訓(xùn)

軟件需求面臨的主要

困難

態(tài)度問題

用戶說不清楚需求或者需求發(fā)生變更—常見的問題

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

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

的用戶需求

軟件需求面臨的主要

困難

合作關(guān)系

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

他們在需求開發(fā)過程中會(huì)很疲憊

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

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

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

需求分析員不是銷售人員，他們不可能象銷售人員那樣

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

。

出色的需求分析員

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

溝通

能力

軟件需求面臨的主要

困難

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

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

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

如果條件允許的話，

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

程的培訓(xùn)

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

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

軟件需求面臨的主要

困難

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

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

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

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

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

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

并對有爭議的需求作出決策

。

如果認(rèn)為

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

可以拒絕在需求文

檔上簽字。

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

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

軟件需求面臨的主要

困難

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

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

1.

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

協(xié)作

，盡可能地為開

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

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

地回答需求分析員的問題。

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

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

相關(guān)的材料。

4.

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

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

軟件需求面臨的主要

困難

用戶說不清楚需求

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

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

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

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

軟件需求面臨的主要

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

五顏六色的黑

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

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

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

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

軟件需求面臨的主要

困難

雙方誤解需求

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

都有可能誤解需求

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

軟件需求面臨的主要

困難

開發(fā)人員寫不好需求文檔

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

了不少需求信息，

卻寫不出好的需求文檔來

。

可以毫不

夸張地說，

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

不及開發(fā)能力

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

熟能生巧

。

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

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

軟件需求面臨的主要

困難

軟件需求面臨的主要

困難如何解決？

需求工程關(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ī)格說明之間的聯(lián)系，關(guān)注以上因素與其隨時(shí)間或跨產(chǎn)品族而演化之后的相關(guān)因

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

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

需求開發(fā)

需求管理

需求工程

什么是需求工程

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

需求工程

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

需求開發(fā)過程域

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

義產(chǎn)品需求

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

，產(chǎn)

生《需求陳述》

。

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

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

。

常見的需求分析方法有

“問答分析法”和“建模分析法”兩類。

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

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

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

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

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

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

需求工程

需求管理過程域

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

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

并控制需

求的變更。

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

雙方對需求

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

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

建立維護(hù)

“需求跟蹤矩陣”

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

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

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

程處理需求變更，

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

需求工程

需求工程

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

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

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

同用戶類的需要和限制的過程

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

一步

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

及最需要交流的方面

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

說需求的簡單拷貝

需求獲取技術(shù)

需求獲取技術(shù)

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

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

調(diào)查問卷

座談

考察、培訓(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ù)

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

需求獲取技術(shù)

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

需求的來源

訪問并與有潛力的用戶探討

市場調(diào)查和用戶問卷調(diào)查

觀察正在工作的用戶

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

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

表格和報(bào)表等

把對目前的競爭產(chǎn)品的描述寫成文檔

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

需求獲取技術(shù)

獲取需求的方法

面談（訪談）

問卷調(diào)查

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

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

文檔研究

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

用例與角色扮演

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

研究類似公司

需求獲取技術(shù)

面談

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

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

局限就是需求獲取障礙

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

技巧：錄音筆

需求獲取技術(shù)

需求獲取技術(shù)

面談

開放式問題（Open-Ended）

封閉式問題（Closed）

面談-開放式問題

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

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

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

開放

式問題比較合適

例如：

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

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

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

需求獲取技術(shù)

開放式問題的優(yōu)缺點(diǎn)優(yōu)點(diǎn)

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

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

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

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

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

會(huì)見者可以在沒有太多準(zhǔn)

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

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

細(xì)節(jié)；

面談可能失控；

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

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

息量；

可能會(huì)使會(huì)見者看上去沒

有準(zhǔn)備。

需求獲取技術(shù)

面談-封閉式問題

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

例如：

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

“

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

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

（

1）

填好的客戶投訴單；

（

2

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

（

3）

與客戶面對面的

交流

；（4）

退回的貨物。”

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

需求獲取技術(shù)

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

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

切中要點(diǎn)；

保持對面談的控制；

快速探討大范圍問題；

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

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

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

失去主要思想；

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

需求獲取技術(shù)

需求獲取技術(shù)

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

低

低

廣

多

難高

高

高

窄

少

易需要的面談技能封閉式問題開放式問題分析的難易度

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

金字塔型

漏斗型

菱形

需求獲取技術(shù)

你碰到的防火墻問題有什么

特殊性

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

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

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

里的安全性更有效

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

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

需求獲取技術(shù)

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

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

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

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

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

息的價(jià)值是什么需求獲取技術(shù)通過使用這項(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工人，營銷5人。

解答：（

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

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

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

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

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

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

形(必要時(shí)，

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

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

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

面談

需求獲取技術(shù)

問卷調(diào)查

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

查方

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

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

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

分、問卷總結(jié)等

需求專題討論會(huì)

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

頭腦風(fēng)暴

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

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

實(shí)施

總結(jié)

需求獲取技術(shù)

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

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

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

流程的

貌，同作流程

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

改

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

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

需求獲取技術(shù)

文檔研究

文檔研究

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

反映了組織的信息流

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

、

填寫和分發(fā)說明

對比填寫好的表格–

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

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

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

–

等等

需求獲取技術(shù)

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

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

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

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

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

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

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

執(zhí)行狀況，

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

需求獲取技術(shù)

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

組織描述文檔

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

門戶網(wǎng)站

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

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

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

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

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

形成對組織工作過程的清晰理解

需求獲取技術(shù)

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

觀察

現(xiàn)場證所可

觀察也

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

需求獲取技術(shù)

用例和角色扮演

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

需求獲取技術(shù)

戶做什么。

原型開發(fā)

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

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

為

“模糊”需求建立原型

需求獲取技術(shù)

需求陳述

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

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

需求陳述用來明確軟件的用途，

它不僅要說明軟件有什

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

需求獲取技術(shù)

需求獲取技術(shù)

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

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

是什么？

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

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

附加內(nèi)容：

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

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

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

一個(gè)接待員

。

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

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

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

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

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

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

。

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

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

需求獲取技術(shù)

需求陳述用例圖

挖掘隱性需求

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

接得到的需求；

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

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

需求獲取技術(shù)

需求工程

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

需求理解的大局觀

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

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

必屬于功能

、質(zhì)量

、

約束這三類需求的某一類

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

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

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

需求分類

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

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

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

素+

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

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

需求的層次化

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

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

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

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

求

？

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

架構(gòu)

？

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

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

FlyJewelry在它的

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

可是，

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

同步

。

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

、

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

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

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

此外

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

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

利可圖，是否帶來其他的銷售

。

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

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

。

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

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

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

需求的層次化：

案例分析

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

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

二維需求矩陣

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

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

需求模型分類

用例建模

(UC)

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

(DFD)

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

(ER)

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

需求建模

Unified

Modeling

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

用例建模技術(shù)

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

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

用例建模技術(shù)

視用戶圖

用例建模（

Use

Case

Modeling）

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

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

用例建模主要包括：

用例圖(UseCase

Diagram)

用例描述文檔

(UseCaseSpecification)

用例建模技術(shù)

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

用例建模技術(shù)

用例圖用例模型

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

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

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

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

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

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

但是網(wǎng)

上預(yù)訂只能通過信用卡進(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ù)訂，也可以直接去酒店通過

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

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

(3)

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

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

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

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

進(jìn)行通信；

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

繪制用例圖

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

(1)顧客

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

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

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

(3)

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

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

上預(yù)訂只能通過信用卡進(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ì)約束書寫用例文檔

用例的內(nèi)容

基本路徑

通過控制流程圖分離出主要的用例

書寫用例文檔

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

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

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

書寫用例文檔

基本路徑書寫準(zhǔn)則

只書寫“可觀測”的（說人話）

使用主動(dòng)語句

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

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

分支和循環(huán)

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

書寫用例文檔

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

…系統(tǒng)按照查詢條件搜索零件只書寫“可觀測”的對錯(cuò)

書寫用例文檔

基本路徑歐文從貝克漢姆處得到傳球，守門

員…貝克漢姆傳球給歐文，歐文射門，

守門員撲救…

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

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

書寫用例文檔

使用主動(dòng)語句

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

書寫用例文檔

基本路徑用戶提交表單

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

“

”

查…

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

書寫用例文檔

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

書寫用例文檔

用例文檔實(shí)例

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

查

，

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

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

功能需求的完備性

模型是否易于理解

是否存在不一致性

避免語義二義性

檢查用例模型

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

檢查用例模型

用例檢查表

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

需求模型分類

用例建模

(UC)

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

(DFD)

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

(ER)

需求建模

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

Flow

Diagram,

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

它以圖形的

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

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

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

非法請求信息

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

自外向內(nèi)，

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

完善求精

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

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

讀者情況

非法查詢請求信息

2處理查詢請求▲

圖書目錄文件借書文件3登記讀者信息1處理管理請求非法管理工作請求信息

罰款單

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

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

Entity-Relation

Modeling

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

實(shí)體：矩形框

屬性：

圓形

聯(lián)系：線

概念模型

學(xué)生課程

m

學(xué)習(xí)

n

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

概念模型

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

*

收費(fèi)

1

*

1醫(yī)師門診處方1

1

開處方

*

數(shù)量

單價(jià)*

*出診

生成

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

明細(xì)

11*

需求工程

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

軟件需求規(guī)格說明書

(SRS)

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

(Software

RequirementSpecification,SRS)

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

、

開發(fā)人員及測

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

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

實(shí)現(xiàn)

、

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

需要及時(shí)更新

編寫軟件需求規(guī)格說

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

i;}規(guī)格說明書

編寫軟件需求規(guī)格說

明書

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

機(jī)器域程序需求

正確性

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

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

如果“

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

檔就能解決問題。

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

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

為確保需

求是正確的，

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

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

編寫軟件需求規(guī)格說

明書

清楚性

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

。

清楚的

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

可以采用反問的方式來判斷需求文檔是否清楚：

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

上下文是否不連貫？

文檔的語句是否含糊其詞

、

羅里羅嗦？每句話都是對的，

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

編寫軟件需求規(guī)格說

明書

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

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

求的產(chǎn)品。

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

編寫軟件需求規(guī)格說

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

無二義性

一致性（Consistency）

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

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

盾

。

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

編寫軟件需求規(guī)格說

明書

必要性

《軟件需求規(guī)格說明書》

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

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

么是“錦上添花”。

“

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

作。所以要盡量剔除“

畫蛇添足”的需求。

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

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

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

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

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

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

編寫軟件需求規(guī)格說

明書

完備性

《軟件需求規(guī)格說明書》

中沒有遺漏一些必要的需求。

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

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

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

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

編寫軟件需求規(guī)格說

明書

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

《軟件需求規(guī)格說明書》

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

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

并且滿足時(shí)間、

費(fèi)用、

質(zhì)量等約束。

營銷人員和用戶談生意時(shí)，

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

提出的需求“來者不拒”。

吹牛雖然不犯法，

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

《軟件需求規(guī)格說明書》

中的內(nèi)容，

那就是違約。

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

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

則應(yīng)事

先與用戶協(xié)商，

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

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

編寫軟件需求規(guī)格說

明書

可驗(yàn)證性

《軟件需求規(guī)格說明書》

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

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

Verifiable）

。

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

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

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

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

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

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

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

編寫軟件需求規(guī)格說

明書

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

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

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

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

、

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

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

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

做

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

費(fèi)用

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

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

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

低”三級(jí)

。

一般地，

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

先級(jí)。

編寫軟件需求規(guī)格說

明書

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

《軟件需求規(guī)格說明書》

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

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

段的事情。

很多軟件公司里，

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

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

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

這

并沒有什么過錯(cuò)。

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

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

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

檔里就行了。

編寫軟件需求規(guī)格說

明書

編寫軟件需求規(guī)格說

明書

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

需求工程

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

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

需求規(guī)格說明書》

進(jìn)行評審，

雙方對需求達(dá)

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

工作

：“需求評審”和“需求承諾”。

需求確認(rèn)

需求評審面臨的困難

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

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

。

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

越到后頭越馬虎。

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

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

。

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

需求確認(rèn)

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

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

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

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

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

。

適當(dāng)?shù)臓幾h有利于澄清

問題

，然而當(dāng)爭議變?yōu)闋幊硶r(shí)就壞事了：爭吵不僅對評

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

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

的觀點(diǎn)，

嘗試著讓自己站在他人的立場思考問題，這樣

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

需求確認(rèn)

需求承諾

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

。如果需

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

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

。我明白需求的變更

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

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

需求確認(rèn)

需求工程

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

需求跟蹤概述

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

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

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

需求跟蹤有兩種方式：

正向跟蹤

。

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

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

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

逆向跟蹤

。

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

、

代