❶ 什麼是軟體評審為什麼需要進行軟體評審
評審是對軟體元素或者項目狀態的一種評估手段，以確定其是否與計劃的結果保持一致，並使其得到改進。
❷ 作為一個軟體測試人員，需求評審應該做些什麼
需求評審對於軟體測試人員來說就像是最初的「產品測試」，在理解的基礎上發現產品設計上缺陷，其中包括邏輯錯誤，功能缺失，細節問題等等，這樣就會有效的在前期規避很多後期開發中產生的bug，減少了很多後期返工的成本。可偏偏需求評審往往是最不重視的一環，甚至可以說是沒有這個環節，追其原因無非因為項目時間緊迫或者覺得沒有必要，其實這是本末倒置和得不償失的。
產品需求作為程序的源頭，只有控制好最開始部分，才不會到最後去亡羊補牢。我有過很多血的教訓，所以才深深的體會到需求評審的重要性。
說了需求評審的重要性，接著就來談談如何進行需求評審，一般還是分為3步：
第一步就是要完全讀懂產品需求，這個過程只需要理解而不是去挑刺，因為要明白這個需求的目的是什麼，為什麼這樣做，怎麼做等等，只有在理解的基礎上才能去發現問題，而不是一知半解的去挑毛病，有些需求設計的是不合理，但也許有其特殊的用意，或者只是沒有更好的方案，不能為了挑毛病而去挑。
第二步就是分析和找問題；這就有點類似寫測試用例的時候設計測試方案了，把邏輯梳理出來，看看有沒有不對或者遺漏的點，整理出來反饋給產品經理。除了考慮有問題的地方，沒問題的地方也是需要分析的，比如有些設計非常合理，但會增加代碼的復雜度或者不利於後續的擴展和修改，同時也可能會給測試帶來成倍的工作量，這些也是需要指出的，因為測試要考慮的東西一定要比產品經理多，用戶使用習慣，程序復雜度，與線上系統的兼容性等等，不然直接讓產品經理做測試不就好了嗎？
第三步就是細節問題的糾正，可以是界面，可以是文字，開發一般都是復制黏貼或者照著樣子畫葫蘆，這些小問題後期其實也可以測試出來的，但其鍋不在於開發，早點發現問題早點解決也是好事一件，至少不用提bug走一套bug處理流程了，也算給大家省點工作量，積少成多也是極好的。
當然需求評審能解決的問題也是有限的，一方面計劃往往趕不上變化，中間會有部分需求的改動，另外一方面有些深層次的問題只有在測試之後才會發現。但無論如何對於測試來說還是非常有必要的，如果能重視起來不僅僅對項目的效率提高不少，而且也能讓後期測試壓力減小，何樂而不為呢？
❸ 需求評審時測試人員需要關注哪些方面
1. 完整性審查：應保證測試需求能充分覆蓋軟體需求的各種
特徵，重點關注功能要求、數據定義、介面定義、性能要
求、安全性要求、可靠性要求、系統約束等方面，同時還
應關注是否覆蓋開發人員遺漏的、系統隱含的需求；
2. 准確性審查：應保證所描述的內容能夠得到相關各方的一
致理解，各項測試需求之間沒有矛盾和沖突，各項測試需
求在詳盡程度上保持一致，每一項測試需求都可以作為測
試用例設計的依據。
需求評審會議中，帶著列出的疑問點向產品、開發溝通自己對產品的疑惑和質疑點，多提幾個為什麼？
1.如何實現？
2.數據獲取來源？
3.超出預期的數據怎麼處理？
4.緩存處理機制如何？
5.數據保存何處？
6.邏輯由前端處理還是後端服務？
7.後端服務邏輯是否跟第三方關聯？
❹ 軟體測試首先要進行需求評審，需求評審和設計評審可以同時進行嗎為什麼
不能同時進行。需求評審是「從用戶的角度」出發，一切圍繞用戶進行評審。理解了軟體產品的業務需求和用戶需求後，才能進一步進行設計。從而對軟體實現的功能進行設計評審。可以說，「需求在前，設計在後。」
❺ 為什麼要在做測試計劃前對軟體需求進行評審和測試
需求是不斷更新的，當客戶加上某點或是刪去某點功能，需求變更隨時都可能發生。需求的開發是貫穿整個開發過程的，不是做測試計劃前就完成。這是一個不斷循環迭代的過程。
需求驗證活動可以確保需求符合優秀需求稱述的特徵，並且符合好的需求規格說明的特徵。
因此，在部分需求確定下來時，就對這些已經發現的需求進行評審和測試，盡快開發測試用例，就能夠及早發現需求方面的缺陷和問題，這樣就可以只用較低的費用解決這些問題。
若是在測試結束後，才發現遺漏了某個重要需求；對於某個不是很重要的需求，開發過程中卻將其作為重點等等這些問題，那麼這個損失就巨大了，需要開發人員重新開發，甚至於重新回到原點，這樣將耗費巨大的人力物力。
❻ 軟體測試首先要進行需求評審，需求評審和設計評審可以同時進行嗎為什麼
不能同時進行，需求評審組由開發方和客戶方的代表共同組成；而設計評審組可包括其他功能團組的人員，例如營銷、製造、質量保證部。
他們評價的內容和側重方面不一樣。
❼ 軟體工程：3.需求分析
需求分析的任務就是准確地回答「 系統必須做什麼 」。是通過系統分析員與用戶一起商定，清晰、准確、具體地描述軟體產品必須具有的 功能 、 性能 、 運行環境 等要求。
用戶：知道做什麼，不知道怎麼做。
開發人員：知道怎麼做，不知道做什麼。
因此，系統分析員必須和用戶密切配合、充分交流信息，得出經過用戶認可的系統需求。
需求分析的目的是澄清用戶的需求，並把雙方共同的理解明確地表達成一份書面文檔—— 需求規格說明書 。
需求分析是一項軟體工程活動，它包括： 需求獲取 、 需求建模 、 需求規格說明 、 需求評審 。
需求分析模型 是准確地描述需求的圖形化工具，主要有 實體關系圖 、 數據流圖 、 狀態轉換圖 。需求分析建立起來的模型為日後軟體設計人員提供了可被翻譯成 數據結構 、 體系結構 、 介面 和 處理過程 設計的模型。
如上圖所示，目標系統模型的建立過程分 4 步完成：
把分析的結果用正式的文檔記錄下來，作為最終軟體配置的一個組成成分。需求規格說明為開發人員和用戶提供軟體開發完成時質量評價的依據。
作為需求分析階段的復審手段，在需求分析的最後一步應該對功能的正確性、完整性和清晰性以及其他需求給予評價。
需求分析研究的對象是 用戶的要求 。必須 全面理解 用戶的各項要求， 准確表達 用戶的要求。只有經過確切描述的軟體需求才能成為軟體設計的基礎。
評審應由專人負責，評審組由軟體開發成員、軟體專家、領域專家和用戶構成。
需求分析是一個不斷的迭代過程。只有需求全面，准確無誤，才能開發出用戶滿意的系統。
需求獲取是軟體開發工作中最重要的環節之一，其工作質量對整個軟體系統開發的成敗具有決定性影響。需求獲取工作量大，所涉及的過程、人員、數據、信息非常多，因此要想獲得真實、全面的需求必須要有正確的方法。常規的需求獲取的方法有以下幾種：
需求分析模型 是准確地描述系統需求的圖形化工具。它可以使人們更好地理解將要建造的系統，它有助於系統分析員理解系統的信息、功能和行為，成為確定需求規格說明完整性、一致性和精確性的重要依據，奠定軟體設計基礎。
需求分析建模的方法有 結構化分析建模 和 面向對象分析建模 。
結構化分析導出的分析模型包括 數據模型 、 功能模型 和 行為模型 。
需求分析模型以「 數據字典 」為核心，描述了軟體使用的所有數據對象，圍繞這個核心的是「 實體關系圖 」、「 數據流圖 」和「 狀態轉換圖 」。
具體形式如下圖所示：
實體關系圖（ER，Entity-Relationship Diagram） ：是一種數據模型，是以實體、關系、屬性三個基本概念概括數據的基本結構，從而描述 靜態數據結構 的概念模型。
ER 包括三種基本元素：
關聯的重數 定義了在關聯的一端可以存在的數據實體實例的數量。 關聯重數可以具有下列值之一：
兩個數據對象之間按關聯的重數有以下三種關聯：
以下實體關系圖描述的是教師、課程、學生三者之間的關系。
以下實體關系圖描述的是出勤、職工、獎金、扣款之間的關系。
數據流圖（DFD，Data flow diagram） ，是描述數據流和數據轉換的圖形工具，它是進行結構化分析的基本工具，也是進行軟體體系結構設計的基礎。
DFD 有四種元素，其基本符號如圖所示：
示例，工資計算系統的頂層（0層）數據流圖：
在數據流圖中有時也使用 附加符號 ： * 、 + 、 ⊕ ，分別表示與、或、互斥關系。
數據流圖可分為不同層次，頂層（0層）DFD 稱為 基本系統模型 ，可以將整個軟體系統表示為一個具有輸入和輸出的黑匣子，其加工處理是 軟體項目的名稱 ，用一個圓圈表示。
DFD 中的每一個加工可以進一步擴展成一個獨立的數據流圖，以揭示系統中加工的細節。這種循序漸進的細化過程可以繼續進行，直到最底層的 DFD 圖僅描述加工的 原子過程 為止。每一層數據流圖必須與它上一層數據流圖的輸入輸出保持平衡和一致。
數據流圖是在需求陳述的基礎上繪制的。
這個數據流圖只是一個高層的系統邏輯模型，它反映了目標系統要實現的功能。
第二層數據流圖——銷售細化：
第二層數據流圖——采購細化：
當軟體系統涉及 時序關系 時需要進行 行為建模 ，由於數據流圖不描述時序關系，系統的控制和事件流需要通過行為模型來描述。
在描述系統或各個數據對象的行為時，採用 狀態轉換圖 。通過描述系統或對象的 狀態 ，以及引起系統或對象狀態轉換的 事件 來表示系統或對象的行為。
狀態轉換圖（STD，Status Transition Diagram） ，是描述系統狀態如何響應外部事件進行轉移的一種圖形表示。
狀態 是任何可以被觀察到的系統行為模式，一個狀態代表系統的一種行為模式。狀態規定了系統對事件的響應方式。在狀態圖中定義的狀態主要有： 初始狀態 、 中間狀態 和 最終狀態 。
事件 是在某個特定時刻發生的事情，它是對引起系統從一個狀態轉換到另一個狀態的外界事件的抽象。
在狀態轉換圖中，圓圈「○」表示可得到的 系統狀態 ，箭頭「→」表示從一種狀態向另一種 狀態的轉移 。箭頭旁標上 事件名 。
數據字典（DD，Data Dictionary） 用來描述數據流圖中的數據存儲、數據加工和數據流。 數據字典與數據流圖配合，能夠准確、清晰地表達數據處理的要求。
對於在數據流圖中每一個被命名的圖形元素均加以定義 ，其內容有: 名字、別名或編號、分類、描述、定義、位置、其它。
在數據字典中，數據元素的定義可以是基本元素及其組合，數據進行自頂向下地分解，直到不需要進一步解釋且參與人員都清楚其含義為止。
數據流定義實例：航班訂票單的數據定義
數據元素定義實例：考試成績的數據定義
數據文件定義實例：圖書庫存的數據定義
數據處理定義實例：編輯訂票的數據定義
外部實體定義實例：教師的數據定義
存摺＝戶名＋所號＋帳號＋開戶日＋性質＋(印密)＋1{存取行}50
戶名＝2{字母}24
所號＝「001」..「999」
帳號＝「00000001」..「99999999」
開戶日＝年＋月＋日
性質＝「1」..「6」 註：「1」表示普通戶，「5」表示工資戶等
印密＝「0」 註：印密在存摺上不顯示
存取行＝日期＋（摘要）＋支出＋存入＋余額＋操作＋復核
需求規格說明書（SRS，Software Requirement Specification） ，是系統分析人員在需求分析階段完成的文檔，是軟體需求分析的最終結果。
它的 作用 主要是： 作為軟體人員與用戶之間事實上的技術合同；作為軟體人員下一步進行設計和編碼的基礎；作為測試和驗收的依據 。
SRS 必須用統一格式的文檔進行描述。為了使需求分析描述具有統一的風格，可以採用已有的且能滿足項目需要的模板，如中國國家標准推薦的SRS模板，也可以根據項目特點和軟體開發小組的特點對標准進行適當的改動，形成自己的模板。
❽ 軟體項目中如何開展有效的需求評審
1、需求評審的重要性 在軟體項目中，需求分析是最開始的工作，同時也是最重要的工作。需求分析如果做得不夠詳細或者是偏離用戶需求或者是存在缺陷的話，往往會給項目帶來滅絕性的災難，不重視需求過程的項目團隊將自食其果。因此，如何保證需求分析的正確、准確性，成了決定軟體項目成敗的關鍵因素。在實際的項目過程中，需求階段往往是由一兩位需求分析人員與用戶溝通用戶需求，然後根據自己的理解輸出軟體需求說明書及軟體原型。 接下來的項目計劃、軟體設計、編碼、測試等各個環節都以此為基準。俗話說，當局者迷，旁觀者清，經驗再豐富的需求分析人員也可能犯錯，所謂智者千慮，必有一失，這是永遠不變的客觀規律。另外，受需求分析人員的理解及用戶的表達等因素的影響，需求在傳遞過程中往往存在很大偏差。 需求分析人員輸出的需求分析說明書，到設計人員、編碼人員、測試人員那裡往往又會有不同的理解。因此，軟體需求分析說明書的正確性必須得到徹底的驗證，利益相關方必須徹底理解需求，並達成一致。要達成這一目標、降低需求風險，需求評審是一個行之有效的方法。 目前，很多小型軟體企業在需求階段，往往是需求人員寫完需求後再跟用戶溝通一下，就直接進入設計開發階段了，設計、編碼、測試人員前期沒有參與進來，根本沒有進行需求評審。也有不少企業的需求評審存在「走過場」的情況，其他人員根本不關心軟體需求，認為軟體需求就是需求分析人員的事情，他們怎麼寫大家怎麼做就可以了，在提需求異常時簡單找幾個錯別字提一下應付了事，沒有提出有效的需求異常。也有的時候，在需求評審會議中，大家的關注點常常會不知不覺的轉向設計，結果需求評審會議成了設計討論會議，大家想得最多的是需求如何實現，而不是需求文檔本身有無問題。 或者是因為沒有做好前期准備工作，導致評審時間長、效率低，結果很多問題不了了之。這樣的評審，最終效果可想而知。 2、需求評審的關鍵 下文根據筆者多年參與軟體項目管理的切身體會及經驗，從不同角度對需求評審方法進行論述。 2.1 充分准備評審 好的軟體需求說明書，是進行有效需求評審的前提。 首先，需求人員在與用戶確認需求的過程中，一定不要放過任何一個細節，仔細體會用戶的每一個要求。對於用戶的要求，需求人員需要對其加以梳理：哪些是合理的需求，哪些是不合理的需求，還有一些可能是必要的但是用戶沒想到的需求。 軟體需求說明書不應該只是用戶意願的表達，而應該是從軟體層面上對用戶需求的總結。 軟體需求說明書對需求用例的描述一般分為基本流和擴展流，基本流是大家很容易想到的主要業務流程，而實際設計開發及測試過程中，最耗費時間的是實現擴展流的過程。因此不能只注重基本流，好的軟體需求說明書，擴展流一定遠遠多於基本流，擴展流寫得越完善，說明需求人員考慮得越周全。 而實質上，如果擴展流寫得不完善，後期的設計、開發及測試人員往往在相應的細節處理上無所適從。 2.2 分層次評審 用戶的需求是可以分層次的，一般而言分成以下層次： ①目標性需求，定義整個系統需要達到的目標； ②功能性需求，定義了整個系統必須完成的任務； ③操作性需求，定義了完成每個任務的具體的人機交互；目標性需求是企業的高層管理人員所關注的，功能性需求是企業的中層管理人員所關注的，操作性需求是企業的具體操作人員所關注的。 對不同層次的需求，其描述形式是有區別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標性需求，可能會很容易地導致「撿了芝麻，丟了西瓜」的現象，如果讓高層的管理人員也去評審那些操作性需求，無疑是一種資源的浪費。 分層次評審，可以讓不同類型的參與人分別評審他們關注的內容，從不同的角度找到需求的異常，提高評審效率。