測試 - 軟件需求管理

時間 2019-12-18

原文原文鏈接

目錄html

爲何習軟件需求？

先來說述一個真實的故事：算法

一天，小明和家人在吃晚飯的時候，對他的母親、奶奶、姑姑說：他的褲子左腿（比右腿）長了3釐米，但願剪掉。數據庫

他的姑姑在晚飯後把小明的褲子左腿剪短3釐米；編程

他的母親在睡前也把小明的褲子左腿剪短3釐米；數組

他奶奶在次日早上把小明的褲子左腿剪短3釐米；併發

次日，小明穿着這條褲子高高興興上學去......socket

這個故事的甲方小明提出了明確的需求，委託給乙方（家庭項目組），但因爲溝通不力，在各組員積極的工做下，充分完成了任務。函數

有這個例子能夠看到，乙方並無跟蹤項目的完成狀態，完成的組員沒有彙報，其餘組員沒有驗證需求，致使多裁剪了6釐米。這個示例應用到軟件中也是同樣的。工具

那這個案例給咱們什麼樣的啓示呢？性能

軟件須要基線化，要有管理，不然需求的實現是盲目的、不受控制的。
軟件需求的實現要跟蹤、記錄和標識。
要測量、驗證軟件需求。

那麼後續咱們在學習相關測試模型，好比V模型和W模型，都是以需求分析展開的，因此，咱們有必要學習軟件需求。

做爲測試人員，咱們有必要知道，在軟件需求管理方面，咱們應該充當什麼角色，軟件需求對咱們的工做有什麼樣的影響。

除了知足客戶的顯式需求，做爲軟件開發者還要挖掘隱式需求。

總覽整個項目生命週期，由於在需求階段引起的缺陷，要比設計和編碼階段引起的缺陷還要多。

需求的定義

來看IEEE對需求的定義：

解決用戶問題或達到用戶目標所須要的條件或能力。
爲遵循合同、標準、規格或其餘要求的正式文檔，系統必須知足或擁有的條件或能力。
按文檔表現中的條件或能力，也就是需求文檔（SRS）強調的作什麼（What），而不是如何作（How）。

簡單來說，咱們要從兩方面來考慮需求：

用戶角度，這也是系統的外部行爲。
開發者角度，內部特性。

對於需求來講，它是有層次的：

業務需求，反映了組織機構或客戶對系統、產品高層次的目標需求。在項目視圖與範圍文檔中予以說明，好比在簽定合同中的說明。
用戶需求，描述了用戶使用產品必須完成的任務，這在使用實例文檔或方案腳本，在一些說明中進行說明，好比說用例交互圖。
功能需求，定義了開發人員必須實現的軟件的功能，目的是知足業務需求和用戶需求。

交互的概念：一次交互就是指在特定語境中，爲了實現某一個目標，而在一組對象之間進行交換的一組消息所表示的行爲。

軟件需求是需求工程對軟件行業闡述的一個課題，其中主要包含開發和管理兩個部分。

需求開發

需求開發的活動包括：

肯定產品的指望的客戶類，也就是對客戶進行劃分
獲取每一個用戶類的需求。
瞭解實際用戶任務和目標以及這些任務所支持的業務需求。
分析用戶源信息，以區別用戶任務需求、功能需求、業務規則、質量屬性和其餘的附加信息。
複雜的系統劃分爲子系統。
優先級。
質量屬性的重要性。是功能重要啊，仍是可靠性重要，都要考慮到。

需求獲取

再來看需求獲取，能夠有下面幾種形式：

訪談。
焦點小組會議，或針對需求的某個主題，拉着相關人員進行討論一下。
聯合應用開發，好比開發和客戶一塊兒工做，有啥問題，當面解決。
羣衆創新技術，好比開頭腦風暴會議，你們都提供好的想法。
羣體決策會議，好比提供一些好的方案，你們投票也好，共同決策出一個好的方案。
問卷調查。
觀察法。
原型法等等。

需求分析

獲取完了需求，咱們要對需求進行分析，也有相應的需求分析人員來完成，那麼對需求分析人員的要求有哪些呢？

符合客戶的語言習慣，也就是說最起碼不能跟客戶有溝通障礙，好比你說中文，人家說日語。
瞭解客戶系統業務及目標，這個客戶他的業務是作保險的，仍是作推銷的，仍是作保險推銷的，你要對相應的業務有所瞭解。
文檔編寫能力，編寫有效的需求規格。
好的溝通能力。
積極的職業態度。
重用已有的軟件和組件，也就是須要會點技術。

需求分析人員的角色很是重要，由於他決定軟件是否能知足用戶需求。那麼需求分析都有哪些重要性呢？決策性、方向性、策略性，你要能對軟件作全面的描述，幫助用戶判斷實現功能的肯定性、一致性和完整性。由於有些客戶他都不太清楚他的需求是什麼，咱們要引導......

另外，還須要瞭解軟件實現所須要的所有信息，爲軟件設計、確認和驗證提供基礎。爲全部的項目開發、測試工做編寫相關文檔提供依據。

那麼，需求分析人員都是從哪些方面分析需求的呢？

功能需求。
軟件與硬件或其餘外部系統接口。
軟件非功能需求。
羅列出軟件設計和實現的限制。

需求分析人員，對外要徹底瞭解用戶需求，對內要爲開發、測試提供清晰的思路。

需求定義

分析完了以後，咱們要將需求進行定義，也便是將需求結果輸出到文檔，好比採用哪些工具、語言以及其餘的特色。

最終是使開發組合用戶的意見達成一致。

在對需求定義完了以後，要進行驗證。

需求驗證

需求的驗證，指需求定義結束後，有客戶、公司的決策層、專家來考慮項目的預算、進度等等角度，最終符合合同。

那麼需求開發階段完事，接下來就是要對需求進行管理了。

需求管理

需求管理，它是一種獲取、組織而且記錄系統需求的系統化方案，保證用戶與項目團隊對不斷變動的需求達成並保持一致的認識。

需求管理強調：

控制對需求基線的變更。
保持項目計劃與需求一致。
控制單個需求和需求文檔的版本狀況。
管理需求和聯繫鏈之間的聯繫。就是持續的跟蹤需求。

需求工程和需求管理的關係

需求工程包含需求管理。
需求管理側重於需求工程中的管理活動。
需求管理是CMM二級的第一個KPA。

那麼，需求開發環節完畢後，就要進行需求分配，好比一個很大的系統，須要分配給不一樣的項目組來完成；而後項目組對需求進行評審（解決模糊或有歧義的地方），若是有些問題的話，就要遵循必定的基線進行需求變動，若是沒有問題，也要遵循必定的基線進行開發測試；若是需求進行了變動，那麼就要對此進行跟蹤；那麼要對需求進行變動也要遵循必定的流程，來看軟件需求變動的流程。

軟件需求變動流程

變動控制：

首先要提出變動，也就是建議變動。
既然要變動，就可能帶來必定的影響，咱們就要分析影響。
根據影響做出決策。
影響太大，不能變動，或者能夠變動，都要跟相關人員（設計）進行交流。
在一番交流後，合併決策結果。
最後，要測量（變動後的）需求的穩定。

CMM2級的KPA中的需求管理部分的目標是，把軟件需求創建一個基線，供軟件工程和管理使用，而後軟件計劃產品和活動同軟件需求保持一致，但它並不涉及需求的收集和分析。

當需求管理遵循基線做出變動後，而後肯定變動後的版本，在版本控制中，要肯定需求文檔的版本，究竟是哪些文檔要發生變化，完了以後，肯定需求文檔的版本；

開發和測試工做的展開是基於肯定的需求文檔展開的。

一旦開發或測試中的某個環節發生變動，那麼全部相關的變動都要隨之改變，並保持一致，好比一些開發或測試計劃與需求保持一致。

來看有哪些反應變動的方法：

暫時擱置次要的需求。
獲得必定數量的後備人員，用來彌補可能因爲變動而缺乏人手的問題。
將新的需求安排到工做進度中去。

關於需求的全部變動都要進行跟蹤。

軟件需求跟蹤

能夠看到上圖中每一個環境的箭頭都是雙向的，也就是自上而下能夠持續跟蹤，自下而上能夠追根溯源，避免遺漏。

而軟件需求規格無疑起着承上啓下的做用的，當需求規格說明書明確以後，後續的人員就能夠繼續展開工做，好比設計人員就可以進行概要設計，詳細設計，編碼實現，進行單元測試、集成測試、系統測試，編寫用戶手冊等文檔。它（需求規格說明書）是上述步驟的有力依據。

那軟件需求跟蹤有哪些流程呢？

跟蹤軟件需求的流程是將跟蹤目標分解到各個活動中，也就是說流程是由活動組成的。那這個流程中具體都有哪些活動，而對應這些活動的角色又有哪些呢？

來看一下需求跟蹤涉及到的活動以及它們須要跟蹤的配置項。

在需求跟蹤中，咱們除了要知道它的活動，咱們處於什麼位置，咱們的工做內容是什麼，咱們最終要知足什麼，還須要知道用什麼方法，約束咱們，讓咱們的跟蹤過程更加清晰，這就用到了需求跟蹤矩陣（RTM，Requirement tracking matrix）。

當需求準備完畢並已經明確到位，那咱們的跟蹤工做就開始了，首先咱們要初始化需求跟蹤矩陣，而後把咱們的工做任務書（SOW）和原始需求（AR）列出來。

完事就開始後續的工做，分析需求規格說明書，列出需求項、概要設計項、詳細設計項、編碼項，以及系統測試項、系統測試子項；集成測試項、集成測試子項；單元測試項、單元測試子項；把最原始的需求標識在需求跟蹤矩陣中。

需求跟蹤矩陣它確保了：

確保需求被實現。
確保需求被驗證。
瞭解需求變動影響的範圍。

軟件需求跟蹤階段劃分

對於軟件需求跟蹤，整體劃分爲開發、測試兩條主線。而且兩條主線都有具體的階段劃分，在每一個階段劃分中，都有相應的輸出：

上圖中，每一個活動中，都有相應的跟蹤活動。

由PM負責需求跟蹤，需求跟蹤的目的是確保全部的分配需求均被實現（開發線）、被驗證（測試線），後續的工做產品與分配需求一致。

需求跟蹤過程的主要活動是對RTM的維護，經過創建以下跟蹤關係，達到需求跟蹤的目的：

（開發線）分配給項目的需求 -- 項目的軟件需求規格 -- 概要設計 -- 詳細設計 -- 代碼
（測試線）項目的軟件需求規格 -- 系統測試項 -- 系統測試子項 -- 系統測試用例
（測試線）概要設計 -- 集成測試項 -- 集成測試子項 -- 集成測試用例
（測試線）詳細設計 -- 單元測試項 -- 單元測試子項 -- 單元測試用例

軟件需求跟蹤方法

對於軟件需求跟蹤方法來講，無非就是讓咱們的跟蹤項可以被惟一標識，也就是怎樣命名跟蹤項，以及被跟蹤對象是什麼。

來看需求項的定義：根據工做任務書（用戶需求）的規格，把任務書中的任務分解爲能夠實現的符合要求的具體的需求項，需求項最終落實到需求文檔中（SRS）。

需求項的命名方式：

產品編號-SRS-需求類型-特性名-XXX
如：CALC-SRS-FUNC-ADD-002，表示計算器十進制加法功能需求。

概要設計項的定義：針對需求規格說明書中的需求項作分解，一個需求項能夠被分級爲一個或者多個模塊，每一個模塊之間有明確的接口，模塊的功能獨立，符合高內聚、低耦合的原則，標識每個模塊的項目即概要設計項，概要設計項最終落實到概要設計說明書中。

概要設計項的命名方式：

產品編號-HLD子系統名稱-模塊名-XXX
如：CALC-HLD-ADD-DEC，表示計算器十進制加法功能模塊。

詳細設計項的定義：爲了實現概要設計說明書中的模塊，在詳細設計中，把概要設計模塊細化到函數或者函數組的層面，函數或者函數組即詳細設計項，詳細設計項目最終落實到軟件詳細設計說明書中。

詳細設計項的命名方式：

產品編號-LLD-模塊名稱-XXX
如：CALC-LLD-ADD-DEC-001，表示計算器十進制加法功能模塊參數判斷函數的詳細設計項。

系統測試用例的定義：測試人員根據需求規格說明書中的需求描述，完成的系統測試項、系統測試子項、系統測試用例，稱爲系統測試用例項。

一個項目軟件需求項能夠對應一個、多個甚至數十個系統測試用例項目。

一個系統測試用例項也能夠對應一個、多個軟件需求項。

命名方式：

產品編號 - ST - 系統測試項目 - 系統測試子項名 - XXX

集成測試用例的定義：測試（開發）人員根據概要設計文檔中的概要設計項完成集成測試用例，稱之爲集成測試用例項。

集成測試用你的設計主要關注軟件模塊間的接口，好比文件接口、共享內存接口、socket接口、管道接口、數據庫接口、二進制API接口等。

命名方式：

產品編號 - IT - 集成測試項目名 - 集成測試子項目名稱 - XXX

單元測試用例的定義：測試（開發）人員根據詳細設計文檔中的詳細設計項，完成的單元測試用例，稱之爲單元測試用例項，每一個詳細設計項應該對應一個或一個以上的單元測試用例項目。

命名方式：

產品編號 - UT - 單元測試項目名稱 - 單元測試子項目名稱 - XXX

需求階段需求跟蹤

需求階段需求跟蹤——開發人員

需求跟蹤責任人：PM（開發）。

需求跟蹤的步驟：在SRS review以前，由PM組織項目組成員建立需求跟蹤表，完成需求項錄入。

需求跟蹤方法：在原始需求項和需求分析文檔（SRS）項之間創建對應關係。

需求階段需求跟蹤——測試人員

需求跟蹤責任人：PM（測試）。

需求跟蹤的步驟：在軟件測試計劃（STP） review以前，由PM組織項目組成員完成系統測試項錄入。

需求跟蹤方法：在需求分析文檔（SRS）和系統測試項之間創建對應關係。

概要設計階段需求跟蹤——開發人員

需求跟蹤責任人：PM（開發）。

需求跟蹤的步驟：在HLD review以前，由PM組織完成概要設計項錄入。

需求跟蹤方法：在概要設計項和需求分析文檔（SRS）項之間創建對應關係。

概要設計階段需求跟蹤——測試人員

需求跟蹤責任人：PM（測試）。

需求跟蹤的步驟：

在系統測試方案、系統測試用例 review以前，由PM組織完成概要設計項錄入。
在集成測試計劃（ITP）review以前，由PM組織完成集成測試項錄入。

需求跟蹤方法：

在系統測試項和系統測試子項、系統測試子項和系統測試用例之間創建對應關係。
在概要設計項和集成測試項之間創建對應關係。

詳細設計階段需求跟蹤——開發人員

需求跟蹤責任人：PM（開發）。

需求跟蹤的步驟：在LLD review以前，由PM組織完成概要設計項錄入。

需求跟蹤方法：在詳細設計項和概要設計項之間創建對應關係。

詳細設計階段需求跟蹤——測試人員

需求跟蹤責任人：PM（測試）。

需求跟蹤的步驟：

在集成測試方案、集成測試用例 review以前，由PM組織完成集成測試子項、集成測試用例項錄入。
在單元測試計劃（UTP）review以前，由PM組織完成單元測試項錄入。

需求跟蹤方法：

在集成測試項和集成測試子項、集成測試子項和集成測試用例之間創建對應關係。
在詳細設計項和單元測試項之間創建對應關係。

編碼階段需求跟蹤——開發人員

需求跟蹤責任人：PM（開發）。

需求跟蹤的步驟：在代碼 review以前，由PM組織完成代碼函數項錄入。

需求跟蹤方法：在代碼函數項和詳細設計項之間創建對應關係。

編碼階段需求跟蹤——測試人員

需求跟蹤責任人：PM（測試）。

需求跟蹤的步驟：

在單元測試方案、單元測試用例 review以前，由PM組織完成單元測試子項、單元測試用例項錄入。

需求跟蹤方法：

在單元測試項和單元測試子項、單元測試子項和單元測試用例之間創建對應關係。

需求變動

CR也就是變動請求，能夠來自不一樣的來源，好比用戶、潛在用戶、需求分析人員、測試人員、開發人員、第三方、供應商等等。

CCB是變動控制委員會（高層經理、項目經理、配置管理負責人、測試負責人、QA），來控制變動流程。

完了不是提交變動就能變動的，還要通過一系列的評審、完事以後修改相應的文檔等，始終要保持各個節點的狀態保持一致。

再來看由於需求變動都會影響哪些地方會受到影響。

需求變動引發的需求跟蹤

需求分析階段：
- 需求分析 - 系統測試計劃
概要設計階段：
- 需求分析 - 概要設計
- 需求分析 - 系統測試計劃 - 系統測試方案 - 系統測試用例
- 概要設計 - 集成測試計劃
詳細設計階段：
- 需求分析 - 概要設計 - 詳細設計
- 需求分析 - 系統測試計劃 - 系統測試方案 - 系統測試用例
- 概要設計 - 集成測試計劃 - 集成測試方案 - 集成測試用例
- 詳細設計 - 單元測試計劃
編碼及後期測試執行階段：
- 需求分析 - 概要設計 - 詳細設計 - 代碼
- 需求分析 - 系統測試計劃 - 系統測試方案 - 系統測試用例
- 概要設計 - 集成測試計劃 - 集成測試方案 - 集成測試用例
- 詳細設計 - 單元測試計劃 - 單元測試方案 - 單元測試用例

需求跟蹤工具

那麼都有哪些需求跟蹤的工具供咱們使用呢？

TestDirector
DOORS
QC

需求評審

那麼咱們瞭解完了，在軟件需求中的需求開發，和需求管理的大部份內容。那再來研究在對於需求的評審。

在整個項目流程中，咱們測試人員重點打交道的就是需求跟蹤和評審。

那首先回顧一下什麼是需求管理？就是讓開發人員和客戶對於變化的需求達成共識，這些共識包括：

業務需求。
功能需求。
非功能需求。
質量屬性。
外部接口需求。

評審這部分須要注意的是軟件需求規格說明書的寫做要點，需求規格說明書的評審都有哪些流程，以及評審都有哪些要點等。

再來回顧一下軟件需求規格說明書（SRS）的定義：是對在特定環境下要完成必定功能的軟件產品，程序或一組程序的說明。

應該從如下幾個方面去描述：

功能：軟件要作什麼。
外部接口：如何與人、系統硬件、外部的硬件和軟件交互。
性能：速度、響應時間、恢復時間等。
屬性：可移植性、可靠性、可維護性、可用性等。
實現的設計約束：標準、實現語言、資源限制、操做環境等。

軟件需求規格說明書的目的

在客戶和開發之間達成共識。
爲編制計劃和成本計價提供基礎。
爲設計提供了基礎。
爲確認和驗證提供基礎。
提升開發效率。
便於移植。

除此以外，客戶和營銷部門以需求規格說明書來了解產品，項目經理根據包含在軟件需求規格說明書描述的產品來指定計劃並預測進度安排、工做量、人力資源等。

對於軟件開發小組來講，能夠以此來更好的理解開發的究竟是一個什麼樣的產品。

對於測試人員來講，根據軟件需求規格說明書對產品的描述指定測試計劃、測試用例和明確測試過程。

對於維護和支持人員來講，能夠以此來了解產品的各個功能。

產品發佈組在需求規格說明書和用戶界面設計的基礎上編寫客戶文檔，如用戶手冊和幫助文檔。

對於培訓人員，可依次爲編寫用戶培訓資料。

那麼什麼樣的軟件需求規格說明書算是合格的呢？優秀的需求規格說明書有7+4特徵。

7特性指的是對於每條需求來講：完整性、正確性、一致性、可跟蹤性、劃分優先級、無二義性、可驗證性。其中，劃分優先級單拎出來來說，因此就剩下了6大特性。

軟件需求完整：不能遺漏任何須要的需求信息。
軟件需求的正確性：指每一項需求都必須準確的陳述要開發的功能。
軟件需求一致性：需求規格說明書中所羅列的需求和其餘軟件的需求或高層次的需求不相矛盾，好比在文檔的不一樣位置對同一個需求的描述不一致。
軟件需求無歧義：對全部的需求說明，針對不一樣的讀者都只能有一個明確統一的解釋。儘可能用客觀量化的數據代表需求，避開描述性的語言，好比色彩豔麗、高度適中，這些不一樣的人會有不一樣的理解。
軟件需求可驗證性：檢查每項需求是否能經過設計測試用例或其餘的驗證方法。
軟件需求可跟蹤性：應該能在每項軟件需求與它的根源和設計元素、源碼、測試用例之間創建鏈接鏈。

4特性是針對整篇需求規格說明書來講：完整性、一致性、可修改性、可跟蹤性。

需求分類

有的時候，用戶提出的需求多是模糊籠統的，那麼咱們就須要多用戶的需求加以分析，分類別，爲後續的工做提供更清晰的支撐。說道需求分類，咱們從管理角度來看有，：

原始需求，也稱爲業務需求，描述客戶或者開發公司能夠從產品中獲得的資金、市場或者其餘業務利潤的需求。
產品需求，也稱使用需求，有關利用系統執行業務任務或者達到用戶目標的整體陳述。
軟件需求，開發需求，項目開發人員要開發完成的系統應該提供一些全能和條件。
測試需求，分析要測試的需求，可控、容易觀察、經過測試用例可以實現。

從功能角度來講，能夠分爲：

功能需求，系統應該能知足用戶的需求。
非功能需求，對於功能需求的補充，隱性的需求。是否使用簡答，方便快捷等等。

從技術角度來講：

技術需求：功能、性能、健壯性、接口。
非技術性要求：項目進度要求、質量、成本等方面的要求。

需求的屬性

每個需求類型都有多個屬性：

劃分優先級
工做量
風險
可用於界定項目的範圍、估計工做量、計劃和平衡資源等。

需求的表達

如何將需求表達出來呢？

經過輸入、輸出來講明，也就是文檔。
使用規範化的模型方法（UML）。
使用電子表格。
使用表明性的例子。

需求表達應該避免的問題

需求描述過多涉及到具體的設計和實現。

超出規格，對需求描述大大超出用戶的需求。
過分限制，對需求進行了沒必要要的限制。
不肯定性：
- 以相對的方式描述需求。
- 沒有結束的需求。
- 主管或含糊的描述需求。
需求描述基於未通過確認的假設。

需求規格說明書的寫做要點

那麼在需求規格說明書中，大體有如下幾方面的內容。

項目介紹：
- 描述本軟件需求所描述的項目背景。
產品環境介紹：
- 描述的是當前軟件與其它產品或者項目所組成的總體環境。
- 若是該軟件時獨立的並徹底自我包含，要在此說明一下。
- 若是SRS定義的產品使更大的系統或項目的組件，那麼應該：
  - 描述上級系統或項目每一個組件的功能，而且標識接口。
  - 肯定本軟件產品主要外部接口。
  - 描述相關產品硬件和所使用的外部設備。
  - 經過方塊圖來描述上級系統或者項目的主要組件、互連性以及外部接口是很是有效的。
軟件功能（概述）：
- 概述軟件必須實現的和經過用戶操做實現的主要功能，這裏只須要進行簡要描述（好比目錄列表描述），詳細描述在詳細需求部分描述，對需求功能進行組織，以便於讀者理解，並能指導後續的設計和測試。能夠用圖表來表示主要需求羣組之間的關係，如高層的數據流圖，面向對象分析等。
- 有時此部分所要求的功能概述能夠從分配具體功能給此軟件產品的更高層規格（若是有的話）直接引用。
- 本節不該該描述具體的需求，但本節內容是具體需求章節的基礎。
用戶特徵：
- 列出對用戶或系統操做者的要求，如經驗、能力、角色等。
- 列出用戶屬性，如教育程度、國籍、年齡、性別等。
假設和依賴關係：
- 列出可能影響SRS中需求的全部的假設因素，包括準備使用的第三方或者商業組件，操做和開發環境的問題約束等。若是上述假設不正確、沒有被告或者改變了都將對項目產生影響。
- 列出項目對外部條件的依賴，例如重用其餘項目的模塊，若是在其餘文檔（項目計劃、範圍文檔等）裏已經描述了，在這裏能夠不用描述。
功能需求：
- 本子章節應該描述軟件產品的輸入怎麼樣被轉換成輸出，它描述了軟件必須執行的基本動做。
- 對每一類功能或有時對每個單獨的功能，必須描述輸入、處理、輸出方面的需求，對於每個功能需求，能夠有如下描述：
  - 簡要介紹，你要對功能作下簡要的介紹，包括項目如何響應預期的錯誤輸入，非法條件和無效輸入，需求應該簡明、完整、可驗證。必要是當需求要求的信息不肯定的時候，使用待定。
  - 輸入，有什麼輸入。對該功能的輸入數據作詳細的描述，包括輸入來源、數量、度量單位、時間要求等，包含精度和容忍度的有效輸入範圍。在適當的位置提供對接口規格或者接口控制文檔的參考。
  - 處理，你作了什麼處理。描述對輸入數據所執行的全部操做如何得到輸出的過程，這包括輸入數據的有效性檢測、操做的確切次序，事件的時序等；對異常狀況的迴應，如溢出、通訊失敗、錯誤處理等。
  - 輸出，輸出的結果要描述。對該功能全部輸出數據的詳細描述，包括輸出到何處？打印機或者文件等；數量；度量單位；時序；包含精確度和容忍度的有效輸出範圍；對非法值的處理；錯誤消息；在適當的位置提供對接口規格或者接口控制文檔的參考。
  - 爲了對需求作更好的跟蹤，咱們要對需求編號多多考慮，避開功能需求（1）和功能需求（2）之類的。
性能需求（非功能需求）：
- 在本段落描述讀軟件的靜態和動態的量化需求。
- 靜態量化包括：支持的終端書目；支持的同時使用的用戶數；處理文件和記錄的數目；表和文件的限制；
- 動態量化需求包括：在正常或者峯值工做量狀況下特定時間內處理事務或者任務數目及數據量和對系統資源的消耗。
用戶接口：
- 對每種人機界面，軟件所必須支持的特性，如系統用戶經過一個顯式終端進行操做，那麼應該包括：要求的屏幕格式；頁面規劃及報告或者菜單的內容；輸入和輸出的相關時序；一些組合功能鍵的用法等等。
- 與系統用戶接口使用相關的全部方面，這可能只是一個簡單的關於系統怎麼樣展現給用戶，該作什麼和不應作什麼的列表。
軟件接口：
- 應該描述如何使用其它軟件產品（如數據庫、操做系統），以及與其它應用系統的接口。
- 對每一個必需的軟件產品，應提供：名字；助記符；版本號；接口。
- 若是接口已在其它文檔中描述清楚，這裏無需重複描述，但須要說明應該參考的文檔。
硬件接口：
- 在此描述軟件產品和系統硬件組件之間接口的邏輯特性，包括支持哪些設備，怎樣支持這些設備和協議等。
- 按軟/硬件協議內容和格式定義接口，若是接口已在其它文檔中很清楚的描述，這裏無需重複描述，但須要說明應該參考的文檔。
標準符合度：
- 說明需求所採用的標準或者規範的來源，若是項目採用了國際標準，應該說明國際標準及項目與標準的偏離狀況。
硬件約束：
- 包括軟件在不一樣的硬件平臺運行的需求，如時間相關的約束，內存方面的約束等。
技術限制和本地化：
- 技術限制：包括對使用特定的技術限制，接口、數據庫、並行操做、通信協議、設計約定、編程規範等。
- 本地化，描述支持多語言的需求。
需求分級：
- 必須的，絕對基本的特性，若是不包含，產品就會被取消。
- 重要的，不是基本的特性，但這些特性會影響產品的生存能力。
- 最好有的，指望的特性，但省略一個或多個這樣的特性不會影響產品的生存能力。

需求階段的角色和職責

軟件開發項目經理：

帶領項目組分析審覈工做任務書。
帶領項目組與系統工程師進行需求交流並分析和文檔化。
組織SRS文檔評審。
組織需求跟蹤。

軟件開發工程師：

完成SRS文檔。
完整需求跟蹤。
參加SRS review。
根據SRS評審專家意見，修改SRS文檔。
參加系統測試計劃的評審。

軟件（產品）經理：在SRS評審結束後，批准SRS文檔。

QA：

監督項目組遵循需求管理流程。
參加相關文檔的review。
保證相關組參加文檔review。

CCB（變動控制委員會）的負責人：控制需求的變動。

軟件測試項目經理：

參與開發人員的軟件需求分析，提出可測試性需求。
組織人員參與SRS的評審工做。
軟件系統測試計劃寫做。
組織系統測試計劃的評審。
組織本階段測試需求跟蹤。

軟件測試工程師：

參與SRS評審工做。
協助軟件測試項目經歷完成軟件系統測試計劃寫做。
參加系統測試計劃評審。
完成本階段測試需求跟蹤。

評審流程

參與軟件產品的審查的參與者表明三方面的觀點：

產品的開發組。
先前產品的開發者或者正在評審的項目規格說明編寫者。
要根據正在審查的文檔來展開工做的成員。

軟件評審的過程首要要有一個觸發可以評審的必要條件，也就是何時開始評審。

被評審對象是需求，也就是主角軟件需求規格說明書，或這還要搭配原始的需求說明書，項目計劃書等材料。

每次評審都要有一個評審重點，若是軟件功能較多，那麼一次評審不完，咱們整理成一個Checklist，每次評審其中一個重點。

相關的材料準備完畢，接下來就要選擇，由哪些人（專家）來參加評審，通常咱們建議這些人蔘見評審：

接受過關於review的目標、原則和方法培訓的人員。
主要的候選review人員：來自review人員資源池中涉及該工做產品所處生命週期上一階段、當前階段和後一階段的review人員。
受影響組的成員，如測試工程師。
與review工做產品有關的同行。

除了上面那些專家以外，還須要有軟件需求評審組織者：

接受過關於review的目標、原則和方法培訓的人員。
接受過如何領導review團隊培訓的人員。
有組織能力。

這些組織者負責組織評審會議，選擇合適的專家，還要有相應的權利、技術。

在評審的時候，除了組織者和評審專家，可能還須要做者、記錄員、講解者參與。

而且，在評審過程當中，還須要遵照必定的原則：

任何一次review最少須要3人，一個做者兩個review人員。
任何一次review最多須要7人蔘與（人太多，七嘴八舌的.......），一個做者和6個review人員。
需求規格說明書的review規模不過超40頁。
做者在提交檢視對象前，首先進行自檢。
組織者能夠根據review工做產品的checklist來定製本次review的checklist重點事項，保證review質量。
組織者應當根據被review對象的規模及複雜程度爲檢視這留出足夠的準備時間，對review規模不超過40頁的工程文檔，建議準備時間是2~3天。
review會議時間通常爲2小時，但組織者能夠根據被review對象的類型及規模來調整。
在review會議上組織者根據返工帶來的影響程度（如修改量的大小，是否影響到關鍵的功能和算法）等來決定是否須要再此review，同時還能夠參考本次review的效果（如是否達到質量目標）來決定是否須要再次review。

通過一番評審專家的評審，也會有相應的評審結果產生，如根據評審專家意見修改後的軟件需求規格說明書，也能夠有這樣一個軟件需求規格說明書評審表格。

評審人員	問題描述	位置（頁/段/全部）	缺陷/疑問	缺陷嚴重程度	問題確認	做者修改說明	是否已改正

那麼在評審中要注意哪些事項呢？

是否全部的分配需求都在SRS中體現？
在SRS中定義需求時，是否避免使用那些會引發歧義的術語，諸如也許、可能等，每條需求都清晰無歧義？
是否在SRS中清晰的描述了軟件要作什麼及不作什麼？
是否在SRS中描述了軟件使用的目標環境，指明並簡短描述了目標環境中其它相關軟件產品/子系統/模塊？
是否每個具體需求都有惟一編號？
每個需求是否切實可行、可測試、先後一致、彼此不衝突？
是否在SRS中說明了對每一個輸入的驗證措施，並描述了每一個輸入的屬性如：度量單位、邊界值、時序要求等等？
是否在SRS中說明了每一個輸入的處理？
是否在SRS中說明了每一個輸出項是如何輸出的，而且描述了每一個輸出的屬性，如度量單位，邊界值等等？
是否在SRS中描述了軟件全部的性能需求？
是否性能需求的描述能經過測試來進行驗證？
是否在SRS中說明了全部對系統可能的約束？
質量屬性是否能夠測量或可驗證的術語進行描述？
是否在SRS中描述了系統中與其它子系統、模塊或硬件設備的相關接口？
是否對每一個接口的描述足夠清晰，實現時不須要更多解釋？
是否在SRS中描述了與操做系統的接口？
是否在SRS的附錄中記錄了分配需求可行性的分析結果？
是否項目工做任務書（SOW）所對應的分配需求都在RTM（發佈生產階段）中體現？

同行評審

在需求評審中，主要採用同行評審的方法。想一想目前火爆的選秀節目，都是採用同行評審的方法。

同行評審（Peer Review）是一種經過做者的同行來確認缺陷和須要變動區域的檢查方法，須要進行同行評審的特定產品在定義軟件過程的時候被肯定而且做爲軟件開發計劃的一部分被安培了進度。須要前期準備、計劃和時間進度表，越早進行同行評審效果越好。

同行評審的做用：早期發現缺陷、去除缺陷、下降成本、提升質量。

同行評審的類型：

正規檢視：軟件正規檢視是在軟件開發過程當中進行的，發現、排除軟件在開發週期各階段存在的錯誤、不足的過程，是一種軟件靜態測試方法，其生存週期爲軟件的開發週期，應用於開發過程當中產生的（非階段性）軟件文檔和程序代碼。正規檢視的主要目的是發現缺陷。它的評審對象比較普遍，有嚴格的評審流程，但要考慮時間成本等問題。
技術評審：是由一個正式的組對產品進行評價，它確認任何與規格和標準不一致的地方或者在檢查後給出可替換的建議，或者包含這二者，技術評審的嚴格程度沒有像正規檢視那麼嚴格，技術評審的參與者包括做者，以及產品技術領域內的專家。
走讀，走讀的目的是要評價一個產品，一般是軟件代碼，走讀一直以來都與代碼檢查聯繫在一塊兒，其實走讀也能夠應用到別的產品，好比結構設計、詳細設計、測試計劃等。走讀最主要的目標是發現缺陷、遺漏和矛盾的地方、改進產品和考慮可替換的實現方法。走讀還有其它的目的，好比技術交換、參與人員技術培訓，設計思想的介紹等。

同行評審流程中，主要有七個活動，其中有兩個活動根據實際狀況進行選擇，那就是介紹會議和第三小時會，根據狀況是否開啓介紹會議和第三小時會議。

通用評審流程計劃階段：