创建需求文档的正确方法是什么？
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
现在，我的主管正在使用错误跟踪软件为我创建需求文档 /规格。对我来说，这似乎是一个可怕的想法，所有的要求都在这些小门票上，我必须单击此愚蠢的Webform才能满足要求。什么是针对需求 /软件规格的理智软件解决方案？
需要明确的是，我正在构建这个具有很多功能的大型软件组件，并且在此错误跟踪软件中阐明了这些功能。
解决方案
我很惊讶到目前为止没有人建议使用 维基 用于跟踪要求。
我发现它几乎是完美的系统，因为：
- 它允许人们在要求上进行协作，并使这一方面高度可视化；
- 它使您能够随着项目的进行，可以轻松地保持最新需求；
- 如果“这不是我们同意”的争议，您可以随时进入历史；
- 大多数现代Wikis具有不错的格式功能，因此看起来几乎和Word Doc一样好。
- 您可以直接从要求直接链接到实际文档；
- 您永远不必担心人们在不同/过时的副本上工作；
- 就像设计/实施一样，要求开始被视为迭代过程。
- 如果需求开始变得非常大/复杂，则很容易将它们分成页面/主题。
- 大多数Wiki接受HTML，因此，如果您确实需要高级格式，则可以使用类似的工具 Windows Live Writer.
考虑到选择，这些天我几乎总是选择Wiki方法，与老式的Word文档相比，它确实很痛苦，或者试图将其全部塞入错误跟踪器中。
其他提示
我始终将IEEE STD 830-1998（IEEE推荐用于软件需求指定的实践）作为我的SRS文档的模板。看 http://standards.iee.org/reading/ieee/std_public/description/se/se/830-1998_desc.html
最终的SRS文档本身通常是一个openoffice.org文档，但通常有许多组成部分进入其中，包括电子表格和图表。
我通常将所有这些文档放在一个存储库中 修订控制系统, ，例如SVN或CVS。所有其他业务分析师，设计师，开发人员，测试人员，项目经理以及 客户 可以访问此存储库，因此他们可以阅读并进行编辑。
请记住，SRS是一个活生生的文件。它将继续改变和增长一段时间。对于所有利益相关者而言，不仅可以访问SRS，而且具有完整的变更历史以及在必要时也可以回滚这些更改的能力也很重要。因此，修订控制系统可为此目的效果很好。祝你好运！
使用错误跟踪器进行需求管理具有 隐藏缺乏协作的趋势 和公司内部的沟通。
没有对任何特定方法的判断：
- 如果要使用瀑布，则需要结构良好，准确，多页文档（很多人通常将其作为错误描述键入）。如果营销/销售人员（启动要求的人）与工程人员的合作不佳，那么这些文件也无法以不错的质量编写和维护。
- 如果您要使用一种敏捷方法，那么一个要求的单位是用户故事，以故事卡为代表。卡本身不是必需的，而只是对话的起点。
我过去的一位雇主使用错误跟踪器的（简短）经历是，它使许多人成为完全停止完全交流的非常简单的方法。人们会简单地写一个愿望，将其丢入错误跟踪器中，并假设它最终会实现。
当然，他们这样做了：
- 他们自己的资格
- 他们在项目中的股份
- 与其他要求冲突
- 需求差距
- 费用
- 任何技术考虑
- 等等
我认为，出于以下原因，“单词”文档是错误的选择方法：
- 无法“差”两个文档来查看发生了什么变化。
- 用户界面在整个过程中都使用一致的样式灰心。是的，可以使用样式，但是由于困难，大多数人都不会被打扰。
- 文档格式实质上是隐藏的。当然，有一个针对OLE文件的规格，我猜是“ word”文档，但是微软将所有有用的东西都埋在了大量的blath下，所以没人知道。迟早，您的闪亮，新的“单词”不会打开文档。
- 与其他格式的玩法不佳。也就是说，除非您使用Windows和IE，否则如果有人在HTML文件中组织了一个带有“ Word”格式文件的链接的项目文档，那么您就会失去运气。单击错误的链接，您必须坐在长期的下载和启动期间，打断思想流。从“单词”文档到他人的超链接可能会或可能不起作用。
- “ Word”基本上是用于撰写旨在出现在纸上的文档。一个令人钦佩的目标，但对于在线观看而言，它的目标不大。
我没有经验的替代建议，但是我考虑过Python的重组文本或降价作为替代方案。
我们通常使用单词，但实际上，您如何在软件中创建它们不如您收集数据来创建数据以及收集信息的人是否已经知道何时过于复杂，并且会比贵得多，远不及更简单的要求却没有为任何人添加实际价值（例如，当他们希望始终以无需跳过的情况下分配ID号时）或与现有要求或其他计划中的功能冲突时。通常，实际用户永远不会与之交谈，当他们的经理不了解绝对必须完成的事情，而不是在软件的新版本中，就会出现很多惊喜。
我们还可以使用各种PDF，Excel或Visio文件。这些项目的所有内容都是从SharePoint中收集和编辑的，因此，如果需要，我们可以看到较早的版本。
我维护包含的产品积压（每个项目或产品） 用户故事. 。它们可以像您使用的那样存储在错误跟踪软件中。我的人使用 Excel 对于积压和 trac 对于Sprint积压（您可能使用该工具）。
仅在需要时，我创建一个 Word文档 用更多详细信息描述用户故事，并将其附加到用户故事中。但是我试图通过将用户故事分为较小的故事来避免这种情况。
小型用户故事更容易管理（包括估计）
我喜欢文字文档，因为它允许我放置链接，格式化文本，放置表，屏幕截图等，每个人都可以阅读它。
当然，在估算会话和Sprint计划中详细说明了每个用户的故事，当开发人员决定处理它时，我总是会出现更多问题。使用Sprint评论的频繁反馈可以阻止开发人员做的事情与产品所有者的要求不同。
就个人而言，过去我使用过Word文档，但决心将来找到一个工具来为我管理此工具...尤其是可以将错误设置为需求的能力，因为很多时候，错误是在要求中，不是规格与实施之间的偏差。
我甚至从来没有想到使用错误跟踪工具，但这完全有意义。
出于好奇，您不喜欢它是什么？
编辑：一个警告；告诉您的经理重新命名错误跟踪软件。否则，其中的所有内容都被认为是一个错误。我在上一个客户遇到了这个政治问题，在那里我将任务放在错误跟踪器中。不好。
我在6或7年前编写了一个要求数据库来处理这一点。每个需求记录都有一个简短的描述，一个“定义”备忘录和“注释”备忘录（既有文本，具有嵌入屏幕屏幕的能力等）。对于项目，可交付，序列编号，还有其他字段（可以从逻辑上订购），用用例/功能与时间估算相关的用法/功能，如果有人选择了它用于实现，等等
在设计功能时，还有一个“状态” - “输入”。 “批准”，一旦审查了一组要求并确定准备实施； “实施”是由程序员认为完成要求完成的，一旦QA Tech与程序员一致，则“已验证”。 （如果QA技术不同意，他可以将其设置回“批准”，以便程序员将其恢复。）要求也可以“推迟”，“拒绝”或“质疑”（这意味着变更控制委员会需要查看它）
做得很好的诀窍是合理的粒度。有时有一个句子要求有意义（例如“第12345期中描述的问题已固定”），但总的来说，要求应描述整个功能的所有重要方面（或一个大部分）。例如，典型的“新报告”功能将需要报告格式（输出的外观），并且对选项对话框的要求（解释字段，验证等）甚至可能有第三个有一个复杂的发电机来处理数据，而不仅仅是一个简单的查询或其他内容。此外，我们将为相应的帮助主题创建“帮助”要求。
将这些内容保存在数据库记录中而不是大文档中有很大的优势。多个程序员可以同时处理要求。单个记录被锁定，因此只有一个人可以一次编辑，但是可以在其他人进行编辑时打开和阅读。不过，最大的优点是，它可以轻松搜索要求的内容，并说明如何实施它们。我们现在有超过25,000个要求，我们可以在10秒钟内轻松地找到所有字段，定义或注释或其他内容的所有要求。 （尝试使用6年以上的Word文档进行尝试。）
我明白为什么人们可能会说在“错误跟踪器”中执行要求是一个坏主意，但我的猜测是因为工具很烂，不是因为在可搜索的数据库中保留需求是一个坏主意。
我曾经用过一次 http://www.pivotaltracker.com/ 但是在我目前的公司中，我们将.doc用作核心规范源，灯塔作为愿望清单和问题跟踪的组合功能。对我来说，当其他人非常习惯时，很难让其他人开始使用任何其他工具。
如果您可以遵循敏捷方法，以下链接可以指导您选择一个良好的敏捷项目管理工具：
认真地，尝试敏捷的方法 - 它在您所做的任何事情上都会讲简单，优雅，毫无意义，无爵士乐，常见的感官方法，以使每个团队成员都理解并欣赏其他所有成员的角色和努力。
祝你好运！
