软件工程实训有必要吗_软件工程之需求工程

设计和编写软件富有挑战性、创造性和趣味性。事实上，编写软件是如此吸引人，以至于很多软件开发人员在清楚地了解用户需要什么之前就迫切地投入到编写工作中。开发人员认为:在编写的过程中事情总是会变得清晰;只有在检验了软件的早期版本后项目利益相关者才能够更好地理解要求;事情变化太快，以至于理解需求细节是在浪费时间;最终要做的是开发一个可运行的程序，其他都是次要的。构成这些论点的原因在于其中也包含了部分真实情况°，但是这中间的每个论点都存在一些小问题，汇集在一起就可能导致软件项目的失败。

需求工程(Requirement Engineering，RE)是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续到建模活动。它必须适用于过程、项目、产品和人员的需要。

需求工程在设计和构建之间建立起联系的桥梁。桥梁源自何处?有人可能认为源于项目利益相关者(如项目经理、客户、最终用户)，也就是在他们那里定义业务需求、刻画用户场景、描述功能和特性、识别项目约束条件。其他人可能会建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。但是不管起始点在哪里，横跨这座桥梁都将把我们带到项目之上更高的层次:允许由软件团队检查将要进行的软件工作的内容;必须提交设计和构建的特定要求;完成指导工作顺序的优先级定义;以及将深切影响随后设计的信息、功能和行为。

在过去的几十年，有很多技术变革影响着需求工程的过程。无处不在的计算使计算机技术能够与许多日常事务相结合。这些事务通过联网就能生成更多完整的用户信息，同时伴随着对隐私和安全问题的关注。

在电子市场广泛传播的应用引领了更多各式各样利益相关者的需求。利益相关者能定制产品，以满足一小部分最终用户特定的需求目标。当产品开发周期缩短时，流水线型需求工程会有压力，目的是推动产品更快进入市场。但是存在的根本问题仍然是如何及时获得精准稳定的利益相关者的输入信息。

需求工程包括七项明确的任务:起始，获取，细化，协商，规格说明，确认和管理。注意，这些需求工作中的一些任务会并行发生，并且要全部适应项目的要求。

起始。如何开始一个软件项目?有没有一个独立的事件能够成为新的基于计算机的系统或产品的催化剂?需求会随时间的流逝而发展吗?这些问题没有确定的答案。某些情况下，一次偶然的交谈就可能导致大量的软件工程工作。但是多数项目都是在确定了商业要求或是发现了潜在的新市场、新服务时才开始。业务领域的利益相关者(如业务管理人员、市场人员、产品管理人员)定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。所有这些信息都取决于变更，但是应该充分地与软件工程组织及时讨论。在项目起始阶段中R，要建立基本的理解，包括存在的问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。

获取。询问客户、用户和其他人:系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作。这些问题看上去是非常简单的，但实际上并非如此，而是非常困难。获取过程中最重要的是建立商业目标[Cle10]。我们的工作就是与利益相关者约定，鼓励他们诚实地分享目标。一旦抓住目标，就应该建立优先机制，并(为满足利益相关者的目标)建立潜在架构的合理性设计。

细化。在起始和获取阶段获得的信息将在细化阶段进行扩展和提炼。该任务的核心是开发一个精确的需求模型(第8～10章)，用以说明软件的功能、特征和信息的各个方面。细化是由一系列的用户场景建模和求精任务驱动的。这些用户场景描述了如何让最终用户和其他参与者与系统进行交互。解析每个用户场景以便提取分析类——最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类所需要的服务°，确定类之间的关联和协作关系，并完成各种补充图。

协商。业务资源有限，而客户和用户却提出了过高的要求，这是常有的事。另一个相当常见的现象是，不同的客户或用户提出了相互冲突的需求，并坚持“我们的特殊要求是至关重要的”。

需求工程师必须通过协商过程来调解这些冲突。应该让客户、用户和其他利益相关者对各自的需求排序，然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求的成本和风险，处理内部冲突，删除、组合或修改需求，以便参与各方均能达到一定的满意度。

规格说明。在基于计算机的系统(和软件)的环境下，术语规格说明对不同的人有不同的含义。规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。

有人建议应该开发一个“标准模板”并将之用于规格说明，他们认为这样将促使以一致的从而也更易于理解的方式来表示需求。然而，在开发规格说明时保持灵活性有时是必要的，对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。而对于技术环节明确的较小产品或系统，使用场景可能就足够了。

确认。在确认这一步将对需求工程的工作产品进行质量评估。需求确认要检查规格说明°以保证:已无歧义地说明了所有的系统需求;已检测出不一致性、疏忽和错误并予以纠正;工作产品符合为过程、项目和产品建立的标准。

正式的技术评审是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他利益相关者，他们检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步澄清的地方、丢失的信息、不一致性(这是建造大型产品或系统时遇到的主要问题)、冲突的需求或是不可实现的(不能达到的)需求。

为了说明发生在需求验证过程中的某些问题，要考虑两个看似无关紧要的需求:

·软件应该对用户友好。

·成功处理未授权数据库干扰的比率应该小于0.0001。

第一个需求对开发者而言概念太模糊，以至于不能测试或评估。什么是“用户友好”的精确含义?为了确认它，必须以某种方式使其量化。

第二个需求是一个量化元素(“小于0.0001”)，但干扰测试会很困难且很费时。这种级别的安全真的能保证应用系统吗?其他附加的与安全相关的需求(例如密码保护、特定的握手协议)能代替指明的定量需求吗?

需求管理。对于基于计算机的系统，其需求会变更，而且变更的要求贯穿于系统的整个生命周期。需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动°。这类活动中的大部分和第21章中讨论的软件配置管理(SCM)技术是相同的。