需求決定了軟體做什麼，要提供什麼功能。
軟體工程初期的一般過程是，軟體開發的計畫，確定要實現的目標和進度等，然後就是需求規格說明書，該說明書要得到使用者的認可。使用者往往提供了乙份要求的說明，開發人員在這個基礎上進行了加工和整理。此後的開發過程，都是圍繞著需求規格說明書進行進一步地細化，直至開發出產品。當然，測試計畫中也要針對需求進行驗證，看看是否滿足了使用者的要求。
一般來說，用例檢視可以很好地表現需求。用例圖中，若干角色actor與系統提供的用例（功能）之間的連線關係。
以下是參考《ieee推薦的軟體需求規格說明的方法（ieee 830-1998）》的乙個系統規格說明書srs模板：
一、引言
（一） 產品的前景
（二） 產品的功能
（三） 使用者型別和特徵
（四） 執行環境
（五） 設計和實現上的限制
（六） 假設和依賴
三、外部介面需求
（一） 使用者介面
（二） 硬體介面
（三） 軟體介面
（四） 通訊介面
四、系統特性
（一） 說明和優先順序
（二） 激勵/響應序列
（三） 功能需求
五、其它非功能需求
（一） 效能需求
（二） 安全設施需求
（三） 安全性需求
（四） 軟體質量屬性
（五） 業務規則
（六） 使用者文件
六、其它需求
附錄a：詞彙表
附錄b：分析模型
附錄c：待確定問題的列表
另外，《gb9385-88計算機軟體需求說明編制指南》也為軟體需求實踐提供了規範化的方法。
需求的問題，是乙個複雜的問題
有些時候，需求的問題會變得很複雜的。尤其是在做行業軟體或者erp的時候，你遇到不同的客戶，每個客戶都有他的想法或要求，而且有些客戶沒有明確的思路，有些則有他們很固執的思路，一時間彷彿需求是沒完沒了的。或許你的軟體已經是乙個產品，那麼究竟對什麼功能進行取捨，對什麼功能要增加進軟體的核心，對什麼功能採用二次開發，都是需要仔細判斷的事情。
1、需求的重複和變更
對於比較大的系統，客戶不可能一次性地把需求完全提清楚。這是必須容忍的。只要你不斷溝通和了解，使用者需求就會不斷增加。有些公司採用的方法是在需求規格說明書上讓客戶簽字，然後嚴格按照該說明書來實現。如果以後客戶有新的要求，則要另外考慮。但在另一方面，客戶永遠是上帝 ，乙個軟體的成功，應該是使用者用得非常流暢和滿意。
2、有些需求無法實現
和客戶的溝通也很重要。什麼是必須滿足的需求，而另外一些需求可能暫時不能提供實現，這也需要解釋清楚。
3、實現的功能和客戶原來提出的需求會有所差別
很多軟體的問題最後總結下來是因為需求沒有明確。開發人員沒有認準客戶究竟需要什麼。這時候只能修改軟體。
需求的問題，是乙個技術的問題
每個需求的特性可體現在很多方面：如優先順序、有效性，效率，靈活性，完整性，互操作性，可靠性，健壯性，可用性；可維護性，可移植性，可重用性，可測試性等。
確定需求優先順序：可以粗略地分為**：
高 乙個關鍵任務的需求，必須在此版本實現；只有在這些需求上達成一致意見，軟體才會被接受；必須完美地實現
中 支援必要的系統操作，最終所要求的，但如果有必要，可以延遲到下一版本；實現這些需求將增強產品的效能，但如果忽略這些需求，產品也是可以被接受的；需要付出努力，但不必做得太完美
低 功能或質量上的增強，如果資源允許的話，實現這些需求會使產品更完美；實現或不實現均可；可以包含缺陷
更精確的優先順序設定如下表：
權值 1 1 1 1
需求 收益 代價 價值 價值% 成本 成本% 風險 風險% 優先順序
《需求》 <1-9> <1-9> <> <> <1-9> <> <1-9> <> <>
其中各權值按實際情況而定，不能確定按1取值。
收益：實現此需求對使用者的益處；
代價：未實現此需求對使用者的損害；
價值=收益*收益權值+代價*代價權值
價值%=價值/（總價值）*100%
成本：實現此需求所需的各種成本；
成本%=成本/（總成本）*100%
風險：實現此需求所承擔的風險，特別是技術上的；
風險%=風險/（總風險）*100%
優先順序=價值%/（成本%*成本權值+風險%*風險權值）
最後按需求優先順序排序，優先實現高優先順序的需求。
風險的控制和避免：
對需求將可能面臨的風險要有充分的估計並盡量避免風險的發生及其所造成的損失。建立風險跟蹤 ，保持對危害最大的幾項風險的控制，並在開發過程中周期性地更新風險跟蹤專案。
需求的問題，是乙個管理的問題
需求取得：市場銷售部門、技術支援或客戶服務所得到的需求，或者開發人員內部通過對業務的分析歸納得出的一些要改進的功能。
對需求進行管理的環節應該盡可能精簡。最好直接由系統分析來做。經過很多環節的篩選，需求可能已經走樣了。紙面上只有一兩句話的需求，背後有你看不到的真正想法存在。 所以應該主動走出去尋找需求，應該選擇最典型的客戶進行訪問。領會他們的管理思路和改革方向。
需求決策：對於相互矛盾的需求，在同類使用者中由產品代表決策；對於不同類使用者要根據重要性作適當折衷；對於使用者的特別喜好要根據使用者的重要性決定；使用者中領導的需求要服從最終實際使用的使用者需求；當開發者想象中的產品通常要服從使用者的需求，但並不表示使用者總是對的。
需求分析：分析需求的各個特性，製作出需求分析規格說明書。
需求評審：由相關人員共同對需求進行評審。
需求變更：如果遇到需求的變更，需要及時作出調整，即使與開發部門聯絡，提出變更的建議，並分析可能產生的影響，如對產品穩定性的影響。變更的需求需要嚴格的測試。
版本控制：確定需求文件版本，確定單個需求文件的版本；
需求跟蹤：需求的跟蹤記錄需求的狀態，包括未定義、放棄、需完善、已定義、實現中、待測試、測試中、完成、放棄實現等
需求管理工具：曾經看到過的工具有rational requsite pro 4.5版。需要用word 97支援。但對中文的支援不夠好。
有問題是正常的
背景 最近搭建個專案，折騰了許久。最後，卻是在別人幫忙下，輕而易舉解決了。總結下來，筆者的思路還可以，只是在這樣那樣的原因下，差那麼一點點。之所以這邊想記錄一下，主要感覺最近思維有點混亂。沒有庖丁解牛的本事，又不想按部就班循序漸近。少了點耐心，多了點蠻幹的味道。開發者，其實就是解決問題。解決問題的過...
問題 A 乙個簡單的整數問題
問題 a 乙個簡單的整數問題 時間限制 5 sec 記憶體限制 128 mb 提交 75 解決 25 提交 狀態 討論版 命題人 quanxing edit testdata 題目描述 你有 n個整數，a1，a2，an。你需要處理兩種操作。一種操作是在給定間隔中為每個數字新增一些給定數字。另一種是要...
怎麼判斷乙個問題是不是遞迴的
遞迴，怎麼理解這個概念？我們不需要用複雜的語言來描述這個概念，只需要從這個詞的本意入手即可。遞迴的英文也就是recursion，這個詞的詞源是recur，我們都知道occur的意思是發生，那麼recur的意思也就不難理解了，也就是重 生。所以說，遞迴，就是指乙個事情週期性重 生，也就是說，在乙個演算...