在《軟體工程最佳實踐》一書中，羅列了18種軟體需求方**，這裡逐一介紹如下：
「使用者代表」代表的是使用者，決定的是需求。有了使用者代表，需求的確認和變更，以及需求優先順序的確定，都會便捷很多。這種方法完美契合敏捷的「交流勝於文件」的思想。唯一的問題是，這種方**只能適用於小型軟體的開發，對於大型軟體來說，它就無能為力；甚至某些特定的嵌入式系統軟體，如燃油噴射控制系統，它也會力不從心。
需求蔓延指的是軟體開發完成後的功能點高於需求開發結束時的功能點。多出的功能點就是蔓延的需求。使用聯合應用設計和原型模擬等方法，可以抑制甚至杜絕需求蔓延。
對於那些「古老」的軟體，**的變更常常會領先需求和設計文件的變更幾條街。如果因為維護或者其他原因，需要從這些軟體收集需求，是沒有辦法依靠這些落後的文件，我們只能從**中來提取需求。這種需求提取，除了**審查的手工操作之外，還可以借助一些自動化工具。
可執行語言是一些自動化工具產生的，用它來對需求進行描述，可以幫助我們分析需求。msdn就是目前已知的提供關於可執行語言資訊的最好的**。而且，在理論上，可執行語言還可以利用靜態分析工具進行解析，以去除可執行語言中存在的邏輯錯誤和遺漏。
焦點小組是乙個使用者集合，這些使用者會參與軟體的功能、效能的討論。焦點小組可以對軟體產品提供建議，甚至提供軟體原型。焦點小組非常適合多使用者需求的場景。
功能性需求會增加軟體的規模，它可以用功能點估算方法來進行度量；非功能性需求是使用者關心的一些限制和約束，如效能指標、可靠性知識，它可能需要一些工作量，但通常不會增加軟體的規模。
聯合應用設計是正式的需求審查會，參會人員包括使用者和開發方的架構師和設計師，雙方使用需求檢查表進行逐項需求的審查。聯合應用設計是收集大型軟體需求最有效的方法。
模式匹配的前提是軟體的功能都以一種標準的方式記錄下來，並建立完整的分類系統，這樣通過模式匹配就可以對軟體需求進行重用。但是，只要需求還在使用30多種圖表並混雜各種各樣的語言來描述的話，模式匹配就只能通過人工，自動化的模式匹配不可能實現。
建立軟體原型來展示軟體的功能和邏輯結構，可以幫助我們進行需求確認。但是原型只會保留大約完整軟體1/10的功能。所以，它只是適用少於1000個功能點的軟體。因為規模太大，原型的建立會非常困難。原型有一次性和進化性兩種。無論哪種原型，都可以成功的減少需求蔓延。
質量功能展開，又叫質量屋，是一種源於日本的質量需求分析方法。一些計算機公司如惠普和ibm，已經將其用於軟體產品。但是，要熟練使用質量功能展開並且在軟體專案中成功應用，還需要付出大量的訓練和實踐。
需求工程包括需求提取、需求分析、建立模型、需求檢驗等活動，它非常適用執行在複雜物理裝置上對軟體成功執行有著嚴格質量標準要求的系統軟體或嵌入式軟體，能夠使用需求工程的組織，通常是已經通過了cmmi**認證的組織。
需求審查是最有效的缺陷去除方法，並有著最高的缺陷去除效率。審查是一項團隊合作的活動，參與者包括好的主持人、記錄員、審查者及審查物件。
理論上如果為每個確定的需求分配乙個唯一識別碼或序列號，那麼需求的雙向追蹤就是可以實現的。我們通常使用二維矩陣來進行需求追蹤：矩陣的一軸列出所有的需求，另一軸列出包含該需求的文件或**段，兩軸交叉點可以表示該需求是否已分析、已設計和已實現。如果多個軟體使用同乙個可重用需求，那我們可能就需要使用三維矩陣來跟蹤了。
可重用對於軟體質量和生產率都是意義非凡。但是，可重用的應用仍然任重道遠，因為擴大可重用的比率，需要我們建立起乙個完善的可重用功能元件的系統。而要建立這個系統，需要記錄以下分類資訊：
此功能的起源時至今日，使用防火牆和防毒軟體已經不足以保護軟體的安全。安全需求要求我們提高軟體**防外部攻擊的能力。一些先進的方法，包括提高軟體邏輯運算速度、嚴格限制許可權、使用安全性較高的程式語言等，可以幫助實現軟體的安全需求。另外，軟體的安全性需求還需要進行安全審查（使用靜態分析工具來查詢安全漏洞）和安全測試。此功能所建立的日期
此功能的版本號
此功能的認證等級
此功能的業務目標
此功能的名稱
此功能用於進行追蹤溯源的序列號
實現此功能所用的程式語言
此功能的輸人資料
此功能的輸出資料
此功能對其他軟體功能的輸出資訊
此功能從其他軟體處接收到的輸入資訊
此功能相關的實體及其相互關係
此功能所使用的邏輯檔案
對此功能所使用的審查型別
如果此功能和其他軟體的互動不僅限於資訊的話那麼此功能和其他功能的介面定義
此功能的容錯方式
此功能的加密方式
此功能所使用的演算法邏輯
統一建模語言是一套內容豐富的圖表表示方法不僅包括軟體需求的描述，也包括軟體架構和資料庫設計等描述。使用標準的審查方法，可以很容易地對uml圖表進行有效性和一致性檢查。
用例的目標是直接描述功能需求，它是用一種有趣的視覺方式來展現使用者使用軟體時的動作，包括提出請求、修改請求、控制行為和完成請求。用例不僅可以用於正式的需求審查和設計審查，還可以通過功能點分析來**軟體的規模。
使用者故事是一種快速靈活的需求收集方式，它通常是和測試用例同時開發出來的。由於使用者故事的簡潔性，對其正式審查也很難發現其中的缺陷，但是我們可以通過審查測試用例來做一些彌補。
產品的18般武藝
1 野心，這裡的野心更多是傾向於你有多少決心去做乙個產品，因為野心有多大，你完成工作的主動性就有多強。相比其他崗位，pm必須有足夠的主動性，從分析市場 競品，規劃自己產品的功能形態，為產品立項爭取資源到每一環節去促使最好的完成，pm得驅動整個產品流程，努力打造成成功的產品。我有時候也會說，野心就是一...
軟體開發總結 需求與開發
需求不是越多越好，也不是越詳細越好。使用者價值是不允許討論 妥協 的，具體實現方案是允許討論 妥協 的。實現和預想之間可能存在差距 例如時間，複雜度，難度，可能性 所以開發人員應該也是需求參與者，負責向需求提出者反饋這些問題，以利於需求提出者做出進一步決策。一是完備性 需求需要明確為什麼樣的使用者提...
軟體開發的一般流程
軟體開發一般分為五個階段 此階段是軟體開發與需求放共同討論，主要確定軟體的開發目標及其可行性。文件為可行性研究報告和專案開發計畫 在確定軟體開發可行性的情況下，對軟體需要實現的各個功能進行詳細需求分析。文件為軟體需求說明書，資料要求說明書 此階段中要根據需求分析的結果，對整個軟體系統進行設計，如系統...