• 需求開發(fā)與需求管理過程中的常見問題
• 熱身聯(lián)系：角色扮演游戲
  過程：講師扮演客戶，學(xué)員（分組）扮演需求調(diào)研人員，模擬需求開發(fā)過程。目的是：1）熱身以及2）團(tuán)隊(duì)融冰
  講評：通過演練來認(rèn)識“靠譜的需求從哪里來”的命題，認(rèn)識需求開發(fā)與需求管理的常見誤區(qū)——邊界不清晰、缺少可視化監(jiān)控手段以及無限制拔高用戶對系統(tǒng)的期望值 ……
• 軟件項(xiàng)目的“魔鬼數(shù)字”
  關(guān)于軟件項(xiàng)目已經(jīng)被證明行之有效的、被廣加利用的一些經(jīng)驗(yàn)數(shù)據(jù)，例如：
  需求分析和需求開發(fā)活動的工作量占比至少應(yīng)該達(dá)到多少？
  工具對于效率提升的極限可以達(dá)到多少？
  極端情況下進(jìn)度最多可以被壓縮多少……
• 一個不是問題的問題——誰該來寫需求
  案例剖析：“IT引領(lǐng)業(yè)務(wù)”的A銀行信息科技部 Vs.“IT支撐該業(yè)務(wù)”的B銀行信息科技部
  “做正確的事” Vs.“把事做正確”——需求開發(fā)與需求管理過程中完成的蛻變
  做好需求分析的第一要務(wù)——我們交付的是價值，而非產(chǎn)品本身——案例剖析
  “桌面以上的交付價值”Vs.“桌面以下的交付價值”——哪些沒有被講出來的需求
  案例剖析之一：化繁就簡
  案例陋習(xí)之二：去簡就繁
  需求開發(fā)與需求管理中的3個基本問題和3個拓展問題
  小結(jié)：需求開發(fā)與需求管理是一個公司的核心競爭力

• Attention! 我們說的可是“軟件需求”—— “需求”基本概念、各類“需求”的定義（功能需求、非功能需求/質(zhì)量屬性、設(shè)計(jì)約束的定義）和各個層級的需求（用戶需求/業(yè)務(wù)需求、產(chǎn)品需求與產(chǎn)品組件需求）
• 現(xiàn)實(shí)總不如看起來那么美好之1——軟件需求開發(fā)和需求管理的兩大常態(tài)：1）“用戶講不清楚需求”和2）“需求總是處于變更當(dāng)中”
• 現(xiàn)實(shí)總不如看起來那么美好之2——你所接收從用戶/市場人員/業(yè)務(wù)人員轉(zhuǎn)發(fā)過來的需求通常存在哪些問題：
  “業(yè)務(wù)流程”與“系統(tǒng)流程”的邊界不清晰
  “用戶期望”與“系統(tǒng)功能”“的邊界不清晰
  只有“系統(tǒng)能做什么”，沒有“系統(tǒng)做的有多好”
  最容易被忽略的一類用戶——Administrator
• 三種不同詳細(xì)程度的“需求”：白云級需求、風(fēng)箏級需求和場景級需求
• 你準(zhǔn)備好了嗎——作為需求分析人員，在軟件需求開發(fā)和需求管理過程中你將承擔(dān)怎樣的角色與職責(zé)？
  你能講的清楚嗎，你自己項(xiàng)目的“獨(dú)特性”特征是什么？
  你能講的清楚嗎，你自己項(xiàng)目的“目標(biāo)”是什么？或者僅僅只以一句“按時保質(zhì)的完成任務(wù)”作為搪塞，并不清楚或者沒有關(guān)注到自己的項(xiàng)目會給客戶帶來的價值？

• 決定捕捉需求策略的三大要素——客戶/用戶參與程度、需求分析人員的熟練程度、技術(shù)性約束條件
• 真的需要“傾聽每一個客戶的聲音”嗎——客戶的“癢點(diǎn)”和“痛點(diǎn)”是什么、我的系統(tǒng)將解決他/她的什么問題
• 我們交付的是“價值”而非“項(xiàng)目”本身——如何從孤立的用戶需求中判斷系統(tǒng)的“交付價值”
• 諾蘭模型永放光芒——如何有效的引導(dǎo)和限制用戶的“期望值”
• 挖掘需求技術(shù)哪家強(qiáng)？實(shí)際案例展示——有效的需求捕捉與無效的需求捕捉正反案例介紹與剖析

• 分組演練之1：各小組分析演練場景的內(nèi)容，識別各自的相關(guān)方及其關(guān)注點(diǎn)，并且用“一句話”總結(jié)本項(xiàng)目的交付價值
• 【特別企劃】：演練中可以使用貴公司自己的實(shí)際項(xiàng)目作為演練場景。
• 捕捉需求的熱身活動：需求調(diào)研計(jì)劃與需求調(diào)研提綱（含案例分享）
• 需求開發(fā)的方法之1：訪談
• 需求開發(fā)的方法之2：業(yè)務(wù)邏輯捕捉
• 需求開發(fā)的方法之3：聯(lián)合需求工作會議
• 分組演練2：使用演練1的成果，識別案例中需求不明確或者缺失的部分，并據(jù)此制定需求調(diào)研提綱和問題列表

• 需求分析的基本原則：問題的識別、評估、平衡和綜合
• 分析功能性需求的三種工具之1
  早期需求分析的神器——用戶故事（User Story）
  講得清楚每條需求“以便于給用戶帶來怎樣的價值”是用戶故事方法最神奇的地方
  正反案例介紹與剖析：用戶故事描述“風(fēng)箏級”需求的實(shí)例
• 分組演練之3：使用“用戶故事” 方法分析演練項(xiàng)目場景的5項(xiàng)需求
• 分析功能性需求的三種工具之2
  場景級需求的分析神器——用戶用例（UseCase）
  UseCase所帶來的“劃一刀”效應(yīng)：區(qū)分“系統(tǒng)”與“用戶”的邊界
  正反案例介紹與剖析：用戶用例描述“場景級”需求的實(shí)例
• 分組演練之4：使用“用戶用例”方法分析演練項(xiàng)目場景的3項(xiàng)需求
• 分析功能性需求的三種工具之3
  當(dāng)“誰也講不清楚系統(tǒng)的需求”時使用的分析神器——原型法
  原型法最關(guān)鍵的地方——你需要哪一部分的原型？
  原型法的“需求評估”環(huán)節(jié)如何操作？
• 分析非功能性需求的“八元方法”——從8個維度分析非功能性需求
• 需求的平衡與“二叉樹”方法設(shè)定需求的優(yōu)先級

?

• 需求建?！褂梅柣Z言動態(tài)的描述需求
  需求建模的方法之一：數(shù)據(jù)流圖
  需求建模的方法之二：實(shí)體－關(guān)系圖
  需求建模的方法之三：狀態(tài)遷移圖
• 分組演練之5：使用“狀態(tài)遷移圖”完成演練項(xiàng)目場景的頂層建模，使用數(shù)據(jù)流圖分析指定的需求。
• 需求的規(guī)格化的基本原則
  ;兩種模式的需求規(guī)格說明書文檔的樣例——IRF（界面原型-業(yè)務(wù)規(guī)則-業(yè)務(wù)流程）和UseCase（用戶用例）
  需求的命名規(guī)則
  “好”的和“不好”的需求描述樣例剖析
• 分組演練之6：使用IRF方法撰寫需求規(guī)格（含非功能需求）

• 需求的分解——從用戶需求/業(yè)務(wù)需求到軟件需求，從“用戶的視角”——>“軟件的視角”
• 需求的跟蹤的兩種方法——需求跟蹤矩陣、需求履歷
• 如何針對“增強(qiáng)開發(fā)模式”跟蹤需求
• 需求的橫向跟蹤的解決方案
• 需求重用，以及“模式重用”的案例介紹與剖析
• 分組演練之7：根據(jù)第6個演練的成果，進(jìn)一步使用使用IPO方法撰寫軟件需求規(guī)格說明書文檔

• 軟件需求的團(tuán)隊(duì)協(xié)作模型
• 需求評審的方法介紹：
  正規(guī)檢視
  同行專家評審
  走查
• 關(guān)于需求分析和需求管理的既往經(jīng)驗(yàn)集成——需求評審檢查單
• 分組演練之8：小組交換第7個演練的成果、使用“走查”方法評審對方的需求規(guī)格

• 變更管理的流程
• 變更管理的度量

• 為何放棄治療——為什么不愿意把需求寫清楚？
• 讓我們一起把把脈吧——在貴公司如何部署需求開發(fā)與需求管理活動?