软件需求工程概要PPT课件

2020/4/30,软件需求工程SoftwareRequirementsEngineering(SRE)第二部分软件需求开发第十六章需求开发面临特殊难题,王如龙,2/20,学习目标,在学完本章内容之后，你应该能够：了解需求开发所面临的严峻现实与特殊难题；认识和理解各类项目需求开发问题，包括：维护项目，软件包解决方案，外包项目，突发型项目；,3/20,16.0其他类型项目的需求实践,一般来说，所述的需求开发，是针对一个新软件或系统开发项目情况，多称为零起点项目。然而，大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版本，还有其他一些组织可能将开发工作外包给开发公司。这样一些项目以及需求变化多且不确定。,P198,4/20,16.1维护项目的需求,维护是指对当前运行的项目进行修改，有时也称为继续工程或后续开发；维护工作经常会耗用软件组织的大部分资源；维护的任务主要是纠错、添加新的功能或报表，以及对功能进行修改以便满足新的业务规则。,P198,5/20,16.1维护项目的需求,维护人员往往会遇到这种情况，几乎没有什么遗留系统完备的文档，那些最初参与项目开发的人员虽然记得项目的一些关键信息，但他们可能早就离开了公司。如何编写正在维护中的项目的需求是我们必须解决的问题。,P198,6/20,16.1维护项目的需求,对于一个成熟的产品，其下一版本的SRS基本上会这样陈述：“新系统能够完成旧系统的所有功能，只是新系统添加了新功能并修正了存在的Bug”。然而，通常我们最终却很难找到一份真正SRS，应该明确，当版本升级时，应该为其编写一个全面的需求文档，这样项目的所有涉众才能真正理解系统的运作情况。,P198,7/20,16.1维护项目的需求,如果缺少精确需求文档，维护人员就必须采用逆向工程得方法，通过代码来理解系统，这就是所谓的“软件考古学”。为了能够从逆向工程中获取最大的收益，“考古探险队”应该将通过需求和设计描述表中所了解的信息记录下来；然后将有关当前系统某些部分的精确信息积累起来，这样项目团队才能够更有效地完成未来的升级任务。,P199,8/20,16.1维护项目的需求,一种行之有效的技术是为添加的新屏幕绘制一副对话图，图中包括到已有屏幕元素和来自屏幕元素的导航连接。其他一些有用的建模技术还包括类图、交互图、数据流图和实体关系图，可以采用关联图或用例图来描绘与系统交互的外部实体或执行者。填补信息空白的另一种方法是，当往系统中添加新的数据元素或对已有的定义进行修改时，创建数据字典条目。,P199,9/20,16.2软件包解决方案需求,应该明确，即使是购买商用软件包作为一个新项目的部分和全部解决方案，也需要需求文档。一般情况下，我们需要对商用软件产品进行配置、定制、集成和扩展之后，才能在目标环境中正常运行它，这些活动也要有需求。需求也可以用来评估候选方案，以确定哪种软件包最能满足我们的需要。,P202,10/20,16.2软件包解决方案的需求,一种评估方法包括如下一些活动：确定需求的重要程度，并用010来对主要程度进行区分；就每个候选软件包满足每一条需求的程度进行评价；评估每个软件包的非功能需求；评估产品费用、厂商的生存能力、厂商对产品的支持能力、外部接口能力、环境的适应能力、约束范围和限制条件。,P202,11/20,16.2软件包解决方案的需求,采用如下方法来考虑需求定义：开发用例：如果我们计划购买现成产品，没有必要指定详细的功能需求或设计用户界面，应该将精力集中在用户需求这一级别的商用现货需求上。用例就是能够达到此目标的一个很好选择。通过用例进行差异分析是一种有效的方法。考虑业务规则：经过需求探索，来确定软件产品能够满足相关业务规则的能力。应该了解软件包的配置能力，以满足企业企业策略、业界标准或政府规则。,P203,12/20,16.2软件包解决方案的需求,采用如下方法来考虑需求定义：定义质量属性：软件质量属性和性能目标是选择包解决方案时所要考虑的用户需求的另一个方面，至少应该考虑如下几个属性。性能易用性灵活性互操作性完整性,P203,13/20,16.3外包项目的需求,将产品的开发承包给某个软件公司，需要准备高质量的需求文档，因为与开发团队的直接交互可能很少。,图16.1需求是外包项目的奠基石,需方将向供方提交一份需求文档和验收标准，供方则要向需方返回完成的软件产品和支持文档。,P204,14/20,16.3外包项目的需求,在上述这种模式的外包的项目中，我们没有机会进行日常的需求澄清、决策制定和更改，而这些在开发人员和客户紧密协作的项目中却很容易完成。定义和管理不当的需求是外包项目失败的常见原因。,P204,15/20,16.3外包项目的需求,对外包项目准备需求文档时，需要牢记：提供细节；避免二义性；安排与承包方的接触点；定义双方都能接受的变更控制过程；为需求的多次迭代和评审预留时间；制定验收标准。,P204,16/20,16.4突发型项目的需求,在许多项目中，多是属于成熟的问题域的项目，确实可能在早期阶段就指定许多预期的功能。对这样的项目来说，预先指定具体的需求开发过程是很有意义的。然而，在一些探索式或易变的项目中，预期的系统功能只有随着时间的推移才渐渐的明朗化。这种突发式项目的特征是需求不确定而且变更频繁，因此无论是需求开发还是软件开发，都要采用迭代式、增量式和适应式方法来解决。,P205,17/20,16.4突发型项目的需求,要进行开发工作，必须先理解用户要利用这一软件完成什么任务。然而，快速变化的项目需求太不稳定，以至于无法证明预先投资许多需求开发工作确实是值得的。由于突发型和快速变动的项目变得流行，所以产生了各种敏捷开发方法，这些方法强调将可用的功能快速地交付给用户。,P206,18/20,16.4突发型项目的需求,敏捷开发原理：在于认为软件变更既是不可避免的也是合乎需要的。这种方法是对系统不断进行演化，以便响应客户的反馈信息和变更业务需求。敏捷开发适应场合：这种方法和适应于需求高度不确定的信息系统或Internet项目，而不太适应于其需求已经很好地理解的应用程序。,P206,19/20,16.4突发型项目的需求,可以采用如下几种方法来解决项目需求设立一名专职的现场客户，开发团队随时与他交流；尽早地而且经常地设定优先级；有效的、简单的变更管理。,P206,20/20,本章小结,维护的任务主要是纠错、添加新的功能或报表，以及对功能进行修改以便满足新的业务规则。如何编写正在维