談談需求（上）

         楔子

标題叫《談談需求》其實不好，因為需求隻是一個名詞，但是很明顯我這所指并不是要闡述“需求”這個概念，而是指需求分析這個階段性動作。但是後續可能還會寫談談設計、談談測試、談談寫代碼之類的文章，做成一個系列，為了标題對仗，也就把動詞省略了。

何謂需求，往小了說，就是使用者想要實作的一個IT系統功能；往大了說，其實也是人類求生欲望的延續，就類比克勞.塞維茨說的——戰争不過是政治的延續。當然，這裡的求生在人類科技文明高度發展的今天，不僅僅是求生存，而是求生活——渴求更好的生活。這種生活不僅僅是滿足人的物質生活，更是為了滿足人的精神生活，以求精神富足。

         将IT技術拿出來看，其實不過是人類更高效工作、更友善生活的工具與手段，使用者需求，本質上不過是人們高效工作或更好生活的欲望的可實作性延續，是為了滿足人的資訊生活而存在。這裡所謂“可實作性延續”，一不小心又說成了一個IT術語，即是可以在軟體系統中實作的功能延續。

         概念辨析

說到“需求分析”，很容易讓人聯想到《需求分析報告》，但是我這所指并不僅僅是這一步，還包括《需求規格》。這兩份文檔是需求分析階段中使用者需求分析、功能需求規整這兩個前後相承的分析設計步驟的階段成果性傳遞文檔，而生産出這兩份文檔的這兩個步驟亦是整個需求分析階段的兩大關鍵步驟，這兩個步驟的品質高低很大程度上決定了未來實作所的系統的功能穩定程度、與使用者需求期望的比對程度，也是軟體系統架構是否穩定的一大決定性的影響因素。

         說到《需求分析報告》、《需求規格說明書》，很多人總以為這就是一份文檔，或者分不清這兩者的差別，其實很簡單，各自加上兩個字就一目了然了——《使用者需求分析報告》、《功能需求規格說明書》。

         《需求分析報告》是需求分析師收集了使用者需求進行系統分析後所形成的最終結論性文檔，而《需求規格說明書》則是軟體設計師根據《分析報告》中所分析出的分散的功能需求，進行系統級的統一規整的産物，也就是說“需求分析”分析的是使用者需求，而“需求規格”規整的則是功能需求。《需求分析報告》是《需求規格說明書》的輸入，《需求規格說明書》是《需求分析報告》的最終輸出。兩者的描述内容可能相近，但并不等價，各有側重。使用者需求側重從使用者角度出發來描述一個需求，相對而言，比較抽象化、感性化；而功能需求側重從産品定位、系統設計與實作的高度來考慮一個需求（對，是高度，不僅僅是角度），是以會更加系統化、理性化地來考慮需求的實作，若能配上界面原型圖，就能更加具體、接地氣。

         史蒂夫.喬布斯說過“使用者永遠不知道他們自己真正想要的是什麼。”，此話同樣适用于軟體工程領域的需求分析工作，因為使用者對IT知識的掌握程度有限，是以并不能苛求他們能用很專業的IT術語來将一個業務需求描述得很清楚。他們對需求的描述往往會更貼近于他們的具體業務背景，甚至會夾帶很多所在業務領域的專業術語。他們口中所說的需求也許并不是真正的功能需求，而隻是他們業務中真正需求的一個“外體化、形象化”的展現。使用者口中所說要實作的“功能”也許并不是真正能滿足他業務需求的功能，隻是由于他的IT知識所限，隻能描述成這樣。

         是以需求分析工作一定要系統、客觀、冷靜。需求分析人員應該盡可能地引導使用者将他們心中真實的需求“吐”出來。為了達到此目的，需求分析人員甚至可能還需要對目标使用者所在業務領域進行一定深度的了解，以便盡可能地熟悉使用者關注的業務場景，通過業務場景的熟識，來了解使用者真正的業務訴求。

需求分析報告内容組織

         到此，本文總算可以進入正題了，也就是《需求分析報告》具體要做哪些工作、内容如何整理輸出。根據上文思考，需求分析報告必然以業務場景為機關進行整理，當業務場景數量開始龐大時，就需要将業務場景進行分類，而分類的标準，根據筆者的經驗，傾向于根據需求來源劃分（每處來源用一個一級标題辨別），而不是根據預先設計的系統大功能子產品來劃分。這樣做的好處就是便于不同業務使用者進行需求跟蹤、以及最終的需求簽署确認。業務使用者隻需要關注自己那個一級标題下的需求的分析過程就可以了，而不需要從全篇文檔來Search屬于自己的需求。

         說完了業務需求的整理規範，接下來該讨論《需求分析報告》的核心部分——内容組織了。需求分析報告一般都包括以下幾部分，也即是可以作為一級标題的内容：産品目标與範圍、使用者需求（包括原始需求清單、使用者需求分析、安全性需求、品質屬性需求）、限制條件、術語約定。

産品目标與範圍

簡短描述該軟體産品的開發目的，包括功能利益和産品定位目标等，把軟體産品開發與企業目标或者業務政策相聯系，一般包括産品目标描述與業務範圍界定兩部分。前者需要明确此項目的業務期望目标、産品定位；後者需要能明确此系統的使用者範圍、功能範圍、甚至地域範圍。

業務功能性需求

使用者需求部分是此文檔的核心部分，首先包括一個用于統計跟蹤原始需求用的使用者需求清單，該清單維護的目的即是友善業務方跟蹤總攬所有原始需求，一般以表格形式記錄，包括業務需求編号、需求來源、原始需求簡短描述等内容。

對業務需求有了總體記錄後，接下來便是詳細的業務需求分析了，這也是需求分析報告傳遞品質高低的核心内容。此部分内容中，需要對每個業務需求進行細緻系統分析，是以一般以表格形式表述為好。每個業務需求對應一個小表格，主要包括以下幾個部分内容，每行描述一條：需求編号、業務需求描述、業務處理流程、使用者範圍、前置條件、業務規則、關鍵功能需求點、需求提出人。最好是以表格形式來描述。

         需求編号：這是用來檢索所有業務需求用的，一般是如下格式：R.BussinessDomain2.008，R是《需求分析文檔》字母簡寫、BussinessDomain2用于标記來源，008則是需求順序編号。如果對word文檔操作很熟練，此處編号建議自定義一個自增式編号格式，這樣友善後續插入業務需求時文檔自動編号。

         業務需求描述：以文字形式來記錄業務提出的原始需求語言，盡可能細緻明确但不羅嗦，多用短句對業務點進行明晰表述。

         業務處理流程：在業務需求描述基礎上，對業務期望的處理流程進行描繪，盡量抽取出重要流程節點，建議用類似流程圖的格式描述。

         使用者範圍：在需求分析階段，參與者不需要馬上分别出系統角色，可以按照實際業務角色來記錄即可。

         前置條件：描述執行此業務功能的前提條件，有可能由此産生與其他系統內建的接口需求。

         業務規則：用于描述執行此業務功能的業務限制性條件，包括邏輯判定、資料邊界值等，例如，一個資料輸入，資料最大、最小值是多少。。

         主要功能需求點：此處是業務需求分析的主要傳遞成果，需求分析人員根據上面的“業務需求描述”内容，并參考“業務處理流程”，初步抽取出核心功能需求點，此處需求點盡量以清單展示，句式簡潔扼要但必須語意清晰，盡可能挖潛出使用者尚未表達出的真實需求。對于需要內建業務需求的軟體系統，此處可能會産生與外部軟體內建的接口需求，此接口需求将對應《需求規格》中的外部系統內建需求部分内容。

         需求提出人：此處記錄此業務需求的提出人，也是業務需求确認人，若後續需求蔓延，或者因開發技術性原因導緻需求無法全部實作，均跟此人溝通确認。

需求編号

業務需求描述

業務處理流程

使用者範圍

主要功能需求點

業務規則

需求提出人

         非功能性需求

         非功能性需求包括可用性需求、可靠性需求、可擴充性需求、性能需求、安全需求等内容。某些文檔中還包括硬體需求等。

         這些内容大多跟具體業務相關，本系列文章着重軟體系統設計，在此就不過多細述了。

         費了這麼多口舌，堪堪寫完需求分析，需求規整還沒開始，那就未完待續咯。不過行家應該知道的，《需求規格說明書》核心就是Use Case。

         散論

使用者需求實作的最終目的并不在于為讨部分使用者歡心而去花大力氣實作某個好看花哨但不實用的功能，而在于通過此系統更好的滿足絕大部分使用者的業務需要，提高其業務執行效率。注意，我這講的是“此系統”而不是“此功能”，因為功能永遠是局部的，而系統則是整體的。局部功能強大所緻的局部工作效率提升并不一定就能代表整個事務效率的提升。隻有開發系統的幫助事務在各個重要節點都得到普遍效率提升，才算是真正地滿足了使用者需求，達到了業務期望。

一個一直堅持的觀點：其實，軟體工程文檔的模闆并不僅僅是模闆，而且并非各自獨立的文檔，而是一整套互相聯系的設計說明書，是系統開發思路的節奏性展現，就像剝洋蔥，層層剝開，循序漸進，每一個步驟都馬虎不得，這類設計文檔寫到一定程度，設計人員就能根據目前階段文檔撰寫的流暢程度去判斷前一階段文檔傳遞品質的好壞。是以，可以這麼說，這一套文檔模闆水準的高度就直接決定了軟體設計水準的高低。

         寫這些文章的用意，其實很簡單，技術之路漫漫兮，望乞高人指點一二，望與同仁切磋切磋，以不至于把路走偏走絕。