软件需求工程简介
计算机基础知识点软件工程需求工程
计算机基础知识点软件工程需求工程计算机基础知识点：软件工程需求工程在现代社会中，计算机及其相关软件已经渗透到我们生活的方方面面。
而软件的开发和维护离不开一个重要领域——软件工程。
软件工程是指对软件进行开发、维护和管理的一系列过程和方法。
其中，需求工程是软件工程的一个核心环节。
本文将就软件工程的需求工程部分进行探讨。
一、什么是软件工程的需求工程？需求工程是指通过了解用户的需求和系统的环境来识别、定义和规范软件开发的要求，是软件工程中关键的一个阶段。
需求工程的过程主要包括需求获取、需求分析、需求规格说明和需求验证等。
二、需求工程的重要性需求工程的作用是确保软件系统满足用户需求并提供具有一定质量的软件产品。
以下是需求工程的重要性：1. 确定用户需求：需求工程帮助收集、分析和定义用户的需求，以便软件开发团队明确用户的具体需求。
通过需求工程的过程，可以找到用户真正需要的功能和特性，并将其映射到软件开发的项目中。
2. 降低开发成本和风险：通过需求工程，可以在软件开发的早期阶段发现问题和冲突，并进行相应的调整和解决，从而减少后期开发的成本和风险。
3. 提高软件质量：需求工程可以确保软件开发团队准确理解用户需求，并为系统设计、开发和测试提供明确的指导。
这有助于减少开发出不符合用户期望的软件的可能性，并提高软件的质量。
4. 增加用户满意度：通过需求工程，开发团队能够开发出用户真正需要的软件系统，满足用户的期望和要求，从而提高用户的满意度。
三、需求工程的过程需求工程包含几个主要的过程，下面将分析每个过程的作用和具体步骤。
1. 需求获取：需求获取是需求工程的起点，它包括与用户、利益相关者和系统其他部分的交流与合作，以确保在开发过程中获取到准确的需求信息。
需求获取的主要方法包括：- 面谈：与用户和利益相关者进行面谈，了解他们的需求和期望。
- 观察：通过观察用户使用系统的方式和行为来获得需求信息。
- 文档分析：分析相关文档，如已有的需求文档、用户手册等，以获得更多的需求细节。
软件需求工程
软件需求工程软件需求工程是指将用户需求转化为明确的和可行的软件需求规范的过程。
它是软件开发生命周期中非常重要的一步，决定了项目的成功与否。
本文将从需求工程的定义和目标、需求获取方法、需求分析和整理、需求规格化等方面进行探讨。
一、需求工程的定义和目标需求工程是指在软件工程中，从用户需求出发、对需求进行获取、分析、规格化和变更控制的一系列活动集合。
需求工程的目标在于确保软件开发团队和用户之间的需求达成一致，并深入挖掘用户真正的需求，从而产出一个高质量、可靠的需求规格。
二、需求获取方法需求获取是指收集用户需求的过程，根据不同的项目和情况，可以采用以下几种常见的需求获取方法：1. 面谈法：工程师和用户面对面进行沟通，通过问答的方式获取用户的需求。
2. 观察法：直接观察用户在使用现有系统或业务流程中的行为，从中捕捉用户的需求。
3. 问卷法：设计问卷并发放给用户，通过用户填写的问卷来获取用户需求。
4. 原型法：根据初步的用户需求，制作出原型，供用户参考和反馈，进一步完善需求。
三、需求分析和整理需求分析主要是对收集到的用户需求进行梳理、分类和分析，确保需求的完整性和可行性。
需求整理是将需求进行排序、分类，以及去除重复、冲突等问题，形成一个清晰明确的需求列表。
在需求分析和整理的过程中，可以采用用例图、数据流图、状态转换图等工具帮助分析和整理需求。
这些工具可以帮助识别需求之间的关系和依赖，以及对需求进行更加深入的理解。
四、需求规格化需求规格化是指将用户需求转化为明确的需求规格文档。
需求规格化的主要目标是准确地描述软件系统的功能、性能、接口等方面，为开发团队提供清晰明确的开发目标。
在需求规格化的过程中，可以使用自然语言描述、UML建模语言、流程图等方法，将用户需求转化为符合工程规范的需求规格文档。
需求规格文档应该包括详尽的需求描述、需求的优先级、需求的变更控制等内容，使开发人员能够准确理解和开发。
五、需求验证与变更控制需求验证是指对需求规格进行检查，确保需求规格的准确性和完整性。
软件需求工程
软件需求工程软件需求工程是指在软件开发过程中对软件需求进行系统化、规范化的管理和处理的过程。
它包括软件需求的获取、分析、规范化、验证和管理等环节。
在整个软件开发生命周期中，软件需求工程起着至关重要的作用，它直接影响到软件开发质量和项目进展。
一、软件需求工程的定义软件需求工程是指在软件开发过程中对软件需求进行系统化、规范化的管理和处理的过程。
它包括软件需求的获取、分析、规范化、验证和管理等环节。
软件需求工程的目标是确保软件开发团队理解用户需求，并能够根据用户需求开发出满足其期望的软件产品。
二、软件需求工程的重要性软件需求工程在软件开发过程中具有重要的地位和作用，主要体现在以下几个方面：1. 确保项目顺利进行：软件开发过程中，需求不明确或者需求变更频繁往往会导致项目进展受阻。
通过对软件需求进行有效的工程化管理，可以确保项目按计划进行，减少开发过程中的不确定性。
2. 提高软件质量：软件需求工程能够对软件需求进行全面、准确的描述和规范化处理，使开发团队对用户需求有明确的认识。
这样可以避免开发过程中的误解和偏差，从而提高软件的质量和用户满意度。
3. 降低开发成本：软件需求工程能够在软件开发初期就发现和解决潜在的问题，避免在后期进行大幅度的修改和调整。
这样可以降低开发成本，并节约开发团队的时间和资源。
4. 加强项目管理：软件需求工程作为软件开发的基础，能够帮助项目经理对项目进展、人力资源和进度进行有效的管理。
通过对软件需求的追踪和管理，项目经理能够及时发现问题并做出相应的调整和决策。
三、软件需求工程的主要过程软件需求工程包含以下主要过程：1. 需求获取：通过与用户交流、访谈、需求调研等方式，获取用户的需求信息。
需求获取是软件需求工程的第一步，也是最关键的一步，它直接关系到后续工作的开展和软件开发质量。
2. 需求分析：在需求获取的基础上，进行需求分析工作，主要包括需求划分、需求描述、需求模型化等。
通过需求分析，将用户需求转化为开发团队所理解的形式，为后续的开发工作提供参考依据。
软件需求工程
软件需求工程随着现代社会信息技术的快速发展，软件需求工程作为软件开发的第一关键环节，越来越受到人们的重视。
所谓软件需求工程，是指将用户或客户对软件的需求转化成软件系统的所有功能和性能要求的过程，是确保软件系统最终的用户需求和实际应用需求之间的一项重要的技术和程序。
软件需求工程的目的，就是在开发软件系统前，尽可能完整地了解和分析用户的需求，并根据这些需求来指导软件系统设计、开发和测试的整个过程。
好的软件需求工程能够确保软件系统的功能和性能满足用户的期望，同时可以让软件开发人员和用户之间建立起良好的沟通和合作关系，从而更好地实现软件开发的目标。
软件需求工程的过程大致可以分为需求识别、需求分析、需求规格和需求确认四个阶段。
首先，需求识别是软件需求工程中最重要的环节之一。
它的主要目标是，在开发软件系统前，充分了解并识别用户的需求，准确地确定软件系统的使用范围和用户群，为后续的需求分析和规格制定打下坚实的基础。
在需求识别的过程中，要充分考虑用户的主要需求和目标、系统使用环境和约束条件等相关因素，发现和概述系统中的功能、性能和界面等方面的需求。
其次，需求分析是软件需求工程中的第二个关键环节。
它的主要任务是对用户需求进行进一步分析和细化，分析不同的用户需求之间的关系，确定软件系统的功能模块、依赖关系和图例等方面的需求，为后续的需求规格提供基础。
在需求分析的过程中，需要采取多种形式的需求收集方法，例如面谈、问卷、代码审查等，分析不同需求之间的相互作用和影响，制订具体的软件系统需求规范。
然后，需求规格是软件需求工程中实现用户系统上述需求的纲要和规范。
在软件需求规格制定的过程中，需要制定出一个完整的、清晰明了的需求规格书，并确保该规格书能够精确、完整地描述出软件系统的所有要求和特性。
在制定需求规格书的过程中，需要要明确为每个软件需求规范分配一个唯一的标识，并针对每个需求规范给出相应的检验方法。
最后，关于需求确认，它是软件需求工程中的最后一个环节。
软件需求工程概述
一．软件需求工程概述1.1需求工程的重要性1.需求在软件项目中的重要地位：软件系统开发过程中最难的部分是对要开发什么作出准确的判断。
所有概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件系统的接口1.2 软件需求工程的概念1. 什么是需求?IEEE的软件工程标准术语表(1990)则将需求定义为:第一项．用户为解决某个问题或达到某个目标而需具备的条件或能力。
第二项．系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。
2.什么是工程?工程的定义:工程就是运用科学知识，对现实问题提供性能价格比合理的解决方案。
性价比合理：涉及性能价格的权衡，尤其是在资源的使用方面。
解决方案：工程是有创造性和实效性的。
现实问题：问题是受人们关注的。
科学知识：用到应用科学中的分析方法3.软件工程的特殊性软件的特殊性（1）软件具有抽象性软件是不能独立存在的，其作用在于驱动硬件进行某种操作（2）软件行为不受物理定律约束（3）软件复杂性不受物理限制（4）软件无磨损传统的可靠性度量方法不再适用（5）软件复制无损耗复制品与原件无区别4.什么是需求工程？需求工程是系统工程及软件工程的重要分支。
需求工程旨在了解软件系统设计的真实意图，具体功用及限制条件。
并精确定义上述因素与系统行为的关系及系统随时间和产品线变化而发生的各种演化5.需求的层次软件需求包括三个不同的层次（1）业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
（2）用户需求描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
（3）功能需求（包括非功能需求）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
6.需求层次实例：（1）业务需求用户能有效地纠正文档中的拼写错误。
（产品包装盒封面上可能会标明这是个满足业务需求的拼写检查器。
软件工程专业优质课软件需求工程
软件工程专业优质课软件需求工程软件工程专业优质课——软件需求工程软件需求工程是软件工程领域的一门重要课程，它主要关注软件项目中的需求分析、规划与管理。
通过系统地收集、分析和定义用户对软件系统的需求，软件需求工程可以帮助开发团队更好地理解用户需求，并将其转化为可执行的开发计划。
下面将从需求工程的基本概念、流程和关键技术等方面进行论述。
一、需求工程的基本概念软件需求工程是指在软件开发或系统维护过程中，对需求进行收集、分析、定义、验证与管理等一系列活动的过程。
它的目标是构建一个正确、完整、准确、一致和可追踪的需求规格说明，为软件开发提供基础。
需求工程的核心是要确保需求的正确性和完整性。
只有对用户需求进行准确的理解和把握，才能保证软件开发过程中的目标和结果与用户的期望保持一致。
因此，需求工程在整个软件开发过程中具有举足轻重的地位。
二、需求工程的流程需求工程的流程可以分为需求获取、需求分析、需求定义、需求验证和需求管理等五个阶段。
1. 需求获取阶段需求获取阶段主要通过面对面交流、问卷调查、访谈和文献分析等方式，与用户直接沟通以获取需求信息。
在这个阶段中，需求工程师需要充分了解用户的背景、目标和需求，明确项目的范围和目标，以确保需求的准确性和一致性。
2. 需求分析阶段需求分析阶段是对需求进行详细分析和整理的过程。
在这个阶段中，需求工程师会对需求进行分类、排序和整理，以便更好地理解和表达需求。
同时，需求工程师还需要识别需求之间的相互关联和依赖，并找出潜在的冲突和问题。
3. 需求定义阶段需求定义阶段是将需求转化为可执行的设计和规划的过程。
在这个阶段中，需求工程师需要将需求进行详细描述，并明确需求的优先级和可实现性。
同时，还需要与开发团队共同讨论和协商，确立一个合理的开发计划和时间表。
4. 需求验证阶段需求验证阶段是对需求的正确性和完整性进行验证的过程。
在这个阶段中，需求工程师会与用户进行沟通和协商，共同确认和验证需求的准确性和可行性。
《软件需求工程》课件
需求变更管理
需求变更分类
将需求变更分为功能性需求变更、非功 能性需求变更和设计约束变更等。
变更影响分析
对需求变更的影响进行分析，评估变 更对项目进度、成本和风险等方面的
影响。
变更控制流程
建立严格的变更控制流程，包括变更 申请、审批、实施和验证等阶段。
变更实施与跟踪
实施需求变更，并对变更实施过程进 行跟踪，确保变更的有效性和正确性 。
用于记录和管理需求变更，确保需求的一致性和完整性。
如Enterprise Architect、Visio等，用于绘制数据流图、实体关 系图等，帮助分析人员更好地理解和管理需求。
通过建立需求与设计、代码、测试用例之间的关联，确保需求 的实现和验证。
如录音笔、屏幕录制软件等，用于记录用户的原始需求和问题 ，便于后续分析和整理。
风险识别
识别需求工程中可能出现的风险，如需求变 更频繁、需求不清晰等。
风险应对措施
制定风险应对计划，包括风险预防、减轻和 转移等措施。
风险评估
对识别出的风险进行评估，分析风险发生的 概率和影响程度。
风险监控与报告
对风险应对措施的实施过程进行监控，定期 报告风险状态和应对效果。
06 软件需求工程实践
需求分析的步骤
01
需求获取
通过与用户沟通、观察用户操作 等方式，了解用户的需求和期望
。
03
需求评审
对已定义的需求进行审查和评估 ，确保需求的准确性和完整性。
02
需求分析和定义
对获取的需求进行整理、分类和 细化，明确需求的范围、功能、
性能等要求。
04
需求变更管理
建立需求变更的流程和机制，确 保在项目过程中对需求的变更进
软件工程中的需求工程
软件工程中的需求工程在软件工程中，需求工程是一个关键的阶段，它在软件开发过程中起到了至关重要的作用。
需求工程是指对软件系统所需功能、性能和约束条件的识别、规范、文档化以及维护的过程。
在本文中，我们将探讨需求工程的定义、重要性以及常用的需求工程方法。
一、需求工程的定义需求工程是软件开发过程中的第一步，它旨在确保软件系统能够满足用户的需求和期望。
换句话说，需求工程是为了确定和理解用户对软件的需求，以便设计和开发人员可以据此创建出满足这些需求的软件系统。
二、需求工程的重要性1. 确保软件系统满足用户需求：需求工程的首要目标是确保软件系统能够满足用户的需求，避免开发出无用的软件或者与用户期望不符的软件。
2. 降低开发成本和风险：通过需求工程的精确分析和规范，可以减少开发过程中的错误和漏洞，提高开发效率，降低开发成本。
此外，需求工程还可以帮助开发团队识别和解决潜在的风险。
3. 促进团队合作和沟通：需求工程强调与用户、开发人员和其他利益相关者的密切合作和沟通。
这有助于增强团队的合作意识，提高沟通效率，确保各方对需求的理解保持一致。
4. 改进软件质量：需求工程可以帮助开发团队在早期识别和解决软件系统中存在的问题。
通过细致地分析需求并制定详细的需求规范，可以提高软件质量，减少后续开发过程中的修复和调整。
三、常用的需求工程方法1. 用户访谈和调查：通过与用户进行面对面的交流和深入的访谈，开发团队可以了解用户的实际需求和期望。
此外，还可以借助调查问卷等方式收集用户意见和反馈。
2. 需求文档化：将用户需求转化为可执行的需求文档，包括功能需求、非功能需求和约束条件等。
这些文档可以作为软件开发的指导和参考，确保开发人员和用户对需求有共同理解。
3. 原型开发：通过创建初步的软件原型，可以将抽象的需求具象化，方便用户和开发人员进一步理解和确认需求。
原型开发可以迅速反馈用户需求和期望，帮助开发团队及时调整和改进。
4. 需求验证和验证：需求验证是指与用户和其他利益相关者一起验证需求是否准确、完整和一致。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求风险
⑤ 过于精简的规格说明。
容易导致遗漏某些关键需求。 会给开发人员带来挫折，（使他们在不正确 的假设前提下和极其有限的指导下工作）。 也会给客户带来烦恼（他们无法得到他们所 设想的产品）。 重视需求分析的重要性，完成尽量详细的需 求说明。
31
需求风险
⑥ 忽略了用户分类。
多数产品是由不同的人使用其不同的特性， 使用频繁程度也有所差异，使用者受教育程 度和经验水平也不尽相同 。 忽略某一部分用户类的需求将导致众多客户 的不满 。 不在项目早期就针对所有这些主要用户进行 分类的话，必然导致有的用户对产品感到失 望。
Software Requirements Engineering
软件需求工程
郑州大学软件学院 软件工程专业必修课程 •授课对象:本科3年级 •授课教师:徐强
1
关于本课程
授课对象：计算机科学和软件工程专业的高 年级本科生及研究生。 授课学时：每周4学时，共9-10周。
课程目的：为工业界培养需求工程师，为学 术界准备从事相关研究的学者。
35
优秀需求说明的特征
① 正确性。
② 完整性。 ③ 无二义性。 ④ 必要性。 ⑤ 可行性。
⑥ 划分优先级。
⑦ 可验证性。
36
优秀需求说明的特征
① 正确性。
每一项需求都必须准确地陈述其要开发出的功 能性。
只有用户代表才能确定用户需求的正确性，这 就是为何一定要有用户的积极参与的原因。 没有用户参与的需求只是是评审者凭空猜测。
“为什么”和“做什么”是指系统的设计目的，是 臵身系统外部，对应用领域性质的描述。 “怎么做”是指系统的内部结构和行为。
19
需求的重要性
在软件工程项目中，所有的利益相关者 （stakeholder）都感兴趣的就是需求分析 阶段。
利益相关者包括客户、用户、业务或需求分析 员、开发人员、测试人员、用户文档编写者、 项目管理者和客户管理者。
27
需求风险
③ 模棱两可的需求。
模棱两可是需求规格说明中最为可怕的问 题 。
它的一层含义是指诸多读者对需求说明产 生了不同的理解 。
另一层含义是指单个读者能用不止一个方 式来解释某个需求说明 。
28
需求风险
③ 模棱两可的需求。
模棱两可的需求会使会使开发人员为错误 问题而浪费时间，并且使测试者与开发者 所期望的也不一致。 模棱两可的需求带来不可避免的后果便是 返工。
37
优秀需求说明的特征
② 完整性。
不能遗漏任何必要的需求信息。遗漏需求将 很难查出。
每一项需求都必须将所要实现的功能描述清 楚 。
开发人员可以从需求规格说明中获得设计和 实现这些功能所需的所有必要信息。
38
优秀需求说明的特征
③ 无二义性。
对所有需求说明的读者都只能有一个明确统一 的解释。
2
关于本课程
授课目标：通过这门课达到掌握如下的知识 和技能
了解需求工程在软件工程和系统工程中的重要地 位 了解需求工程的性质 了解和应用需求工程的概念，方法，过程和工具 理解掌握需求开发各阶段的技术 理解掌握需求管理的技术 学习需求工程领域当前最新研究成果和实践
3
课程提纲
软件需求工程概述 软件需求过程 需求获取 需求分析 需求规格说明 需求验证 需求管理 需求开发向设计规划的转化
软件需求规格说明 （software requirements specification 简称“SRS”）
在软件需求规格说明中说明的功能需求充分描 述了软件系统所应具有的外部行为。
软件需求规格说明在开发、测试、质量保证、 项目管理以及相关项目功能中都起了重要的作 用。
15
术语的定义
非功能需求
作为功能需求的补充，描述了系统展现给用户 的行为和执行的操作等。
26
需求风险
② 用户需求的不断扩展。
在开发中若不断地补充需求，项目就越变越庞大 以致超过其计划安排及预算范围 。 用户需求的扩展将带来过度的耗费和降低产品的 质量 。 要控制变更范围的不断扩展，必须一开始就对项 目视图、范围、目标、约束限制和成功标准给予 明确说明，并将此说明作为评价需求变更和新特 性的参照框架 。
指明必须实现什么样的规格说明。它描述 了系统的行为、特性或属性，是在开发过 程中对系统的约束 。
8
软件需求的定义
IEEE软件工程标准词汇表（1997年）中 定义需求为：
① 用户解决问题或达到目标所需的条件或 权能（Capability）。 ② 系统或系统部件要满足合同、标准、规 范或其它正式规定文档所需具有的条件 或权能。 ③ 一种反映上面①或②所描述的条件或权 能的文档说明。
用户需求文档描述了用户使用产品必须要完成 的任务，这在使用实例文档或方案脚本说明中 予以说明。
12
需求的层次
功能需求(functional requirement)
定义了开发人员必须实现的软件功能，使得用 户能完成他们的任务，从而满足了业务需求。
13
需求关系图
软件需求各组成Leabharlann 分之间的关系14术语的定义
尽量把每项需求用简洁明了的用户性的语言表 达出来。
避免二义性的有效方法包括对需求文档的正规 审查，编写测试用例，开发原型以及设计特定 的方案脚本。
39
优秀需求说明的特征
④ 必要性。
每一项需求都应把客户真正所需要的和最终系 统所需遵从的标准记录下来。
“必要性”也可以理解为每项需求都是用来授 权你编写文档的“根源” 。
需求是产品的根源，需求工作的优劣对产品 影响最大。就像一条河流，如果源头被污染 了，那么整条河流也就被污染了。 国内软件业的痼疾：人们并不清楚究竟该做 什么，但却一直忙碌不停地开发。
22
需求错误的代价
阶段
0.1-0.2 0.5 1 2 5 20
需求
设计
编码 单元测试 验收试验 保养维护
在生命周期的不同阶段修复缺陷的相对成本
• • • • • 频繁的需求变更； 遗漏的需求； 与用户交流不够； 质量低下的需求规格说明 不完善的需求分析
34
高质量的需求过程带来的好处
在开发后期和整个维护阶段的重做的工作大大减少了 。
让用户积极参与需求收集过程能使产品更富有吸引力，而 且能建立起更加忠实的客户关系 。 用户的参与能弥补用户期望和开发者实际开发之间的“鸿 沟”（期望差异）。 将确定的系统需求明确地分配到各软件子系统，确保软硬 件系统功能匹配适当。 有效的变更控制也能降低需求变更带来的负面影响 。 将需求编写成清晰、无二义性的文档将会极大地有利于系 统测试，确保产品质量 。
9
需求的层次
软件需求包括三个不同的层次。
业务需求 用户需求 功能需求 （包括非功能需求 ）
10
需求的层次
业务需求(business requirement)
反映了组织机构或客户对系统、产品高层次的 目标要求，它们在项目视图与范围文档中予以 说明。
11
需求的层次
用户需求(user requirement)
41
优秀需求说明的特征
⑥ 划分优先级。
给每项需求、特性或使用实例分配一个实施优 先级以指明它在特定产品中所占的分量。
不划分优先级，将导致项目管理者在开发或节 省预算或调度中就丧失控制自由度 。
42
优秀需求说明的特征
⑦ 可验证性。
检查一下每项需求是否能通过设计测试用例或 其它的验证方法，如用演示、检测等来确定产 品是否确实按需求实现了。 如果需求不可验证，则确定其实施是否正确就 成为主观臆断，而非客观分析了。
业务需求：“用户能有效地纠正文档中的拼写 错误” 。 用户需求：“找出文档中的拼写错误并通过一 个提供的替换项列表来供选择替换拼错的词”。 功能需求：
找到并高亮度提示错词的操作。 显示提供替换词的对话框 实现整个文档范围的替换
18
什么是需求
需求的基本概念
宽泛地讲，需求来源于用户的一些“需要”，这 些“需要”被分析、确认后形成完整的文档，该 文档详细说明了产品“必须或应当”做什么。 需求描述必须给出为什么需要这样一个系统，通 常，需求描述系统要做什么，而不是怎么做。
23
需求缺陷造成的成本增加
重新进行需求规格说明 重新设计 重新编码 重新测试 改变订单——告诉用户将以一个修正后的版本来替代有缺陷的版 本。 纠正活动——消除由于不准确的特定系统的错误造成的危害，可 能涉及到赔偿客户损失。 报废——包括对于已经完成的代码、设计和测试，当发现它们是 根据不正确的需求进行的时候，这些工作成果不得不被丢弃。 收回有缺陷的软件产品以及相关的用户手册。 产品赔偿或保修的成本。 重新安装新版本的成本。 重新建档的成本。
一份前后矛盾，不可行或有二义性的需求也是 不可验证的 。
43
Textbook / References
需求工程: Requirements Engineering: A Good Practice Guide. / (英) Ian Sommerville, Pete Sawyer.赵文耘，叶恩等译。机械工业出版社 需求分析与系统设计：Requirments Analysis and System Design:Developing Information System with UML./(澳)Leszek A Maciaszek.金芝 译。机械工业出版社 实用软件需求：Practical Software Requirments:A Manual of Content & Style./（美）Benjamin L.Kovitz.胡辉良，张罡 等译。机械 工业出版社 掌握需求过程（第2版）：Mastering the Requirments Process(Second Edition)./(英)Suzanne Robertson,James Robertson. 王海鹏译。人民邮电出版社