分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

                需求驗證的5大要點

    要做好需求驗證，必須在思想、方法、語言、人員、內容5個要點上做好相應的工作，否則就會產生很多負面的影響。
1．思想
    前面已經說過，由於Review被翻譯成“評審”，導致很多人將其與中國人常說的評審相混淆，其實它們之間是有區別的：中國人常說的評審是評價，而Review應該是複查，是發現問題。這一點，必須成為所有組織、參加需求評審會的人員都應該建立的統一認識。
隱喻：
    當測試團隊嚴肅、認真地對你說：“經過我們三天時間的測試，發現你提交的程式一個Bug也沒有！”請問你會作何理解呢？
  A、我的程式很牛！
  B、這個測試團隊的方法或態度有問題。
    我想很多人會選擇B吧！因為“人非聖賢，孰能無過！”應該是測試手段還存在問題，導致潛在的問題沒有被暴露。
可是，“我的需求評審通過了！”之類的話題總是被許多需求人員以很開心、愉快的方式說出來，我怎麼聽怎麼覺得像聽到“我的程式真牛！”。
    就像我們不是想花大量的測試成本來驗證自己的程式無錯一樣，採用成本昂貴的評審技術也不是為了驗證需求文件是無錯的，而是幫助我們儘早地發現問題、找到錯誤，避免因問題被延誤到後期解決而付出慘痛的代價。
SERU誡語8-1：需求驗證的目標是儘可能暴露問題，而不是證明無錯。
2．方法
    統一了思想之後，接下來的重點就是“方法得當”。
SERU誡語8-2：在企業中推行即時評審、同級桌查等正式化程度不高的評審手段，是建立企業評審文化的有效手段。
3．語言
SERU誡語8-3：在評審會中，不要用“評價者”的口氣談論你的觀點。
4．人員
    要開好評審會，選擇合適的參與人員是很重要的；要點在於合適，而不是越多越好。具體來說，包括三個方面的要點：
  同級：別忘了，在CMM/CMMI中提到的是Peer Review，Peer就是同級，千萬不要一開評審會就請高階領導。
  該來的人要請：也就是評審的內容所涉及的第一責任人，要想辦法請他們參加。
  不該來的人不要請：也就是評審不是越多人蔘加越好的，通常應該保持比較小的範圍，要直接相關的人員參與；一方面可以保證參與者對評審內容熟悉，另一方面也可以保證參與者關心評審過程。
SERU誡語8-4：參加需求評審的人不是越多越好，一定要保證同級、適合。
5．內容
    建議大家控制在9條之內，理由就是心理學中的“7±2” 原則，也就是人們容易記住的資訊條目在5～9條之間。因此大家也可以根據實際的情況做一些變通。
    除了要對缺陷檢查表的規模進行壓縮之外，還應該對評審的需求規格說明書進行壓縮。根據筆者的經驗，一個較熟悉的團隊，要對需求進行相對有效的評審，應該控制在每小時30～40頁之間。
那麼在實際的工作中，我們如何對需求文件進行切分呢？是開一個時間週期很長的評審會，還是多次時間週期較短的評審會呢？似乎這兩種方法都不盡可行。
    解決該問題的關鍵在於必須對需求規格說明書進行拆分，根據讀者的層次、所關心問題域的不同進行拆分，具體的方法我們在第4～6章中已經做了很多說明。
SERU誡語8-5：評審時要確保評審內容、缺陷檢查表的規模適合，內容應該按每小時30～40頁的速度來準備，缺陷檢查表儘量在9條之內。
上述文字摘自於 徐峰老師 編著的《 軟體需求最佳實踐：SERU過程框架原理與應用 》一書

中國互動網購買地址：http://www.china-pub.com/209259

【書 名】軟體需求最佳實踐：SERU過程框架原理與應用
【作 者】徐鋒 著
【ISBN】978-7-121-07395-3
【出版社】 電子工業出版社
【出版日期】2008年10月
【宣傳語】
•經驗密集，直擊需求實踐中各種問題。
•貫穿全書的SERU過程框架，詳盡地覆蓋了需求工作中各個環節的任務、要點及產物，可操作性極強。
【內 容 簡 介】
本書首先從軟體需求實踐中出現的主要問題和困難入手，指出了改進的主要方向；然後逐一說明了需求定義、需求捕獲、需求分析與建模、編寫規約、需求驗證等需求開發活動的任務、要點和具體手段；並提出了一個可操作性強、易於上手的SERU過程框架，能夠幫助讀者清晰地瞭解整個過程，理解各階段的關鍵產物和產物之間的關係。
本書還對包括需求基線、變更管理、需求跟蹤在內的需求管理活動的操作要點進行了闡述，給出了具有很強實踐性的具體建議。綜觀全書，語言淺顯、文字生動，蘊含了許多人文、心理、交流方面的知識，即使非技術背景的讀者也能夠輕鬆讀懂大部分內容，從中受益。
本書可作為計算機軟體專業本科生、研究生和軟體工程碩士的軟體需求分析教材，也可以作為軟體工程、軟體開發管理培訓的教材，更是一線專案經理、需求分析人員、資深開發人員、資訊系統執行管理人員、研發企業管理人員的必備參考書。

目  錄
第1部分  原理、模型與誤區
第1章  需求實踐現狀分析    2
在資訊化高速發展的今天，構建與時俱進的資訊化系統已成為所有政府、企事業單位的重點課題之一。然而在軟體專案實施過程中，進度超期、經費超預算、變更頻繁的現象層出不窮，甚至有許多專案根本無法達到預期的目標，更談不上為業主創造真正的效益。歸根結底，軟體需求實踐這一共同的軟肋是問題的根源。
1.1  軟體專案失敗的根源    2
1.1.1  CHAOS Report 1994    2
1.1.2  CHAOS Report後續版本    3
1.1.3  需求相關敗因簡要分析    4
1.1.4  一幅漫畫帶來的思考    8
1.2  透過表象，分析本質    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  開發思想    18
1.4  小結    19
第2章  不同軟體專案的需求檢視    20
隨著資訊化應用的逐漸深入，軟體專案在企業、政府等各類組織中所擔負的角色也越來越多，應用層面也在逐漸地深入，同時也意味著不同的軟體專案具有不同的特點，這也就對需求工作產生了諸多影響。在本章中，我們就將針對資訊系統、嵌入式系統、軟體產品等不同角度來說明如何進行相應的需求工作，為需求分析師提供一個切實有效的檢視。
2.1  資訊系統的需求檢視    20
2.1.1  資訊系統的本質與分類    20
2.1.2  聯機事務處理系統——流程電子化    22
2.1.3  管理資訊系統——資料資訊化    25
2.1.4  其他資訊系統    29
2.1.5  資訊系統的多維檢視    31
2.2  嵌入式系統的需求檢視    33
2.2.1  面向直接使用者的嵌入式系統    34
2.2.2  面向特定裝置的嵌入式系統    35
2.3  軟體產品的需求檢視    36
2.4  小結    40
第3章  軟體需求與需求工程    41
筆者在做需求分析師的培訓時，經常會問學員這樣的一個問題：什麼是軟體需求？這個看似簡單的問題卻並不好回答，也許很多人會簡單地認為軟體需求就是使用者需要實現的功能加上一些非功能方面的要求。但這樣的理解卻並不完整，如果對使用者所處的業務場景沒有建立正確認識，經常會給工作帶來麻煩。因此本章將對一些與需求、需求工程相關的關鍵概念進行闡釋。
3.1  什麼是軟體需求    41
3.1.1  需求的三個層次    41
3.1.2  需求的三種類型    43
3.1.3  優秀需求的標準    46
3.2  需求工程解析    50
3.2.1  需求工程的範疇    50
3.2.2  需求開發工作要點    51
3.2.3  需求管理工作要點    56
3.2.4  需求分析人員的技能組成    58
3.2.5  SERU模型概述    59
3.3  小結    61
第2部分  需求開發
第4章  需求定義最佳實踐    64
需求定義活動準確來說是不屬於需求工程範疇的，它實際上是立項管理需要做的工作。但需求定義階段的產物對於需求捕獲、分析與建模活動都有著直接的影響，如果這個階段的工作做得不理想，就會出現“上樑不正下樑歪”的結果。因此本書還是將這個活動納入進來，並將給大家提供一個能夠與後續活動結合緊密的方法。
4.1  需求定義任務概述    64
4.1.1  需求定義的時機    64
4.1.2  需求定義的理念與策略    65
4.2  問題分析的五步法    66
4.2.1  在問題定義上達成共識    67
4.2.2  分析問題背後的問題    73
4.2.3  確定相關人員和使用者    77
4.2.4  定義解決方案的界限    78
4.2.5  確定加在解決方案上的約束    80
4.2.6  小結    81
4.3  需求定義的產物與要素    81
4.3.1  需求定義的產物    81
4.3.2  需求定義的要素    82
4.4  定義需求範圍    87
4.4.1  案例說明    87
4.4.2  劃分主題域    88
4.4.3  確定主題域範圍    97
4.4.4  標識業務事件與報表    101
4.4.5  生成需求大綱    104
4.5  小結    108
第5章  需求捕獲最佳實踐    109
需求捕獲是需求開發中的第一個活動，可以說任何一個需求團隊對它都不陌生，但如何提高需求捕獲的有效性卻一直以來是困擾大家的問題。需求捕獲的要點在於計劃性和科學性，計劃性體現在對捕獲物件、問題、時間的計劃，科學性則表現在如何有效地選擇合適的捕獲方法。本章的目的就在於幫助大家更好地達到這兩個目標，從而提高需求捕獲活動的質量。
5.1  需求捕獲的策略    109
5.1.1  需求捕獲應該是主動的    109
5.1.2  需求捕獲應該是聚焦的    110
5.1.3  破解需求的冰山模型    111
5.1.4  破解阻礙需求捕獲的心理現象    113
5.1.5  不要忽視對變更可能的捕獲    117
5.1.6  需求協商    118
5.2  需求捕獲的主要方法    125
5.2.1  使用者訪談    125
5.2.2  使用者調查    137
5.2.3  文件考古    142
5.2.4  情節串聯板    144
5.2.5  現場觀摩    145
5.2.6  聯合開發    147
5.3  需求捕獲的記錄工具    150
5.3.1  工具的選擇與定義    150
5.3.2  任務卡片    151
5.3.3  場景說明    152
5.3.4  其他工具    153
5.4  小結    154
第6章  需求分析與建模最佳實踐    156
需求分析是需求工程中最為核心的工作，而需求建模則是需求分析的主要手段。但由於分析這個詞比較抽象，很多時候讓人感到無從入手，甚至導致被輕易地滑過了，直接將需求捕獲的結果整理到軟體需求規格說明書中。而需求建模也有很多工具，到底怎麼有效地應用到需求分析過程中也是令人感到難以掌握的東西。因此本章的目標就是為讀者勾勒出需求分析的階段與任務，指出如何選擇適合的建模工具，以及在什麼時機、如何應用這些建模工具。
6.1  需求分析與建模的要點與誤區分析    156
6.1.1  需求分析到底做什麼    156
6.1.2  建模的目標與要點    159
6.1.3  選擇建模工具的要點    160
6.2  週期一：理清框架與脈絡    164
6.2.1  業務流程分析    165
6.2.2  業務實體分析    191
6.2.3  角色與使用場景分析    216
6.2.4  週期一的產物    232

6.3  週期二：確定需求細節    249
6.3.1  確定行為需求的細節    250
6.3.2  確定結構需求的細節    270
6.3.3  週期二的產物    279
6.4  其他需求分析    292
6.4.1  介面需求    292
6.4.2  非功能需求的追蹤    294
6.4.3  設計約束    297
6.5  小結    301
第7章  需求描述最佳實踐    302
需求描述就是將需求捕獲、分析的結果進行文件化的過程。在軟體開發時，將分析的結果文件化是不可或缺的任務，也稱為編寫規約活動；而在某個專案中，可能還會由使用者代表或需求捕獲人員對捕獲的內容進行整理，形成使用者需求說明書。具體要幹什麼，想必大家並不陌生，而且在前一章中也看到了一些例項的片段。因此本章將重點從需求描述的風格與格式、寫作策略與技巧兩個方面做些強調和補充。
7.1  需求描述的風格與格式    302
7.1.1  常見的描述風格與選用標準    302
7.1.2  典型軟體需求規格說明書模板解析    303
7.1.3  定義模板的技巧    318
7.1.4  使用者需求說明與軟體需求規格說明    326
7.2  寫作策略與技巧    328
7.2.1  文字表達的先天不足    328
7.2.2  需求描述的兩大原則    330
7.2.3  不要忽視陳述需求理由的重要性    332
7.2.4  注意措辭    334
7.3  小結    335
第8章  需求驗證最佳實踐    336
需求驗證是需求開發的最後一個環節，它是一個質量關。也就是說，其目標是發現儘可能多的錯誤，減少因為需求的錯誤而帶來的工作量浪費。而需求驗證的主要手段就是Review（複查，也常譯為評審）。但是許多需求團隊都覺得需求驗證比較容易變得“務虛”，收效很少，本章的目標就是幫助大家緩解這個問題。
8.1  需求驗證的主要手段    336
8.1.1  不同正式化程度的評審    336
8.1.2  審查過程概述    338
8.2  需求驗證的主要誤區與解決方案    340
8.2.1  需求驗證的5大要點    341
8.2.2  需求驗證常見的5大問題    344
8.3  小結    346
第3部分  需求管理
第9章  需求基線操作實務    348
需求基線是需求管理活動中最為基礎的一個，通常也是在專案中首先應該引入的管理活動。但許多相關書籍中對需求基線的介紹相對比較理論化，很少給出具體的操作方法，往往使得許多軟體開發團隊無從入手。為了幫助大家更好地引入需求基線，本章的重點將是結合具體的例項來說明需求基線的劃分方法。
9.1  需求基線的理念與策略    348
9.1.1  基線思想的起源    348
9.1.2  基線的策略    350
9.2  基線劃定的基礎：優先順序評價    351
9.2.1  組織需求項    351
9.2.2  業務優先順序評價    352
9.2.3  根據技術依賴性和專案風險調整優先順序    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  小結    364
第10章  變更管理操作實務    365
需求變更頻繁恐怕是困擾無數軟體開發團隊的惡魔之首，而且在美國權威的第三方機構Standish Group的CHAOS報告中，也將其列為困擾軟體開發團隊、導致專案失敗的5大原因之一，其中原因實際上也充分暴露了整個產業的不成熟。需求變更在 CHAOS報告中是排名第四的問題，而在中國軟體開發團隊中卻是排名第一的問題，這裡面就意味著存在距離，本章的目的就是希望幫助大家找到其中的差距。
10.1  變更管理的理念    365
10.2  變更管理要點一：統一渠道    366
10.2.1  CCB背後的道理    366
10.2.2  變更處理過程    368
10.3  變更管理要點二：統一平臺    373
10.3.1  變更管理平臺的選擇    373
10.3.2  變更管理平臺的應用要點    374
10.4  小結    375
第11章  需求跟蹤操作實務    376
需求跟蹤是一個高階的管理活動，它的目標是為了更好地管理需求的狀態、更好地分析需求變更產生的影響。雖然執行需求跟蹤會帶來不錯的效益，但其所需付出的工作量也是巨大的。本章我們就對跟蹤的一些要點做一簡要的說明。
11.1  需求跟蹤的基本概念    376
11.1.1  使用者需求到軟體需求的跟蹤    377
11.1.2  軟體需求到軟體需求的跟蹤    377
11.1.3  軟體需求到下游工作產品的跟蹤    377
11.2  需求跟蹤的操作方法    378
11.2.1  表格法    378
11.2.2  連結串列法    379
11.3  小結    381
第4部分  總結
第12章  SERU過程框架總結    384
筆者經常說一個觀點：“我們並不缺乏軟體工程、需求工程的理論、技術，缺乏的是將這些理論與技術有效地應用到實踐中去的具體方法”。而貫穿全書的SERU過程框架（也稱為SERU模型）正是筆者基於多年不同領域、不同規模的軟體專案實踐的基礎上，通過對許多重型方法的剪裁而得到的一個清晰、實用的軟體需求過程框架。
12.1  SERU過程框架要點概述    384
12.1.1  SERU過程框架的理論基礎    384
12.1.2  SERU過程框架全景圖    385
12.1.3  SERU過程框架匯入建議    388
12.2  需求實作要點概述    388
12.3  結語    391
參考文獻    392
SERU誡語目錄
第1章  需求實踐現狀分析    2
SERU誡語1-1：需求規格說明書應該採用業務導向的樹型層次結構來組織。    6
SERU誡語1-2：對於需求分析員而言，真正的專業主義是基於業務利益
SERU誡語1-2：（解決問題、創造機會、提高管控力等）的溝通。    6
SERU誡語1-3：緩解溝通失真最有效的方法是及時複述。    9
SERU誡語1-4：需求分析的本質在於業務分析，而非技術分析。    11
SERU誡語1-5：業務場景是需求之魂。    12
SERU誡語1-6：需求分析人員對於技術方法論的評價重在適用性。    16
SERU誡語1-7：對預設計的需求是評判敏捷方法論是否適用的關鍵。    18
第2章  不同軟體專案的需求檢視    20
SERU誡語2-1：流程分析（業務事件）是OLTP系統的關鍵線索和主要檢視。    23
SERU誡語2-2：報表分析是MIS系統的關鍵線索和主要檢視。    26
SERU誡語2-3：決策場景是DSS系統的關鍵線索和主要檢視。    29
SERU誡語2-4：工作場景是專家系統的關鍵線索和主要檢視。    30
SERU誡語2-5：並行工作流是OA系統的關鍵線索和主要檢視。    30



           

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow