- 您的团队可以轻松浏览和理解
- 可供所有利益相关者审查
- 提供可追溯到其他文档的设施。
为什么实时可追溯性™是必要的
实时可追溯性是在整个产品开发周期中对需求的跟踪。它记录了正在进行的所有工作的状态，并显示了开发历史以及特定更改的影响。它的好处包括更容易遵守法规、团队更加同步以及发布质量更高。
2019 年，FDA 召回了 50 件医疗器械——这是自 2014 年以来最多的一次。除其他目的外，审计线索有助于加强产品开发控制，从而降低召回风险。
2010 年代召回的三大原因是设备设计缺陷、软件问题和生产流程缺陷。审计线索记录了这些问题是如何出现的。但审计线索往往是在事后组装的，没有实时可追溯性。信息可能来自许多离散文档，例如包含数百个过时条目的电子表格。相比之下，实时可追溯性在整个过程中发生，为数据关系添加了支持背景，并有助于更好的决策和未来规划。
实时可追溯性使以系统、可审计且增强信心的方式管理和应对变化成为可能。在我们的新信息图中，我们研究了实时可追溯性如何帮助团队建立审计线索。
现代产品开发需要实时可追溯性™
实施可追溯性软件的主要原因之一是简化法规遵从性。假设一家医疗设备制造商计划将一种新的联网设备推向美国市场。
美国食品药品监督管理局要求遵守有关电子记录和电子签名的法规，例如 FDA 21 CFR 第 11 部分。如果建立了具有完整版本历史记录的统一记录系统（即软件可追溯性解决方案），则创建详细的审计跟踪以遵守这些规则会更加简单。
现代可追溯性软件（如 Jama Connect）绘制了产品开发中的关系和相互依赖关系，允许在完整的历史背景下对风险和需求进行认真跟踪。实时协作还使地理上分散的团队在跟踪和追踪工作项目时保持一致。随着产品变得越来越复杂和由软件驱动，这种级别的可追溯性（可以查看谁进行了每次更改以及出于什么原因）变得尤为重要。
记录需求
一旦需求开始从您的引出过程中出现，就开始记录它们。
将它们写下来并以您的组织同意的任何格式收集它们。这可能是您公司设计的产品需求文档 (PRD)、政府规定的系统需求规范、供应商提供的需求管理 (RM) 工具（如 Jama Connect）、电子表格、数据库或您的整个团队可以访问的任何其他适当的存储库。
最重要的是需求文档……
模板非常有用，无论是对于整个规范还是单个需求。可靠的、经过实战考验的模板和标准化格式有助于提供清晰度和帮助导航。
确认需求
与所有利益相关者一起审查需求。确保需求清楚地表达了预期内容，并且各方对每个需求都有共同的理解。如果您发现需求中存在任何歧义，请对其进行修改。
您还应尽可能通过原型设计和测试来验证您的需求。现代原型设计工具可以快速轻松地创建规范的工作模型。然后，您可以使用该模型执行可行性、可用性和产品概念测试。
在确定单个需求后，让利益相关者签字同意。在最终审查期间对整个规范执行相同操作。
确定需求的优先级
大多数工程开发计划都会遇到意想不到的挑战。遇到意想不到的障碍。时间表延误。优先级发生变化。能够适应这些挑战和变化非常重要。
这就是为什么根据每个需求将如何影响您的发布目标和目的来确定需求的优先级至关重要。
许多产品经理会给功能贴上标签，例如“必须具备”、“非常想要”和“最好具备”等，以此确定功能的优先顺序。但对这些类别中的每个需求进行排序也很重要。这样做有两个原因。
首先是上市时间。时间表经常会延误。如果出现延误，您可能需要削减功能和需求以满足发布日期。您不希望您的团队首先实现最简单的需求，结果却发现没有足够的时间完成所有必备功能。
第二个原因是需求会不断发展。在实施过程中，您可能会发现新的需求。有些需求可能至关重要，并且在优先级上会取代现有需求。您需要知道这些新需求在您的优先顺序中处于什么位置。如果您不知道，那么不太重要的因素将决定首先实施哪些需求，这可能会对产品的成功产生不利影响。
常见的需求收集陷阱
对听到的内容做出假设
小心简单、宽泛的需求。不要假设您完全了解它们的含义。最重要的是，不要假设所有利益相关者都以相同的方式解释这些需求。
像“网站应该有一个博客”这样的宽泛陈述可能会掩盖大量潜在的假设。仔细研究此类需求。提出大量问题。帖子将如何显示？作者应该如何管理？评论、类别、标记如何？是否应该有 RSS 提要？……等等。
交叉检查您收到的答案。然后提出一组更具体、可验证的需求，每个人都可以同意。
关注如何而不是什么
需求解决两件事。第一是产品必须做什么（功能需求）。第二是产品如何工作的必要约束（非功能需求）。
需求不应解决产品如何完成其必须做的事情。换句话说，在非功能性需求的约束范围内，您的规范应尽可能与实现无关。
在需求获取过程中，尽量不要考虑如何实现产品。忘记工程师痴迷的最新技术、软件团队的日常工具以及您认为产品基线中缺少的任何功能。而是专注于利益相关者的需求。
首先倾听利益相关者的意见。然后收集、审查和完善您的需求。最后，完成所有这些工作后，找出基线中的差距，并确定哪些技术可以满足您的客户和利益相关者的真正需求。
与利益相关者的协商不足
系统工程师和产品经理在收集需求时犯的最大错误可能是未能充分咨询利益相关者。利益相关者协商有几个方面。
首先，与每个利益相关者群体进行深入交流（并跟进）以充分了解他们的需求至关重要。未能做到这一点是导致需求失败的主要原因之一。
第二个重要方面是透明度。每次采访、会议和调查后，都要清理笔记并分享。最简单的方法是通过所有团队成员都可以访问的现代 RM 工具。像 Jama Connect 这样的工具允许您将笔记附加到需求本身，以便进行可追溯性。这大大提高了流程速度并简化了审查任务。
该领域的第三个潜在陷阱是审查不足。一定要举行审查，让利益相关者可以审查需求、提供反馈、提出异议并捍卫自己的立场。让所有相关利益相关者参与的公开讨论有助于发现和纠正需求缺陷并达成共识。
最后，让所有利益相关者签署需求，承认他们理解这些需求，并且这些需求足以让他们完成工作。一定要让利益相关者清楚他或她的签名意味着什么。
敏捷开发的需求收集
敏捷的需求收集有什么不同？
首先，敏捷团队希望快速行动。因此，他们的需求管理解决方案必须满足开发人员对速度的需求。
透明度是另一个优先事项。需求文档必须不断更新、易于注释并提供清晰的可追溯性。
这两种需求使得 Word 文档和 Excel 电子表格成为敏捷团队的不良 RM 选择。它们的静态性质使它们更新繁琐且共享繁琐。这些缺点使得很难让每个人都快速访问最新配置并让他们保持一致。此外，文档和电子表格不提供注释和可追溯性的原生功能。
RM 产品（如 Jama Connect）可帮助敏捷团队简化需求收集并在整个 ALM 产品开发过程中实时协作管理需求。
您是否在敏捷开发环境中工作？下载我们的数据表，了解 Jama Connect 如何简化需求收集和管理。
0 Comments