產品需求是產品經理的想法，一般需要通過產品需求文件來寫出來做說明。

運用這種方式（工具）是有助於其他人理解產品的。

要做成一個產品要靠團隊協作，團隊當中還應該有一個參考點，在研發階段產品需求文件就扮演了參考點的角色。這個參考點不光一人明白就可以了，還要向團隊其他人說明白。

如何說明白？先說什麼？怎麼說？

先說什麼？

就涉及到說明順序。

所謂合理的說明順序，是指：能充分表現事物或事理本身特徵的順序，也是符合人們認識事物、事物規律的順序。

正確的順序能正確地理清文章思路，能幫助讀者理解。

在開發階段，和團隊人員說明產品需求描述，可以口頭交流可以藉助文字——一般是先說這個產品的主要功能，讓程式設計師有大體的了解，然後具體到細節。

先說大體再說具體，這已是大多數人的習慣。這個習慣體現了從概括到具體、整體到區域性的順序，也是描述產品需求的邏輯順序。這裡面可以看到曾經在學校時老師教寫說明文的影子，所要描述的物件和目的不一樣。

先說概括，那概括的該怎麼說呢。

門衛保安常通過三問——“你是誰？來自哪裡？到哪裡去？”來了解來訪者。

“我是誰？來自哪裡？到哪裡去？”這三大哲學命題，個人覺得對人認識產品、改造產品是具有指導意義的，適用於理解產品以及指導寫產品需求文件。畢竟產品也是一個世界，而且似乎真是值得好好玩味的三點。

描述一個產品往往是這樣：通過這個產品的什麼功能內容給誰帶來了什麼？

產品經理描述產品需求就像是：站在一個造物者去造物（軟體產品）的角度來闡述所造之物。

軟體需求包括三個不同的層次:業務需求，說明了提供給客戶和產品開發商的新系統的利益,反映了組織機構或客戶對系統、產品高層次的目標要求，它們將在專案檢視與範圍文件中予以說明;使用者需求，描述了使用者使用系統必須要完成的任務，這在使用例項文件或方案指令碼說明中予以說明;功能需求和非功能需求，定義了開發人員必須實現的軟體功能，使得使用者能順利完成他們的任務，從而滿足了業務需求。

一、需求獲取

需求的收集、分析、細化、核實並組織的步驟，並將它編寫成文件。這個活動包括了編寫專案檢視和範圍文件、使用者群分類、選擇使用者代表、建立核心隊伍、確定使用例項、召開聯合會議、分析使用者工作流程、確定品質屬性、檢查問題報告和需求重用10個具體任務，文章將在後面進行詳細的闡述。

二、需求分析

根據需求獲取中得到的需求文件，分析系統實現方案。這個活動需要完成下面幾個任務：

1、繪製關聯圖，用於定義系統與系統外部實體間的邊界和介面的簡單模型;

2、建立開發原型，當開發人員或使用者不能明確某些需求時，開發一個系統原型，這樣使得許多概念和可能發生的事更為直觀明了;

3、分析可行性，在允許的成本、效能要求下，分析每項需求實施的可行性，明確每項需求實現相聯絡的風險，包括與其它需求的衝突，涉及各類使用者的利益平衡，對外界因素的依賴和技術障礙;

4、確定需求優先順序：分析方法來確定使用例項、系統特性或單項需求實現的優先級別，以優先順序為基礎確定產品版本將包括哪些特性或哪類需求;

5、為需求建立模型，為需求建立圖形分析模型是軟體需求規格說明極好的補充說明，可以為系統需求從多個角度建模;

6、編寫資料字典，建立資料字典資料字典是對系統用到的所有資料項和結構的定義，以確保開發人員使用統一的資料定義;

7、應用品質功能調配，將系統特性、屬性與對客戶的重要性聯絡起來，提供了一種分析方法以明確哪些是客戶最為關注的特性。

三、編寫需求規格說明書

需求開發的最終成果是客戶和開發小組對將要開發的產品達成一致協議，這一協議就是通過文件化的需求規格說明書來體現。需求規格說明書包括專案檢視和範圍文件說明了系統的業務需求，而使用例項文件則說明了使用者需求。這個活動需要完成下面幾個任務：

1、採用模版,在你的組織中要為編寫軟體需求規格說明書等文件定義一種標準模板,該模板為記錄系統需求和各種其它與需求相關的重要資訊提供了統一的結構;

2、指明需求來源，為了讓所有專案風險承擔者明白需求規格說明書中為何提供這些功能需求，要能追溯每項需求的來源，來源可能是一種使用例項或其它客戶要求，也可能是某項更高層系統需求、業務規範、政府法規、標準或別的外部來源，這些來源應該記錄在需求的跟蹤能力矩陣中;

3、為每項需求註上標號，為了需求的可跟蹤性和可修改性的品質標準，必須唯一確定每個軟體需求，為制定一種慣例來為需求規格說明書中的每項需求提供一個獨立的可識別的標號或記號;

4、記錄業務規範，是指關於系統的操作原則，比如誰能在什麼情況下采取什麼動作,將這些編寫成需求規格說明書中的一個獨立部分，或一獨立的業務規範文件;

四、需求驗證

需求的驗證是為了確保需求說明準確、完整，表達必要的品質特點,需求將要作為系統設計和最終驗證的依據,因此一定要保證它的正確性。需求驗證務必確保符合完整性、正確性、靈活性、必要性、無二義性、一致性、可跟蹤性及可驗證性這些良好特徵。這個活動需要完成下面幾個任務：

1、審查需求文件，對需求文件進行正式審查是保證軟體品質的有效的方法。組織一個由不同代表(如使用者，分析人員，設計人員，測試人員)組成的小組，對需求規格說明書及相關模型進行仔細的檢查;

2、依據需求編寫測試用例，根據使用者需求所要求的產品特性寫出系統的功能測試用例作為系統測試依據;

3、編寫使用者手冊，在需求開發早期即可起草一份使用者手冊，用它作為需求規格說明的參考並輔助需求分析;

4、確定合格的標準，需求說明中描述什麼樣的產品才算滿足使用者的要求和適合他們使用的，將合格的測試建立在使用情景描述或使用例項的基礎之上。

五、需求管理

需求管理是組織、控制和文件化需求的系統方法，也是一種建立和維護使用者和開發組織對於改變系統功能的協議。需求開發的結果經驗證批准就定義了開發工作的需求基線,這個基線在客戶和開發人員之間就構築了一個需求約定，需求管理包括在專案進展過程中維持需求約定一致性和精確性的活動。現在很多商業化的需求管理工具都能很好的支援需求管理活動。這個活動需要完成下面幾個任務：

1、確定變更控制過程,確定一個選擇、分析和決策需求變更的過程,所有的需求變更都需遵循此流程;

2、建立軟體變更控制委員會,組織一個由專案風險承擔者組成的小組作為變更控制委員會，由他們來評估和確定需求變更;

3、進行變更影響分析,評估需求變更對專案進度、資源、工作量和專案範圍以及其它需求的影響;

4、跟蹤變更影響的產品,當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計文件、原始碼和測試用例，這些相關部分可能也需要修改;

5、建立基準和控制版本,需求文件確定一個基線，這是一致性需求在特定時刻的快照，之後的需求變更就遵循變更控制過程即可;

6、維護變更的歷史記錄,記錄變更需求文件版本的日期以及所做的變更、原因，還包括由誰負責更新和更新的新版本號等情況;

7、跟蹤每項需求的狀態,這裡狀態包括"確定"、"已實現"、"暫緩"、"新增"、"變更"等。建立一個數據庫，其中每一條記錄記錄一項需求;

8、衡量需求穩定性,記錄基線需求的數量和每週或每月的變更數量。

需求獲取是在問題及其最終解決方案之間架設橋樑的第一步，是軟體需求過程的主體。一個專案的目的就是致力於開發正確的系統，要做到這一點就要足夠詳細地描述需求，也就是系統必須達到的條件或能力，使使用者和開發人員在系統應該做什麼，不應該做什麼方面達成共識。我們都知道開發軟體系統最為困難的部分就是準確說明開發什麼，最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟體系統的介面。

獲取需求就是為了解決這些問題，它必不可少的成果就是是對專案中描述的使用者需求的普遍理解，一旦理解了需求，分析者、開發者和使用者就能探索出描述這些需求的多種解決方案。

這一階段的工作一旦做錯，將最終會給系統帶來極大損害的部分，由於需求獲取事物造成的對需求定義的任何改動，都將導致設計、實現和測試上的大量返工，而這時花費的資源和時間將大大超過仔細精確獲取需求的時間和資源。

大家還在看

首先要理清想思路開發什麼樣的一個軟體，主要應用於哪裡，目標客群是誰，想達到什麼樣的一個效果，然後你作為產品經理，要把產品需求表給理出來，裡面包含哪些開發模組，涉及哪些開發語言，哪些功能需求；

其次，做一個思維導圖，和客戶或團隊進行確認，哪些地方還需要修改；

再次，做出主要頁面的原型圖出來，展示明確的互動邏輯，這些都理清楚，就可以開始著手開發寫程式碼了。

我就是一名軟體開發的從業者，軟體開發需求，就是為那些希望通過網際網路來達到某種成就，這時候就需要定位好你要的產品，需要解決什麼問題。這些綜合起來就成了軟體需求，需求不是一成不變的，會根據市場風向標改變而改變，也就是不斷的創新與迭代，將產品做的更好，可能這就是我理解的軟體需求吧。

軟體需求分析就是把軟體計劃期間建立的軟體可行性分析求精和細化，分析各種可能的解法，並且分配給各個軟體元素。需求分析是軟體定義階段中的最後一步，是確定系統必須完成哪些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。