需求工程介绍

引述
       构建一个软件系统最困难的部分是确定构建什么。其他工作不会像这部分工作一样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此困难。
                                                                                                     —— Fred Brooks

       设计和编写软件富有挑战性、创造性和趣味性。事实上，编写软件是如此吸引人，以至于很多软件开发人员在清楚地了解用户需要什么之前就迫切地投入到编写工作中。开发人员认为:在编写的过程中事情总是会变得清晰;只有在检验了软件的早期版本后项目利益相关者才能够更好地理解要求;事情变化太快，以至于理解需求细节是在浪费时间;最终要做的是开发一个可运行的程序，其他都是次要的。构成这些论点的原因在于其中也包含了部分真实情况θ，但是这中间的每个论点都存在一些小问题，汇集在一起就可能导致软件项目的失败。（θ对小项目(不超过一个月)和只涉及简单的软件工作的更小项目，这确实是正确的。但随着软件规模和复杂性的增加，这些论点就开始出问题了。）
       需求工程(Requirement Engineering，RE)是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续到建模活动。它必须适用于过程、项目、产品和人员的需要。

关键点
       需求工程为设计和构造奠定了坚实的基础。如果没有需求工程，那么实现的软件很有可能无法满足客户的需求。
 

建议
       可以在需求阶段做一些设计工作，在设计阶段做一些需求工作。

       需求工程在设计和构建之间建立起联系的桥梁。桥梁源自何处?有人可能认为源于项目利益相关者(如项目经理、客户、最终用户)，也就是在他们那里定义业务需求、刻画用户场景、描述功能和特性、识别项目约束条件。其他人可能会建议从宽泛的系统定义开始，此时软件只是更大的系
统范围中的一个构件。但是不管起始点在哪里，横跨这座桥梁都将把我们带到项目之上更高的层次:允许由软件团队检查将要进行的软件工作的内容;必须提交设计和构建的特定要求;完成指导工作顺序的优先级定义;以及将深切影响随后设计的信息、功能和行为。
        在过去的几十年，有很多技术变革影响着需求工程的过程[Wev11]。无处不在的计算使计算机技术能够与许多日常事务相结合。这些事务通过联网就能生成更多完整的用户信息，同时伴随着对隐私和安全问题的关注。在电子市场广泛传播的应用引领了更多各式各样利益相关者的需求。
       利益相关者能定制产品，以满足一小部分最终用户特定的需求目标。当产品开发周期缩短时，流水线型需求工程会有压力，目的是推动产品更快进入市场。但是存在的根本问题仍然是如何及时获得精准稳定的利益相关者的输入信息。
       需求工程包括七项明确的任务:起始，获取，细化，协商，规格说明，确认和管理。注意，这些需求工作中的一些任务会并行发生，并且要全部适应项目的要求。

引述
       大多数软件灾难的种子通常都是在软件项目开始的头三个月内种下的。
                                                                                                             ——   Caper Jones

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

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

信息栏      基于目标导向的需求工程

       目标是一个系统或产品必须达到的长期目的。目标可能涉及功能性或非功能性(例如可靠性、安全性、可用性等)内容。目标通常是向利益相关者解释需求的好方法，一旦建立了目标，就可以在利益相关者中处理冲突和矛盾。
       从目标中可以系统地推出目标模型和需求。展示目标之间各种链接的目标图，能提供一定程度的追踪性，从高层次的策略关注到低层次的技术细节。目标应该精确定义，并为需求的细化、验证与确认、冲突管理、协商、解释和发展提供服务基础。需求检测中的冲突通常是目标自身存在冲突的结果。通过一套相互商定的目标可获得冲突解决方案，这些目标与每个成员及利益相关者的渴求相一致。有关目标和需求工程更完备的讨论可以查找Lamsweweerde的论文[LaM01b]。

Christel和Kang[Cri92]指出了一系列问题，可以帮助我们理解为什么获取需求这么困难。范围问题发生在系统边界不清楚的情况下，或是客户和用户的说明带有不必要的技术细节，这些细节可能会导致混淆而不是澄清系统的整体目标。理解问题发生在客户和用户并不

       如果要开发一个基于计算机的系统，那么讨论将从系统工程过程开始。请访问www.mhhe.com/pressman获取更多系统工程的讨论详情。
      统一过程定义了更全面的“起始阶段”，包括起始、获取和细化工作。

提问
       为什么获得对客户需要的清晰理解会非常困难?

       完全确定需要什么的情况下，包括:对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上存在问题，忽略了那些他们认为是“明显的”信息，确定的需求和其他客户及用户的要求相冲突，需求说明有歧义或不可测试。易变问题发生在需求随时间推移而变更的情况下。为了帮助解决这些问题，需求工程师必须以有组织的方式开展需求收集活动。

建议
       细化是件好事，但你必须知道何时可以停止细化。关键是能采用为设计建立一个坚实基础的方式说明问题。如果超出这个点就是在做设计。

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

建议
     在有效的协商中没有赢家也没有输家，而是双赢。这是因为双方合作才是“交易”的坚实基础。

       协商。业务资源有限，而客户和用户却提出了过高的要求，这是常有的事。另一个相当常见的现象是，不同的客户或用户提出了相互冲突的需求，并坚持“我们的特殊要求是至关重要的”。需求工程师必须通过协商过程来调解这些冲突。应该让客户、用户和其他利益相关者对各自的需求排序，然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求的成本和风险，处理内部冲突，删除、组合或修改需求，以便参与各方均能达到一定的满意度。

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

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

关键点
       规格说明的形式和规格随着待开发软件的规模和复杂度的不同而变化。

        确认。在确认这一步将对需求工程的工作产品进行质量评估。需求确认要检查规格说明以保证:已无歧义地说明了所有的系统需求;已检测出不一致性、疏忽和错误并予以纠正;工作产品符合为过程、项目和产品建立的标准。
       正式的技术评审是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他利益相关者，他们检查系统规格说明，查容或解释上的错误，以及可能需要进一步澄清的地方、丢失的信息、不一致性(这是建造大型产品或系统时遇到的主要问题)、冲突的需求或是不可实现的(不能达到的)需求。
      为了说明发生在需求验证过程中的某些问题，要考虑两个看似无关紧要的需求:
        ●软件应该对用户友好。
        ●成功处理未授权数据库干扰的比率应该小于0.0001。
       第一个需求对开发者而言概念太模糊，以至于不能测试或评估。什么是“用户友好”的精确含义?为了确认它，必须以某种方式使其量化。
       第二个需求是一个量化元素(“小于0.0001”)，但干扰测试会很困难且很费时。这种级别的安全真的能保证应用系统吗?其他附加的与安全相关的需求(例如密码保护、特定的握手协议)能代替指明的定量需求吗?

       每个项目有不同的规格说明特性。在某些情况下，规格说明是指收集到的用户场景或其他一些事物。在另一些情况下，规格说明可以包括用户场景、模型和说明性文档。

建议
       需求确认时的一个重要问题是一致性。使用分析模型可以保证需求说明的一致性。

       Glinz[Gli09]写到质量需求要以恰当的方式表述，从而保证交付最优价值。这意味着要对不能满足利益相关者质量要求的交付系统进行风险(第26章)评估，并且试图以最小代价减轻风险。质量需求越关键，越需要采用量化术语来陈述。在某些情况下，常见质量需求可以使用定性技术进行验证(例如用户调查或检查表)。在其他情况下，质量需求可以使用定性和定量相结合的评估方式进行验证。

信息栏      需求确认检查单
     
通常，按照检查单上的一系列问题检查每项需求是非常有用的。这里列出其中部分可能会问到的问题:

• 需求说明清晰吗?有没有可能造成误解?
• 需求的来源(如人员、规则、文档)弄清了吗?
• 需求的最终说明是否已经根据或对照最初来源检查过?
• 需求是否用定量的术语界定?
• 其他哪些需求和此需求相关?
• 是否已经使用交叉索引矩阵或其他机制清楚地加以说明?
• 需求是否违背某个系统领域的约束?
• 需求是否可测试?
• 如果可以，能否说明检验需求的测试(有时称为确认准则)?
• 对已经创建的任何系统模型，需求是否可追溯?
• 对整体系统1产品目标，需求是否可追溯?
• 规格说明的构造方式是否有助于理解、轻松引用和翻译成更技术性的工作产品?
• 对已创建的规格说明是否建立了索引?
• 和系统性能、行为及运行特征相关的需求说明是否清楚?哪些需求是隐含出现的?

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

       正规的需求管理只适用于具有数百个可确认需求的大型项目。对于小项目，该需求工程工作可以适当裁剪，一定程度的不正规也是可以接受的。
       这里提到的工具只是此类工具的例子，并不代表本书支持采用这些工具。在大多数情况下，工具名被各自的开发者注册为商标。