软件需求工程概要.ppt

1、2020/8/6，软件需求工程(SRE)，第二部分，软件需求开发，第16章，需求开发面临的特殊困难，王如龙，2/20，学习目标，学习本章后，你应该能够：了解需求开发面临的严峻现实和特殊问题；了解和理解各种项目需求开发问题，包括：维护项目、软件包解决方案、外包项目和意外项目；3/20、16.0其他类型项目的要求实践。一般来说，需求开发是针对一个新的软件或系统开发项目，这通常被称为零起点项目。然而，大多数组织专注于维护现有的遗留系统或构建现有商业产品的新版本，而其他组织可能将其开发工作外包给开发公司。这样的项目和需求是多种多样和不确定的。P198，4月20日，16.1维护项目要求。维护是指对当前正

2、在运行的项目的修改，有时称为连续工程或后续开发；维护经常消耗软件组织的大部分资源；维护任务主要是纠正错误、添加新的功能或报表、修改功能以满足新的业务规则。P198，5/20，16.1维护人员经常会遇到这种情况，很少有完整系统的文件遗留下来。虽然那些最初参与项目开发的人记得项目的一些关键信息，但他们可能很久以前就离开了公司。如何编制维修项目的需求是我们必须解决的问题。P198，6月20日，16.1维护项目要求。对于一个成熟的产品，下一个版本的SRS将基本上声明如下：“新系统可以完成旧系统的所有功能，但是新系统增加了新的功能并纠正了现有的缺陷。”然而，对我们来说，最终找到一个真正的SRS通常是困难

3、的。应该清楚的是，当版本升级时，应该为它准备一个全面的需求文档，以便项目中的所有涉众能够真正理解系统的操作。P198，7/20，16.1维护项目需求，如果没有准确的需求文档，维护人员必须用逆向工程的方法通过代码来理解系统，这就是所谓的“软件考古”。为了从逆向工程中获得最大的利益，“考古探险”应该记录通过需求和设计描述表所了解到的信息；然后积累关于当前系统某些部分的准确信息，以便项目团队能够更有效地完成未来的升级任务。p199，8月20日，16.1为了满足维护项目的需要，一种有效的技术是为添加的新屏幕绘制一个对话图，其中包括与现有屏幕元素之间的导航连接。其他有用的建模技术包括类图、交互图、数据流

4、图和实体关系图。关联图或用例图可以用来描述与系统交互的外部实体或执行者。填补信息空白的另一种方法是在向系统添加新数据元素或修改现有定义时创建数据字典条目。P199，9/20，16.2软件包解决方案要求，应明确指出，即使商业软件包是作为新项目的部分或全部解决方案购买的，也需要需求文档。一般来说，在商业软件产品能够在目标环境中正常运行之前，我们需要对其进行配置、定制、集成和扩展，这些活动也有需求。需求也可以用来评估候选人，以确定哪个软件包最符合我们的需求。P202，10/20，16.2，一个评价方法包括以下活动：确定需求的重要性，并用010来区分主要程度；评估每个候选软件包满足每个需求的程度；评估

5、每个软件包的非功能需求；评估产品成本、制造商的生存能力、制造商对产品的支持能力、外部接口能力、环境适应性、约束范围和约束条件。，P202，11/20，16.2软件包解决方案需求，采用以下方法来考虑需求定义：开发用例：如果我们计划购买现成的产品，没有必要指定详细的功能需求或设计用户界面，而是应该在用户需求层面上关注商业现场需求。用例是实现这个目标的好选择。通过用例分析差异是一种有效的方法。考虑业务规则：在需求探索之后，确定软件产品满足相关业务规则的能力。您应该知道软件包的配置能力，以满足企业政策、行业标准或政府规定。P203，12/20，16.2软件包解决方案的要求由以下方法定义：定义质量属性：

6、软件质量属性和性能目标是用户在选择软件包解决方案时需要考虑的另一个方面，至少应考虑以下属性。性能、易用性、灵活性、互操作性和完整性，P203，13/20，16.3外包项目需求，将产品开发承包给软件公司，需要准备高质量的需求文档，因为与开发团队的直接交互可能很少。图16.1需求是外包项目的基石。买方将向供应商提交一份需求文件和验收标准，供应商将把完成的软件产品和支持文件返还给买方。P204，14/20，16.3外包项目的要求。在上述这种模式的外包项目中，我们没有机会阐明日常需求，做出决策并改变它们，这在开发人员和客户紧密合作的项目中很容易完成。需求定义和管理不当是外包项目失败的常见原因。P204

7、，15/20，16.3外包项目的要求。在为外包项目准备需求文件时，有必要记住：提供细节；避免歧义；安排与承包商的联络点；定义双方都能接受的变更控制流程；为需求的多次迭代和评审预留时间；建立验收标准。意外项目的需求，其中许多属于成熟的问题领域，可能确实在早期阶段指定了许多预期的功能。对于这样的项目，提前指定具体的需求开发过程是有意义的。然而，在一些探索性或可变的项目中，预期的系统功能只是随着时间的推移而逐渐变得清晰。这种突发项目的特点是需求不确定，变化频繁。因此，应该采用迭代、增量和自适应的方法来解决需求开发和软件开发。P205，17/20，16.4对于意外项目的需求，要进行开发工作，我们必须首

8、先了解用户应该用这个软件完成什么任务。然而，快速变化的项目需求太不稳定，无法证明提前投资于许多需求开发工作是真正值得的。随着突然和快速变化的项目变得流行，各种敏捷开发方法已经出现，它们强调向用户快速交付可用的功能。P206，18/20，16.4紧急项目的需求，敏捷开发原则：人们认为软件变更是不可避免的，也是可取的。这种方法是为了不断发展系统，以响应客户反馈信息和改变业务需求。敏捷开发适应各种情况：这种方法适用于需求高度不确定的信息系统或互联网项目，但不适用于需求已经被很好理解的应用程序。P206，19/20，16.4为满足突发项目的需要，可采用以下方法。可以建立一个全职的现场客户，开发团队可以随时与他沟通；尽早并经常设定优先级；有效而简单的变更管理。P206，20/20，本章摘要，维护任务主要包括纠错、添加新功能或报表、修改功能以满足新的业务规则。如何编制维