軟件需求最佳實踐

出版時間:2008  出版社:電子工業(yè)出版社  作者:徐峰  頁數(shù):396  
Tag標(biāo)簽:無  

前言

  寫一本書不容易,寫一本讓自己滿意的書更不容易,而寫一本讓讀者喜歡的書則是難上加難?;蛟S這一“冠冕堂皇”的理由可以作為筆者一再錯過向關(guān)注本書的讀者所承諾的上市時間的借口。但是沒有任何理由可以讓筆者松懈下來,畢竟自己一直在標(biāo)榜要解決“我們并不缺乏需求的理論,缺少的是真正落地的方法”的問題,為所有讀者提供一種切實可行的實踐手段,是筆者寫作本書的核心目標(biāo)?! ≡诜x本書時,或許你會從本書的字里行間讀到幾分輕松,這是因為書中有不少的文字是筆者在風(fēng)景秀麗的員當(dāng)湖畔的咖啡廳里寫就的,希望筆者這種輕松的心情能夠透過這些文字傳遞給每位工作在“沉重”的需求分析過程中的所有讀者?! ≡诩?xì)究本書時,或許你會從本書的文字里頭看到幾處零亂,這是因為文中有很多的段落是筆者在吚哎學(xué)語的一歲小兒的惡作劇邊碼成的,希望筆者這些零碎的想法能夠借助書的脈絡(luò)傳達(dá)給每位工作在“繁雜”的需求分析原則下的所有讀者。  在將書稿交付編輯之時,我深刻地感到:本書雖然沒有Martin七年磨一劍的鋒芒,卻也有三年憋一本的艱辛。在整個寫作過程中,多次經(jīng)歷了自我否定、推倒重來的痛苦,也享受了許多自我升華的樂趣;當(dāng)然筆者衷心地希望本書能夠向大家傳遞樂趣。

內(nèi)容概要

  本書首先從軟件需求實踐中出現(xiàn)的主要問題和困難入手,指出了改進(jìn)的主要方向;然后逐一說明了需求定義、需求捕獲、需求分析與建模、編寫規(guī)約、需求驗證等需求開發(fā)活動的任務(wù)、要點和具體手段;并提出了一個可操作性強、易于上手的SERU過程框架,能夠幫助讀者清晰地了解整個過程,理解各階段的關(guān)鍵產(chǎn)物和產(chǎn)物之間的關(guān)系?! ”緯€對包括需求基線、變更管理、需求跟蹤在內(nèi)的需求管理活動的操作要點進(jìn)行了闡述,給出了具有很強實踐性的具體建議。綜觀全書,語言淺顯、文字生動,蘊含了許多人文、心理、交流方面的知識,即使非技術(shù)背景的讀者也能夠輕松讀懂大部分內(nèi)容,從中受益?! ”緯勺鳛橛嬎銠C(jī)軟件專業(yè)本科生、研究生和軟件工程碩士的軟件需求分析教材,也可以作為軟件工程、軟件開發(fā)管理培訓(xùn)的教材,更是一線項目經(jīng)理、需求分析人員、資深開發(fā)人員、信息系統(tǒng)運行管理人員、研發(fā)企業(yè)管理人員的必備參考書。

作者簡介

  徐鋒,中國系統(tǒng)分析員顧問團(tuán)(CSAI)軟件工程首席顧問,中國軟件技術(shù)大會杰出貢獻(xiàn)專家,資深咨詢顧問、培訓(xùn)講師。主要研究領(lǐng)域為需求工程、系統(tǒng)分析與設(shè)計、軟件估算,致力于推動軟件工程方法論的落地應(yīng)用。作者具有聿富的軟件開發(fā)、信息系統(tǒng)運行與管理、市場規(guī)劃、企業(yè)管理等領(lǐng)域的從業(yè)經(jīng)驗,善于從業(yè)務(wù)、技術(shù)兩個視角審視軟件開發(fā)工作?!   ≡凇冻绦騿T》等媒體發(fā)表了《實戰(zhàn)OO》、《項目管理三步曲》、《大話Design》等多個專欄文章,著有《UML面向?qū)ο蠼;A(chǔ)》等多本書籍,翻譯了(UML 2.O實戰(zhàn)》、《AOSD中文版》、《Cloud to CodedP文版》等多本技術(shù)書籍。

書籍目錄

第1部分 原理、模型與誤區(qū)第1章 需求實踐現(xiàn)狀分析	2在信息化高速發(fā)展的今天,構(gòu)建與時俱進(jìn)的信息化系統(tǒng)已成為所有政府、企事業(yè)單位的重點課題之一。然而在軟件項目實施過程中,進(jìn)度超期、經(jīng)費超預(yù)算、變更頻繁的現(xiàn)象層出不窮,甚至有許多項目根本無法達(dá)到預(yù)期的目標(biāo),更談不上為業(yè)主創(chuàng)造真正的效益。歸根結(jié)底,軟件需求實踐這一共同的軟肋是問題的根源。1.1 軟件項目失敗的根源	21.1.1 CHAOS Report 1994	21.1.2 CHAOS Report后續(xù)版本	31.1.3 需求相關(guān)敗因簡要分析	41.1.4 一幅漫畫帶來的思考	81.2 透過表象,分析本質(zhì)	121.2.1 需求變更頻繁	121.2.2 上線阻力大	131.2.3 運行效果差	141.2.4 完全崩潰	151.3 方法論與需求工作	161.3.1 計算模式	161.3.2 軟件工程方法論	171.3.3 開發(fā)思想	181.4 小結(jié)	19第2章 不同軟件項目的需求視圖	20隨著信息化應(yīng)用的逐漸深入,軟件項目在企業(yè)、政府等各類組織中所擔(dān)負(fù)的角色也越來越多,應(yīng)用層面也在逐漸地深入,同時也意味著不同的軟件項目具有不同的特點,這也就對需求工作產(chǎn)生了諸多影響。 在本章中,我們就將針對信息系統(tǒng)、嵌入式系統(tǒng)、軟件產(chǎn)品等不同角度來說明如何進(jìn)行相應(yīng)的需求工作,為需求分析師提供一個切實有效的視圖。2.1 信息系統(tǒng)的需求視圖	202.1.1 信息系統(tǒng)的本質(zhì)與分類	202.1.2 聯(lián)機(jī)事務(wù)處理系統(tǒng)——流程電子化	222.1.3 管理信息系統(tǒng)——數(shù)據(jù)信息化	252.1.4 其他信息系統(tǒng)	292.1.5 信息系統(tǒng)的多維視圖	312.2 嵌入式系統(tǒng)的需求視圖	332.2.1 面向直接用戶的嵌入式系統(tǒng)	342.2.2 面向特定設(shè)備的嵌入式系統(tǒng)	352.3 軟件產(chǎn)品的需求視圖	362.4 小結(jié)	40第3章 軟件需求與需求工程	41筆者在做需求分析師的培訓(xùn)時,經(jīng)常會問學(xué)員這樣的一個問題:什么是軟件需求?這個看似簡單的問題卻并不好回答,也許很多人會簡單地認(rèn)為軟件需求就是用戶需要實現(xiàn)的功能加上一些非功能方面的要求。但這樣的理解卻并不完整,如果對用戶所處的業(yè)務(wù)場景沒有建立正確認(rèn)識,經(jīng)常會給工作帶來麻煩。因此本章將對一些與需求、需求工程相關(guān)的關(guān)鍵概念進(jìn)行闡釋。3.1 什么是軟件需求	413.1.1 需求的三個層次	413.1.2 需求的三種類型	433.1.3 優(yōu)秀需求的標(biāo)準(zhǔn)	463.2 需求工程解析	503.2.1 需求工程的范疇	503.2.2 需求開發(fā)工作要點	513.2.3 需求管理工作要點	563.2.4 需求分析人員的技能組成	583.2.5 SERU模型概述	593.3 小結(jié)	61第2部分 需求開發(fā)第4章 需求定義最佳實踐	64需求定義活動準(zhǔn)確來說是不屬于需求工程范疇的,它實際上是立項管理需要做的工作。但需求定義階段的產(chǎn)物對于需求捕獲、分析與建?;顒佣加兄苯拥挠绊懀绻@個階段的工作做得不理想,就會出現(xiàn)“上梁不正下梁歪”的結(jié)果。因此本書還是將這個活動納入進(jìn)來,并將給大家提供一個能夠與后續(xù)活動結(jié)合緊密的方法。4.1 需求定義任務(wù)概述	644.1.1 需求定義的時機(jī)	644.1.2 需求定義的理念與策略	654.2 問題分析的五步法	664.2.1 在問題定義上達(dá)成共識	674.2.2 分析問題背后的問題	734.2.3 確定相關(guān)人員和用戶	774.2.4 定義解決方案的界限	784.2.5 確定加在解決方案上的約束	804.2.6 小結(jié)	814.3 需求定義的產(chǎn)物與要素	814.3.1 需求定義的產(chǎn)物	814.3.2 需求定義的要素	824.4 定義需求范圍	874.4.1 案例說明	874.4.2 劃分主題域	884.4.3 確定主題域范圍	974.4.4 標(biāo)識業(yè)務(wù)事件與報表	1014.4.5 生成需求大綱	1044.5 小結(jié)	108第5章 需求捕獲最佳實踐	109需求捕獲是需求開發(fā)中的第一個活動,可以說任何一個需求團(tuán)隊對它都不陌生,但如何提高需求捕獲的有效性卻一直以來是困擾大家的問題。需求捕獲的要點在于計劃性和科學(xué)性,計劃性體現(xiàn)在對捕獲對象、問題、時間的計劃,科學(xué)性則表現(xiàn)在如何有效地選擇合適的捕獲方法。本章的目的就在于幫助大家更好地達(dá)到這兩個目標(biāo),從而提高需求捕獲活動的質(zhì)量。5.1 需求捕獲的策略	1095.1.1 需求捕獲應(yīng)該是主動的	1095.1.2 需求捕獲應(yīng)該是聚焦的	1105.1.3 破解需求的冰山模型	1115.1.4 破解阻礙需求捕獲的心理現(xiàn)象	1135.1.5 不要忽視對變更可能的捕獲	1175.1.6 需求協(xié)商	1185.2 需求捕獲的主要方法	1255.2.1 用戶訪談	1255.2.2 用戶調(diào)查	1375.2.3 文檔考古	1425.2.4 情節(jié)串聯(lián)板	1445.2.5 現(xiàn)場觀摩	1455.2.6 聯(lián)合開發(fā)	1475.3 需求捕獲的記錄工具	1505.3.1 工具的選擇與定義	1505.3.2 任務(wù)卡片	1515.3.3 場景說明	1525.3.4 其他工具	1535.4 小結(jié)	154第6章 需求分析與建模最佳實踐	156需求分析是需求工程中最為核心的工作,而需求建模則是需求分析的主要手段。但由于分析這個詞比較抽象,很多時候讓人感到無從入手,甚至導(dǎo)致被輕易地滑過了,直接將需求捕獲的結(jié)果整理到軟件需求規(guī)格說明書中。而需求建模也有很多工具,到底怎么有效地應(yīng)用到需求分析過程中也是令人感到難以掌握的東西。因此本章的目標(biāo)就是為讀者勾勒出需求分析的階段與任務(wù),指出如何選擇適合的建模工具,以及在什么時機(jī)、如何應(yīng)用這些建模工具。6.1 需求分析與建模的要點與誤區(qū)分析	1566.1.1 需求分析到底做什么	1566.1.2 建模的目標(biāo)與要點	1596.1.3 選擇建模工具的要點	1606.2 周期一:理清框架與脈絡(luò)	1646.2.1 業(yè)務(wù)流程分析	1656.2.2 業(yè)務(wù)實體分析	1916.2.3 角色與使用場景分析	2166.2.4 周期一的產(chǎn)物	2326.3 周期二:確定需求細(xì)節(jié)	2496.3.1 確定行為需求的細(xì)節(jié)	2506.3.2 確定結(jié)構(gòu)需求的細(xì)節(jié)	2706.3.3 周期二的產(chǎn)物	2796.4 其他需求分析	2926.4.1 接口需求	2926.4.2 非功能需求的追蹤	2946.4.3 設(shè)計約束	2976.5 小結(jié)	301第7章 需求描述最佳實踐	302需求描述就是將需求捕獲、分析的結(jié)果進(jìn)行文檔化的過程。在軟件開發(fā)時,將分析的結(jié)果文檔化是不可或缺的任務(wù),也稱為編寫規(guī)約活動;而在某個項目中,可能還會由用戶代表或需求捕獲人員對捕獲的內(nèi)容進(jìn)行整理,形成用戶需求說明書。具體要干什么,想必大家并不陌生,而且在前一章中也看到了一些實例的片段。因此本章將重點從需求描述的風(fēng)格與格式、寫作策略與技巧兩個方面做些強調(diào)和補充。7.1 需求描述的風(fēng)格與格式	3027.1.1 常見的描述風(fēng)格與選用標(biāo)準(zhǔn)	3027.1.2 典型軟件需求規(guī)格說明書模板解析	3037.1.3 定義模板的技巧	3187.1.4 用戶需求說明與軟件需求規(guī)格說明	3267.2 寫作策略與技巧	3287.2.1 文字表達(dá)的先天不足	3287.2.2 需求描述的兩大原則	3307.2.3 不要忽視陳述需求理由的重要性	3327.2.4 注意措辭	3347.3 小結(jié)	335第8章 需求驗證最佳實踐	336需求驗證是需求開發(fā)的最后一個環(huán)節(jié),它是一個質(zhì)量關(guān)。也就是說,其目標(biāo)是發(fā)現(xiàn)盡可能多的錯誤,減少因為需求的錯誤而帶來的工作量浪費。而需求驗證的主要手段就是Review(復(fù)查,也常譯為評審)。但是許多需求團(tuán)隊都覺得需求驗證比較容易變得“務(wù)虛”,收效很少,本章的目標(biāo)就是幫助大家緩解這個問題。8.1 需求驗證的主要手段	3368.1.1 不同正式化程度的評審	3368.1.2 審查過程概述	3388.2 需求驗證的主要誤區(qū)與解決方案	3408.2.1 需求驗證的5大要點	3418.2.2 需求驗證常見的5大問題	3448.3 小結(jié)	346第3部分 需求管理第9章 需求基線操作實務(wù)	348需求基線是需求管理活動中最為基礎(chǔ)的一個,通常也是在項目中首先應(yīng)該引入的管理活動。但許多相關(guān)書籍中對需求基線的介紹相對比較理論化,很少給出具體的操作方法,往往使得許多軟件開發(fā)團(tuán)隊無從入手。為了幫助大家更好地引入需求基線,本章的重點將是結(jié)合具體的實例來說明需求基線的劃分方法。9.1 需求基線的理念與策略	3489.1.1 基線思想的起源	3489.1.2 基線的策略	3509.2 基線劃定的基礎(chǔ):優(yōu)先級評價	3519.2.1 組織需求項	3519.2.2 業(yè)務(wù)優(yōu)先級評價	3529.2.3 根據(jù)技術(shù)依賴性和項目風(fēng)險調(diào)整優(yōu)先級	3569.3 基線劃定的要素:工作量估算	3569.3.1 估算的意義與要點	3569.3.2 定義階段的估算示例	3589.3.3 分析一階段的估算示例	3619.4 基線劃定與管理	3629.4.1 劃定基線	3629.4.2 管理基線	3639.5 小結(jié)	364第10章 變更管理操作實務(wù)	365需求變更頻繁恐怕是困擾無數(shù)軟件開發(fā)團(tuán)隊的惡魔之首,而且在美國權(quán)威的第三方機(jī)構(gòu)Standish Group的CHAOS報告中,也將其列為困擾軟件開發(fā)團(tuán)隊、導(dǎo)致項目失敗的5大原因之一,其中原因?qū)嶋H上也充分暴露了整個產(chǎn)業(yè)的不成熟。需求變更在CHAOS報告中是排名第四的問題,而在中國軟件開發(fā)團(tuán)隊中卻是排名第一的問題,這里面就意味著存在距離,本章的目的就是希望幫助大家找到其中的差距。10.1 變更管理的理念	36510.2 變更管理要點一:統(tǒng)一渠道	36610.2.1 CCB背后的道理	36610.2.2 變更處理過程	36810.3 變更管理要點二:統(tǒng)一平臺	37310.3.1 變更管理平臺的選擇	37310.3.2 變更管理平臺的應(yīng)用要點	37410.4 小結(jié)	375第11章 需求跟蹤操作實務(wù)	376需求跟蹤是一個高階的管理活動,它的目標(biāo)是為了更好地管理需求的狀態(tài)、更好地分析需求變更產(chǎn)生的影響。雖然執(zhí)行需求跟蹤會帶來不錯的效益,但其所需付出的工作量也是巨大的。本章我們就對跟蹤的一些要點做一簡要的說明。11.1 需求跟蹤的基本概念	37611.1.1 用戶需求到軟件需求的跟蹤	37711.1.2 軟件需求到軟件需求的跟蹤	37711.1.3 軟件需求到下游工作產(chǎn)品的跟蹤	37711.2 需求跟蹤的操作方法	37811.2.1 表格法	37811.2.2 鏈表法	37911.3 小結(jié)	381第4部分 總結(jié)第12章 SERU過程框架總結(jié)	384筆者經(jīng)常說一個觀點:“我們并不缺乏軟件工程、需求工程的理論、技術(shù),缺乏的是將這些理論與技術(shù)有效地應(yīng)用到實踐中去的具體方法”。而貫穿全書的SERU過程框架(也稱為SERU模型)正是筆者基于多年不同領(lǐng)域、不同規(guī)模的軟件項目實踐的基礎(chǔ)上,通過對許多重型方法的剪裁而得到的一個清晰、實用的軟件需求過程框架。12.1 SERU過程框架要點概述	38412.1.1 SERU過程框架的理論基礎(chǔ)	38412.1.2 SERU過程框架全景圖	38512.1.3 SERU過程框架導(dǎo)入建議	38812.2 需求實作要點概述	38812.3 結(jié)語	391參考文獻(xiàn)	392SERU誡語目錄第1章 需求實踐現(xiàn)狀分析	2SERU誡語1-1:需求規(guī)格說明書應(yīng)該采用業(yè)務(wù)導(dǎo)向的樹型層次結(jié)構(gòu)來組織。	6SERU誡語1-2:對于需求分析員而言,真正的專業(yè)主義是基于業(yè)務(wù)利益SERU誡語1-2:(解決問題、創(chuàng)造機(jī)會、提高管控力等)的溝通。	6SERU誡語1-3:緩解溝通失真最有效的方法是及時復(fù)述。	9SERU誡語1-4:需求分析的本質(zhì)在于業(yè)務(wù)分析,而非技術(shù)分析。	11SERU誡語1-5:業(yè)務(wù)場景是需求之魂。	12SERU誡語1-6:需求分析人員對于技術(shù)方法論的評價重在適用性。	16SERU誡語1-7:對預(yù)設(shè)計的需求是評判敏捷方法論是否適用的關(guān)鍵。	18第2章 不同軟件項目的需求視圖	20SERU誡語2-1:流程分析(業(yè)務(wù)事件)是OLTP系統(tǒng)的關(guān)鍵線索和主要視圖。	23SERU誡語2-2:報表分析是MIS系統(tǒng)的關(guān)鍵線索和主要視圖。	26SERU誡語2-3:決策場景是DSS系統(tǒng)的關(guān)鍵線索和主要視圖。	29SERU誡語2-4:工作場景是專家系統(tǒng)的關(guān)鍵線索和主要視圖。	30SERU誡語2-5:并行工作流是OA系統(tǒng)的關(guān)鍵線索和主要視圖。	30SERU誡語2-6:高層管理人員的關(guān)注點往往在問題和機(jī)會。	33SERU誡語2-7:對于面向用戶的嵌入式系統(tǒng),行為分析是要點。	35SERU誡語2-8:面向特定設(shè)備的嵌入式系統(tǒng),外部接口和事件分析是要點。	36SERU誡語2-9:信息系統(tǒng)類軟件產(chǎn)品的需求重點在于針對不同目標(biāo)客戶群體的SERU誡語2-9:不同商業(yè)模式分離變化點;經(jīng)常需要減出通用性,再通過插接SERU誡語2-9:解決擴(kuò)展性。	39SERU誡語2-10:基于使用場景的困難點分析是工具軟件的需求要點。	40第3章 軟件需求與需求工程	41SERU誡語3-1:業(yè)務(wù)需求是需求定義的產(chǎn)物,用戶需求是需求捕獲的產(chǎn)物,SERU誡語2-9:軟件需求是需求分析與建模的產(chǎn)物。	43SERU誡語3-2:功能需求的要點在于如何組織。	44SERU誡語3-3:非功能需求的要點在于保證信息的有效傳遞和注意其局部性。	44SERU誡語3-4:設(shè)計約束包括非技術(shù)因素的技術(shù)選型、預(yù)期的軟硬件環(huán)境和預(yù)期的SERU誡語2-9:使用環(huán)境三大類型。	45SERU誡語3-5:業(yè)務(wù)導(dǎo)向的層次結(jié)構(gòu)是保障完整性的關(guān)鍵。	46SERU誡語3-6:需求有時會戴上“高優(yōu)先級”的面具,實際上就是擔(dān)心SERU誡語2-9:你不去實現(xiàn)它。	48SERU誡語3-7:滿意/不滿意度模型是需求必要性評價的有效手段。	49SERU誡語3-8:在需求捕獲活動中,化被動為主動是關(guān)鍵。	52SERU誡語3-9:需求分析就是向下分解+向上提煉,外加一些規(guī)格化。	53SERU誡語3-10:需求分析是目標(biāo),需求建模是手段。	54SERU誡語3-11:在編寫需求規(guī)格說明書時,應(yīng)確保一類信息只在一處描述。	55SERU誡語3-12:劃分出大小合適、粒度均勻的需求項是需求管理的前提。	57SERU誡語3-13:需求優(yōu)先級與工作量估算是基線管理的關(guān)鍵。	57SERU誡語3-14:SERU模型是需求分析的工作指南。	60第4章 需求定義最佳實踐	64SERU誡語4-1:清晰的項目目標(biāo)和范圍定義,能夠引導(dǎo)需求工作順利進(jìn)行。	65SERU誡語4-2:對混沌不清的目標(biāo),可以通過內(nèi)部尋根或外部溯源來破解。	65SERU誡語4-3:對問題進(jìn)行了正確的定義,意味著成功解決了一半。SERU誡語2-9:而在問題定義時應(yīng)該善于使用轉(zhuǎn)換和本源兩個技巧。	68SERU誡語4-4:需求定義階段要善于將未知解問題轉(zhuǎn)換成已知解問題。	68SERU誡語4-5:在確定某問題的解決方案時,一定要思考是否會引發(fā)新問題。	70SERU誡語4-6:直接修改錯誤,不要用其他方案來彌補錯誤。	71SERU誡語4-7:魚骨圖為解決問題找到了靶子,帕累托圖則標(biāo)上了環(huán)數(shù)。	76SERU誡語4-8:范圍是涉及的事、物,邊界是人與系統(tǒng)的職責(zé)邊界。	79SERU誡語4-9:用戶永遠(yuǎn)會希望花同樣的錢,獲得盡可能多的功能。	79SERU誡語4-10:需求階段描述的是用戶的能力特點,旨在提高可用性。	86SERU誡語4-11:你可以不做一件事,但一定不能不知道為什么需要做這件事。	86SERU誡語4-12:在分解系統(tǒng)時,應(yīng)該按業(yè)務(wù)的脈絡(luò)來劃分成不同的主題域。	89SERU誡語4-13:各個主題域之間的服務(wù)接口是需求變更的防火墻。	91SERU誡語4-14:確保能做的事和知道的事相匹配是職責(zé)驅(qū)動設(shè)計的要點。	93SERU誡語4-15:目標(biāo)決定范圍。	96SERU誡語4-16:繪制上下文關(guān)系圖,先考慮Customer再考慮Worker是要點。	98SERU誡語4-17:業(yè)務(wù)事件應(yīng)該是主動觸發(fā)的,并且將會產(chǎn)生一系列后續(xù)行為。	103SERU誡語4-18:業(yè)務(wù)事件是直接作用于系統(tǒng)的,也就是將觸發(fā)系統(tǒng)行為。	103第5章 需求捕獲最佳實踐	109SERU誡語5-1:需求捕獲是撒網(wǎng)打魚,不是休閑釣魚。	109SERU誡語5-2:善于聚焦訪談話題是需求捕獲人員成功的關(guān)鍵。	111SERU誡語5-3:嘗試?yán)斫鈽I(yè)務(wù)場景是合格需求分析人員的良好習(xí)慣。	112SERU誡語5-4:善于利用技術(shù)為用戶創(chuàng)造全新體驗是優(yōu)秀需求人員的特質(zhì)。	113SERU誡語5-5:通過比較用戶代表的表述來識別言過其實,利用差異展現(xiàn)、SERU誡語2-9:瓶頸分析法來緩解影響。	114SERU誡語5-6:針對越俎代庖心理現(xiàn)象最有效的方法是識別正確的被訪談?wù)摺?114SERU誡語5-7:離開辦公室、對訪談進(jìn)行計劃是避免非正事現(xiàn)象的主要手段。	115SERU誡語5-8:化敵為友是緩解抗拒心態(tài)的主要方向。	116SERU誡語5-9:傾聽對方的抱怨是化敵為友的有效手段之一。	116SERU誡語5-10:突破推卸責(zé)任心理的簡單手段是讓被訪談?wù)呓榻B工作場景。	117SERU誡語5-11:需求捕獲時不要忽視對變更可能的了解。	117SERU誡語5-12:在需求捕獲時要善于使用“?”之箭,找到真正的需求。	120SERU誡語5-13:“撥開立場,尋找利益訴求”是需求協(xié)商的要點。	122SERU誡語5-14:不要孤立地看待需求項,應(yīng)該將所有需求視為一個整體。	123SERU誡語5-15:“環(huán)境”將改變結(jié)果,切換不同的視角會得到不同的認(rèn)識。	124SERU誡語5-16:善于打比方是提高跨專業(yè)溝通效果的好方法。	125SERU誡語5-17:占用時間長和信息的片面性是用戶訪談的兩大敵人。	126SERU誡語5-18:訪談的線索是因“人”(用戶類型)而異的。	126SERU誡語5-19:盡量將訪談問題事先發(fā)給被訪談?wù)?,讓他打一場有?zhǔn)備之戰(zhàn)。	128SERU誡語5-20:在需求捕獲時別忘了“一圖抵千言”這句經(jīng)典提示。	132SERU誡語5-21:用戶訪談是一個有計劃的、科學(xué)的過程。	135SERU誡語5-22:用戶調(diào)查能夠有效克服用戶訪談中存在的片面性。	137SERU誡語5-23:在需求捕獲過程中,先訪談再調(diào)查是更合理的方式。	137SERU誡語5-24:大樣本用戶、跨地域用戶的存在就是使用用戶調(diào)查的時機(jī)。	138SERU誡語5-25:分析文檔資料時應(yīng)該思考新流程對其的影響。	143SERU誡語5-26:收集文檔時,應(yīng)該盡可能讓用戶提供帶有真實數(shù)據(jù)的樣本。	143SERU誡語5-27:需求捕獲人員要善于根據(jù)流程分析的結(jié)果主動收集相關(guān)文檔。	144SERU誡語5-28:情節(jié)串聯(lián)板是消除用戶盲區(qū)的有效技術(shù)。	144SERU誡語5-29:情節(jié)串聯(lián)板應(yīng)該以業(yè)務(wù)場景作為展示的主線索。	145SERU誡語5-30:交互才是情節(jié)串聯(lián)板的本質(zhì),不要只關(guān)注于界面的靜態(tài)效果。	145SERU誡語5-31:現(xiàn)場觀摩技術(shù)是消除開發(fā)團(tuán)隊認(rèn)識盲區(qū)的有效手段。	146SERU誡語5-32:現(xiàn)場觀摩技術(shù)能夠使開發(fā)團(tuán)隊實現(xiàn)對業(yè)務(wù)場景“感同身受”。	146SERU誡語5-33:聯(lián)合開發(fā)是突破雙方需求盲區(qū)的有效手段。	147SERU誡語5-34:出現(xiàn)“上面開大會,下面開小會”現(xiàn)象,一半責(zé)任在組織者。	148SERU誡語5-35:溝通決定內(nèi)容,內(nèi)容決定格式。	150第6章 需求分析與建模最佳實踐	156SERU誡語6-1:需求分析就是先分解,再提煉,在這個過程中消除矛盾。	156SERU誡語6-2:需求建模的過程遠(yuǎn)比建模的結(jié)果更重要。	159SERU誡語6-3:模型是用來溝通的,因此僅當(dāng)需要時才構(gòu)建它。	160SERU誡語6-4:建模的要點是根據(jù)要完成的任務(wù)選擇合適的建模工具。	161SERU誡語6-5:UML本身不是方法論。	163SERU誡語6-6:業(yè)務(wù)流程是對信息系統(tǒng)進(jìn)行“庖丁解?!钡暮诵木€索。	165SERU誡語6-7:流程有組織級、部門級、崗位級三個層次,其中部門級是SERU誡語2-9:需求分析的主線索,崗位級是需求細(xì)節(jié)填充時的工作內(nèi)容,SERU誡語2-9:組織級是對部門級流程的抽象概括。	170SERU誡語6-8:應(yīng)該根據(jù)項目的特點和團(tuán)隊的技能情況選擇合適的模型。	172SERU誡語6-9:模型最有效的方式是在交流中演化出來的。	176SERU誡語6-10:流程圖繪制完成之后,花些時間進(jìn)行瓶頸和利益分析會有意SERU誡語6-10:想不到的收獲。	185SERU誡語6-11:在需求建模時,應(yīng)該大膽地用中文命名類和類的屬性。	194SERU誡語6-12:需求階段的類建模應(yīng)該盡可能保持簡單,引入過多的輔助建模SERU誡語6-10:元素反而會降低圖的可讀性。	199SERU誡語6-13:領(lǐng)域模型是自底向上合并出來的。	205SERU誡語6-14:領(lǐng)域模型的要點是拒絕實現(xiàn)、保持簡單、忠于問題域。	207SERU誡語6-15:領(lǐng)域建模時應(yīng)遵循“拒絕實現(xiàn)細(xì)節(jié)、大類不分拆、子類不合并、SERU誡語6-10:同類不抽象”的原則。	207SERU誡語6-16:團(tuán)隊的分工不明確往往是導(dǎo)致視圖交疊的原因,了解不同視圖的SERU誡語6-10:關(guān)注點,是理解不同模型的關(guān)鍵。	214SERU誡語6-17:僅在需求規(guī)格中出現(xiàn)用例圖并不意味著應(yīng)用了用例技術(shù)。	216SERU誡語6-18:千萬不要為了使用擴(kuò)展、包含關(guān)系而使用它們。擴(kuò)展用例SERU誡語6-18:建模的通常是優(yōu)先級較低的擴(kuò)展事件流,包含關(guān)系建模的SERU誡語6-18:通常是多個用例所包含的公共子事件流。	222SERU誡語6-19:在訪談現(xiàn)場,就流程圖討論出用例圖是高效的建模方法。	226SERU誡語6-20:如果說用例有粒度,那么它取決于業(yè)務(wù)流程和任務(wù)分工。	230SERU誡語6-21:系統(tǒng)動作(諸如新增、刪除之類)和業(yè)務(wù)名詞在用例名稱中SERU誡語6-18:相遇時,就是一個十分危險的信號。	230SERU誡語6-22:對不影響泳道間協(xié)作的判斷、活動均屬于細(xì)節(jié)信息。	234SERU誡語6-23:對于報表而言,并不一定非得按用例模板來組織需求描述。	238SERU誡語6-24:諸如Rose之類的建模工具,對模型抽象的支撐是最重要的。	249SERU誡語6-25:前、后置條件出現(xiàn)的頻度并不高,不要畫蛇添足。	254SERU誡語6-26:避免在用例事件流描述中出現(xiàn)實現(xiàn)細(xì)節(jié)、分支結(jié)構(gòu)、SERU誡語6-18:循環(huán)結(jié)構(gòu);特別是不應(yīng)該出現(xiàn)多路分支結(jié)構(gòu),如果出現(xiàn)SERU誡語6-18:要反思用例抽象是否正確。	261SERU誡語6-27:界面原型部分是約束、是建議,目的是支持有效的UI設(shè)計。	266SERU誡語6-28:建議使用不同的字體風(fēng)格約定,以表達(dá)出數(shù)據(jù)的結(jié)構(gòu)特點。	276SERU誡語6-29:歷史記錄的標(biāo)準(zhǔn)也是數(shù)據(jù)需求的一部分。	276SERU誡語6-30:哪里有分解,哪里就有接口。	292第7章 需求描述最佳實踐	302SERU誡語7-1:需求規(guī)格的格式取決于開發(fā)團(tuán)隊的特點及所選的開發(fā)方法論。	324SERU誡語7-2:用戶需求說明書是為生成軟件需求規(guī)格說明書服務(wù)的。	328SERU誡語7-3:文字的歧義可能與其長度成正比。	330SERU誡語7-4:要使需求描述更加清晰,就應(yīng)該轉(zhuǎn)用“結(jié)構(gòu)化文本”式描述。	332SERU誡語7-5:在你被逼在需求描述中增加How的信息之前,先確認(rèn)自己已經(jīng)SERU誡語7-5:嘗試過為需求添加了Why。	334SERU誡語7-6:對于非功能需求而言,應(yīng)該拋棄定性,改用場景化描述;SERU誡語7-5:并通過選取指標(biāo)、積累經(jīng)驗值的方法過渡到定量描述。	335第8章 需求驗證最佳實踐	336SERU誡語8-1:需求驗證的目標(biāo)是盡可能暴露問題,而不是證明無錯。	341SERU誡語8-2:在企業(yè)中推行即時評審、同級桌查等正式化程度不高的評審手段,SERU誡語7-5:是創(chuàng)建企業(yè)評審文化的有效手段。	342SERU誡語8-3:在評審會中,不要用“評價者”的口氣談?wù)撃愕挠^點。	343SERU誡語8-4:參加需求評審的人不是越多越好,一定要保證同級、適合。	343SERU誡語8-5:評審時要確保評審內(nèi)容、缺陷檢查表的規(guī)模適合,內(nèi)容應(yīng)該按每SERU誡語7-5:小時30~40頁的速度來準(zhǔn)備,缺陷檢查表盡量在9條之內(nèi)。	344第9章 需求基線操作實務(wù)	348SERU誡語9-1:優(yōu)先級是相對的,要在同一級中進(jìn)行比較。	355SERU誡語9-2:評價具體功能點的優(yōu)先級時,應(yīng)將其放到業(yè)務(wù)場景甚至是業(yè)務(wù)SERU誡語7-5:流程環(huán)境中考慮。	356SERU誡語9-3:軟件估算是隨著工作任務(wù)的細(xì)化不斷提高精確度的。	357SERU誡語9-4:不同階段進(jìn)行軟件估算時,應(yīng)該采用不同的計數(shù)單元。	357SERU誡語9-5:悲觀估計、樂觀估計應(yīng)和“風(fēng)險”理由對應(yīng)起來。	362第10章 變更管理操作實務(wù)	365SERU誡語10-1:需求變更管理的目標(biāo)是控制變更,而非避免變更。	365SERU誡語10-2:控制變更的目標(biāo)是減少變更對開發(fā)工作的影響。	365SERU誡語10-3:需求團(tuán)隊的貢獻(xiàn)在于“盡早標(biāo)識變更”,設(shè)計團(tuán)隊的貢獻(xiàn)在于SERU誡語10-3:“盡可能以彈性的設(shè)計來減少變更的影響”。	366SERU誡語10-4:建立統(tǒng)一的渠道讓客戶意識到變更的成本,減少“來路不正”SERU誡語10-3:的變更,記錄“變更的工作”。	366SERU誡語10-5:CCB的核心人員只有兩個,分別代表用戶團(tuán)隊和開發(fā)團(tuán)隊,SERU誡語10-3:其他組成人員都是協(xié)作者和決策者。	367SERU誡語10-6:基于業(yè)務(wù)驅(qū)動的需求項(樹型)列表,是對變更進(jìn)行業(yè)務(wù)SERU誡語10-3:影響分析的有效方法。	372SERU誡語10-7:對變更進(jìn)行分類、再分類,是管理變更的重中之重。	375第11章 需求跟蹤操作實務(wù)	376SERU誡語11-1:需求跟蹤是高階管理活動,所需的工作量很大,特別是軟件需求SERU誡語10-3:到設(shè)計元素的跟蹤,因此一定要考慮投入與產(chǎn)出是否成正比。	377

章節(jié)摘錄

  第1章 需求實踐現(xiàn)狀分析	  在信息化高速發(fā)展的今天,構(gòu)建與時俱進(jìn)的信息化系統(tǒng)已成為所有政府、企事業(yè)單位的重點課題之一。然而在軟件項目實施過程中,進(jìn)度超期、經(jīng)費超預(yù)算、變更頻繁的現(xiàn)象層出不窮,甚至有許多項目根本無法達(dá)到預(yù)期的目標(biāo),更談不上為業(yè)主創(chuàng)造真正的效益。歸根結(jié)底,軟件需求實踐這一共同的軟肋是問題的根源?! ?.1 軟件項目失敗的根源  “在中國做軟件太難了!客戶連自己的需求都說不清楚!”,這種抱怨的話總是在筆者耳邊響起。實際上,軟件項目失敗率居高不下、需求問題層出不窮的現(xiàn)象并不僅僅是中國軟件業(yè)的困擾,在大洋彼岸的美國軟件業(yè)也未能幸免。  第三方機(jī)構(gòu)Standish Group每隔幾年都會對軟件項目實踐現(xiàn)狀進(jìn)行分析與統(tǒng)計,其顯示的“成績單”(CHAOS Report)十分令人擔(dān)憂。正所謂“他山之石可以攻玉”,下面我們分別來看看幾次報告中顯示的數(shù)據(jù),分析失敗的原因,以便從中獲得一些幫助我們改進(jìn)工作的思路?! ?.1.1 CHAOS Report 1994  1994年度發(fā)布的報告顯示,美國每年的IT應(yīng)用開發(fā)項目大約有175 000個,總投資高達(dá)2500億美元,大型、中型、小型企業(yè)的軟件開發(fā)項目的平均成本分別是232.2萬美元、133.I萬美元和43.4萬美元?! 《鳶tandish Group的研究顯示:高達(dá)31.1%的項目徹底失敗,高達(dá)52.7%的項目進(jìn)度超期或成本超支,被認(rèn)為成功的項目僅有可憐的16.2%?! 《鴮?dǎo)致進(jìn)度超期、成本超支的項目中,最主要的原因之一是項目的重新啟動,而每100個項目中就有94個曾經(jīng)遇到這個問題,甚至在這94個項目中還有許多項目經(jīng)歷了多次的重新啟動?! 《煌捻椖康倪M(jìn)度超期、成本超支情況還是有所不同的,下面我們就通過CHAOS報告中總結(jié)的表格來了解一下,如表1.1所示?! ≡诒?—2中可以看出,十大成功保證中有三個是直接與需求相關(guān)的(已加粗顯示),累計權(quán)重達(dá)到37.1%;而十大敗因中與需求直接相關(guān)的更是高達(dá)五個,累計權(quán)重高達(dá)51.6%,可見需求問題對項目影響程度之高?! 《鴮τ谀切┏杀境А⑦M(jìn)度超期的項目而言,報告也總結(jié)出了導(dǎo)致這一結(jié)果出現(xiàn)的十大因素:缺乏用戶參與(12.8%)、不完整的需求(12.3%)、需求變更頻繁(11.8%)、缺乏執(zhí)行層的支持(7.5%)、技術(shù)能力缺乏(7.0%)、資源不足(6.4%)、不切實際的用戶期望(5.9%)、沒有清晰的愿景和目標(biāo)(5.3%)、不切實際的時間限制(4.3%)、新技術(shù)風(fēng)險(3.7%)、其他(23.0%)。

媒體關(guān)注與評論

  六年前,當(dāng)我認(rèn)識徐鋒時,他就是軟件需求領(lǐng)域的高手。潛心實踐、研究,六年磨一劍,如今鋒利出鞘。中國的軟件產(chǎn)業(yè)并不缺乏軟件工程理論,而是我們沒有很好地運用這些理論。我給軟件工程碩士講授課程,使用過各種版本的教材,這些書籍的通病就是實踐性不強。當(dāng)我讀到這本書稿時,倍感親切,這不是一本軟件需求的理論書,而是一本需求實踐指導(dǎo)手冊?!  獜堄焉┦浚ㄏY惥W(wǎng)首席架構(gòu)師,著名計算機(jī)教育專家)  涵蓋面廣,實用性強,有理有據(jù)(例),亦莊亦諧,樸實無華又非常受用,在技術(shù)類書籍中當(dāng)屬不可多得的佳作?!  锟ㄓ糜汛髮W(xué)執(zhí)行校長,高級企業(yè)培訓(xùn)師) ?。ㄜ浖枨笞罴褜嵺`>是一本足以令人拍案叫好的書。它經(jīng)驗密集,直擊需求實踐中各種問題,給出令人信服的問題解決思路。它實踐體系完善,貫穿全書的SERLJ過程框架,詳盡地覆蓋了需求工作中各個環(huán)節(jié)的任務(wù)、要點及產(chǎn)物,脈絡(luò)清晰,可操作性極強。最可貴的是,SERU過程框架漂亮地 “打通了”業(yè)務(wù)工程到傳統(tǒng)需求的“鴻溝”,而眾多企業(yè)需求實踐中的最大困惑恰恰常在于此。故此,鄭重推薦徐鋒的這本佳作!  ——溫昱資深咨詢顧問.軟件架構(gòu)高級培訓(xùn)講師)

編輯推薦

  《軟件需求最佳實踐:SERU過程框架原理與應(yīng)用》可作為計算機(jī)軟件專業(yè)本科生、研究生和軟件工程碩士的軟件需求分析教材,也可以作為軟件工程、軟件開發(fā)管理培訓(xùn)的教材,更是一線項目經(jīng)理、需求分析人員、資深開發(fā)人員、信息系統(tǒng)運行管理人員、研發(fā)企業(yè)管理人員的必備參考書?! ×昵?,當(dāng)我認(rèn)識徐鋒時,他就是軟件需求領(lǐng)域的高手。潛心實踐、研究,六年磨一劍,如今鋒利出鞘。中國的軟件產(chǎn)業(yè)并不缺乏軟件工程理論,而是我們沒有很好地運用這些理論。我給軟件工程碩士講授〈需求工程〉課程,使用過各種版本的教材,這些書籍的通病就是實踐性不強。當(dāng)我讀到這本書稿時,倍感親切,這不是一本軟件需求的理論書,而是一本需求實踐指導(dǎo)手冊。  ——張友生博士(希賽網(wǎng)首席架構(gòu)師,著名計算機(jī)教育專家)  涵蓋面廣,實用性強,有理有據(jù)(例),亦莊亦諧,樸實無華又非常受用,在技術(shù)類書籍中當(dāng)屬不可多得的佳作。  ——田俊國(用友大學(xué)執(zhí)行校長,高級企業(yè)培訓(xùn)師) ?。ㄜ浖枨笞罴褜嵺`〉是一本足以令人拍案叫好的書。它經(jīng)驗密集,直擊需求實踐中各種問題,給出令人信服的問題解決思路。它實踐體系完善,貫穿全書的SERLJ過程框架,詳盡地覆蓋了需求工作中各個環(huán)節(jié)的任務(wù)、要點及產(chǎn)物,脈絡(luò)清晰,可操作性極強。最可貴的是,SERU過程框架漂亮地 “打通了”業(yè)務(wù)工程到傳統(tǒng)需求的“鴻溝”,而眾多企業(yè)需求實踐中的最大困惑恰恰常在于此。故此,鄭重推薦徐鋒的這本佳作!  ——溫昱資深咨詢顧問.軟件架構(gòu)高級培訓(xùn)講師)

圖書封面

圖書標(biāo)簽Tags

評論、評分、閱讀與下載


    軟件需求最佳實踐 PDF格式下載


用戶評論 (總計10條)

 
 

  •     在經(jīng)過很多資深需求分析人員推薦后,購買了這本老書。全書寫作風(fēng)格就跟做項目一樣,現(xiàn)狀分析、解決方案、實施落地等逐一展開介紹。全書除了秉承一圖勝千語的風(fēng)格外,還有很多典型小故事生動的案例剖析,解決了枯燥無味的理論知識,抽象、歸納、總結(jié)了軟件需求的開發(fā)和管理全過程。更重要的是本書還將很多筆者多年積累的寶貴經(jīng)驗作為誡語醒目的分享給讀者,而且整理成為目錄,可以方便快速的為讀者提供幫助!
  •     推薦這本書,里面很多軟件需求分析的工具都很實用,同時書中的案例也很形象,看得出是作者日常工作中遇到的問題,而不是生搬硬套,語言也很簡潔,由簡入深,簡述需求的定義及基本流程,再由具體項目從細(xì)致處著眼對需求進(jìn)行實踐,可以參照書中提供的方法進(jìn)行需求捕獲和調(diào)研以及需求分析的工作。
  •     這是參加徐鋒的《軟件需求最佳實踐》課程培訓(xùn)后的再一次總結(jié),筆者在提出SERU過程框架的時候常說到一個觀點,就是我們并不缺乏軟件工程,需求工程的理論,技術(shù),缺乏的是將這些理論和技術(shù)有效的應(yīng)用到實踐。而作者的SERU過程框架正好是將軟件工程理論和具體的需求實踐工作真正的結(jié)合起來了,個人認(rèn)為最核心的不是提出了很多重要的需求誡語,更重要的是可以通過SERU框架系統(tǒng)來梳理和回顧我們的需求開發(fā)和需求管理活動。
      
      首先對SERU模型的四個字母再做一個說明
      
      S:Subject Area,表示子問題域,其核心思想是要通過業(yè)務(wù)來分解系統(tǒng),盡量保證業(yè)務(wù)獨立和低耦合。
      E:Event,表示業(yè)務(wù)事件,通過業(yè)務(wù)事件能夠找到流程,通過流程能夠找到不同場景和用例。
      R:Report,表示報表,統(tǒng)一處理查詢,分析和統(tǒng)計類需求。
      U:Use Case,表示用例,需求組織的最小單位,到了需求分析階段的重要活動和產(chǎn)出。
      
      SERU過程框架模型將需求過程分解為了三個階段,第一個階段是需求定義,重點是主題域劃分和業(yè)務(wù)事件識別。第二個階段是理清需求框架和脈絡(luò),重點是通過業(yè)務(wù)流程圖轉(zhuǎn)到具體的領(lǐng)域類圖和用例圖。到了第三個階段重點就是填充需求細(xì)節(jié),包括用例的詳細(xì)編寫,界面和交互設(shè)計等。
      
      第一階段-需求定義階段
      
      需求定義階段強調(diào)了一個重點就是高屋建瓴和從頂向下的思路。當(dāng)要做一個全新的軟件產(chǎn)品的時候,我們首先肯定是進(jìn)行需求收集和調(diào)研,所以書里面專門談到了需求捕獲的最佳實踐,包括用戶的訪談和調(diào)查,現(xiàn)場的觀摩等。同時也提出了類似任務(wù)卡片等很好的現(xiàn)場需求捕獲工具。為什么一開始要強調(diào)第一階段對系統(tǒng)的宏觀把握和高屋建瓴,因為在做一個全新的軟件產(chǎn)品的時候我們很容易收集到大量用戶現(xiàn)有的流程,表單,組織架構(gòu)等信息和資料,但是這樣很容易一次的陷入到需求細(xì)節(jié)中而對企業(yè)的業(yè)務(wù)沒有一個宏觀的把握。
      
      主題域劃分+上下文圖,是需求定義階段的重要輸出。主題域劃分主要是從業(yè)務(wù)的視角來考慮子系統(tǒng)應(yīng)該如何劃以降低業(yè)務(wù)本身的耦合,在書中也專門提到了主題域劃分的思考應(yīng)該從組織結(jié)構(gòu)為線索,從分管領(lǐng)導(dǎo)找突破以及借鑒典型的業(yè)務(wù)職能區(qū)塊等。主題域劃分清楚了下一步重點就是要確定主題域的范圍,自然引入了上下文關(guān)系圖,其核心就是要將主題域或子系統(tǒng)作為一個黑盒來分析,搞清楚邊界和其于外部用戶的交互。通過理清楚上下文關(guān)系圖后第一階段的輸出基本就很容易明確了,即業(yè)務(wù)事件+報表需求。
      
      在這里我覺得重點要借鑒的就是從頂向下的系統(tǒng)思維和分而治之,這是解決問題很重要方法。同時剛開始一定不要跳過這個階段而落入需求細(xì)節(jié)。主題域和業(yè)務(wù)事件是兩個重要概念,而這兩個概念核心又是業(yè)務(wù)場景。
      
      第二階段-需求分析階段
      
      在第二個階段重點就是粒度的細(xì)化,從主題域我需要細(xì)化一層到識別了關(guān)鍵業(yè)務(wù)對象的領(lǐng)域視圖,從業(yè)務(wù)事件進(jìn)行流程分析我們需要講業(yè)務(wù)事件細(xì)化一層到具體的業(yè)務(wù)活動,而業(yè)務(wù)活動正式我們在識別用例的時候的重要參考。所以在這里我們基本清楚了第二階段剛開始是通過業(yè)務(wù)事件進(jìn)行業(yè)務(wù)流程分析,業(yè)務(wù)實體分析,業(yè)務(wù)場景分析,識別領(lǐng)域類和用例。
      
      需求分析就是先分解,在提煉,然后在這個過程中消除矛盾。不管是采用結(jié)構(gòu)化的方法還是面向?qū)ο蟮姆椒?,分解是人類控制?fù)雜性,認(rèn)知復(fù)雜事物的最佳實踐?,F(xiàn)代工程理論更建議采用業(yè)務(wù)導(dǎo)向的分解而非系統(tǒng)導(dǎo)向的分解。在第一階段的分解我們可以看到以主題域為主線索,具體的分解過程為目標(biāo)系統(tǒng)-》主題域-》業(yè)務(wù)事件;到了第二階段則是以業(yè)務(wù)流程為主線索進(jìn)行分解,具體為業(yè)務(wù)事件-》業(yè)務(wù)流程和業(yè)務(wù)活動-》領(lǐng)域類圖和用例。
      
      業(yè)務(wù)流程是對信息系統(tǒng)進(jìn)行庖丁解牛的核心線索,每個業(yè)務(wù)事件都是一個業(yè)務(wù)流程的觸發(fā),因此針對每個業(yè)務(wù)事件都應(yīng)繼續(xù)做業(yè)務(wù)流程分析。對于業(yè)務(wù)流程是企業(yè)核心業(yè)務(wù)的重要載體,業(yè)務(wù)流程本身就是結(jié)構(gòu)化的,而且是分級的,通過分析業(yè)務(wù)流程就能夠識別企業(yè)核心業(yè)務(wù)活動,為需求建模做好準(zhǔn)備工作。
      
      在這個階段我們看到兩個重要輸出,一個是靜態(tài)的領(lǐng)域類涉及到領(lǐng)域建模,而領(lǐng)域建模的重點就是標(biāo)識類,明確類之間的邏輯關(guān)系和數(shù)量關(guān)系,添加重要的結(jié)構(gòu)規(guī)則。另外一個就是動態(tài)的用例,在RUP核心三要素中專門強調(diào)了用例驅(qū)動,足見用例建模的重要性,但是我們要注意到第二階段的重點仍然是搭框架結(jié)構(gòu),因此并沒有要求要識別所有的領(lǐng)域類和用例。
      
      第三階段-需求細(xì)化
      
      需求細(xì)化是什么?在第二階段我已經(jīng)通過分解和細(xì)化到達(dá)了具體的用例,而第三階段的重點就是單個用例以及該用例可能涉及到的界面部分建模。書中將用例分為三類是有一定道理的,即業(yè)務(wù)用例,報表用例和接口用例。對于業(yè)務(wù)用例的重點是基本流,擴(kuò)展流和業(yè)務(wù)規(guī)則。對于報表類的用例重點則是報表的輸入,輸出內(nèi)容,輸出格式。在這里有個情況不得不提出的就是,一些報表類用例脫離了只要不是項目歷史開發(fā)人員很難看懂,原因即是關(guān)鍵的報表的數(shù)據(jù)來源在哪里沒有說清楚,這點也是報表類用例必須關(guān)注的要點。
      
      如果將用例分為兩個層次,第一重點就是關(guān)注業(yè)務(wù)活動流和規(guī)則的細(xì)化,另外一個就是涉及到交互和界面的建模和細(xì)化。這兩個層次仍然有一定的關(guān)系,重點仍然是要先考慮業(yè)務(wù)流和規(guī)則,再來考慮交互和界面。如果先陷入到了界面建模再考慮業(yè)務(wù)流和規(guī)則,則又是順序錯誤的開發(fā)人員思維,即違背了用例是業(yè)務(wù)活動驅(qū)動的初衷。
      
      這里多說一句即是功能點估算在什么時候用,在第一階段用是毫無意義的,最佳的使用點就是在需求細(xì)化后,具體的業(yè)務(wù)流和規(guī)則,需要的數(shù)據(jù)輸入和輸出都基本清楚后,最適合進(jìn)行功能點估算。因此我們也建議一種方法,即第一階段先進(jìn)行專家法估算,到了第三階段通過功能點估算對專家法估算內(nèi)容進(jìn)行驗證。
  •     這本書應(yīng)該是算100%的純國貨了,差不多應(yīng)該算是我讀過的在這方面的國產(chǎn)貨中最出色的了.
      從這本書中可以看出,本書的作者閱讀了大量外國這方面的精華作品,對需求工程的理解也相當(dāng)?shù)纳羁?
      
      下面說一下本書的不足
      
      1.虎頭蛇尾
      本書從一開始,章節(jié)內(nèi)容逐漸增加,到第6章達(dá)到頂點,然后急轉(zhuǎn)直下,每章內(nèi)容迅速減少,越往后面寫,越給人感覺是在敷衍.章節(jié)劃分以及每章要寫多少內(nèi)容應(yīng)該在最開始就規(guī)劃好.
      
      2.小故事
      小故事這種形式已經(jīng)被大量的運用在了外文書中,本書也學(xué)習(xí)了外文書的這個優(yōu)點,不過編寫故事方面還需要加強,很多時候我太愿意去讀文中的小故事,讀了之后感覺啟發(fā)也不大.
      
      3.結(jié)構(gòu)
      本書的結(jié)構(gòu)很模糊.就我看過的外文書來看,結(jié)構(gòu)一般分為三類,要么是總分的形式,要么是根據(jù)一個線索順沿下來,要么是以一定的觀點或者事件為中心獨立成章.本書的結(jié)構(gòu)組織哪一個也不象,給人有點混亂的感覺.依據(jù)本書所講的內(nèi)容,個人建議采用總分的模式.特別是依據(jù)現(xiàn)在這個結(jié)構(gòu),最后一章在我看來簡直就是敗筆,還不如直接放到附錄中去.
      
      4.細(xì)節(jié)
      本書在具體細(xì)節(jié)方面還不夠具體,給人更多的感覺只是在羅列事實,而非一個具體的指導(dǎo)過程,很多地方對方法的描述應(yīng)該更細(xì)致,更具體.
      
      5.錯誤
      本書有些小地方犯了一些常識性的錯誤,不過影響不大.
      
      
      不過,畢竟需求工程是個外來之物,國內(nèi)對這方面的研究也沒有國外時間那么的長,那么的精通,本書能做到這種程度,已經(jīng)相當(dāng)?shù)牟诲e了.
      如果沒有讀過其他方面的關(guān)于需求工程的書,本書可以讓你對需求工程有一個比較全面的認(rèn)識和了解.讀完這本書之后,然后可以去讀<掌握需求過程>.如果已經(jīng)讀過了前面提到的那本書,那么本書可以用來選讀,可以繼續(xù)加深你對需求工程的認(rèn)識和了解.
  •     第1部分 原理、模型與誤區(qū)
        第1章 需求實踐現(xiàn)狀分析 2
        在信息化高速發(fā)展的今天,構(gòu)建與時俱進(jìn)的信息化系統(tǒng)已成為所有政府、企事業(yè)單位的重點課題之一。然而在軟件項目實施過程中,進(jìn)度超期、經(jīng)費超預(yù)算、變更頻繁的現(xiàn)象層出不窮,甚至有許多項目根本無法達(dá)到預(yù)期的目標(biāo),更談不上為業(yè)主創(chuàng)造真正的效益。歸根結(jié)底,軟件需求實踐這一共同的軟肋是問題的根源。
        1.1 軟件項目失敗的根源 2
        1.1.1 CHAOS Report 1994 2
        1.1.2 CHAOS Report后續(xù)版本 3
        1.1.3 需求相關(guān)敗因簡要分析 4
        1.1.4 一幅漫畫帶來的思考 8
        1.2 透過表象,分析本質(zhì) 12
        1.2.1 需求變更頻繁 12
        1.2.2 上線阻力大 13
        1.2.3 運行效果差 14
        1.2.4 完全崩潰 15
        1.3 方法論與需求工作 16
        1.3.1 計算模式 16
        1.3.2 軟件工程方法論 17
        1.3.3 開發(fā)思想 18
        1.4 小結(jié) 19
        第2章 不同軟件項目的需求視圖 20
        隨著信息化應(yīng)用的逐漸深入,軟件項目在企業(yè)、政府等各類組織中所擔(dān)負(fù)的角色也越來越多,應(yīng)用層面也在逐漸地深入,同時也意味著不同的軟件項目具有不同的特點,這也就對需求工作產(chǎn)生了諸多影響。在本章中,我們就將針對信息系統(tǒng)、嵌入式系統(tǒng)、軟件產(chǎn)品等不同角度來說明如何進(jìn)行相應(yīng)的需求工作,為需求分析師提供一個切實有效的視圖。
        2.1 信息系統(tǒng)的需求視圖 20
        2.1.1 信息系統(tǒng)的本質(zhì)與分類 20
        2.1.2 聯(lián)機(jī)事務(wù)處理系統(tǒng)——流程電子化 22
        2.1.3 管理信息系統(tǒng)——數(shù)據(jù)信息化 25
        2.1.4 其他信息系統(tǒng) 29
        2.1.5 信息系統(tǒng)的多維視圖 31
        2.2 嵌入式系統(tǒng)的需求視圖 33
        2.2.1 面向直接用戶的嵌入式系統(tǒng) 34
        2.2.2 面向特定設(shè)備的嵌入式系統(tǒng) 35
        2.3 軟件產(chǎn)品的需求視圖 36
        2.4 小結(jié) 40
        第3章 軟件需求與需求工程 41
        筆者在做需求分析師的培訓(xùn)時,經(jīng)常會問學(xué)員這樣的一個問題:什么是軟件需求?這個看似簡單的問題卻并不好回答,也許很多人會簡單地認(rèn)為軟件需求就是用戶需要實現(xiàn)的功能加上一些非功能方面的要求。但這樣的理解卻并不完整,如果對用戶所處的業(yè)務(wù)場景沒有建立正確認(rèn)識,經(jīng)常會給工作帶來麻煩。因此本章將對一些與需求、需求工程相關(guān)的關(guān)鍵概念進(jìn)行闡釋。
        3.1 什么是軟件需求 41
        3.1.1 需求的三個層次 41
        3.1.2 需求的三種類型 43
        3.1.3 優(yōu)秀需求的標(biāo)準(zhǔn) 46
        3.2 需求工程解析 50
        3.2.1 需求工程的范疇 50
        3.2.2 需求開發(fā)工作要點 51
        3.2.3 需求管理工作要點 56
        3.2.4 需求分析人員的技能組成 58
        3.2.5 SERU模型概述 59
        3.3 小結(jié) 61
        第2部分 需求開發(fā)
        第4章 需求定義最佳實踐 64
        需求定義活動準(zhǔn)確來說是不屬于需求工程范疇的,它實際上是立項管理需要做的工作。但需求定義階段的產(chǎn)物對于需求捕獲、分析與建?;顒佣加兄苯拥挠绊?,如果這個階段的工作做得不理想,就會出現(xiàn)“上梁不正下梁歪”的結(jié)果。因此本書還是將這個活動納入進(jìn)來,并將給大家提供一個能夠與后續(xù)活動結(jié)合緊密的方法。
        4.1 需求定義任務(wù)概述 64
        4.1.1 需求定義的時機(jī) 64
        4.1.2 需求定義的理念與策略 65
        4.2 問題分析的五步法 66
        4.2.1 在問題定義上達(dá)成共識 67
        4.2.2 分析問題背后的問題 73
        4.2.3 確定相關(guān)人員和用戶 77
        4.2.4 定義解決方案的界限 78
        4.2.5 確定加在解決方案上的約束 80
        4.2.6 小結(jié) 81
        4.3 需求定義的產(chǎn)物與要素 81
        4.3.1 需求定義的產(chǎn)物 81
        4.3.2 需求定義的要素 82
        4.4 定義需求范圍 87
        4.4.1 案例說明 87
        4.4.2 劃分主題域 88
        4.4.3 確定主題域范圍 97
        4.4.4 標(biāo)識業(yè)務(wù)事件與報表 101
        4.4.5 生成需求大綱 104
        4.5 小結(jié) 108
        第5章 需求捕獲最佳實踐 109
        需求捕獲是需求開發(fā)中的第一個活動,可以說任何一個需求團(tuán)隊對它都不陌生,但如何提高需求捕獲的有效性卻一直以來是困擾大家的問題。需求捕獲的要點在于計劃性和科學(xué)性,計劃性體現(xiàn)在對捕獲對象、問題、時間的計劃,科學(xué)性則表現(xiàn)在如何有效地選擇合適的捕獲方法。本章的目的就在于幫助大家更好地達(dá)到這兩個目標(biāo),從而提高需求捕獲活動的質(zhì)量。
        5.1 需求捕獲的策略 109
        5.1.1 需求捕獲應(yīng)該是主動的 109
        5.1.2 需求捕獲應(yīng)該是聚焦的 110
        5.1.3 破解需求的冰山模型 111
        5.1.4 破解阻礙需求捕獲的心理現(xiàn)象 113
        5.1.5 不要忽視對變更可能的捕獲 117
        5.1.6 需求協(xié)商 118
        5.2 需求捕獲的主要方法 125
        5.2.1 用戶訪談 125
        5.2.2 用戶調(diào)查 137
        5.2.3 文檔考古 142
        5.2.4 情節(jié)串聯(lián)板 144
        5.2.5 現(xiàn)場觀摩 145
        5.2.6 聯(lián)合開發(fā) 147
        5.3 需求捕獲的記錄工具 150
        5.3.1 工具的選擇與定義 150
        5.3.2 任務(wù)卡片 151
        5.3.3 場景說明 152
        5.3.4 其他工具 153
        5.4 小結(jié) 154
        第6章 需求分析與建模最佳實踐 156
        需求分析是需求工程中最為核心的工作,而需求建模則是需求分析的主要手段。但由于分析這個詞比較抽象,很多時候讓人感到無從入手,甚至導(dǎo)致被輕易地滑過了,直接將需求捕獲的結(jié)果整理到軟件需求規(guī)格說明書中。而需求建模也有很多工具,到底怎么有效地應(yīng)用到需求分析過程中也是令人感到難以掌握的東西。因此本章的目標(biāo)就是為讀者勾勒出需求分析的階段與任務(wù),指出如何選擇適合的建模工具,以及在什么時機(jī)、如何應(yīng)用這些建模工具。
        6.1 需求分析與建模的要點與誤區(qū)分析 156
        6.1.1 需求分析到底做什么 156
        6.1.2 建模的目標(biāo)與要點 159
        6.1.3 選擇建模工具的要點 160
        6.2 周期一:理清框架與脈絡(luò) 164
        6.2.1 業(yè)務(wù)流程分析 165
        6.2.2 業(yè)務(wù)實體分析 191
        6.2.3 角色與使用場景分析 216
        6.2.4 周期一的產(chǎn)物 232
        6.3 周期二:確定需求細(xì)節(jié) 249
        6.3.1 確定行為需求的細(xì)節(jié) 250
        6.3.2 確定結(jié)構(gòu)需求的細(xì)節(jié) 270
        6.3.3 周期二的產(chǎn)物 279
        6.4 其他需求分析 292
        6.4.1 接口需求 292
        6.4.2 非功能需求的追蹤 294
        6.4.3 設(shè)計約束 297
        6.5 小結(jié) 301
        第7章 需求描述最佳實踐 302
        需求描述就是將需求捕獲、分析的結(jié)果進(jìn)行文檔化的過程。在軟件開發(fā)時,將分析的結(jié)果文檔化是不可或缺的任務(wù),也稱為編寫規(guī)約活動;而在某個項目中,可能還會由用戶代表或需求捕獲人員對捕獲的內(nèi)容進(jìn)行整理,形成用戶需求說明書。具體要干什么,想必大家并不陌生,而且在前一章中也看到了一些實例的片段。因此本章將重點從需求描述的風(fēng)格與格式、寫作策略與技巧兩個方面做些強調(diào)和補充。
        7.1 需求描述的風(fēng)格與格式 302
        7.1.1 常見的描述風(fēng)格與選用標(biāo)準(zhǔn) 302
        7.1.2 典型軟件需求規(guī)格說明書模板解析 303
        7.1.3 定義模板的技巧 318
        7.1.4 用戶需求說明與軟件需求規(guī)格說明 326
        7.2 寫作策略與技巧 328
        7.2.1 文字表達(dá)的先天不足 328
        7.2.2 需求描述的兩大原則 330
        7.2.3 不要忽視陳述需求理由的重要性 332
        7.2.4 注意措辭 334
        7.3 小結(jié) 335
        第8章 需求驗證最佳實踐 336
        需求驗證是需求開發(fā)的最后一個環(huán)節(jié),它是一個質(zhì)量關(guān)。也就是說,其目標(biāo)是發(fā)現(xiàn)盡可能多的錯誤,減少因為需求的錯誤而帶來的工作量浪費。而需求驗證的主要手段就是Review(復(fù)查,也常譯為評審)。但是許多需求團(tuán)隊都覺得需求驗證比較容易變得“務(wù)虛”,收效很少,本章的目標(biāo)就是幫助大家緩解這個問題。
        8.1 需求驗證的主要手段 336
        8.1.1 不同正式化程度的評審 336
        8.1.2 審查過程概述 338
        8.2 需求驗證的主要誤區(qū)與解決方案 340
        8.2.1 需求驗證的5大要點 341
        8.2.2 需求驗證常見的5大問題 344
        8.3 小結(jié) 346
        第3部分 需求管理
        第9章 需求基線操作實務(wù) 348
        需求基線是需求管理活動中最為基礎(chǔ)的一個,通常也是在項目中首先應(yīng)該引入的管理活動。但許多相關(guān)書籍中對需求基線的介紹相對比較理論化,很少給出具體的操作方法,往往使得許多軟件開發(fā)團(tuán)隊無從入手。為了幫助大家更好地引入需求基線,本章的重點將是結(jié)合具體的實例來說明需求基線的劃分方法。
        9.1 需求基線的理念與策略 348
        9.1.1 基線思想的起源 348
        9.1.2 基線的策略 350
        9.2 基線劃定的基礎(chǔ):優(yōu)先級評價 351
        9.2.1 組織需求項 351
        9.2.2 業(yè)務(wù)優(yōu)先級評價 352
        9.2.3 根據(jù)技術(shù)依賴性和項目風(fēng)險調(diào)整優(yōu)先級 356
        9.3 基線劃定的要素:工作量估算 356
        9.3.1 估算的意義與要點 356
        9.3.2 定義階段的估算示例 358
        9.3.3 分析一階段的估算示例 361
        9.4 基線劃定與管理 362
        9.4.1 劃定基線 362
        9.4.2 管理基線 363
        9.5 小結(jié) 364
        第10章 變更管理操作實務(wù) 365
        需求變更頻繁恐怕是困擾無數(shù)軟件開發(fā)團(tuán)隊的惡魔之首,而且在美國權(quán)威的第三方機(jī)構(gòu) Standish Group的CHAOS報告中,也將其列為困擾軟件開發(fā)團(tuán)隊、導(dǎo)致項目失敗的5大原因之一,其中原因?qū)嶋H上也充分暴露了整個產(chǎn)業(yè)的不成熟。需求變更在 CHAOS報告中是排名第四的問題,而在中國軟件開發(fā)團(tuán)隊中卻是排名第一的問題,這里面就意味著存在距離,本章的目的就是希望幫助大家找到其中的差距。
        10.1 變更管理的理念 365
        10.2 變更管理要點一:統(tǒng)一渠道 366
        10.2.1 CCB背后的道理 366
        10.2.2 變更處理過程 368
        10.3 變更管理要點二:統(tǒng)一平臺 373
        10.3.1 變更管理平臺的選擇 373
        10.3.2 變更管理平臺的應(yīng)用要點 374
        10.4 小結(jié) 375
        第11章 需求跟蹤操作實務(wù) 376
        需求跟蹤是一個高階的管理活動,它的目標(biāo)是為了更好地管理需求的狀態(tài)、更好地分析需求變更產(chǎn)生的影響。雖然執(zhí)行需求跟蹤會帶來不錯的效益,但其所需付出的工作量也是巨大的。本章我們就對跟蹤的一些要點做一簡要的說明。
        11.1 需求跟蹤的基本概念 376
        11.1.1 用戶需求到軟件需求的跟蹤 377
        11.1.2 軟件需求到軟件需求的跟蹤 377
        11.1.3 軟件需求到下游工作產(chǎn)品的跟蹤 377
        11.2 需求跟蹤的操作方法 378
        11.2.1 表格法 378
        11.2.2 鏈表法 379
        11.3 小結(jié) 381
        第4部分 總結(jié)
        第12章 SERU過程框架總結(jié) 384
        筆者經(jīng)常說一個觀點:“我們并不缺乏軟件工程、需求工程的理論、技術(shù),缺乏的是將這些理論與技術(shù)有效地應(yīng)用到實踐中去的具體方法”。而貫穿全書的SERU過程框架(也稱為SERU模型)正是筆者基于多年不同領(lǐng)域、不同規(guī)模的軟件項目實踐的基礎(chǔ)上,通過對許多重型方法的剪裁而得到的一個清晰、實用的軟件需求過程框架。
        12.1 SERU過程框架要點概述 384
        12.1.1 SERU過程框架的理論基礎(chǔ) 384
        12.1.2 SERU過程框架全景圖 385
        12.1.3 SERU過程框架導(dǎo)入建議 388
        12.2 需求實作要點概述 388
        12.3 結(jié)語 391
        參考文獻(xiàn) 392
  •     寫一本書不容易,寫一本讓自己滿意的書更不容易,而寫一本讓讀者喜歡的書則是難上加難?;蛟S這一“冠冕堂皇”的理由可以作為筆者一再錯過向關(guān)注本書的讀者所承諾的上市時間的借口。但是沒有任何理由可以讓筆者松懈下來,畢竟自己一直在標(biāo)榜要解決“我們并不缺乏需求的理論,缺少的是真正落地的方法”的問題,為所有讀者提供一種切實可行的實踐手段,是筆者寫作本書的核心目標(biāo)。
        在翻讀本書時,或許你會從本書的字里行間讀到幾分輕松,這是因為書中有不少的文字是筆者在風(fēng)景秀麗的員當(dāng)湖畔的咖啡廳里寫就的,希望筆者這種輕松的心情能夠透過這些文字傳遞給每位工作在“沉重”的需求分析過程中的所有讀者。
        在細(xì)究本書時,或許你會從本書的文字里頭看到幾處零亂,這是因為文中有很多的段落是筆者在吚哎學(xué)語的一歲小兒的惡作劇邊碼成的,希望筆者這些零碎的想法能夠借助書的脈絡(luò)傳達(dá)給每位工作在“繁雜”的需求分析原則下的所有讀者。
        在將書稿交付編輯之時,我深刻地感到:本書雖然沒有Martin七年磨一劍的鋒芒,卻也有三年憋一本的艱辛。在整個寫作過程中,多次經(jīng)歷了自我否定、推倒重來的痛苦,也享受了許多自我升華的樂趣;當(dāng)然筆者衷心地希望本書能夠向大家傳遞樂趣。
        本書特點
        本書是一本直擊需求實踐中各種問題的書籍,在這里沒有大量的理論和教條,有的只是翔實、生動的案例與場景;在這里沒有高談闊論般的“道法自然”,有的只是源于生活瑣碎細(xì)節(jié)的“欣然頓悟”;在這里沒有鷹擊長空般的豪情,有的只是“撒一把土、夯實它,再撒一把土……”的務(wù)實。
        在全書的組織形式上,采用了簡單明了的語法,段落簡潔(就像寫需求那樣),讓你能夠輕松地閱讀;同時貫穿了許多源于生活、源于項目實踐的場景與案例,讓需求藝術(shù)“源于生活、高于生活”,為全書添色增彩;穿插了許多能夠令人沉思、輕松一笑的隱喻,為全書增加了一些漣漪;還埋伏了一些小提示,為全書增加了一些外延和聯(lián)想;而且還羅織了大量的誡語,使全書更多一些骨架與韻味。
        相信所有需求實踐者都能夠從書中看到你工作的影子,尋找到一些“開箱即用” 的技巧和手段,同時也會有整理了一下思緒的妙味。
        本書講了什么
        本書的主線索是筆者在RUP(Rational統(tǒng)一過程)、信息工程理論、結(jié)構(gòu)化分析方法、面向?qū)ο蠓治龇椒ǖ幕A(chǔ)上,結(jié)合長期需求分析工作的實際經(jīng)驗,剪裁出來的一個針對軟件需求工程階段的SERU過程框架。
        SERU過程框架覆蓋了需求定義、需求捕獲、需求分析與建模、需求描述四大活動,明確地定義了工作任務(wù)、介紹了工作方法、指出了工作產(chǎn)物、說明了產(chǎn)物之間的連接方法,可以幫助軟件開發(fā)團(tuán)隊快速應(yīng)用到工作中,有效提高需求工程的質(zhì)量。
        本書一共由4個部分,12個章節(jié)組成:
        部 分 名 章 名 主要內(nèi)容 頁碼
        第一部分
        原理、模型與誤區(qū) 第1章
        需求實踐現(xiàn)狀分析 歸納實踐中遇到的問題,分析問題背后的原因,提出解決問題的方法,強調(diào)“業(yè)務(wù)驅(qū)動的需求過程”的重要性
        第2章
        不同軟件項目的需求視圖 指出各類軟件的需求視圖與線索,幫助需求人員明確工作方向
        第3章
        軟件需求與需求工程 從需求層面的角度理解需求工作的階段,并掌握不同需求類型的組織方法;指出實現(xiàn)優(yōu)秀需求的核心手段,實例講解如何保障;對需求開發(fā)和需求管理工作的任務(wù)進(jìn)行概述,說明需求分析人員工作的技能要求
        第二部分
        需求開發(fā) 第4章
        需求定義最佳實踐 指出需求定義的任務(wù),介紹需求定義的操作思路,介紹常用的人文方法;介紹需求定義階段確定系統(tǒng)范圍的具體方法;并說明需求定義階段的產(chǎn)物,核心內(nèi)容為兩圖一綱(構(gòu)件圖、上下文關(guān)系圖和需求大綱)
        第5章
        需求捕獲最佳實踐 從溝通的角度說明需求捕獲的障礙,并結(jié)合心理學(xué)知識提升捕獲能力;介紹各種需求捕獲方法的使用時機(jī)、要點;能在正確的時機(jī)正確地使用
        第6章
        需求分析與建模最佳實踐 幫助讀者理解為什么要建模、什么時候要建模、如何選擇模型等;學(xué)會正確理清流程分析、業(yè)務(wù)實體分析和用例分析,掌握正確的建模方法以及產(chǎn)物之間的關(guān)系;掌握填充用例和領(lǐng)域類的方法;學(xué)會有效地組織非功能需求、設(shè)計約束的方法
        續(xù)表
        部 分 名 章 名 主要內(nèi)容 頁碼
        第7章
        需求描述最佳實踐 介紹需求描述的主要格式、寫作要點,以及一些提高需求規(guī)格說明書質(zhì)量的手段與技巧
        第8章
        需求驗證最佳實踐 介紹需求驗證的主要手段、常見誤區(qū),以及相應(yīng)的解決方案
        第三部分
        需求管理 第9章
        需求基線操作實務(wù) 說明基線和迭代開發(fā)的關(guān)系,通過實例說明基線管理中估算和優(yōu)先級劃分兩大工作任務(wù)的具體執(zhí)行方法。
        第10章
        變更管理操作實務(wù) 說明變更管理的目標(biāo)與策略,并且進(jìn)一步解釋統(tǒng)一渠道、統(tǒng)一平臺兩大要點
        第11章
        需求跟蹤操作實務(wù) 說明需求跟蹤的作用、啟動時機(jī)及操作要點
        第四部分
        總結(jié) 第12章
        SERU過程框架總結(jié) 對SERU過程框架進(jìn)行概述,指出在實際項目中導(dǎo)入該過程框架的具體步驟和方法,強調(diào)了需求分析過程中的一些重要的原則與方法
        如何進(jìn)一步互動
        為了更好地與讀者交互,提供相關(guān)信息及后續(xù)的更新,本書還將創(chuàng)建一個專門的網(wǎng)站來推廣SERU過程框架,相信不久就可以在http://www.serumodel.com上看到它。
        如果你發(fā)現(xiàn)本書中的問題,或者在實際的工作中遇到問題,也可以通過電子郵件xf@csai.cn和我取得聯(lián)系。
        致謝
        望著這本傾注了巨大激情的書籍,不禁想起被它吞噬的日日夜夜,不由得萌生出對家人的深深歉意,沒有你們的支持本書是不可能完成的;在此由衷地感謝我深愛的妻子許高芳以及敬愛的母親楊美琴,感謝你們多年來的鼓勵與支持。
        望著這本匯聚了大量觀點的書籍,不禁想起為它貢獻(xiàn)的蕓蕓眾生,不由得萌生出對朋友的深深謝意,沒有你們的幫助本書是不可能精彩的;在此由衷地感謝我親愛的朋友們以及予以支持的學(xué)員,感謝你們一直來的關(guān)愛與幫助。
        望著這本集結(jié)了眾多文字的書籍,不禁想起為它糾錯的雙雙眼睛,不由得萌生出對編輯的深深敬意,沒有你們的協(xié)助本書是不可能高質(zhì)的;在此由衷地感謝本書的責(zé)任編輯以及所有工作人員,感謝你們盡職盡責(zé)地把好最后一關(guān)。
        最后,我還要向CSAI創(chuàng)始人張友生博士,主要貢獻(xiàn)者馬映冰、田俊國、溫昱、張華表示感謝,你們的觀點讓我如沐春風(fēng);向博文視點的郭立、李冰表示感謝,你們的幫助讓本書最終付諸實現(xiàn);向中國平安、中國工商銀行、中國建設(shè)銀行、中興通訊、東軟集團(tuán)、用友政務(wù)、新大陸、福諾等企業(yè)中聽過我的課程,以及參加各期公開課的朋友們表示感謝,你們的意見、觀點、建議使本書更加精彩,在我向大家分享經(jīng)驗的同時也收獲了許多寶貴的財富。
        譚 文
        2008年4月2日
  •   同參加過徐鋒軟件需求最佳實踐SERU培訓(xùn)的飄過~~ 總結(jié)的很好,我們現(xiàn)在基本上也是應(yīng)用這個模式
  •    不過書的思路真的非常非常的亂~
  •   同感,書寫的真不怎么樣http://www.tufangbian.com/bbs/
  •   其實就是有點零亂
    其它的還不錯吧
 

250萬本中文圖書簡介、評論、評分,PDF格式免費下載。 第一圖書網(wǎng) 手機(jī)版

京ICP備13047387號-7