需求文档示例
我想知道是否有人可以提供一些关于他们在需求文档中提供的信息，你如何构build它？ 我是有史以来第一次领导，我想确保我提供良好的文件，使项目成功。
任何模板/例子都会很棒。
一般的指导方针是把重点放在所要求的而不限制如何完成的方面。 有关政策决定的考虑以及有关实施和安全的具体问题，应在“ build议书”部分提到的“ 限制，问题和问题”部分及相关影响中加以澄清。
报告模板
执行摘要：
以决策者能够有效和高效地做出重要决定的forms，提供对需求调查结果的概述。
介绍：
介绍报告的主要部分以及参与要求收集的主要人员以及编写报告的技巧。 客户也是明确的。
背景：
描述为了让读者了解背景所需的任何信息，例如，谁发起了这个背景，为什么。
范围和目的：
描述拟议产品的范围和目的。
方法和仪器：
介绍用于收集信息的方法和技巧，如观察和调查。 应该提供逐步的描述。 介绍在此阶段使用的所有工具和工具，这些工具的副本应包含在附录中 。
限制，问题和问题：
精确规定问题，问题和问题。 阐明有关可实现性和依赖政策的决定的任何限制和问题，还描述了在需求收集（例如问卷，访谈协议或焦点小组协议）中使用的工具的可靠性和有效性的威胁。 列出“非要求”来区分你忘记的东西和你不需要的东西。 明确和细节是必要的，以使有用的答案。
结果：
说出结果; 清楚地列出所有确定的要求。 应该在适当的地方使用图表，图表和统计数据。
build议：
根据给定的局限性，问题和问题的结果，提出实现范围和目的的build议。
参考文献：
列出分析过程中审查或咨询的来源。
附录：
附加材料的澄清，扩展和信息的目的。
在这个答案更多的参考资料 。
这是一个有点深的问题，所以我不愿意给出一个简短的答案。 阅读一些描述不同方法的好书，比如描述基于场景的functiondevise的The Inmates Are The Asylum ，这是一个好主意。 另一种方法是使用高级用例，如编写有效用例所述 。
一些准则：
- 写下所需要的而不限制如何完成。
- 使每个要求成为一个单独的编号列表条目进行交叉引用。
- 将需求拆分成单独的项目，直到每个项目都是“primefaces”。
- 包括一个安全部分，并明确要求什么安全。
- 包括非function性需求部分，用于像性能和可用性这样的约束。
- 包括一个非要求部分列出的东西不是要求，所以你可以分辨出你忘了的东西和你不需要的东西之间的区别。
- 指定外部接口（对其他系统）以及用户界面要求。
在了解软件系统或组件的要求时，我发现重要的信息包括：
- 软件系统的上下文。
- 系统边界。 在更大的系统环境下，这些要求所描述的软件的范围是什么？ 这个软件需要与系统进行交互或交换数据的系统是什么？
- 顶级function。 简要的执行摘要说明系统做了什么或应该做什么。 给定一组更详细的要求，这组函数和属性的目的是什么？
- 接口。 如果用户与这个软件交互，他们是如何做到的？ 他们是否在命令行中使用参数运行它？ 有没有文字的用户界面？ 一个GUI？ 它如何与其他硬件和软件进行通信？ 是否需要使用某些物理接口（如RS-232或USB）？ 有光纤连接或以太网连接吗？ 除了硬件之外，在与其他系统进行通信时还需要什么特定的通信协议？
- 谁是用户？ 他们的特点，经验，知识，培训，对领域或类似系统的熟悉程度如何？ 不仅要考虑每日用户，还要考虑那些需要维护软件的人。 更新是由用户还是专业IT来pipe理？
- 需求文档的其余部分正在做什么假设？ 其他软件存在哪些依赖关系？ 如果同时构build多个系统的组件，是否有任何阻止其他组件启动或结束的function？ 是否有任何要求被阻止，直到其他组件提供function？
- 具体要求。
- function需求或系统必须提供的function。
- 非function性要求或质量属性。 系统必须如何performance的描述 例子包括可用性，容错性，性能，可移植性，可用性，安全性等。
- 其他types的要求和devise约束。 示例包括文档及其如何呈现给用户（例如，用户手册和/或内置的帮助和支持），configurationpipe理和托pipe以及许可或法律方面的问题。
“ 软件需求和更多关于软件需求”的作者Karl Wiegers也有一个名为Process Impact的网站。 虽然模板是出售的，你应该检查出好吃的部分，其中有5美元的名义总和的文件。
如果你有钱，我会推荐这两本书。 如果你不想要他们，也许你的公司可以购买并拥有他们，如果有公司的图书馆或类似的东西。 无论哪种方式，对于从事需求收集/分析工作的任何人来说，它们都是必读文章。
那么，任何东西都可能是一个需求文档。 任何描述Thing [tm]function的东西。 也许你想看看基于GUI的软件http://joelonsoftware.com/articles/fog0000000036.html 。
如果你正在寻找一个特定的标准，你可以看看IEEE 820-1998 – 软件需求标准。 有周围的模板等，如果你谷歌他们。 wiki上甚至还有一个基本模板： IEEE 830 – SRS模板
您可能也想看看IEEE的整个SWEBOK （软件工程知识体）。
我是有史以来第一次领导，我想确保我提供良好的文件，使项目成功。
在这种情况下，最好的办法是不要使需求文档镀金，而是使其可编辑。 它，需要是不错的，你，testing者和客户同意这个软件是什么，但没有更好的; 它需要足够的灵活性，一旦客户停止同意你的软件是什么，你可以适应。
当我编写需求规格说明时，我将重点放在满足市场需求或明确的客户要求上。 这通常是根据现有条件，现场stream程和环境来完成的。 例如;
-
X公司使用从货车出售和交付面包的雇员出售面包给超市。
-
目前正在使用纸质docker，并希望转移到电子系统。
-
他们希望这个系统能够inputSAP，这将自动保持账户的最新状态，并为客户生成所有必要的文件。
-
用户通常来自弱教育背景，没有计算机技能，这个系统必须非常容易使用和易于培训。
-
该系统必须比现有的纸张系统更快地在现场使用
-
硬件必须足够坚固，以在光线不足的恶劣环境下工作。 如IP76和背光屏幕。
-
系统的成本不得超过每用户5千美元
等等…
基本上，需求文档是需求分析的logging。 需求分析是对客户需求的详细调查。 我个人在这个阶段避免提供与潜在解决scheme相关的任何function信息，因为我喜欢保持需求和实施的独立性。 在更灵活的环境中，您可能会多次遍历需求和潜在的实现。
艾伦·库珀（Alan Cooper）曾经推荐过“囚犯正在逃避庇护” – 这本高级别的书籍旨在解释以用户为中心的devise对pipe理层和行政人员的重要性。
关于Face 3.0 by Alan Cooper是以用户为中心devise的从业者指南，是确保产品满足用户需求的绝佳指南。
我推荐用于生成需求文档的最佳资源是由Robertson＆Robertson掌握需求过程以及由Soren Lauesen提供的软件需求。 后者深入介绍了一些需求收集和捕获技术。
根据项目的性质（以及angular色），您可能需要考虑更轻量级的敏捷方法。 软件需求总是在其编写后发生变化，灵活的方法被devise用来认识到这一点，并将变化因素转化为软件开发过程 – 随着项目的进展产生非常精简的初始需求集合。 请查阅Kent Beck的“Extreme Programming Explained”了解更多关于这种风格的内容。
如果您已经完成了所有这些工作，并且只是在模板之后，那么两个最常用（或改编）的是IEEE标准（1220-1998）和国防部标准MIL-STD-498 。 其中MIL标准似乎（对我来说）提供最大的价值，以最小的开销 – 但仍然需要大量的努力，可能不会直接增加您的项目的价值。
Scott Ambler的“敏捷build模”网站有一些很好的样本。 一般来说，对敏捷要求也有很多简明实用的build议。
值得一看！
我认为你首先需要决定你可以使用什么stream程。 这可能取决于项目types，规模，时间表，最初的口头要求等等。一旦你决定了哪个过程（在与客户/原则/谁接触之后）就会得到关于该过程的几本书，你需要的东西以及如何去做。
例如，如果您采用敏捷stream程，您可能只需要几张简短的文章就可以了。 （这当然是最简单的）
但是，如果您采用更传统的瀑布式方法，则需要预先提供非常详细的要求，并且完全改变您的要求和计划阶段的方式。
要求文件描述了function要求（歌剧院的build设将列出座位容量，舞台大小，声音和照明需求等）和非function性要求（安全性，安全性，符合标准等），并列出要求假设和约束。
这个过程主要是项目的不同利益相关者的输出。
WBS词典中也列出了需求文件的信息，在项目章程/工作说明书中也find了高级别的要求。
第一段中提到的信息对于需求文档来说可能更为重要，因为它的名字暗示了必要性。
您可能想要学习IEC29148和相应的ISO12207 。 另一个黑客，如果你正在使用门，试试它的模板。 它们被组织为DXL脚本，并为您创build模块，包括从IEEE风格的SRS，SDD等到DoD490a，DoD498等的所有内容。另请尝试http://www.letu.edu/people/jaytevis/Software-工程/ MIL-STD-498 / MIL-STD-498-documentation.html获取更多文档。
