❶ 什么是软件评审为什么需要进行软件评审
评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。
❷ 作为一个软件测试人员，需求评审应该做些什么
需求评审对于软件测试人员来说就像是最初的“产品测试”，在理解的基础上发现产品设计上缺陷，其中包括逻辑错误，功能缺失，细节问题等等，这样就会有效的在前期规避很多后期开发中产生的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 分层次评审 用户的需求是可以分层次的，一般而言分成以下层次： ①目标性需求，定义整个系统需要达到的目标； ②功能性需求，定义了整个系统必须完成的任务； ③操作性需求，定义了完成每个任务的具体的人机交互；目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。 对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费。 分层次评审，可以让不同类型的参与人分别评审他们关注的内容，从不同的角度找到需求的异常，提高评审效率。