那些奇怪的需求
需求1
客戶：做個百度幾千塊夠不夠？
程式員：不夠的！
客戶：一萬夠了吧?
程式員：不夠的!
客戶：就那麼幾個頁面，我做一個淘寶也隻才幾千塊，你是不是坑我?
程式員：你找到了可以做的麻煩介紹給我，我也想做一個。。。
需求2
需求3
上司:那個運維啊，你來把他的系統了，要不把他伺服器黑了也行。給你一天時間，搞不搞得定。
常見的需求問題
1、 需求不明确
- 盲人摸象，各階段人員隻掌握了一段
- 初期階段，業務還在摸索
- 各部門目标和kpi不一緻，需求有沖突
2、需求了解不一緻
客戶：我家有三個小孩，我須要一個能三個人用的秋千。它是由一繩子吊在我園子裡的樹上。
項目經理：秋千這東西太簡單了，就是一塊闆子，兩邊用繩子吊起來，挂在樹上的兩個枝子上。
設計師：這個無知的項目經理，兩個樹枝上挂上秋千哪還能蕩漾起來嗎？除非是把樹從中截斷再支起來，這樣就滿足要求了。
項目最重要的階段是進行需求分析，明白真正的需求。項目需求指的是使用者真正需要什麼，而不是供應商假設使用者需要什麼和供應商能夠供應什麼。需求的準确定位就是要按使用者要求，對目标系統提出完整、準确、清晰、具體要求。這對一個項目的成功來說非常重要，需求分析做得不好，就會造成需求不斷變更，進而影響進度、費用，甚至會導緻項目失敗。
3、需求自身經常變動
- 盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求。以便在進行系統設計時，将軟體的核心建築在穩定的需求上，否則将會吃盡苦頭。
- 在合同中一定要說清楚“做什麼”和“不做什麼”。如果合同含含糊糊，日後扯皮的事情就多。
7、需求擷取
1、需求來源
幹系人
幹系人（Stake holder）：對于系統有利益關系的個人，團隊、組織和其他系統。
項目幹系人包括但不限于：
- 投資方：系統的投資方
- 主管方：準許/管理系統的
- 最終使用者：使用者/系統受益方
- 操作方：操作/維護系統的
- 監管方：認證系統的
- 測試方：負責系統驗收
示例：XX信貸管理系統
投資方： 資金部
主管方：資訊化部
使用者代表： 市場部
最終使用者： 營業員
監管方： 審計部
測試方： 資訊化部
操作方： 資訊化部 2、需求分類
軟體需求的三個層次：
1. 業務需求
描述組織或客戶的高層次目标，通常問題定義本身就是業務需求。業務需求就是系統目标，它必須是業務導向、可度量、合理、可行的。這類需求通常來自于高層，例如項目投資人、實際使用者的管理者、市場營銷部門或産品策劃部門。
業務需求從總體上描述了為什麼要開發系統 （why） ，希望達到什麼目标。比如“希望實施CRM後公司的客戶滿意度達到80％以上”。
業務需求對之後的使用者需求和功能需求起了限定作用，任何使用者和功能需求都必須符合業務需求。
2. 使用者需求
使用者需求是指描述使用者使用産品必須要完成什麼任務，怎麼完成需求，通常是進行使用者訪談、調查，對使用者使用的場景進行整理，進而建立從使用者角度的需求。
使用者需求必須能夠展現軟體系統将給使用者帶來的業務價值 ，也就是說使用者需求描述了使用者能使用系統來做些什麼（what），這個層次的需求是非常重要的。
使用者需求可細分為：
- 基本型需求： 産品功能必須滿足的使用者需求。例如社交産品的加友功能；音樂産品的聽歌功能。
- 期望型需求： 使用者滿意度随着此類需求的滿足程度而線性提升或下降。當此類型需求越得到滿足則使用者滿意度越高，反之則使用者滿意度越低。例如，音樂類産品的歌曲越多越好。
- 興奮型需求： 是一種完全出乎使用者意料的屬性或功能。例如微信的搖一搖。
- 無差異型需求： 這類需求無論滿足與否，使用者滿意度都不會受其影響，使用者對此因素并不在意。例如産品的簡介。
- 反向型需求： 使用者沒有此需求，提供後滿意度适得其反。例如産品付費功能。
3. 功能需求
功能需求描述的是開發人員需要實作什麼，是需求的主體，它描述的是開發人員如何設計具體的解決方案來實作這些需求（how），其數量往往比使用者需求高一個數量級。
這些需求記錄在軟體需求規格說明（Software Requirments Specification） 中。SRS完整地描述了軟體系統的預期特性。開發、測試、品質保證、項目管理和其他相關的項目功能都要用到 SRS。
3、擷取步驟
我們必須知道擷取需求的具體步驟
- 辨別項目幹系人：幹系人清單
- 與項目幹系人交流：溝通計劃
- 收集需求：需求溝通紀要
- 重要性排序：需求優先級
- 選擇需求：根據資源和限制，選擇實作的需求
- 記錄需求：編寫文檔
軟體研發是一個團隊性工作，各個角色協同工作，共同把項目完成。每個階段和角色的産出，又是下一階段和角色的輸入。比如作為架構師，會根據産品經理編寫的功能需求說明書，進行整體系統架構設計，而開發人員，也會根據産品經理的需求說明書和架構師的概要設計，做詳細的設計和開發。
8. 需求要素
1、角色、場景
一般來說每個業務活動是對使用者使用場景的抽象（例如電商購物活動），每個業務活動可能包含多個場景（例如商品浏覽、購物車、下單、支付），分析使用場景時應按照業務活動為主線逐個進行分析，每個業務活動分析時應包含如下内容：
1.明确活動執行角色
2.明确活動執行的前置條件
3.明确不同場景：
一個業務活動可能包含正常的使用場景、備選使用場景和異常使用場景
4.明确每個場景的執行步驟
5.業務規則和限制：
明确在每個業務活動下應遵循的業務規則和限制，這裡一般是與業務流程相關的行為規則，或與資料實體相關的資料規則（比如某個字段的長度）
2、業務流程
針對流程類需求必須進行業務流程分析。需求人員進行流程分析應遵循如下方法：
（1）業務流程确認
一個流程為一個業務事件，一般是外部角色發起或系統内部主動發起（比如時間事件或狀态事件），發起後會觸發一系列業務活動。
（2）角色及業務活動确認
流程圖中的每個泳道都必須對應到角色，每個角色對應多個業務活動。需求人員在确認業務活動時一定要保證活動的粒度，一個業務活動一定是由一個角色完成且每個業務活動都是有價值的。
（3）業務活動間關系及資料确認
确定所有業務活動的前後關系，并明确流程間傳遞的資料實體。
（4）流程整體瓶頸分析
一般若某個角色業務活動工作量較大，或流程涉及進階上司，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優化建議。
3、資料實體
針對流程類需求需要分析各業務活動傳遞的資料實體，統計分析類需求需要分析統計查詢條件資料實體和展現資料實體，接口類需求需要分析接口傳遞資料實體，具體分析包含如下内容：
1.明确資料實體
确認需要分析的所有資料實體，明确哪些為系統原有實體、哪些為新增實體、哪些為改造實體。
2.明确所有資料實體間關系
實體間關系包含（1對1、1對多、多對多），另外需要分析資料實體變更是否需要保留版本，實體删除（邏輯删除、實體删除）是否影響其它資料實體。
3.明确資料實體字段
針對新增資料或改造資料實體需要明确新增字段的名稱、字段類型、是否必填、字段取值方式（人工輸入、系統自動繼承自其它資料實體、系統自動計算需要明确計算公式）。
4.資料權限分析
需要分析不同角色在資料權限方面的差異，若涉及縱向多級使用者，要說明對于集團/省/地市使用者的資料隔離。
4、功能性需求
系統功能分析是結合系統現狀和上述分析進一步明确實作相應使用者場景的系統功能，主要還包含内容如下：
1.功能清單
分析得出實作上述業務活動對應的功能/接口清單，并明确新增功能、改造功能；
2.功能/接口關聯影響分析
實作某個業務活動需要新增或改造的功能對其它關聯功能/接口的影響分析。比如改造請購池受理功能，可能會影響采購項目建立功能；采購項目建立功能修改一個字段取值範圍，會影響項目統計分析和同步ES系統接口。
3.系統互動原型分析
需求人員應遵循界面規範，并與研發溝通确定系統互動原型，幫助研發或使用者更好的了解需求場景。
在互動原型中應包含如下内容：
- 原型界面的名稱、入口，原型間關聯關系和使用角色
- 頁面内容、格式及排序方法
- 操作要點：比如互動的資訊提示、界面規則和限制（比如界面以不同顔色顯示不同的校驗結果）。
4.算法分析：
在系統功能互動時涉及比較複雜的算法，需要單獨對算法進行分析。
5、 非功能性需求
包含需求的可行性分析、健壯性分析、可擴充性分析、執行效率分析，可行性分析從以下幾個方面進行：
1.技術可行性 系統互動實作方式與研發确認是否可行，需求人員在與研發溝通過程中需要不斷積累哪些功能實作在技術層面很難支撐。
2.時間可行性 根據使用者的上線時間要求分析是否可滿足要求。
3.合法合規可行性 分析使用者需求是否滿足國家法規或公司法規要求。
4.資料安全性分析 使用者需求是否滿足資訊系統安全要求。
9. 案例：電商訂單系統
1、概述
電商所有子產品中，訂單系統是非常核心的一個子系統，決定了整個流程能不能順暢的執行，起着承上啟下的作用，其他子產品都是圍繞訂單系統進行建構的。訂單系統出問題，或者功能流程設計不完善、不準确，将會造成整個電商系統整體或局部業務流轉不順暢，甚至導緻項目的失敗。
訂單系統的作用是：管理訂單類型、訂單狀态，收集關于商品、優惠、使用者、收貨資訊、支付資訊等一系列的訂單實時資料，進行庫存更新、訂單下發等一系列動作。訂單系統業務的基本模型涉及使用者、商品（庫存）、訂單、付款。訂單基本流程是下訂單-->減庫存，這兩步必須同時完成，不能下了訂單不減庫存（超賣），或者減了庫存沒有生成訂單（少賣）。
下面我們從需求分析的角度，來看一看B2C電商中先款後貨模式下的訂單系統設計的過程。
2、角色
一個訂單系統，涉及到的角色包括：
實體角色：
- C端使用者
- B端商戶
- 電商平台
- 配送商
- 第三方平台
系統關系：
3、場景(用例)
從使用者的角度，我們看到的使用者場景如下：
用例圖：
4、功能
訂單系統業務架構：
（1）訂單服務
該子產品的主要功能是使用者日常使用的服務和頁面，主要有訂單清單、訂單詳情、線上下單等，還包括為公共業務子產品提供的多元度訂單資料服務。
（2）訂單邏輯
訂單系統的核心，起着至關重要的作用，在訂單系統負責管理訂單建立、訂單支付、訂單生産、訂單确認、訂單完成、取消訂單等訂單流程。還涉及到複雜的訂單狀态規則、訂單金額計算規則以及增減庫存規則等。在4節核心功能設計中會重點來說。
（3）底層服務
資訊化建設達到一定程度的企業，一般會将公司公共服務子產品化，比如：産品，會建構對應的産品系統，代碼、資料庫，接口等相對獨立。但是，這也帶來了一個問題，比如：訂單建立的場景下需要擷取的資訊分散在各個系統。
如果需要從各個公共服務系統調用：一是會花費大量時間，二是代碼的維護成本非常高。是以，訂單系統接入所需的公共服務子產品接口，在訂單系統即可完成對接公共系統的服務。
5、實體