The Essential Guide toRequirements Management and Traceability

章节

优秀需求的特征

    如何区分优秀的软件需求和软件需求规范 (SRS) 与可能导致问题的软件需求和软件需求规范 (SRS)?在这篇文章中,我们将首先讨论单个需求应表现出的几个不同特征。然后,我们将研究成功的 SRS 整体上应具备的理想特征。


    有效需求的特征

    在理想情况下,每个单独的用户需求、业务需求和功能需求都会表现出以下部分中描述的特质。

    完整

    每个需求都必须完整描述要交付的功能。它必须包含开发人员设计和实现该功能所需的所有信息。如果您知道自己缺少某些信息,请使用 TBD(待定)作为标准标记来突出显示这些差距。在继续构建该部分之前,请解决需求每个部分中的所有 TBD。

    没有人说您需要在构建开始之前完成整个需求集。在大多数情况下,您永远无法实现该目标。但是,使用迭代或增量开发生命周期的项目应该对每次迭代都有一套完整的需求。

    使用最低限度的需求规范可能会让不同的人根据不同的假设和决定以不同的方式填写空白。将需求细节保持为口头而不是书面形式也使得业务分析师、开发人员和测试人员难以对需求集达成共识。

    正确

    每个需求都必须准确描述要构建的功能。

    正确性的参考是需求的来源,例如实际用户或高级系统需求。与其父系统需求相冲突的软件需求是不正确的。

    只有用户代表才能确定用户需求(例如用例)的正确性,这就是用户或其密切代理人必须审查需求的原因。

    可行

    必须能够在系统及其操作环境的已知功能和限制范围内实现每个需求。为避免指定无法实现的需求,请在整个引出过程中让开发人员与营销或 BA 合作。

    开发人员可以提供现实检查,了解哪些技术上可以做和不能做,哪些只能以过高的成本完成。增量开发方法和概念验证原型是评估需求可行性的方法。

    必要

    每个需求都应记录利益相关者真正需要的功能或符合外部系统要求或标准所需的功能。

    每项需求都应来自有权指定需求的来源。将每项需求追溯到特定的客户心声输入,例如用例、业务规则或其他价值来源。

    优先排序

    为每个功能需求、特性、用例或用户故事分配一个实施优先级,以表明它对特定产品版本的重要性。

    如果所有需求都被视为同等重要,项目经理就很难应对预算削减、计划超支、人员流失或开发过程中增加的新需求。优先级排序是成功迭代开发的关键。

    明确

    需求声明的所有读者都应该对其做出单一、一致的解释,但自然语言很容易产生歧义。用适合用户领域的简单、简洁、直白的语言编写需求。“可理解”是与“明确”相关的需求质量目标:读者必须能够理解每个需求的意思。在词汇表中定义所有专业术语和可能使读者感到困惑的术语。

    确保以简洁、明确的语言编写需求的一个好方法是使用需求模板,如 EARS 模型。

    可验证

    看看您是否可以设计一些测试或使用其他验证方法(例如检查或演示)来确定产品是否正确实施了每项要求。

    如果某项要求不可验证,则确定其是否正确实施就变成了个人意见,而不是客观分析。不完整、不一致、不可行或模棱两可的要求也是不可验证的。


    有效软件需求规范(SRS)的特点

    仅有出色的个别需求陈述是不够的。收集到软件需求规范 (SRS) 中的一系列需求应该具有以下部分中描述的特征。

    完整

    不应缺少任何需求或必要信息。缺失的需求很难发现,因为它们根本不存在!专注于用户任务而不是系统功能可以帮助您避免不完整。“我不知道有什么方法可以绝对确定您没有遗漏任何需求,”《软件需求》第三版的作者 Karl Weigers 说。“我的书中有一章提供了一些建议,告诉您如何查看自己是否忽略了重要的东西。”

    一致

    一致的软件需求不会与同类型的其他需求或更高级别的业务、系统或用户需求相冲突。在开发继续进行之前,必须解决需求之间的分歧。如果您发现一对相互冲突的需求,您可能不知道哪一个(如果有的话)是正确的,除非您进行一些研究。记录每个需求的发起者可以让您知道在发现软件需求规范中存在冲突时应该与谁联系。

    可修改

    您必须能够在必要时修改 SRS,并维护对每个需求所做更改的历史记录。这要求每个需求都应有唯一的标签,并与其他需求分开表达,以便您可以明确地引用它。

    每个需求在 SRS 中只应出现一次。仅更改重复需求的一个实例很容易产生不一致。考虑将后续实例交叉引用回原始语句,而不是重复需求。目录和索引将使 SRS 更易于修改。将需求存储在数据库或商业需求管理解决方案中可使它们成为可重用的对象。

    可跟踪

    可跟踪需求可以向后链接到其来源,向前链接到实现它的设计元素和源代码以及验证实现是否正确的测试用例。可跟踪需求使用持久唯一标识符进行唯一标记。它们以结构化、细粒度的方式编写,而不是编写长篇叙述段落。避免将多个需求集中到单个语句中;单个需求可能追溯到不同的设计和代码元素。


    如何知道您的需求和 SRS 是否具有这些属性?

    判断您的需求是否具有这些所需属性的最佳方法是让几个项目利益相关者仔细审查 SRS。不同的利益相关者会发现不同类型的问题。例如,分析师和开发人员无法准确判断完整性或正确性,而用户无法评估技术可行性。

    您永远无法创建一个所有需求都展示所有这些理想属性的 SRS。但是,如果您在编写和审查需求时牢记这些特征,您将生成更好的需求文档并构建更好的产品。

联系表单

这将关闭于 0