需求不是越多越好，也不是越詳細越好。
使用者價值是不允許討論（妥協）的，具體實現方案是允許討論（妥協）的。 實現和預想之間可能存在差距（例如時間，複雜度，難度，可能性）， 所以開發人員應該也是需求參與者， 負責向需求提出者反饋這些問題，以利於需求提出者做出進一步決策。
一是完備性
需求需要明確為什麼樣的使用者提供什麼樣的價值， 需求還要明確驗收條件，達到什麼樣的程度就認為需求已經完成，
二是生動
乙個需求不生動，很難在需求的各類參與者之間達成一致。這裡的生動主要是指應用場景。
三是簡潔
當前很多需求規格說明書或prd中，內容太多，不簡潔，導致這些需求不明確。
四是有度
在做需求時，一定要注意，哪些是需求該做的，哪些是需求不該做的，如果越界，過猶不及。我認為乙個需求應該包括： 使用者故事，表明使用者和價值；應用場景： 生動描述需求是怎麼應用的，容易在各類人員之間達成一致的理解；驗收條件： 完成到什麼程度，需求就完成了； 依賴，假設和限制： 明確這個需求依賴什麼，基於什麼假設，有哪些限制；最多在加上風險。
五是持續完善
乙個需求從不是很了解開發，到逐漸明晰，是正常的，我們不能期望一開始就有人將一切都想明白，設計好，這也是以前需求規格說明書和prd過界的地方。我們冗餘別人經歷從不明晰到明晰的過程，包括所有人員。也允許應用場景逐漸增加或減少，驗收條件的變動，依賴假設和限制的修改等，但是最好使用者和價值不要改動（是否允許增加可以討論）。
六是留白
需求中有想不清楚，需求要進一步思考討論的問題是正常而且有益的，在需求中指出這些問題，對日後完善需求，展開溝通有好的作用。所以開放性問題也是需求的乙個重要的方面。
基於如上的理解，我們期望qa人員對業務需求從版本目標和使用者價值，驗收標準三個方面對需求進行測試和審核，開發人員，qa人員對業務場景方面進行溝通，以期達成一致。
1： 發布版本有明確的目標
2: 有多個需求支撐發布版本
3： 需求能為使用者提供價值，且能描述出來
4： 需求的驗收條件明確且可測試
6： 指出需求的依賴，假設和限制
7： 需求在業務，qa和開發人員之間真正達成一致，且有手段確保一致
8： 不明確的問題，要指出，最好是列為開放性問題
9： 有持續完善的機制
10： 指出需求的責任人和客戶代表，要指出溝通方式
1： 確保對需求達成一致
2： 需要將需求拆分為大致的任務，注意不要漏掉哪些非開發的任務，非開發的任務可以反饋到需求人員。
3： 如果需求比較大，需要將需求的實現拆分為多個版本， 按照一定的節奏開發這些版本
這些版本不要時間太長，應為可能存在對需求理解不一致的情況，可以通過盡快發布版本來察覺這些不一致並改正。 版本的劃分要以使用者價值為指導。
4： 根據需求（特別是業務價值），列出各版本的驗收條件， 並確保達成一致
5：對任務，版本進行估算，得出初步的計畫。（我們有初步的計畫，但是估算這一塊做的不好）
6： 編寫功能的測試用例，或者叫功能設計，需求規格說明書或prd中都有這一塊，現在想來，還是放在開發這邊做比較好，因為開發需要知道做到什麼程度，這個功能就算完成了。還有一點，開發人員有能力自動化這些測試用例，其他人員可能不具備這個能力，所以建議將功能測試放在開發這邊。（因為我的開發中，與互動設計打交道比較少，所以沒有將互動設計考慮進去， 當前將互動設計人員也理解成開發的一員）
7： 乙個任務或版本只有對客戶代表(或需求人員)演示完成且演示人員認可才算完成。 如果客戶代表認為不滿意，即使滿足前面列的驗收條件也不行，因為前邊列的驗收條件是為大家理解達成一致的，而不是為了推卸責任的，這時候可以有兩種方法： 1： 與客戶代表進行溝通，讓他認可這一版，在下一版中，將新的驗收條件新增上去， 個人推薦這種方法， 2： 在本版中就將這些驗收條件新增進去。
需要注意的是，演示需要在開發人員測試完成且有把握的條件下，才可以進行，否則會消耗客戶代表對團隊的信任。
軟體開發 非功能需求與功能需求
需求定義 需求 requirement 就是系統 更廣義的說法是專案 必須提供的能力和必須遵從的條件。需求分類 1 在一般使用中，需求按照功能性 行為的 和非功能性 其它所有的行為 來分類。功能性需求是說有具體的完成內容的需求。非功能性需求是指軟體產品為滿足使用者業務需求而必須具有且除功能需求以外的...
軟體開發總結 開發模式選擇
改善協作 想象乙個軟體開發組織，它和市場緊密連線，可以隨時交付完成的工作或調整方向，對市場做出準確的反應，這樣的組織必然會在市場競爭中佔據優勢。響應能力是所有軟體開發組織所期望具備的，但真正能做到的卻很少。究竟是什麼影響了組織的響應能力。從內部看，主要是堆積的 在製品 和技術及學習 債務 從外部看主...
軟體開發模型總結
2006 11 20 20 17 鑑於軟體測試在面試階段總是提及軟體開發模型的緣故,於是粗略的總結一下軟體開發模型,請指正 瀑布模型將軟體生命週期的各項活動規定為依固定順序聯接的若干階段工作，形如瀑布流水，最終得到軟體產品。優點 a.強調開發的階段性 b.強調早期計畫及需求調查 c.強調產品測試。缺...