浅谈需求捕获的来源和技术

需求捕获与软件需求的来源以及软件工程师如何收集它们有关。这是建立对软件需要解决的问题的理解的第一个阶段。它基本上是一种人工活动，是确定利益攸关方并在开发团队和客户之间建立关系的地方。它被称为“需求捕获”、“需求发现”和“需求获取”。

一个好的需求捕获过程的基本原则之一是在各个利益攸关方之间进行有效的沟通。在整个软件开发生命周期(软件开发生命周期)过程中，在不同的时间点与不同的利益攸关方进行这种交流。在开发开始之前，需求专家可能会形成这种沟通的渠道。他们必须在软件用户(和其他利益攸关方)的领域和软件工程师的技术世界之间进行协调。在不同抽象层面上的一组内部一致的模型促进了软件用户/利益攸关方和软件工程师之间的通信。

需求捕获的一个关键元素是告知项目范围。这包括提供被指定的软件的描述，以及它的目的和交付的优先级，以确保客户最重要的业务需求首先得到满足。这最大限度地减少了需求专家花费时间来引出那些不重要的需求，或者那些在软件交付时不再相关的需求的风险。另一方面，描述必须是可伸缩的和可扩展的，以接受第一个正式列表中没有表示的进一步需求，并与递归方法中预想的前一个需求兼容。

3.1需求来源

在典型的软件中，需求有许多来源，识别和评估所有潜在的来源是至关重要的。本主题旨在提高人们对软件需求的各种来源以及管理这些需求的框架的认识。主要内容如下:

目标。术语“目标”(有时称为“业务关注”或“关键成功因素”)指的是软件的总体、高层次的目标。目标提供了开发软件的动机，但通常是模糊的表述。软件工程师需要特别注意评估目标的价值(相对于优先级)和成本。可行性研究是一种成本相对较低的方法。

领域知识。软件工程师需要获得或拥有有关应用程序领域的可用知识。领域知识提供了背景，所有引出的需求知识必须在此基础上设置，以便理解它。在知识领域中模拟本体论方法是一个很好的实践。应该确定应用领域内相关概念之间的关系。

利益攸关方(见第2.2节，过程参与者)。许多软件被证明是不令人满意的，因为它强调了一组利益相关方的需求而牺牲了其他的利益相关方。因此，交付的软件很难使用，或者颠覆了客户组织的文化或政治结构。软件工程师需要识别、表示和管理许多不同类型的利益攸关方的“观点”。

业务规则。这些语句定义或约束业务本身的结构或行为的某些方面。“如果还有一些未支付的学费，学生就不能注册下学期的课程”这是一个商业规则的例子，它将成为大学课程注册软件的需求来源。

操作环境。需求将来自执行软件的环境。例如，这些可能是实时软件中的时间约束或操作环境中的性能约束。这些必须积极地寻求，因为它们会极大地影响软件的可行性和成本，并限制设计选择。

组织环境。通常需要软件来支持业务过程，对业务过程的选择可能受到组织的结构、文化和内部政治的制约。软件工程师需要对这些敏感，因为一般来说，新软件不应该强制在业务过程中进行计划外的变更。

3.2启发式技术

一旦确定了需求源，软件工程师就可以开始从它们中提取需求信息。请注意，需求很少是现成的。相反，软件工程师从这些信息中获取信息来制定需求。本主题集中于让人类利益攸关方表达需求相关信息的技术。这是一项非常困难的任务，软件工程师需要敏感地认识到这样一个事实，即(例如)用户可能难以描述他们的任务，可能会遗漏重要的信息，或者可能不愿意或不能合作。特别重要的是要明白，启发式抽取不是一种被动的活动，即使有合作的、善于表达的利益攸关方可用，软件工程师也必须努力工作来引出正确的信息。许多业务或技术需求都是默认的或尚未从最终用户获得的反馈。计划、验证和确认在需求捕获中的重要性怎么强调都不过分。有许多技术可以用于提取需求;最主要的是:

采访。采访利益攸关方是获得需求的“传统”方法。重要的是要了解访谈的优势和局限性以及应该如何进行。

场景。场景为引出用户需求提供了一种有价值的方法。它们允许软件工程师提出“如果”和“如何完成”的问题，从而为有关用户任务的问题提供框架。最常见的场景类型是用例描述。这里有一个主题4.2(概念建模)的链接，因为场景符号，例如用例图，在建模软件中很常见。

原型。对于澄清不明确的需求，该技术是一种有价值的工具。它们可以以与场景类似的方式进行操作，为用户提供一个环境，用户可以在其中更好地理解需要提供哪些信息。原型技术的范围很广——从屏幕设计的纸质模型到软件产品的beta测试版本——它们在需求捕获和需求验证方面的不同用途有很大的重叠(见6.2节，原型)。低保真度原型通常是为了避免利益相关方“锚定”在一个高质量原型的次要的、偶然的特征上，这些特征会以意想不到的方式限制设计的灵活性。

促进会议。这些会议的目的是试图达到一种总结性的效果，通过这种效果，一组人可以对他们的软件需求带来比单独工作更多的见解。他们可以集思广益，提炼那些通过评审难以表达出来的想法。另一个优点是冲突的需求很早就出现了，可以让利益攸关方识别这些需求发生的位置。当它工作得很好时，这种技术可能会导致比其他方法更丰富、更一致的需求集。然而,会议需要谨慎处理(因此需要主持人),以防止情况的关键能力的团队正在侵蚀组织忠诚,或在需求反映了一些直接的担忧(也许高级)人青睐的损害他人。

观察。在组织环境中软件环境的重要性导致了观察技术的适应，例如需求捕获的民族志。软件工程师通过将自己沉浸在环境中来学习用户任务，并观察用户如何通过相互交互以及软件工具和其他资源来执行他们的任务。这些技术相对昂贵，但也很有指导意义，因为它们说明了许多用户任务和业务过程太过微妙和复杂，以至于参与者很难描述它们。

用户故事。这种技术通常用于自适应方法中(参见软件工程模型和方法知识领域中的敏捷方法)，并引用了用客户术语表达的所需功能的简短、高层次的描述。典型的用户故事有这样的形式:“As A ， I want<目标/愿望>，则<效益>。一个用户故事应该包含足够的信息，以便开发人员能够对实现它所付出的努力做出合理的估计。这样做的目的是为了避免在项目中经常发生的一些浪费，在这些项目中，详细的需求在工作开始之前就被收集起来了，但是这些需求在工作开始之前就变得无效了。在实现用户故事之前，客户必须编写一个适当的验收过程，以确定用户故事的目标是否已经实现。

其他技术。还有一系列其他技术支持提取需求信息，从分析竞争对手的产品到应用数据挖掘技术，再到使用领域知识库或客户请求数据库。

原文标题：3.需求获取

文章出处：【微信公众号：汽车电子硬件设计】欢迎添加关注！文章转载请注明出处。

责任编辑：haq