需求分析是乙個我們與客戶不斷溝通的過程，這個過程就如同我們與老闆的一次對話。老闆把你叫去，給你交待了一大堆任務。我們首先是仔細聆聽任務的內容，然後整理個一二三四。然後我們複述一遍老闆的意思：「老闆，我複述一遍，您看看我理解得對不對。首先，您要求我×××，然後×××，最後×××。」老闆：「恩，就是這意思，你照著辦吧。」之後，我們開始了我們的工作。這個複述的步驟相當重要，因為人與人的溝通最大的問題就是失真。由於人在知識水平、觀點看法、性格特質的不同，聽者常常會誤解對方的意思。有了複述的步驟，誤解就會立即被糾正，溝通得以順暢。在需求分析中，這個複述的步驟就是需求確認。
但與一次簡單的溝通不同，需求分析是一系列複雜的溝通過程，它涉及到許多人，談論的是許多的事物。因此，一次簡單的口頭複述不足以滿足需求分析的需要。因此，需求確認是一系列的確認過程，每次確認都可能需要與不同的人，在不同層次的確認。最終應當形成到紙面，形成文件性的東西，雙方簽字確認。這個過程中可以採用的乙個好的方法就是原型法，最終產物應當是需求列表與需求規格說明書，最後結束於一場需求評審會，或者簽字確認會。
當我對無數失敗專案的分析總結之後，得出的乙個重要的結論就是我們的專案需要對需求的跟蹤。大家想想，當乙個專案持續數月，經過數輪的需求分析與設計，再經過數輪的需求確認與變更。使用者、需求分析員、系統架構師、設計人員、開發人員，甚至測試，乙個乙個的角色像走馬燈一樣加入進來。需求開始變得模糊不清，軟體設計的初衷開始偏離。開發人員不知道依據哪個標準開發，測試人員不知道依據哪個標準測試，甚至一些需求被人所遺忘。最終，等到軟體交付的時候，客戶說這不是他們所需要的，專案走向了失敗。問題出在**呢？問題就出在，不論我們如何分析與設計，我們都要如實記錄原始的需求，並以此來驗證我們最終的軟體。這個如實記錄原始需求的文件，就是需求列表。
需求列表，又稱之為需求跟蹤表，是最原始的、使用者對業務需求的描述。它不摻雜任何需求分析人員對業務需求的分析與設計，而是以簡短扼要的語句，以業務人員的口吻表述的，今後要開發的這個系統應當提供給他們的各項功能。
首先，需求列表不摻雜我們對業務需求的任何分析與設計，這是需求列表的核心，也是它存在的意義。從用例模型到領域模型我們不難發現，它是乙個分析與設計的過程。需求分析員對業務需求進行捕獲、認識、理解以後，需要結合軟體專業知識進行分析設計，還要聽取系統架構師和設計師對需求可行性的分析，最後才整理和編寫出用例模型。在這樣乙個過程中，隨著業務需求複雜度的提高，以及各種技術分析的摻雜，最終的結果很有可能偏離原有的業務需求。這種偏離常常表現為對業務需求正確性與完整性的偏離，即需求已經變味兒了，或者某些需求專案缺失。需求列表就是那個最開初的、最完整的、正確的業務需求。用這樣乙個列表來開始我們的分析，最後用它來驗證我們的設計，使之成為我們的分析設計之旅樹立的乙個正確的航標。有了這樣乙個航標，就可以使我們最終能夠到達乙個正確的彼岸。
其次，需求列表應當是站在業務人員的視角，對業務需求的簡明扼要的描述。乙個紛繁複雜的、業務龐大的管理系統，經過整理以後，被分解成乙個乙個的需求專案。每個需求專案是一句簡明扼要的話。簡明扼要意味著清晰易懂；分解成需求專案意味著分解複雜問題為簡單問題。每一次與業務人員討論完業務需求以後，我們就整理成這樣乙個需求列表，使我們與客戶的討論都有乙個清晰明了的討論結果。當下一次與業務人員討論時，我們拿出我們上一次討論的需求列表，又使下一次的討論有乙個基點，使業務討論能以演進的方式推進下去，提高我們的工作效率。
然而，需求列表中應當剔除那些客戶對系統設計的內容。前面我們提到，客戶，特別是那些對資訊化建設有一定經驗的客戶，容易提一些對系統設計的期望，比如什麼功能應當做成什麼樣子，功能介面是怎樣的。客戶提的這些意見，也許不是最佳的，我們經過深入的分析設計以後，可能會提出一些更加合理的方案。因此，這樣內容不能成為我們驗證系統功能的基石，因而不應當寫入需求列表中。需求列表描述的更應當是客戶對軟體功能的意圖，即客戶使用這個功能所達到的目的，而不是功能的具體實現。這一點我們在後面通過具體例項詳細說明。
最後，需求列表也不是一步到位的，而是經過由粗到細逐漸整理形成的。乙個大的需求專案可以分解為多個細的需求專案，進而形成乙個樹狀的需求列表。需求列表應當細分到什麼程度呢？將系統需求描述清楚為宜。簡單需求不需過多的細分，而複雜需求則需要盡量寫細一些。同時，需求列表也是乙個不斷變化的過程，日後的每一次公升級維護都需要不斷增添和修改需求列表，使其與實際系統保持一致。
[url=我們應當怎樣做需求分析[/url]
[url=我們應當怎樣做需求調研：初識[/url]
[url=我們應當怎樣做需求調研：拜訪[/url]
[url=我們應當怎樣做需求調研：研討會[/url]
[url=我們應當怎樣做需求調研：需求研討[/url]
[url=我們應當怎樣做需求調研：迭代[/url]
[url=我們應當怎樣做需求調研：需求捕獲（上）[/url]
[url=我們應當怎樣做需求調研：需求捕獲（下）[/url]
[url=我們應當怎樣做需求分析：功能角色分析與用例圖[/url]
[url=我們應當怎樣做需求分析：業務流程分析（上）[/url]
[url=我們應當怎樣做需求分析：業務流程分析（下）[/url]
[url=我們應當怎樣做需求分析：用例說明[/url]
[url=我們應當怎樣做需求分析：查詢報表分析[/url]
[url=我們應當怎樣做需求分析：子用例與擴充套件用例[/url]
[url=我們應當怎樣做需求分析：行**和狀態圖[/url]
[url=我們應當怎樣做需求分析：業務領域分析[/url]
[url=我們應當怎樣做需求分析：原文分析法[/url]
[url=我們應當怎樣做需求分析：領域驅動設計[/url]
[url=我們應當怎樣做需求分析：非功能需求[/url]
[url=我們應當怎樣做需求確認：需求列表[/url]
[url=我們應當怎樣做需求確認：乙個需求列表的例項[/url]
[url=我們應當怎樣做需求確認：快速原型法[/url]
[url=我們應當怎樣做需求確認：需求規格說明書[/url]
[url=我們應當怎樣做需求確認：評審與簽字確認會[/url]
（續）
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
我們應當怎樣做需求調研 初識
很多需求分析的工作是從需求調研開始的，我們就從這裡說起吧。需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點 既是乙份體力活兒，更是乙份技術活兒。它既要求我們具有一種理解能力 設計能力，更要求我們具有一種與人交往 溝通的能力。在乙個陽光明媚的下午，專案經理帶領著專案組成員，參加了客戶組織...