创建需求文档的正确方法是什么？

现在，我的主管正在使用错误跟踪软件为我创建需求文档/规范。对我来说，这似乎是一个可怕的主意，所有要求都在这些小票上，我必须单击该愚蠢的网络表单才能了解这些要求。什么是针对需求/软件规格的理智的软件解决方案？

明确地说，我正在构建具有许多功能的大型软件组件，并且这些功能已在此BugTracking软件中阐明。

令我惊讶的是，到目前为止没有人推荐使用Wiki来跟踪需求。

我发现它几乎是一个完美的系统，因为：

• 它使人们可以在需求上进行协作，并使这一方面高度可见。
• 它使您可以随着项目的进行轻松地使需求保持最新。
• 如果发生“我们不同意”的争议，您可以随时查看历史记录；
• 大多数现代Wiki都具有不错的格式设置功能，因此其外观几乎与Word文档一样好。
• 您可以直接将需求中的链接直接链接到实际文档中；
• 您无需担心人们使用不同/过时的副本。
• 需求可以像设计/实现一样开始被视为迭代过程。
• 如果需求开始变得很大/很复杂，可以很容易地将它们分成页面/主题。
• 大多数Wiki接受HTML，因此，如果您确实需要高级格式设置，则可以使用Windows Live Writer之类的工具。

有了这些选择，这些天我几乎总是选择wiki方法，与老式的Word文档相比，或者试图将其全部塞入bug跟踪器中，这确实非常轻松。

我始终将IEEE Std 830-1998（IEEE软件要求规范推荐实践）用作SRS文档的模板。参见http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

最终的SRS文档本身通常是一个OpenOffice.org文档，但是其中通常包含许多组成部分，包括电子表格和图表。

我通常将所有这些文档放到一个版本库中，然后将其放入版本控制系统中，例如SVN或CVS。所有其他业务分析师，设计人员，开发人员，测试人员，项目经理和客户都可以访问此存储库，因此他们可以阅读并进行编辑。

请记住，SRS是一个不断发展的文档。它会继续变化并增长一段时间。对于所有利益相关者而言，访问SRS不仅很重要，而且拥有完整的变更历史记录以及必要时回滚这些变更的能力也很重要。因此，修订控制系统可以很好地实现此目的。祝好运！

使用错误跟踪器进行需求管理有一种趋势，那就是隐藏公司内部缺乏协作和沟通的趋势。

在不对任何特定方法做出判断的情况下：

• 如果要使用瀑布，则需要结构合理，准确，多页的文档（而不是很多人通常将其作为错误描述键入的段落）。如果营销/销售人员（提出要求）不能与工程人员一起很好地工作，那么也无法编写和保持这些文件的质量。
• 如果您要使用一种敏捷方法，那么一个需求单元就是一个由故事卡表示的用户故事。卡本身不是必需的，只是对话的起点。

我以前的一位雇主（使用错误跟踪器来满足要求）的（简短）经验是，它为许多人提供了一种完全停止交流的非常简单的方法。人们只是简单地写一个愿望，将其丢弃在bug跟踪器中，并假设它最终会实现。

当然他们这样做是不考虑：

• 他们自己的资格
• 他们在项目中的股份
• 与其他要求冲突
• 需求差距
• 费用
• 任何技术上的考虑
• 等等

我认为，“ Word”文档是错误的获取要求的方法，原因如下：

1. 无法“区别”两个文档以查看发生了什么变化。
2. 始终不鼓励用户使用一致的样式。是的，可以使用样式，但是由于困难，大多数人都不会被打扰。
3. 文件格式实质上是隐藏的。当然，有一个针对OLE文件的规范，我猜这是“ Word”文档，但是Microsoft却将所有有用的东西都埋在了很多废话之下，所以没人真正知道。迟早，您闪亮的新“单词”将无法打开文档。
4. 在其他格式下播放效果不佳。也就是说，除非您使用Windows和IE，否则如果有人用HTML文件中的“ Word”格式文件链接来组织项目的文档，那么您将很不走运。单击错误的链接，您将不得不经历漫长的下载和启动Word阶段，从而中断了思想流程。从“ Word”文档到其他文档的超链接可能有效，也可能无效。
5. “单词”基本上是用于写打算出现在纸上的文档。一项令人钦佩的目标，但对于在线观看而言却没有什么用。

我没有其他建议，但我已经考虑过将Python的重组Text或Markdown作为替代方案。

我们通常使用Word，但是实际上，如何在软件中创建它们并不比如何收集数据来创建它们以及收集信息的人是否足够了解需求何时变得过于复杂而昂贵得多，而成本却远不止于此。一个简单的需求却没有给任何人带来任何实际价值（例如，当他们希望始终按顺序分配ID号而又没有跳过任何ID时），或者当它与现有需求或其他计划中的功能发生冲突时。通常，实际用户从未与他们进行过交谈，当他们的经理不知道绝对必须做的事情并且新软件中没有这些内容时，会感到很多惊奇。

我们也可能使用各种pdf，Excel或Visio文件。项目中所有这些文件都是从SharePoint中收集和编辑的，因此如果需要，我们可以看到较早的版本。

我维护一个包含用户案例的产品积压订单（每个项目或产品一个）。它们可以像您所使用的一样存储在错误跟踪软件中。我个人将Excel用于待办事项，将Trac用于冲刺待办事项（您可能使用了类似该工具的工具）。

仅在需要时，我创建一个Word文档来描述用户故事，并提供更多详细信息，并将其附加到用户故事。但是我试图通过将用户故事分成较小的故事来避免这种情况。

小用户故事更易于管理（包括估算）

我喜欢Word文档，因为它允许我放置链接，设置文本格式，放置表格，屏幕截图等等，每个人都可以阅读。

当然，每个用户故事都会在估算会议和冲刺计划中得到详细说明，并且当开发人员决定使用它时，我总是会提出更多问题。使用sprint审核的频繁反馈会阻止开发人员执行与产品所有者要求不同的操作。

就个人而言，过去我曾使用过Word文档，但决心将来找到一个工具来为我管理此工具……尤其是能够根据需求设置错误，因为很多时候，错误是在要求中，而不是规格和实施之间的偏差。

我什至从未使用过错误跟踪工具，但这是完全有意义的。

出于好奇，您不喜欢它的原因是什么？

编辑：一个警告；告诉您的经理将错误跟踪软件更名。否则，其中的所有内容均假定为错误。我的上一个客户遇到了这个政治问题，我将任务放在错误跟踪器中。不好。

我在6或7年前写了一个需求数据库来处理这个问题。每个需求记录都有一个简短的描述，一个“定义”备忘录和一个“注释”备忘录（均为纯文本，具有嵌入屏幕截图的功能，等等）。还有其他字段，例如项目，可交付成果，序列号（因此可以按逻辑顺序排序），与之相关的用例/功能，时间估计，处理该字段的人员（如果有人选择了该字段进行实施），等等

在设计功能时，还有一个“状态”-“输入”。“已批准”，一旦对一组需求进行了审核并确定准备好实施，则设置“已批准”；一旦认为满足要求，程序员就将其设置为“已实现”；一旦质量检查人员与程序员达成协议，则将其设置为“已验证”。（如果QA技术不同意，他可以将其设置回“已批准”，以便程序员将其取回。）需求也可以“推迟”，“拒绝”或“有疑问”（这意味着变更控制委员会需要对其进行研究） ）

做到这一点的技巧是合理的粒度。有时只有一个句子的要求是有意义的（例如“问题12345中描述的问题已解决”），但总的来说，要求应描述整个功能（或很大一部分）的所有重要方面。例如，典型的“新报告”功能将要求报告格式（输出看起来像），并要求选项对话框（解释字段，验证等）。如果有一个复杂的生成器对数据进行处理，而不仅仅是简单的查询或其他操作。另外，我们将为相应的帮助主题创建一个“帮助”需求。

将这些内容保留在数据库记录中而不是大型文档中具有巨大的优势。多个程序员可以同时处理需求。单个记录被锁定，因此一次只能编辑一个人，但是可以在其他人编辑时打开和读取它们。但是，最大的优点是，它可以轻松搜索需求的文档以及有关如何实现需求的说明。现在我们有超过25,000个需求，并且我们可以在不到10秒的时间内轻松找到所有需求，包括所有字段中的特定单词，定义，注释或其他内容。（尝试使用6年以上的Word文档。）

我可以理解为什么人们可能会说在“错误跟踪器”中执行需求不是一个好主意，但是我的猜测是这是因为工具很烂，而不是因为将需求保存在可搜索的数据库中不是一个好主意。

我曾经使用过http://www.pivotaltracker.com/，但是在我目前的公司中，我们使用.doc作为核心规范源，使用Lighthouse作为组合功能的愿望清单和问题跟踪。对我来说，很难让团队中的其他人开始习惯使用其他任何工具。

如果您可以遵循敏捷方法论，那么以下链接可以指导您选择一个好的敏捷项目管理工具：

• 敏捷项目管理工具
• 各种敏捷项目管理工具的比较

认真尝试敏捷方法-在您做的任何事情中都倡导简单，优雅，胡说八道，毫不费力，爵士般的普通感官方法，以使每个团队成员都能理解并欣赏每个其他成员的作用和努力。

祝好运！