討論軟件需求的文章有很多，對於需求的標準也不盡相同，但是在思想上是相同，都是爲了保證項目的順利進行。
這裏我總結一些比較通用的標準，可能並不完善，但你只要能保證做到這幾點，你的項目就不容易失敗：明確(Clear)、完整(Complete)、一致(Consistent)、可測試(Testable)，此外還有其他的概念，如可跟蹤、可修改等等。
明確：目前大多數的需求分析採用的仍然是自然語言（因爲如果採用形式化語言的話，和用戶的溝通將成爲一個大問題，這意味着客戶在開發軟件之前必須先進行形式化語言培訓，這是不現實的）。自然語言對需求分析最大的弊病就是它的二義性。所以我們不得不對需求分析中採用的語言做某些限制。例如儘量採用主語＋動作的簡單表達方式。說白了，需求分析中的描述讓人看上去像是剛學習學習學習學習寫作的小孩子就對了，千萬不要採用疑問句、修飾這些華麗的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。 打個比方，如果你要做一個銀行的信用卡系統，你就可以這樣描述軟件需求：銀行的卡部管理信用卡，每張信用卡只屬於一個帳戶。信用卡有卡號、餘額。一張信用卡有多筆的交易記錄。
完整：再也沒有什麼比軟件開發接近完成時才發現遺漏了一項需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遺漏需求而不得不返工，這簡直就是惡夢。可是令人遺憾的是，需求的遺漏是很經常發生的事情，不僅僅是你的問題，更多的問題發生在用戶那裏，他們不知道該做些什麼。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各方各面，貫穿了整個過程，從最初的計劃制定到最後的需求評審。
一致：一致性也是一個比較大的概念，很難用幾句話講清楚。簡單的來說，就是用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。嚴格的遵守不同層次間的一致性關係，就可以保證最後開發出來的軟件系統不會偏離最初的實現目標。在實現過程中，我們還必須把一致性關係細化。比如說用戶需求不能超出先前指定的範圍。
可測試：大家覺得一個項目的測試從什麼時候開始呢？有人說從編碼完成後開始。更清楚一點的說是編碼的時候同時進行單元測試，編碼完成後進行系統測試。這些都沒有錯。但是實際上測試是從需求分析過程就開始了。需求分析是測試計劃的輸入和參照。這就要求需求分析是可測試的。什麼是可測試呢？"我們要用新的系統完成報表自動化處理"，你覺得這個需求是可測試的嗎？當然不是，報表包括哪些？自動化處理的標準是什麼？這些在需求中都沒有說明。因此這項需求是無法測試的，就是不具有可測試性。說到這裏，大家可能就會明白之前的需求的幾項標準都是爲了保證需求的可測試性的。事實就是這樣，只有系統的所有需求是可以被測試的，才能夠保證軟件始終圍繞着用戶的需要，保證軟件系統是成功的。