软件需求工程第二部分软件需求开发课件

软件需求工程

SoftwareRequirementsEngineering

(SRE)

第二部分

软件需求开发

第十七章

超越需求开发王如龙2022/12/2软件需求工程

SoftwareRequirements学习目标在学完本章内容之后，你应该能够：

了解做好从需求到项目规划转换的意义与方法；分析从需求到设计、编码、测试的关系与区别；掌握从需求到设计、编码、测试的过程控制原则与方法。

2/25学习目标在学完本章内容之后，你应该能够：2/2517.0做好需求转化的意义和作用一个软件开发项目最终可发行的是满足客户需求和期望的软件系统。需求是从产品概念通向用户满意之路的最本质的一步。把软件需求转化为健壮的设计和合理的项目规划是项目成功的基本保证。

3/2517.0做好需求转化的意义和作用一个软件开发项目最终可发17.0做好需求转化的意义和作用

软件开发人员与客户、用户对需求的理解不同、对系统的要求不同、甚至由于利益关系的不同，将影响转化工作的顺利进行。需求分析人员与软件设计和编码人员在对系统的理解角度、认识水平、掌握的技术，甚至在年龄、工作经历、和所处地位的差别，将影响转化工作的顺利进行。

4/2517.0做好需求转化的意义和作用软件开发人员与客户、用17.0做好需求转化的意义和作用基线需求项目计划设计和代码测试根据需求确定项目的规模根据产品规模进行评估当需求改变时更新计划使用需求优先级驱动迭代让开发人员评审需求根据质量属性决定体系结构设计将需求分配给各组件跟踪需求到设计和代码尽早开始测试设计用需求驱动系统测试让用户开发验收测试跟踪需求到测试图17-1需求推动项目规划、设计、编码和测试活动P209

5/2517.0做好需求转化的意义和作用基线项目计划设计和代码测17.1从需求到项目规划由于需求定义了项目预期的成果，所以项目规划、预测和进度安排都必须以软件需求为基础。但是，请大家牢记，最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。P210

6/2517.1从需求到项目规划由于需求定义了项目预期的成果，所17.1从需求到项目规划项目团队到底应该在需求工程中投入多少时间和精力，是一个必须解决的问题。对小型项目而言，团队在需求工程上所发费的故障量应该占项目的12％～15％。相当多的证据表明，花一些时间理解需求实际上可以加速项目的开发进度。P210

7/2517.1从需求到项目规划项目团队到底应该在需求工程中投入17.1从需求到项目规划欧洲的一份研究表明，产品开发较快的团队，与产品开发较慢的团队相比，在需求阶段所投入的时间和工作量更多一些。P210投入的工作量投入的时间开发较快的项目14％17％开发较慢的项目7％9％表17-1对需求工作的投入可以加速项目的开发

8/2517.1从需求到项目规划欧洲的一份研究表明，产品开发较快17.1从需求到项目规划需求和预估

可以根据文本需求、分析模型、原型或用户界面来估计软件产品的规模；虽然软件的规模没有规定的度量标准，但可以采用如下一些方法来进行度量：需求的数量；功能点和特性点的数量；图形用户界面（GUI）元素的数量、类型和复杂度；用于实现特定需求所需的源代码行数；对象类的数量或其他面向对象系统的衡量标准。P211

9/2517.1从需求到项目规划可以根据文本需求、分析模型、原17.1从需求到项目规划需求和进度安排

许多软件工程实行“从右到左的进度安排”，这种方式常常不能按时完成项目。在做出详细的规划和约定之前定义软件需求是更现实的。进度范围成本需求进度范围成本需求图17-2两种不同的进度安排P212

10/2517.1从需求到项目规划许多软件工程实行“从右到左的进17.1从需求到项目规划需求和进度安排对于复杂的系统，软件仅是最终产品的一部分时，只有在系统需求（产品级需求）产生以后，才能建立高层的进度安排。将系统需求分解并分配到各个不同的软硬件子系统中，有利于进度的安排和执行。必须根据市场需求、销售计划、客户服务要求以及产品开发计划等的为基础建立起一致的产品发行日期。P213

11/2517.1从需求到项目规划对于复杂的系统，软件仅是最终产17.1从需求到项目规划需求和进度安排正确的项目规划需要以下元素：根据对需求的清楚理解来估计产品规模的大小；根据历史记录了解开发小组的工作效率；需要一张综合的任务列表，以便完整地实现和验证每一特性或用例；相当稳定的需求；项目团队的经验。P213

12/2517.1从需求到项目规划正确的项目规划需要以下元素：17.2从需求到设计和编码

需求和设计之间存在差别，需求开发和规格说明应该强调对预期系统外部行为的理解和描述。必须让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。直接从需求规格说明跳到编码阶段，其可能的结果只能是结构性很差的一个软件。在构造软件之前，应该仔细考虑构造系统的最有效的方法。P213

13/2517.2从需求到设计和编码需求和设计之间存在差别，需求17.2从需求到设计和编码分析模型代表了用户和开发小组对正在解决的问题的理解，而设计模型则描绘了应该如何构造系统。如果在需求分析之后立刻进行编码，那么必定会出现代码重复。而且设计上的返工比编码返工可能要效率高一些。以需求为基础，反复设计将产生优良成果，用不同的方法进行设计可以精细化最初的概念。P213

14/2517.2从需求到设计和编码分析模型代表了用户和开发小组17.2从需求到设计和编码在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。

当项目难度很大、涉及的接口和交付复杂、开发人员经验不足时，最能体现设计规划的好处。P215

15/2517.2从需求到设计和编码在开始实现产品之前，虽然不需要17.2从需求到设计和编码如下的建议对所有的项目类型都有益：

为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变；明确需要创建的对象类或功能模块，定义他们的接口、职责以及与其他单元的协作；对并行处理系统，要理解计划执行的线程或对并发进程的功能分配；根据强内聚、松耦合和信息隐藏的设计原则，定义每个代码单元的预期功能；确保设计满足所有的功能需求，但不包括不必要的功能；确保设计能适应可能出现的异常条件；确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。P215

16/2517.2从需求到设计和编码如下的建议对所有的项目类型都有17.3从需求到测试测试和需求工程是一种相互促进的关系，好的需求工程可以生存更好的测试，好的测试分析可以生存更好的需求。需求是系统测试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。产品可以正确地展示基于代码的测试用例所描述的所有行为，但这并不意味着产品正确地实现了用户或功能性需求。应该让测试人员参与需求审查，这样可以确保需求是可以验证的并可以作为系统测试的基础。P216

17/2517.3从需求到测试测试和需求工程是一种相互促进的关系，17.3从需求到测试当每个需求都稳定之后，系统测试人员应该编写以测试用例为主的《测试计划》，通过测试、审查，演示或分析来验证需求。根据需求中的逻辑描述，利用诸如因果图等分析技术来获得测试用例，这将会揭示需求的二义性、遗漏或隐含的其它条件和其它问题。每个需求应至少由一个测试用例来测试。有经验的测试人员可以根据他们对产品的预期功能、用法、质量特性和特有行为的理解，概括出纯粹基于需求的测试。P216

18/2517.3从需求到测试当每个需求都稳定之后，系统测试人员17.3从需求到测试

基于SRS的测试适用于许多测试设计策略如动作驱动、数据驱动、逻辑驱动、事件驱动和状态驱动等。从正式的SRS中很容易自动生成测试用例，但是对于更多的由自然语言描述的SRS，必须手工开发测试用例。比起结构化分析图，对象模型更易于自动生成测试用例。P216

19/2517.3从需求到测试基于SRS的测试适用于许多测试设计17.3从需求到测试在开发的进展过程中，通过详细的软件功能需求仔细推敲来自使用实例的需求，并最终转化成单个代码模块的规格说明。针对需求的测试必须在软件结构的每一层进行，而不只是在用户层进行。即使有些模块功能在整个软件产品中对用户都不可见，但是每个模块功能必须满足其自身的需求或规格说明要求。因此，针对用户需求来测试系统是系统测试的必要但非充分条件。P217

20/2517.3从需求到测试在开发的进展过程中，通过详细的软件17.3从需求到成功如果不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图开发优秀产品的过程中将浪费大量的人力和物力。需求分析是项目成功的基础，软件开发的过程犹如盖房子，如果地基没有做好，那么房子盖完之后的第一件事就是拆房子，而不是测试房子。所以需求到成功的关键是要通过规划、软设计和测试不断确定需求的正确性。P217

21/2517.3从需求到成功如果不以高质量的需求作为项目规划、17.3从需求到成功正确把握需求开发的深度与广度，避免陷入畸形分析的陷阱，是需求开发必须注意的另一面；必须理解到，客户最关心的是结果，当需求开发组花费大量的时间创建不必要的文档、举行各种形式上的会议和评审，而并不解决任何实际问题时，会引起客户甚至设计人员的困惑和不满，最终导致项目被取消。努力在精确的规格说明与可将产品失败的风险降至可接受程度的编码之间做出明智的选择，是需求开发人员的必须掌握的基本功。P217

22/2517.3从需求到成功正确把握需求开发的深度与广度，避免本章小结由于需求定义了项目预期的成果，所以项目规划、预测和进度安排都必须以软件需求为基础。

软件项目可能经常不能达到预定的目标的主要原因不在技术上而在管理上。需求估算有多种方法，但都离不开经验的积累。需求和设计之间存在差别，需求开发和规格说明应该强调对预期系统外部行为的理解和描述。必须让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。必须针对SRS来测试整个软件，而不是针对设计或编码。把软件需求转化为健壮的设计和合理的项目规划是项目成功的基本保证。

23/25本章小结由于需求定义了项目预期的成果，所以项目规划、预测和第3次作业推荐读物

24/25第3次作业24/25需求的开发是需求成功的基本保证。关注与开发非功能需求比功能需求更重要。需求的获取、分析、编写和验证必须建立有效的过程和实用的模板。谢谢大家第二部分

软件需求开发结束体会

25/25需求的开发是需求成功的基本保证。第二部分软件需求开发结束软件需求工程

SoftwareRequirementsEngineering

(SRE)

第二部分

软件需求开发

第十七章

超越需求开发王如龙2022/12/2软件需求工程

SoftwareRequirements学习目标在学完本章内容之后，你应该能够：

了解做好从需求到项目规划转换的意义与方法；分析从需求到设计、编码、测试的关系与区别；掌握从需求到设计、编码、测试的过程控制原则与方法。

27/25学习目标在学完本章内容之后，你应该能够：2/2517.0做好需求转化的意义和作用一个软件开发项目最终可发行的是满足客户需求和期望的软件系统。需求是从产品概念通向用户满意之路的最本质的一步。把软件需求转化为健壮的设计和合理的项目规划是项目成功的基本保证。

28/2517.0做好需求转化的意义和作用一个软件开发项目最终可发17.0做好需求转化的意义和作用

软件开发人员与客户、用户对需求的理解不同、对系统的要求不同、甚至由于利益关系的不同，将影响转化工作的顺利进行。需求分析人员与软件设计和编码人员在对系统的理解角度、认识水平、掌握的技术，甚至在年龄、工作经历、和所处地位的差别，将影响转化工作的顺利进行。

29/2517.0做好需求转化的意义和作用软件开发人员与客户、用17.0做好需求转化的意义和作用基线需求项目计划设计和代码测试根据需求确定项目的规模根据产品规模进行评估当需求改变时更新计划使用需求优先级驱动迭代让开发人员评审需求根据质量属性决定体系结构设计将需求分配给各组件跟踪需求到设计和代码尽早开始测试设计用需求驱动系统测试让用户开发验收测试跟踪需求到测试图17-1需求推动项目规划、设计、编码和测试活动P209

30/2517.0做好需求转化的意义和作用基线项目计划设计和代码测17.1从需求到项目规划由于需求定义了项目预期的成果，所以项目规划、预测和进度安排都必须以软件需求为基础。但是，请大家牢记，最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。P210

31/2517.1从需求到项目规划由于需求定义了项目预期的成果，所17.1从需求到项目规划项目团队到底应该在需求工程中投入多少时间和精力，是一个必须解决的问题。对小型项目而言，团队在需求工程上所发费的故障量应该占项目的12％～15％。相当多的证据表明，花一些时间理解需求实际上可以加速项目的开发进度。P210

32/2517.1从需求到项目规划项目团队到底应该在需求工程中投入17.1从需求到项目规划欧洲的一份研究表明，产品开发较快的团队，与产品开发较慢的团队相比，在需求阶段所投入的时间和工作量更多一些。P210投入的工作量投入的时间开发较快的项目14％17％开发较慢的项目7％9％表17-1对需求工作的投入可以加速项目的开发

33/2517.1从需求到项目规划欧洲的一份研究表明，产品开发较快17.1从需求到项目规划需求和预估

可以根据文本需求、分析模型、原型或用户界面来估计软件产品的规模；虽然软件的规模没有规定的度量标准，但可以采用如下一些方法来进行度量：需求的数量；功能点和特性点的数量；图形用户界面（GUI）元素的数量、类型和复杂度；用于实现特定需求所需的源代码行数；对象类的数量或其他面向对象系统的衡量标准。P211

34/2517.1从需求到项目规划可以根据文本需求、分析模型、原17.1从需求到项目规划需求和进度安排

许多软件工程实行“从右到左的进度安排”，这种方式常常不能按时完成项目。在做出详细的规划和约定之前定义软件需求是更现实的。进度范围成本需求进度范围成本需求图17-2两种不同的进度安排P212

35/2517.1从需求到项目规划许多软件工程实行“从右到左的进17.1从需求到项目规划需求和进度安排对于复杂的系统，软件仅是最终产品的一部分时，只有在系统需求（产品级需求）产生以后，才能建立高层的进度安排。将系统需求分解并分配到各个不同的软硬件子系统中，有利于进度的安排和执行。必须根据市场需求、销售计划、客户服务要求以及产品开发计划等的为基础建立起一致的产品发行日期。P213

36/2517.1从需求到项目规划对于复杂的系统，软件仅是最终产17.1从需求到项目规划需求和进度安排正确的项目规划需要以下元素：根据对需求的清楚理解来估计产品规模的大小；根据历史记录了解开发小组的工作效率；需要一张综合的任务列表，以便完整地实现和验证每一特性或用例；相当稳定的需求；项目团队的经验。P213

37/2517.1从需求到项目规划正确的项目规划需要以下元素：17.2从需求到设计和编码

需求和设计之间存在差别，需求开发和规格说明应该强调对预期系统外部行为的理解和描述。必须让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。直接从需求规格说明跳到编码阶段，其可能的结果只能是结构性很差的一个软件。在构造软件之前，应该仔细考虑构造系统的最有效的方法。P213

38/2517.2从需求到设计和编码需求和设计之间存在差别，需求17.2从需求到设计和编码分析模型代表了用户和开发小组对正在解决的问题的理解，而设计模型则描绘了应该如何构造系统。如果在需求分析之后立刻进行编码，那么必定会出现代码重复。而且设计上的返工比编码返工可能要效率高一些。以需求为基础，反复设计将产生优良成果，用不同的方法进行设计可以精细化最初的概念。P213

39/2517.2从需求到设计和编码分析模型代表了用户和开发小组17.2从需求到设计和编码在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。

当项目难度很大、涉及的接口和交付复杂、开发人员经验不足时，最能体现设计规划的好处。P215

40/2517.2从需求到设计和编码在开始实现产品之前，虽然不需要17.2从需求到设计和编码如下的建议对所有的项目类型都有益：

为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变；明确需要创建的对象类或功能模块，定义他们的接口、职责以及与其他单元的协作；对并行处理系统，要理解计划执行的线程或对并发进程的功能分配；根据强内聚、松耦合和信息隐藏的设计原则，定义每个代码单元的预期功能；确保设计满足所有的功能需求，但不包括不必要的功能；确保设计能适应可能出现的异常条件；确保设计能达到所陈述的性能、健壮性、可靠性和其他一些质量属性的目标。P215

41/2517.2从需求到设计和编码如下的建议对所有的项目类型都有17.3从需求到测试测试和需求工程是一种相互促进的关系，好的需求工程可以生存更好的测试，好的测试分析可以生存更好的需求。需求是系统测试的基础，对产品的测试应该根据需求文档中所记录的产品的预期行为来进行，而不应该根据设计或编码来测试。产品可以正确地展示基于代码的测试用例所描述的所有行为，但这并不意味着产品正确地实现了用户或功能性需求。应该让测试人员参与需求审查，这样可以确保需求是可以验证的并可以作为系统测试的基础。P216

42/2517.3从需求到测试测试和需求工程是一种相互促进的关系，17.3从需求到测试当每个需求都稳定之后，系统测试人员应该编写以测试用例为主的《测试计划》，通过测试、审查，演示或分析来验证需求。根据需求中的逻辑描述，利用诸如因果图等分析技术来获得测试用例，这将会揭示需求的二义性、遗漏或隐含的其它条件和其它问题。每个需求应至少由一个测试用例来测试。有经验的测试人员可以根据他们对产品的预期功能、用法、质量特性和特有行为的理解，概括出纯粹基于需求的测试。P216

43/2517.3从需求到测试当每个需求都稳定之后，系统测试人员17.3从需求到测试

基于SRS的测试适用于许多测试设计策略如动作驱动、数据驱动、逻辑驱动、事件驱动和状态驱动等。从正式的SRS中很容易自动生成测试用例，但是对于更多的由自然语言描述的SRS，必须手工开发测试用例。比起结构化分析图，对象模型更易于自动生成测试用例。P216

44/2517.3从需求到测试基于SRS的测试适用于许多测试设计17.3从需求到测试在开发的进展过程中，通过详细的软件功能需求仔细推敲来自使用实例的需求，并最终转化成单个代码模块的规格说明。针对需求的测试必须在软件结构的每一层进行，而不只是在用户层进行。即使有些模块功能在整个软件产品中对用户都不可见，但是每个模块功能必须满足其自身的需求或规格说明要求。因此，针对用户需求来测试系统是系统测试的必要但