关于编写规范，我有几个问题，它们是：
在编写软件规范时，在“用户需求定义”主题下，我们仅需指定“功能”和“约束”？
“用户界面”属于“功能”还是“约束”？
软件可以细分的主要关键领域（要求）有哪些（例如UI）？
Answers:
尽管我不太喜欢预先详细收集所有需求（因为在一个不重要的项目过程中它们可能会发生很大的变化），但是如果您正在编写需求文档，那么Volere需求规范模板是一个很好的指南。
尽管对于某些项目来说可能有些过头，但它提供了很多要考虑的事项的清单，即使只是从精神上核对清单，您也不需要此项目。
这是有关模板的更多信息的链接：
http://www.volere.co.uk/template.htm
模板本身（以及精通需求过程的书，实际上比模板便宜一点，并且包含完整的模板文本）在各个部分中包含许多信息，示例和建议，涉及各个部分的内容。
这是其中各个部分的摘要（从以上链接中引用）：
项目目的
利益相关者
强制约束
命名约定和定义
相关事实和假设
工作范围
业务数据模型和数据字典
产品范围
功能和数据要求
外观要求
可用性和人性化要求
性能要求
操作和环境要求
可维护性和支持要求
安全要求
文化和政治要求
法律要求
开放式问题
现成的解决方案
新问题
任务
迁移到新产品
风险性
费用
用户文档和培训
等候室
解决方案的想法
我建议阅读有关软件的Joel。我不确定它是否能回答您的特定问题，但是他对编写功能规范的含义有很好的概述：
规范最重要的功能是设计程序。即使您自己一个人编写代码，也只是为了自己的利益编写规范，编写规范的行为（详细描述程序的工作方式）将迫使您实际设计程序。
...当您使用人类语言设计产品时，只需几分钟即可尝试考虑几种可能性，修改和改进您的设计。当他们在文字处理器中删除段落时，没有人会感到难过。但是，当您使用编程语言设计产品时，要花费数周的时间进行迭代设计。更糟糕的是，仅仅花了两周时间编写一些代码的程序员将非常依赖于该代码，无论它有多错误……
...编写规范时，您只需要交流一下程序应如何工作一次。团队中的每个人都可以阅读规范。质量检查人员会阅读它，以便他们知道该程序应如何工作并且知道要进行哪些测试。营销人员使用它编写模糊的蒸发器白皮书，以在网站上发布尚未创建的产品。业务开发人员误读了它，使人们对产品如何治愈秃头，疣和东西产生了奇怪的幻想，但是它吸引了投资者，所以可以。开发人员阅读它，以便他们知道编写什么代码。客户阅读了此书，以确保开发人员正在构建他们想要付费的产品。技术作家阅读并编写了不错的手册。
当您没有规范时，所有这些通信仍然会发生，因为它必须这样做，但是它是临时发生的。质量保证的人鬼混与程序慎之又慎，而当事情看起来很奇怪，他们去和中断程序员再次问他们另一个有关的事情应该如何工作愚蠢的问题...
没有详细的规范，就不可能制定时间表……在太多的编程组织中，每次进行设计辩论时，通常都没有人设法做出决定，通常是出于政治原因。因此，程序员只能处理毫无争议的内容。随着时间的流逝，所有艰难的决定都被推到了最后……编写规范是确定所有烦人的设计决策的好方法，无论您是否制定了规范，这些决策都会被掩盖。 ..
需求的主要要求是可测试的。如果您不知道如何测试需求，很有可能无法按照编写者的意图来实现它。
我从未见过仅限于功能和约束的需求文档，但我可以看到具有这样的结构会有一些价值-它迫使作者将需求归类为“软件需要做的事情”，并“规定了软件需要遵循。”
我认为用户界面在这两个类别中都有要求
限制条件：
功能：
Start按下键时，软件应建立与WOPR的TCP / IP连接”