| Module 0概述：需求開發(fā)與需求管理的“Yes”與“No |
- 需求開發(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ā)與需求管理是一個公司的核心競爭力
|
| Module 1打開軟件需求的黑匣子 |
- 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)目會給客戶帶來的價值？
|
| Module 2 捕捉和挖掘需 |
- 決定捕捉需求策略的三大要素——客戶/用戶參與程度、需求分析人員的熟練程度、技術(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)研提綱和問題列表
|
| Module 3 需求的分析 |
- 需求分析的基本原則：問題的識別、評估、平衡和綜合
- 分析功能性需求的三種工具之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)先級
?
|
| Module 4需求建模與需求規(guī)格化 |
- 需求建模——使用符號化語言動態(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ī)格（含非功能需求）
|
Module 5需求的分解與跟蹤
|
- 需求的分解——從用戶需求/業(yè)務(wù)需求到軟件需求，從“用戶的視角”——>“軟件的視角”
- 需求的跟蹤的兩種方法——需求跟蹤矩陣、需求履歷
- 如何針對“增強(qiáng)開發(fā)模式”跟蹤需求
- 需求的橫向跟蹤的解決方案
- 需求重用，以及“模式重用”的案例介紹與剖析
- 分組演練之7：根據(jù)第6個演練的成果，進(jìn)一步使用使用IPO方法撰寫軟件需求規(guī)格說明書文檔
|
Module 6 需求的評審與確認(rèn)
|
- 軟件需求的團(tuán)隊(duì)協(xié)作模型
- 需求評審的方法介紹：
正規(guī)檢視
同行專家評審
走查
- 關(guān)于需求分析和需求管理的既往經(jīng)驗(yàn)集成——需求評審檢查單
- 分組演練之8：小組交換第7個演練的成果、使用“走查”方法評審對方的需求規(guī)格
|
Module 7 管理需求變更
|
|
| Module8 本次培訓(xùn)總結(jié)及答疑 |
- 為何放棄治療——為什么不愿意把需求寫清楚？
- 讓我們一起把把脈吧——在貴公司如何部署需求開發(fā)與需求管理活動?
|
