软件设计ZhouSu第2章理解需求.ppt

软件体系结构与设计 第2章 理解需求 第2章 理解需求 需求工程 建立根基 导出需求 开发用例 构建需求模型 协商需求 确认需求 第2章 理解需求 正确理解需求是软件体系结构设计的必要条件，而理解问题的需求是软件工程师所面对的最困难的任务之一。在开始任何技术工作之前关注于一系列需求工程任务，有助于理解软件将如何影响业务、客户想要什么以及最终用户将如何和软件交互。 2.1 需求工程 需求工程（Requirement Engineering，RE）是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程发生在与客户沟通活动和为一般的软件过程定义的建模活动过程中，其任务是为设计和构建活动建立一个可靠坚固的基础，它必须适应过程、项目、产品和人员工作的需要。 2.1 需求工程 需求工程在设计和构造之间建立起联系的桥梁。有人可能认为这桥梁开始于项目的利益相关者（干系人，如项目经理、客户、最终用户），即在他们那里定义业务需求，刻画用户场景，描述功能和特性，识别项目约束条件；其他人可能会建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。但是，不管起始点在哪里，横跨这座桥梁将允许由软件团队检查将要进行的软件工作的内容；必须提交设计和构建的特定要求；完成指导工作顺序的优先级定义；以及将深切影响随后设计的信息、功能和行为。 2.1 需求工程 需求工程为以下工作提供了良好的机制：理解客户需要什么、分析要求、评估可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求以至将这些需求转化为可运行系统。需求工程过程通过执行七个不同的活动来实现：起始、导出、精化、协商、规格说明，确认和管理，其中起始、导出和精化属于项目的起始阶段。 2.1 需求工程 （1）起始 大多数项目都是当确定了商业要求或是发现了潜在的新市场、新服务时才开始。业务领域的干系人（如业务管理人员、市场人员、产品管理人员）定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。如果是开发一个基于计算机的系统，讨论将从系统工程开始，涉及关乎各领域的全局以及系统所在的领域活动。 2.1 需求工程 在项目起始阶段中，要建立起基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、项目干系人和开发人员之间达成初步交流合作的效果等。 2.1 需求工程 （2）导出 询问客户、用户和其他人，系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作。这些问题看似简单，但实现却很困难。 2.1 需求工程 下面这组问题有助于理解为什么导出需求这么困难： 范围问题：系统的边界不清楚，或是客户或用户的说明带有不必要的技术细节，这些细节可能会导致混淆系统的整体目标。 理解问题：客户或用户并不能完全确定需要什么，他们对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上存在问题，忽略了一些“明显的”信息，所确定的需求和其他客户或用户的实际需求相冲突，需求说明有歧义或不可测试。 易变问题：需求随时间变化。 为了帮助解决这些问题，需求工程师必须有组织地开展需求收集活动。 2.1 需求工程 （3）精化 在起始和导出阶段获得的信息将在精化阶段进行扩展和提炼。该任务集中于开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。 精化是由一系列的用户场景建模和求精任务驱动的。这些用户场景描述了如何让最终用户和其他参与者与系统进行交互。解析每个用户场景以便提取分析类——最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类所需要的服务。确定类之间的关联和协作关系，并完成各种补充图。 2.1 需求工程 （4）协商 虽然只给予了有限的业务资源，而客户和用户却提出了过高的要求，这是常有的事。另一个常见的现象是，不同的客户或用户提出了相互冲突的需求并坚持其重要性。 需求工程师必须通过协商过程来调解这些冲突。应该让客户、用户和其他利益相关者对各自的需求排序，然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突，删除、组合和（或）修改需求，以便参与各方均能达到一定的满意度。 2.1 需求工程 （5）规格说明 所谓“规格说明”对不同的人有不同的含义。一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。 在编制规格说明时保持灵活性有时是必要的。对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。而对于技术环节明确的较小产品或系统，使用场景可能就足够了。 2.1 需求工程 软件需求规格说明（SRS）是在项目商业化之前必须建立详细描述软件各个方面的