軟件需求實(shí)踐(一)

需求分析師培訓(xùn)第一課需求與需求工程需求是什么?業(yè)務(wù)需求就是系統(tǒng)目標(biāo)業(yè)務(wù)需求是指反映組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常問題定義本身就是業(yè)務(wù)需求?，F(xiàn)狀：功能分解盛行的今天，常常會犯“盲人摸象”的錯誤，這使得需求太過脆弱，難以經(jīng)受考驗(yàn)。目標(biāo)的定義不能夠流于形式，應(yīng)該具有以下特征：業(yè)務(wù)導(dǎo)向、可度量、合理、可行。要

注意目標(biāo)太夸大會浪費(fèi)資源，目標(biāo)

太縮小會影響士氣。（教堂與小屋）目標(biāo)通常就是業(yè)務(wù)需求！

用戶需求用戶需求是指描述用戶使用產(chǎn)品必須要完成什么任務(wù)，怎么完成的需求，通常是在問題定義的基礎(chǔ)上進(jìn)用戶訪談、調(diào)查，對用戶使用的場景進(jìn)行整理，從而建立從用戶角度的需求。用戶有不同類型：

>管理型、事務(wù)型>信息系統(tǒng)、人

>決策層、使用層>常用者、偶用者例子：對快到期的客戶，系統(tǒng)將通過短信

將續(xù)保信息發(fā)給該客戶的代理人軟件需求從系統(tǒng)實(shí)現(xiàn)的角度描述的需求。開發(fā)人員（設(shè)計(jì)及分析人員）在業(yè)務(wù)需求、用戶需求的基礎(chǔ)上生成的。有時還需要考慮相關(guān)聯(lián)的硬件、環(huán)境方面的需求

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

用戶需求

軟件需求需求定義需求捕獲需求分析功能需求功能需求是需求的主體，是需求的本質(zhì)功能需求定義了：系統(tǒng)必須完成的那些事，即為了向它的用戶提供有用的功能，產(chǎn)品必須執(zhí)行的動作功能需求也稱為行為需求零散（需求項(xiàng)）整理（特性、用例、用戶故事）功能需求的要點(diǎn)在于組織!質(zhì)量屬性產(chǎn)品必須具備的屬性或品質(zhì)McCall體系：運(yùn)行(正確性、可靠性、效率、

完整性、使用性)、修正(維護(hù)性、測試性、

靈活性)、轉(zhuǎn)移(移植性、復(fù)用性、共運(yùn)行性)非功能需求重在有效傳遞!1)定性

場景

定量2)全局

局部+全局3)零散

可追蹤設(shè)計(jì)約束也稱為限制條件、補(bǔ)充規(guī)約，這通常是對解決方案的一些約束說明。例如：必須采用國有自主知識版權(quán)的數(shù)據(jù)庫系統(tǒng)…再如：必須運(yùn)行在UNIX操作系統(tǒng)之下三如：用戶將在戶外完成作業(yè)1)非技術(shù)因素決定的技術(shù)選型2)預(yù)期的軟硬件環(huán)境3)預(yù)期的使用環(huán)境需求的“冰山模型”與應(yīng)對需求與需求工程需求開發(fā)與管理需求開發(fā)活動需求定義的工作內(nèi)容出發(fā)點(diǎn)：問題/機(jī)會項(xiàng)目目標(biāo)(業(yè)務(wù)需求)

如何破解混沌不清的項(xiàng)目目標(biāo)?

產(chǎn)物：

項(xiàng)目型：POS文檔

產(chǎn)品型：Vision文檔明確項(xiàng)目的范圍：

傳統(tǒng)模式：列出功能模塊

合理模式：可行性研究：技術(shù)、經(jīng)濟(jì)、社會、……

內(nèi)部溯源

外部尋因列出涉及的人和事需求定義的時機(jī)正常模式：項(xiàng)目立項(xiàng)時

負(fù)責(zé)人：由業(yè)主/產(chǎn)品經(jīng)理完成

問題：現(xiàn)在通常做得不好

原因：立項(xiàng)結(jié)果較空(目標(biāo)空/范圍空)補(bǔ)救模式：項(xiàng)目開工前

困難：大多數(shù)人感到多此一舉

必要性：（“六拍”項(xiàng)目經(jīng)理）需求獲取的誤區(qū)應(yīng)收集什么信息：

>問題域的描述--業(yè)務(wù)模型

>要求解決的問題列表（需求）

>用戶對解系統(tǒng)的行為或結(jié)構(gòu)施加的任何約束缺乏計(jì)劃性：隨意、走過場，預(yù)先沒計(jì)劃缺乏科學(xué)性：未從本質(zhì)入手捕獲對象不明確，甚至造成岐義過于迷信現(xiàn)有文檔過于迷信“聽”到的東西需求獲取技術(shù)閱讀背景資料頭腦風(fēng)暴討論分析文檔考古面談（用戶訪談）聯(lián)合開發(fā)用戶調(diào)查需求剝離現(xiàn)場觀摩情節(jié)串聯(lián)板用例和場景編寫規(guī)約“正規(guī)”的開發(fā)組織都重視，但?！爸匾曔^度”

束之高閣

事后補(bǔ)文檔規(guī)格說明書的格式與所采用的開發(fā)過程、分析方法相關(guān)的，不同的方法格式不同需求驗(yàn)證這個工作大多數(shù)組織都不夠重視，導(dǎo)致這個工作直到交付系統(tǒng)時才真正被履行，這也就是為什么客戶拿到系統(tǒng)后才提出許多這樣那樣的需求變更，甚至認(rèn)為整個系統(tǒng)都不是他所需要的提高需求質(zhì)量的重要手段：

>需求評審

>需求確認(rèn)

>通過原型來驗(yàn)證需求Review是手段，暴露盡可能

多的錯誤是目標(biāo)需求開發(fā)與需求管理的分界需求管理vs.項(xiàng)目管理需求管理的主題是“需求項(xiàng)”，關(guān)乎優(yōu)先級、盡力滿足；項(xiàng)目管理的主題是“項(xiàng)目”，關(guān)乎成本、進(jìn)度需求管理是項(xiàng)目管理的支撐

WBS

優(yōu)先級

基線需求管理管理的是項(xiàng)目中的價(jià)值維需求管理是項(xiàng)目管理的子集現(xiàn)代需求理論的關(guān)鍵思想WorkDownValueAdd基于系統(tǒng)結(jié)構(gòu)的縱向視角

基于使用場景的橫向視角瀑布模型

迭代、增量RUP的核心思想：用例驅(qū)動，架構(gòu)為中心，迭代、增量的開發(fā)過程XP、FDD：迭代、增量的開發(fā)過程，用戶故事/Feature驅(qū)動需求管理的主要活動基線：救火隊(duì)

嚴(yán)謹(jǐn)團(tuán)隊(duì)變更：不是避免，而是控制。通過統(tǒng)一渠道、統(tǒng)一平臺（并分類）做到避免錯誤產(chǎn)生的變更、減少變化產(chǎn)生的變更跟蹤：高階活動，包括用戶需求

軟件需求，軟件需求

軟件需求、軟件需求

設(shè)計(jì)原則的跟蹤版本控制：歷史變化的管理與跟蹤狀態(tài)管理：管理過程中的動作需求與需求工程需求分析所謂分析是指通過對問題域的研究，獲得對該領(lǐng)域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明分析方法：數(shù)據(jù)結(jié)構(gòu)+算法=程序、結(jié)構(gòu)化分析法、面向?qū)ο蠓治龇ㄈ魏畏治龇?，均需描述以下幾個方面:

>問題域的結(jié)構(gòu)

>問題子域的固有屬性及行為

>問題域中的重要事件及現(xiàn)象

>需求：應(yīng)產(chǎn)生的效果需求分析--內(nèi)容與形式需求分析與建模不應(yīng)該是孤立的行為，產(chǎn)生的結(jié)果也不一定非得是規(guī)范度很高的標(biāo)準(zhǔn)文檔，而應(yīng)該重在分析、重在方法、重在交流、重在解決問題團(tuán)隊(duì)聚在一起，利用白板甚至是紙張，在充分的合作下進(jìn)行分析與初步建模是成本最低、效率最高、實(shí)用性最強(qiáng)的方法對于這些活動所產(chǎn)生的結(jié)果，可以利用數(shù)碼相機(jī)、掃描儀進(jìn)行文檔化，“直到你一定要用時，再寫文檔”對于比較重要、核心的內(nèi)容，再采用Rose、Together這樣的工具進(jìn)行文檔化信息系統(tǒng)的基本類型信息系統(tǒng)需求的本質(zhì)1流程電子化--業(yè)務(wù)事件為中心

>利用信息化系統(tǒng)改進(jìn)、固化流程

>事務(wù)處理系統(tǒng)尤其明顯

>工作流定義、流程改進(jìn)、再造

>工作流模型數(shù)據(jù)信息化--Report為中心

>業(yè)務(wù)術(shù)語，業(yè)務(wù)實(shí)體

>需要留存哪些數(shù)據(jù)？誰需要共享？

>需要什么報(bào)表？有哪些數(shù)據(jù)分析規(guī)則？OLTP的需求線索：業(yè)務(wù)事件目標(biāo)：流程電子化傳統(tǒng)問題1：過早考慮程序結(jié)構(gòu)OLTP的需求線索：業(yè)務(wù)事件傳統(tǒng)問題2：流程太零散

流程是分層的：把握管理視野

流程基本分類：生產(chǎn)類、管理類、支撐類業(yè)務(wù)事件是流程的觸發(fā)點(diǎn)BPR、BPD？MIS的需求線索：Report何時開始梳理此類需求？實(shí)施要點(diǎn)：類別要點(diǎn)說明Why目的從管理場景出發(fā)，借助對管理控制點(diǎn)的理解來理解報(bào)表的目的使用部門/職位了解報(bào)表的使用者，以便有針對性地調(diào)研相關(guān)場景諸如用戶數(shù)量、查詢頻率等非功能性場景描述What關(guān)聯(lián)實(shí)體以類圖或E-R圖表示，說明數(shù)據(jù)的來源關(guān)鍵指標(biāo)及計(jì)算規(guī)則細(xì)化推導(dǎo)出關(guān)聯(lián)的字段，以及派生屬性的計(jì)算方法，指導(dǎo)報(bào)表數(shù)據(jù)視圖的實(shí)現(xiàn)How展現(xiàn)形式以虛擬窗口等形式說明最終的呈現(xiàn)方式輸入輸出需要說明是否打印，以什么格式提供等其他信息報(bào)表的常見分類信息系統(tǒng)需求的本質(zhì)2個人知識轉(zhuǎn)換為企業(yè)知識--模型為中心

>將知識工作的經(jīng)驗(yàn)轉(zhuǎn)換成模型

>業(yè)務(wù)場景的分析與抽象是重點(diǎn)

>提高速度、提高質(zhì)量信息決策化--決策模型為中心

>業(yè)務(wù)場景的分析與抽象是重點(diǎn)

>將非程序化問題分解

成多個子問題

>提出所需的數(shù)據(jù)模型、經(jīng)驗(yàn)?zāi)Ｐ筒煌暯窍碌男畔⑾到y(tǒng)需求大綱--SERU模型Subject：主題域，將一個復(fù)雜的大系統(tǒng)分解成由確定接口相互連接的多個子系統(tǒng)—構(gòu)件圖