^^^^^^^^^^^^^^^^^^^^^^^^^^^^

今天翻以前寫的資料，偶然看到一篇總結，覺得有點用，就貼出來供以後再系統性的整理。

 

項目需求分析總結——對某出版集團項目的需求規格說明書的修改意見總結

2009.5

本文以近期對某出版集團項目的需求規格說明書的修改情況爲主，結合在其他項目瞭解到的情況，總結了一些常見問題和經驗，供大家今後在需求分析和編寫需求規格說明書時參考借鑑，有不對的地方請指出。

 

1. 需求規格說明書的用途概述

1.1. 常見問題

一些開發人員在編寫需求規格說明書時，對需求規格說明書中各部分的用途不是很清楚，經常出現下列問題：

1） 爲寫而寫，應付檢查，尤其是在事後補CMM文檔時容易發生；

2） 將需求書寫成了用戶使用說明書，出現大量最終界面，侷限於已開發程序；

3） 忽視用戶的期望，或者需求調研不夠深入，開發人員自己假想出需求；

4） 從開發人員角度來寫，用了很多技術術語，沒考慮用戶和領導能否理解；

1.2. 核心價值

編寫需求規格說明書的關鍵不在於“寫”，而在於“看”，即用於其他人閱讀和檢查。所以我們不需要在如何寫得好看上面下很多功夫，但一定是要能讓人看明白，理解上不會出現較嚴重的歧義，要用他們熟悉的話語表達，要考慮是給特定人看的。

其次，需求規格說明書是用於追求更少的需求變更，儘可能準確和完整的描述出需求，避免因需求不明確或錯誤給開發過程帶來返工和浪費。

1.3. 讀者關注點

編寫需求規格說明書是要讓人看的，有下列人員需要閱讀和關注需求規格說明書：

a、用戶領導

關注所能達到的宏觀目標，這關係到上項目的意義和價值，所以如果我們明確寫明項目目標就比較好，需要注意不要過多涉及細節；

關注項目範圍，涉及到資金、週期、協調；

關注對現有部門的影響，決定是否需要部門調整和安排；

b、用戶技術領導、項目負責人

除了關注用戶領導的範圍外，還關注如何實施、業務流程的合理性、軟件效果等；

c、最終用戶

一般不會閱讀需求規格說明書。關注軟件細節問題，如最終軟件是否易用、合理，對軟件存在的問題比較在意，對項目有評估權，沒有決定權。

d、開發領導、產品經理

關注面較廣，關注技術方案、項目需求是否合理、優先級等；

e、設計編碼人員

關注需要實現哪些功能需求、需要注意的問題；

f、測試人員

關注如何測試、如何使用，需要理解功能需求；

 

2. 需求規格說明書的各部分用途及注意事項

2.1. 名詞定義

用於描述需求規格說明書中容易混淆或不明白的名詞術語。如果讀者老是問一些詞是什麼意思，就該在名詞定義部分說明，或者在第一次出現的地方說明。

這部分的常見問題是常常流於形式，寫的多是大家都知道的。

2.2. 項目背景

用於提醒大家爲什麼要啓動本次開發。

2.3. 項目目標

很重要，準確概括的描述出本次項目需要達到的目標，既要高度概括又要準確無誤。用戶領導和項目負責人很關注項目目標的內容。

描述項目目標需要注意下列問題：

1、避免使用模棱兩可的話，不說大話，避免讓人無限聯想，防止引發出新的系統；

2、避免過分涉及技術細節，畢竟這部分還只是高層次目標（想想用戶領導能否看懂）；

3、以用戶期望的目標爲主，不要把我們自己的設想單方面加進去；

2.4. 運行環境

描述出用戶需要配備的設備、網絡情況、是否需要設備採購和改造；

如果這部門寫的比較準確的話，可供開發人員考慮是否符合實際運行環境。

需要注意網絡情況、部署情況，例如物理位置分佈情況、是否在同一局域網內、百兆網/千兆網/寬帶連接/ADSL/VPN/共享寬帶，這對我們系統的設計和實施至關重要。

2.5. 與其他系統的關係

實際上描述出了項目邊界，需要把這部分內容提前到項目描述章節，以便用戶領導和項目負責人等讀者能結合項目目標一起很明顯的看到項目範圍和相互銜接情況。

這部分內容不能使用模棱兩可的話，一定要準確清晰的描述。

這部分內容一定要很清晰的看出我們需要開發的系統是哪些部分。

與其他系統的銜接要明確出接口方式、銜接情況，明確責任，準確界定邊界。

2.6. 客戶現狀分析

詳細準確的列出客戶目前的現狀（文件資源、部門、網絡、已有系統、協作單位、現有流程、目前問題等），這部分內容的用途是爲準確進行系統分析提供充分的依據，也是系統能給用戶帶來哪些價值以及系統解決重點的分析材料。

2.7. 業務流程描述

這部分描述用戶使用場景（業務流程、業務需求），具體描述了我們的系統實施後各個部門人員是如何工作的。這部分需要詳細描述，用戶從這裏瞭解新系統是否符合使用流程，系統分析人員以此決定需要哪些功能來滿足，開發人員可瞭解功能將在哪些環節使用。

如果沒有這部分內容，直接就是一大堆功能點，就不能準確判斷出提供的這些功能是否滿足用戶需要。

對於有多種使用情況的分別描述出使用場景。

描述業務流程需要注意的地方有：

1、採用用戶能理解的語句表述，不使用專門技術術語，不涉及技術細節；

2、描述出哪些部門、哪些人員、什麼時候、做什麼事情、如何做、爲什麼做，描述出系統應提供的響應和責任；描述出涉及到的其他系統；

3、用戶看不見的內部細節不描述；

2.8. 功能需求

這部分內容主要是給開發人員和測試人員閱讀的，具體描述了需要提供哪些功能。如果已經沒寫業務需求的話，就只好從功能需求中看了，當然這是不好的。

功能需求需要注意的地方有：

1、描述出需要實現哪些功能、操作過程及要求，不要寫成用戶使用說明書。

2、不要插入大量實際用戶界面，有界面也僅是界面示例，不能寫成“功能如圖所示”。

3、不能過分簡單，新功能需要明確描述，已實現功能不用太詳細，應詳細程度一致；

2.9. 重點難點問題分析

需求規格說明書中出現的疑問都不應直接提出疑問，應當作爲不明確待調研的問題，不要期望由用戶來解答其中的問題。

如果是因爲技術複雜等原因不方便列爲本階段的範圍，就需要直接說明難點原因和對策，以便用戶能理解現實侷限性。

 

3. 需求調研需要注意的問題

準確詳細的需求調研和分析是項目成功的關鍵，下面列出一些需要注意的地方：

1、準確瞭解用戶期望和用戶現狀，不要想當然的開發；

2、不要過於侷限於已有系統而忽視用戶所需，不要先入爲主；

3、如果是由開發人員進行需求調研，需要注意切換角色，根據情況切換到需求調研、系統分析、設計、編碼、項目管理等角色；另外需要注意不要首先想到技術實現，首先要調查清楚需求，然後決定哪些人來決定技術實現問題；

 

4. 業務需求描述的改進實例

4.1. 實例：總體業務流程圖

原來情況：

問題：

a． 這個圖屬於系統解決方案圖或功能結構示意圖，作爲總體業務流程圖則太細；

b． 要麼將這個圖放到功能需求部分中，要麼改爲簡單直觀的體現大的業務流程；

改進情況：

改進總結：

對於總體業務流程圖，儘可能體現用戶能看到的業務流程的總體情況，儘可能不涉及細節功能和存儲技術。

整體系統的業務流程圖可以不涉及用戶角色，主要是表現有多少大的流程子系統。

 

4.2. 實例：圖書庫業務流程

原來情況：

問題：

a． 子系統的業務流程需要考慮有哪些部門參與、有哪些業務實體；

b． 子系統的業務流程圖不需要涉及細節功能和內部技術；

改進情況：

改進總結：

業務流程圖中要涉及到用戶實體及數據來源（部門、已有系統、角色），在流程箭頭上可寫上特殊說明的操作方式或數據文件。

 

4.3. 實例：圖書採集的業務流程描述

原來情況：

問題：

a． 業務流程圖圖標混淆、流程步驟太細、角色和流程環節不對應；不應體現內部分多少庫；

b． 流程描述部分太粗，需要準確說明各種人員做什麼事、先後順序；

改進情況：

改進總結：

需要體現用戶和系統分別需要作什麼事，可以對較敏感的操作方式作出明確說明，例如：手工命名、自動入庫、收集文件、通過xxx工具。

 

4.4. 實例：圖書加工業務流程

原來情況：

問題：

1． 除了前一例的問題外，此處還有：不應體現具體用戶界面；

改進情況：

 

4.5. 實例：圖片庫業務流程

原來情況：

問題：

改進情況：

 

4.6. 實例：音視頻庫業務流程

原來情況：

改進情況：

 

5. 功能需求描述的改進實例

這部分主要是給開發人員看到，各種注意事項暫時省略（要寫出來可能要不少篇幅）。

6. 非功能描述

個人覺得最好把非功能描述分別寫到用例中，這一部分只寫全局性通用的非功能。