需求并不是關于需求 (Requirements are not really about requirements)
大家去公共圖書館寄存物品，以前都是掃二維碼開箱，有些圖書館升級了使用指紋識別。
“是否新方法比以前好？”我問年輕的開發人員。
“當然用指紋識別好。新技術！現在已經很少看到使用條碼的系統了。”
“如果取物時指紋識別失敗怎么辦？以前還有條碼紙條作為憑證，找管理員人工開箱處理，但用指紋識別的話，就無法證明自己是寄存那個人，甚至連寄存在哪箱都可能忘記了。而且指紋識別的錯誤率比條碼高，所以雖然是新科技，成本也提升了，但未必帶來價值。”
每次培訓，我都會用這例子提醒學員需求并非只談需求，必須為擁有它的人提供最理想的價值。有些產品經理混淆了解決方案與需求本身：“寄存需要用指紋識別開箱”，
但如果把需求寫成：“讓寄存者取得憑證，之后用來開箱”
設計師就不一定選擇用指紋識別，它只是其中一種方案。
如果希望IT系統給用戶帶來價值，就需要從整個業務全面分析，有些需要由IT系統支持，有些不需要。
下面會舉例說明。
很多團隊都未能做好以下3點：
- 需求分析
- 識別關鍵干系人
- 非功能性需求
需求分析
業務用例，包括產品用例，可以幫助我們分析整個業務流程，確保能為業務產生價值。
使用下面的模型，可以有效地按以下順序系統地分析與設計業務用例（Business Use Case BUC) 、產品用例 (Product Use Case PUC)。
- 現在業務流程(Now,How)
- 現在業務用例(Now,What)
- 未來增強后的業務用例(Future,What)
- 未來的產品用例(Future,How)
例如：線上在超市購物，產品用例就包括處理買家的結賬請求，連接信用卡數據，更新買家的購物歷史和等待發貨的訂單信息。但業務用例就包括系統以外的其他配合工作，包括：超市員工在貨架上按訂單取貨，聯系物流公司把貨品送到買家地址。
首先描述現在的處理方式（左下角）。
在左上角描述現在業務用例，柜臺處理的方式，然后在右上角想象用了系統后，網上選購與下訂單的未來業務用例，哪些流程應該在線上做更容易（右下角）。
“剛年底審查了我們某針對醫院臨床軟件系統，發現整年開發的功能中，有86%都未被使用。”
我們從而了解到，把需求分優先級很重要，所以要制定開發什么功能，集中精力這些會被使用的20%功能，而不是浪費時間在開發完都沒有用的80%功能。
有人提出，其實可以反過來看，怎么篩選哪些功能不應該做，可能更容易。
但應怎么篩選呢？
| 某家專門做高端安防系統的P公司，為一家大賣場S公司開發一款廉價的安防系統，如下：
請問你作為產品經理會如何反應？ --==+++==-- “增加一個缺失的需求去檢測損壞的窗口”很多學生會立馬問（因為剛剛聽完第一條的解讀。）：“客戶為什么要做這個功能？” |
從以上例子看到產品經理不僅僅是傳話，要利用業務的知識，了解和過濾需求，拒絕沒有價值的需求。
需求人員過濾了不合理的需求后，還是要分析成本和給客戶的價值，對價值比成本高的需求分優先級。
| 如果我們必須構建軟件，那么它必須為擁有它的人提供最理想的價值。
|
以上面儲物柜故事舉例：
因為指紋識別成本高，但沒有提供更多價值，所以不應該做。
用例與場景
用戶故事針對“做什么”與“為什么”（“What”，“Why”）； 場景針對“如何做”（“How”），例如普通市民用手機程序搜索下周一央視7臺有什么節目。所以它們之間是互補，沒有沖突。每個需求都應考慮各類場景，以銀行個人用戶用銀行卡去ATM機取款為例：
正常情況：使用個人銀行卡取300元
其他可選情況：從其他銀行卡取款
異常情況：取款后沒有及時取回銀行卡，導致吞卡
正常場景是基礎；但如果沒有全面考慮各種場景便會導致最后開發出來的產品不滿足客戶需求。
實例：護照到期續證
比如我們護照更新，以前是要到柜臺手工辦理，如果我們把那個過程數字化，讓市民可以在線做，不需要親身到柜臺辦理。應怎樣做呢？
某國家的做法是本來的手工填寫模板直接變成系統頁面（每個輸入與手工表格一一對應），申請人在系統里按本來模板填寫并提交，上傳個人新照片，也是經過系統，我有一次嘗試用系統線上填電子表單申請，但因表單很繁瑣，有很多護照原有信息都需要重新填寫，光是填那表就花了我接近一個小時，最大問題還不是在我花時間填手工表，而是最后要上傳照片，因為照片像素高的話就很大，需要很好的網絡才可以傳得上，如果照片像素小，便導致模糊不清，不能通過。最后，一個半小時后，我用盡所有方式都還是無法傳上照片，我最終放棄了在線上提交申請，直接預約去在柜臺做!
之前描述的整個過程只是把原有的手工步驟信息化,和原本的申請手續一樣。但線上辦理和在柜臺現場辦理不同，在現場你可以要求對方直接把照片給你，也可以要求對方提供老護照，但在線上辦理，應很容易從系統里找到個人護照信息，所以很多本來在柜臺要手工填寫的老護照信息就不需要再填了。
客戶：怎么可以簡化整個過程？最困難應是照片的更新？
我：有些國家是這樣做法，比如你申請續證，只需要填上老證件的基本信息，系統就立馬能識別出本來的證件 你確實有那個“舊”證后，便可立馬提交申請。跟在網上購物一樣，你確認過內容沒問題，就在網上付費，然后打印申請表并在表上親手簽字，然后附上幾張符合規格的照片，郵寄到政府機關。他做好新證件以后再郵寄回你。或者你自己到他規定的地點領取也可以。這樣就能很簡單地利用“低”科技解決方案，解決了剛才上傳照片的困難。
從上面例子看到，我們應不僅是把那些本來手工的流程自動化，應該全局看要解決的問題本身，哪些過程自動化，哪些不應該自動化（比如傳照片）。
甲方對怎么可以在線上做這個過程也沒有概念，他只是知道，本來手工需要填表。
乙方也不知道，他只是做開發，也不知道有什么方面可以不用IT方式，而用其他方式更合理。
必須要一起探討才可以有最好的解決方法。
以上例子，業務用例是線上續護照。但有些功能不靠系統處理，如上傳照片，不歸納為產品用例，用其他方式手工處理。
以上只是考慮了正常業務流程，也要考慮各種異常場景才算全面。（請動腦筋，寫出各種異常場景，附件里有以往學員的答案，供參考。）
所以作為業務分析師，你很可能要改變用戶思考問題的方式，例如利用業務過程模型，配合場景與頁面原型，與利益相關者一起探索問題的本質。軟件系統必須為擁有它的人提供最理想的價值，構建軟件系統本身（例如只是把現有流程自動化）不一定能解決客戶業務問題。
識別利益相關者
和杭州客戶領導吃晚飯，領導就跟同桌的項目經理開玩笑說：“你們剛剛完成內部項目管理自動化工具，做調研的時候好像沒有找過我？ 其實我是其中一位經常要使用這系統的管理者，下面項目的監控、申請都是經過我，但我發現這個系統很不合用，對收集我需要的項目信息沒有作用。比如沒辦法處理一些批準信息。”
從上面對話，可以了解如果沒有全面識別項目的利益相關者，可能會影響到項目的成敗。例如我接觸一些有些具備開發經驗的需求人員，但他們通常只注意功能需求的技術細節。
問他們：“哪些是你的項目干系人？”
答：“甲方有協調員，要訪談哪些人都是由甲方協調員安排，我們聽他安排。”所以為了避免未能識別所有干系人的風險，就要主動跟甲方一起策劃。我們說溝通計劃必須是甲乙方一起合作做出來，而且會牽涉甲乙方各個層次的人。
例如要聽甲方出資人的需求，可能就要乙方的總經理出馬，乙方的需求人員頂多可以跟甲方對口的項目組人員溝通。（如何可以做好識別干系人，并制訂溝通計劃，可詳見附件。）
非功能性需求
雖然很多項目有性能、易用性等非功能需求部分，但缺乏可衡量的量化指標。
例如，多少用戶量、數據量、什么平臺與網絡環境下的反應時間。
“客戶沒有提非功能的具體需求。”需求人員可能說。
“但沒有明確可衡量的需求不等于沒有要求。假如驗收時甲方項目經理換了人，項目可能會因為反應時間太慢，甲方說不能接受，但因為非功能需求不明確，你們也無法證明產品滿足需求，最終項目可能被拒收。所以建議你們也要寫上具體可驗證的性能需求，保障自己。如果客戶沒有具體要求，可以依據以前同類項目性能測試結果，制定容易達到的性能規格，成為需求模板。”
除了性能 (Performance) 外，其他主要非功能需求包括：
- 產品觀感（Look and Fell）
- 產品的外觀和感覺越來越受重視，例子：蘋果iPAD MacBook 等都讓客戶覺得產品設計精簡但高貴
- 可用性與易用性（Usability and Humanity）
- 線上網購手機APP，能否容易找到喜歡的菜式、挑選并下單
- 操作環境（Operational and Environmental）
- 從肩高跌落時，產品仍能存活
- 產品應在什么溫度、濕度等條件下使用
- 產品應節省電池壽命
- 可維護性和支持（Maintainability and Support）
- 產品應易于移植到Android和iOS
- 能簡單、快速地從原有的產品導出資料，更新到新一代同類產品
- 應翻譯成各種外文
- 安全（Security）
- 權限（Access），例如：只允許哪些人使用
- 隱私（Privacy），例如：防止打印任何個人及機密資料；防止未經授權的人進一步或二手使用
- 完整性（Integrity），例如：確保傳輸的數據相對應
- 審計（Auditing），例如：在法定期間保留所有交易的日記賬。
- 文化（Cultural），法律（Legal）
其他最佳實踐
用戶故事卡
用戶故事卡片目的是讓用戶（業務）與開發溝通的橋梁。
需求卡片除了包括需求描述，理由，驗收標準外，還應有以下內容:
- 顧客滿意度/顧客不滿意度：
用兩個數比單純用優先級能更全面反應客戶聲音。
（如想多了解為什么要這樣分，請看附件里的“客戶聲音:Kano Diagram”）
- 來源：每項需求都應可追溯到源頭.例如需求是哪個人,什么崗位提出.
- 沖突與依賴其他需求：是/否； 確保需求之間的一致性。
- 獨立的需求編號:
因為設計、編碼、測試用例都應與需求相互對應，有明確編號才能對應。
（用實體卡片,團隊難以互動、分享，有些公司采用系統 記錄與跟蹤需求。電子卡也應包括以上內容。）
做好需求評審
很多團隊都有做需求評審，但因為沒有主要關注點，起不了質量把關的作用，可以利用以下的檢查單提醒需求有沒有犯了這些錯誤，盡早改正。
評價和驗收的準則可包括:
|
總結
上面簡述了3類需求常見問題：
- 需求沒有按價值過濾與分析，分優先級；沒有全面考慮各種場景
- 沒有全面識別利益相關者
- 沒有明確描述非功能需求，并可驗證
和2條實踐：
- 用戶故事卡
- 需求評審
都可以與CMMI模型對應：
- 需求分析：RDM 3.5, 3.6, 3.2 ( 場景 )
- 干系人：PLAN 2.4, MC 2.2 ( 溝通的策劃與監控 )
- 非功能需求：RDM 2.2 ( 客戶需求，包括功能與非功能需求 )
- 需求卡片：RDM 2.2 , 2.4 ( 客戶需求與活動或工作產物之間雙向可追溯 ）
- 需求評審：RDM 2.3
附件
利益相關者
利益相關者計劃檢查單 (Stakeholders Plan Checklist):
1） 列出所有潛在的利益相關者(List all potential stakeholders)
1a. 類型/分組 (What are the base Segments)
1b. 可否再細分(Any sub-segments)
2）把她們分為 F（友好）、I（忽略）、U（不友好）
Assign F (Friendly)、I (Ignore)、 U (Unfriendly) to them
3）他們最關注什么？
What is important to them?
4）學習目標 (Learning objectives):
針對某利益相關者，我們需要了解什么？
For each stakeholder, what will we need to learn?
5）怎樣溝通 (How)
6）什么時間 (When)
抽樣計劃 (Sampling plan)
如何招募(How to recruit)
如何能獲得承諾(How to get commitment)
[針對以上第1至第3項，參閱以下實例/解讀]
實例/解讀(Examples / Explanation)
某公司專門設計、開發新一代手提電腦產品。
1)?全面考慮各類利益相關者（Stakeholders）
出資人 (Sponsor)：出資人為產品的開發付錢
顧客 (Customer)：顧客購買產品。必須對他們有足夠的了解，理解他們認為什么有價值，所以會購買什么產品。
用戶 (User)：確定用戶的目的是為了理解他們所做的工作，以及他們認為哪些改進有價值。
在開發消費產品、大市場軟件時，應該考慮用一個“假想用戶”。假想用戶是一個虛擬用戶，它是大多數用戶的原型。
類型/分組的例子如下：
未來筆記本電腦的潛在用戶：
大類：
- 商業人士 (Business)
- 媒體專業人士(Media Pro)
- 家庭用戶(Home)
細分：
- 主要用戶(Lead User)
- 有極高要求者(有挑戰的 Demanding)
- 潛在用戶(有潛力的 Potential)
- 追求技術完美者 (技術流 Tech-Phobic)
2)?策劃包括哪些用戶（User inclusion strategy）
依據設計人員會怎么對應，把不同識別出來的利益相關者分成?F、I、U
例：以針對筆記本電腦創新產品
F(Friendly)友好，比如家庭用戶、商業用戶、媒體專員
I(Ignore)忽略?，比如忽略殘疾人士
U(Unfriendly)不友好，比如黑客、小孩（禁止他下載游戲、玩游戲）
3)?他們注重什么（主要關注點）
| 干系人 | 角色/概況 | 質量關注重點 |
|---|---|---|
| 商業用戶 | 長期出差者 -坐長途飛機 -做演示 -保護某些秘密文檔 | -待機時長 -屏幕清晰度 -安全性 |
| 專業媒體 | 創造性工作；并要協同。 錄音和錄視頻 | 數字帶寬（聲音和視頻） 電腦速度和內存 |
| 家庭用戶 |
- 以上有那些在調研之前已知，其他有那些需要挖掘。
客戶聲音：Kano Diagram
可以用下圖分析用戶對需求優先級：
解讀上下兩個箭頭應怎樣看：
- 下面的箭頭代表理所當然(Take it for granted)，如果缺乏，客戶會很不滿意，包括覺得是理所當然 (例如滿意度：中立1，非常不滿5)
- 上面的箭頭代表是加分項 (Attractive)，如果包括會非常滿意，但如果缺乏不會覺得不滿意 (例如滿意度：非常滿意5 ，不滿意度：中立1)
所以“需求卡片”用兩個系數：顧客滿意度+顧客不滿意度，能更好判斷某功能屬于哪類功能需求。
線上續護照的 異常場景
以下是部分異常場景： 個人信息類
- 信息不符，無法識別
- 生僻字姓氏，系統無法識別
付款
- 支付失敗
- 直接經銀行付款
- 經渠道支付驗證出錯
系統類
- 系統間接口兼容性問題，提交失敗
- 系統出現故障，無法登錄或無法上交
- 瀏覽器兼容性問題
特殊情況
- 法定假日，不接受申請
- 緊急情況：申請人遇到急病，親人海外死亡等緊急情況，需加急處理
- 信息錯誤：申請表信息填寫不完整或填寫錯誤，需補正
- 照片不符合規格
特殊人群
- 申請人屬于未成年人
- 父母國籍不一致，無法線上判斷國籍
參考 References
- Beck, Kent , with D. West. "User Stories in Agile Software Development" , Ch.13 of?Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle?edited by F. Alexander(2004)
- Robertson, S.?Mastering the requirements process.?(2006) 2/e
)
