用户需求是衡量软件质量的基础。
除满足明确定义的需求外，还要满足隐含的需求。
软件质量因素
1.正确性(Correctness):系统满足规格说明和用户目标的程度，即在预定环境下能正确地完成预期功能的程度;
2.健壮性(Robustness):在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度;
3.效率(Efficiency):为了完成预定的功能，系统需要的计算资源的多少;
4.完整性(Efficiency)或安全性(Security):对未经授权的人使用软件或数据的企图，系统能够控制(禁止)的程度;
5.可用性(Usability):系统在完成预定应该完成的功能时令人满意的程度;
6.风险(Risk): 按预定的成本和进度把系统开发出来，并且为用户所满意的概率;
7.可理解性(Comprehensibility):理解和使用该系统的容易程度;
8.可维修性(Maintainability): 诊断和改正在运行现场发现的错误所需要的工作量的大小;
9.灵活性(Maintainability)或适应性(Adaptability): 修改或改进正在运行的系统需要的工作量的多少;
10.可测试性(Adaptability): 软件容易测试的程度;
11.可移植性(Portability): 把程序从一种硬件配置和(或)软件系统环境转移到另一种配置和环境时，需要的工作量多少。有一种定量度量的方法是:用原来程序设计和调试的成本除移植时需用的费用;
12.可再用性(Reusability): 在其他应用中该程序可以被再次使用的程度(或范围);
13.互运行性(Interoperability): 把该系统和另一个系统结合起来需要的工作量的多少。
缺陷的概念
软件缺陷是指软件对其期望属性的偏离，它包含三个层面的信息： 1. 失效(failure)：指软件系统在运行时其行为偏离了用户的需求，即缺陷的外部表现。 2. 错误(fault)：指存在于软件内部的问题，如设计错误、编码错误等，即缺陷的内部原因。 3. 差错(error)：指人在理解和解决问题的思维和行为过程中所出现的问题，即缺陷的产生根源。
缺陷原因分析
- 一个差错可导致多个错误，一个错误又可导致多个失效。
- 软件缺陷原因的分析不能只停留在“错误”这一层面上，而要深入到“差错”层面，才能防止一个缺陷（以及类似缺陷）的重复发生。
- 因此软件缺陷的根本原因往往与过程及人员问题相关，缺陷预防总是伴随着软件过程的改进。
软件缺陷原因分析过程一般包括选择缺陷数据、分析缺陷数据、识别公共原因并提出改进措施三个步骤。采用该方法的软件组织通常是在软件项目的每个开发阶段结束后，或者定期（如每个月末）进行缺陷原因分析，提出改进措施，从而促进组织的过程改进。
评审（Review） 评审相当于软件开发过程的“过滤器”，在软件开发的一些时间点上对中间产品执行评审，发现和排除错误，防止错误被遗留到后续阶段。因此评审对于保证软件质量和降低开发成本都极为重要。 评审可以在软件项目的任何阶段执行，不必等到软件可运行之后，因此可以尽早发现和消除缺陷，提高软件质量，并降低开发成本。 有统计数据表明，评审可发现75%的设计错误。 技术评审（Technical Review） 技术评审（Technical Review, TR）就是对工作成果进行审查和分析，发现其中的缺陷，并帮助开发人员及时消除缺陷。 技术评审的主要对象：需求和设计规格说明、代码、测试计划、用户手册等。 正式和非正式技术评审 技术评审分为正式技术评审和非正式技术评审两种基本类型，前者比较严格，需要举行评审会议，参加人员比较多，后者的形式比较灵活，通常在同伴之间开展，不必举行评审会议，参与人员相对较少。 一般来说，对重要性和复杂性较高的工作成果，应进行正式技术评审，对重要性和复杂性相对较低的工作成果，可进行非正式技术评审。 技术评审会议 技术评审以会议形式进行，一般有如下约束： 评审会议通常由3~5人参加。 会议之前评审人员要做准备，但每人的准备时间不超过2个小时。 评审会议的时间不超过2个小时。 一次技术评审只关注软件的某一特定部分（例如需求或设计规格说明的一部分）。缩小评审焦点可提高发现错误的可能性。
技术评审的注意事项 评审产品，而不是评审人。评审会议的气氛要轻松和愉快，注意提出问题时的方式和态度，不要让产品开发者产生被审问的感受。 制订评审会议的议程并遵守进度。不要让会议过分拖延。问题的具体解决方案可以在会后讨论。 使用检查清单。为不同的软件产品（需求、设计、代码等）开发检查清单，在检查清单中列出所有重要的、常见的问题，这样可以使评审会议聚焦于一些重要问题。
过程检查 过程检查就是检查软件项目的工作过程和工作成果是否符合既定的规范。在软件项目中，如果工作过程和工作成果不合规范，很可能会导致质量问题。 例如，代码和文档的版本及其命名不符合版本控制规范，重要的变更不遵循变更控制流程，都有可能造成开发工作的混乱，进而导致产品质量下降。 工作过程和工作成果符合既定规范，也并不意味着产品质量一定能得到保证。因此过程检查只是保证质量的一个必要条件，而不是充分条件，它还需要与技术评审、软件测试、缺陷跟踪、过程改进等各方面措施互相配合，共同促进软件质量的提高。 对过程检查要事先做出规划，确定主要检查项、检查时间（或频度）、负责人等。过程检查计划一般包含在软件项目质量管理计划中。
