编写软件需求规范

Question

关于编写规范，我有几个问题，它们是：

1. 当我们编写软件规范时，在“用户需求定义”主题下，我们必须只指定“函数”和“约束”？
2. “用户界面”属于“函数”还是“约束”？
3. 软件可以分为哪些主要的关键领域(需求)(例如UI )？

Answer 1

虽然我不太喜欢预先收集所有详细的需求(因为它们在一个非平凡的项目过程中会受到如此多的更改)，但是如果您正在编写需求文档，Volere需求规范模板是一个很好的指南。

虽然这对某些项目来说可能有些过分，但它提供了一个很好的考虑事项清单，即使只是在精神上检查一下这个需求不需要该项目的列表。

下面链接到有关模板的更多信息：

http://www.volere.co.uk/template.htm

模板本身(以及书籍掌握需求流程 --实际上比模板稍微便宜一些，包含了完整的模板文本)在各个章节中包含了很多关于每个部分应该做什么的信息、示例和建议。

以下是其中各节的摘要(引用自上面的链接)：

1. 项目的目的
2. 利益相关者
3. 法定限制
4. 命名公约和定义
5. 相关事实和假设
6. 工作范围
7. 业务数据模型与数据字典
8. 产品范围
9. 功能和数据需求
10. 外观和感觉要求
11. 可用性和人性化需求
12. 性能要求
13. 业务和环境要求
14. 可维护性和支持需求
15. 安保要求
16. 文化和政治要求
17. 法律要求
18. 未决问题
19. 下架解决方案
20. 新问题
21. 任务
22. 向新产品迁移
23. 风险
24. 成本
25. 用户文档和培训
26. 候诊室
27. 解决方案的思路

Answer 2

我建议阅读关于软件的Joel。我不确定它是否回答了你的具体问题，但他有一个出色的概述了编写功能规范意味着什么：

规范最重要的功能是设计程序。即使您独自编写代码，并且只为自己的利益编写规范，编写规范的行为--详细描述程序的工作方式--也会迫使您实际设计程序....when --你用一种人类语言设计你的产品，只需要几分钟的时间就能试着思考几种可能性，修改和改进你的设计。当他们删除文字处理器中的一个段落时，没有人感到难过。但是，当您用编程语言设计您的产品时，需要几周的时间才能进行迭代设计。更糟糕的是，一个只花了两周时间编写一些代码的程序员将非常依赖于这些代码，不管它是多么的错误....When你写了一个规范，你只需要沟通程序应该如何工作一次。队里的每个人都能读懂规范。QA人员读它是为了让他们知道程序应该如何工作，并且知道要测试什么。营销人员用它来写他们模糊的蒸汽软件白皮书，在网站上抛出关于尚未开发的产品的信息。业务开发部的人误解了它，以为它能治愈秃顶和疣之类的东西，这是一种奇怪的幻想，但它吸引了投资者，所以这没什么。开发人员阅读它是为了让他们知道该写什么代码。客户阅读它是为了确保开发人员正在构建他们想要付费的产品。技术作家们读了它，写了一本很好的手册.当您没有规范时，所有这些通信仍然会发生，因为它必须这样做，但它是临时发生的。QA人员胡乱地摆弄程序，当有些东西看起来很奇怪时，他们就会再一次打断程序员的话，问他们另一个愚蠢的问题，那就是这个东西应该如何工作……没有详细的规范，就不可能制定时间表.在太多的编程组织中，每次有设计辩论时，没有人能做出决定，通常是出于政治原因。所以程序员只做一些没有争议的事情。随着时间的推移，所有艰难的决定都被推到最后.编写规范是一个很好的方法来确定所有那些令人讨厌的设计决策，无论大小，如果你没有规范，这些决策就会被掩盖。

Answer 3

当我们编写软件规范时，在“用户需求定义”主题下，我们必须只指定“函数”和“约束”？

要求是两件事的结合..。

1. 这东西是干什么的。功能需求。
2. 它做得有多好。非功能性需求或“约束”

“用户界面”属于“函数”还是“约束”？

我想说的是，“用户界面”将是您在上一个问题中确定的需求类别。

软件可以分为哪些主要的关键领域(需求)(例如UI )？

这取决于软件。您可以根据系统的各个部分对需求进行分组，也可以根据用例或功能正在执行的业务需求对它们进行分组。

当然，所有这些都是次要的，因为您的实际目标是确定明确、明确和可测试的软件系统描述。