討論軟體需求的文章有很多，對於需求的標準也不盡相同，但是在思想上是相同，都是為了保證專案的順利進行。
這裡我總結一些比較通用的標準，可能並不完善，但你只要能保證做到這幾點，你的專案就不容易失敗：明確(clear)、完整(complete)、一致(consistent)、可測試(testable)，此外還有其他的概念，如可跟蹤、可修改等等。
明確：目前大多數的需求分析採用的仍然是自然語言（因為如果採用形式化語言的話，和使用者的溝通將成為乙個大問題，這意味著客戶在開發軟體之前必須先進行形式化語言培訓，這是不現實的）。自然語言對需求分析最大的弊病就是它的二義性。所以我們不得不對需求分析中採用的語言做某些限制。例如盡量採用主語＋動作的簡單表達方式。說白了，需求分析中的描述讓人看上去像是剛學習學習學習學習寫作的小孩子就對了，千萬不要採用疑問句、修飾這些華麗的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要的是和使用者溝通，可是使用者多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成使用者理解上的困難。 打個比方，如果你要做乙個銀行的信用卡系統，你就可以這樣描述軟體需求：銀行的卡部管理信用卡，每張信用卡只屬於乙個帳戶。信用卡有卡號、餘額。一張信用卡有多筆的交易記錄。
完整：再也沒有什麼比軟體開發接近完成時才發現遺漏了一項需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遺漏需求而不得不返工，這簡直就是惡夢。可是令人遺憾的是，需求的遺漏是很經常發生的事情，不僅僅是你的問題，更多的問題發生在使用者那裡，他們不知道該做些什麼。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各方各面，貫穿了整個過程，從最初的計畫制定到最後的需求評審。
一致：一致性也是乙個比較大的概念，很難用幾句話講清楚。簡單的來說，就是使用者需求必須和業務需求一致，功能需求必須和使用者需求一致。嚴格的遵守不同層次間的一致性關係，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。在實現過程中，我們還必須把一致性關係細化。比如說使用者需求不能超出先前指定的範圍。
可測試：大家覺得乙個專案的測試從什麼時候開始呢？有人說從編碼完成後開始。更清楚一點的說是編碼的時候同時進行單元測試，編碼完成後進行系統測試。這些都沒有錯。但是實際上測試是從需求分析過程就開始了。需求分析是測試計畫的輸入和參照。這就要求需求分析是可測試的。什麼是可測試呢？"我們要用新的系統完成報表自動化處理"，你覺得這個需求是可測試的嗎？當然不是，報表包括哪些？自動化處理的標準是什麼？這些在需求中都沒有說明。因此這項需求是無法測試的，就是不具有可測試性。說到這裡，大家可能就會明白之前的需求的幾項標準都是為了保證需求的可測試性的。事實就是這樣，只有系統的所有需求是可以被測試的，才能夠保證軟體始終圍繞著使用者的需要，保證軟體系統是成功的。
軟體需求文件格式的標準寫法
軟體需求文件格式的標準寫法 1 引言 1 1 編寫目的 闡明開發本軟體的目的 1 2 專案背景 標識待開發軟體產品的名稱 列出本專案的任務提出者 專案負責人 系統分析員 系統設計員 程式設計員 程式設計師 資料員以及與本專案開展工作直接有關的人員和使用者 說明該軟體產品與其他有關軟體產品的相互關係。...
需求規格說明書 ISO標準版 需求分析類
編者說明 當需求調查 分析工作告一段落時，你就需要將這些需求進行規格化描述，整理成文，即軟體需求規格說明書，也就是srs。這是在軟體專案過程中最有價值的乙個文件。iso所提供的標準雖然已經時間久遠，但還是頗具參考價值的。1 引言 1.1編寫的目的 說明編寫這份需求說明書的目的,指出預期的讀者。1.2...
如何寫好需求分析 需求規格說明書 ISO標準版
當需求調查 分析工作告一段落時，你就需要將這些需求進行規格化描述，整理成文，即軟體需求規格說明書，也就是srs。這是在軟體專案過程中最有價值的乙個文件。iso所提供的標準雖然已經時間久遠，但還是頗具參考價值的。1 引言 1.1編寫的目的 說明編寫這份需求說明書的目的,指出預期的讀者。1.2背景 a....