我的任务是为我们小组正在开始的项目制定要求和规范。
我意识到我不知道有什么区别。 Google搜索让我更加困惑-似乎有人说规范是必要条件，但水平较低。
#1 楼
正确的答案是，要求是程序应该做的事情，规范是您打算如何做。另一种查看方式是，需求从用户或整个企业的角度代表应用程序。该规范从技术团队的角度代表了应用程序。规格和要求大致传达了相同的信息，但是传达给了两个完全不同的受众。
评论
什么/如何咬人是正确的；但令人困惑，因为您还可以将程序的规范视为描述程序应执行的操作，而将设计视为程序应如何执行。另一个是声明性pl（例如prolog和SQL），在其中声明什么而不是方法。一种解决方案是它们是抽象的层次结构，父级说明什么，子级说明如何（外部与内部）。我更喜欢您的第二种观点，它更接近于“用途”与“用途”，即利益与功能。
– 13ren
2011-11-29 2:10
我通常会同意您的意见，但这只是“另一种”意见，而不是正确的答案。例如，在Wiki页面上查看需求（en.wikipedia.org/wiki/Requirement）。有非功能性需求，顾名思义是针对技术团队的。还是建筑和约束要求，同样是技术要求，但他们没有将其称为“规范”。我认为没有正确的答案，这将永远是公司与公司之间以及开发商与开发商之间的“模糊”。
–each
2011-11-29 17:54
看看下面的“亚当·维尔”答案，我认为这是对已发布问题的最准确陈述。
–each
11年11月29日在18:06
@Jeach：“贝洛” [原文如此]是相对的。目前可能在此帖子下方，但可能会移至上方，使您的评论难以理解
–布莱恩·奥克利（Bryan Oakley）
11年11月29日在18:39
另一个角度。Wikipedia将规范定义为“一组要求”。这意味着一个规范只能是1个要求，即s：= {r1}。口语化的“需求”似乎更多是“高级”要求，而“技术规格”则是低级要求，这是LOD的事情。
–兰斯·波拉德
15年2月16日在20:28
#2 楼
需求文档说明了需要什么-他们不应该指定方法，而是说明什么。规范说明如何实现需求-他们应该说明如何实现。
这些文档不是分开放置的，并且可以互换使用。
评论
在我公司，我们通常将术语“需求规范”用于内容（您指定，写下详细信息，内容什么），而将“设计规范”用于方式（您指定，写下详细信息，如何编写内容）计划实施）。
–乔治
2011年11月24日10:13
#3 楼
我是航空航天领域的系统工程师，在这两个术语中都广泛使用。这种区别很明显，并不像其他人那样复杂。规范是指定系统或产品的文档，例如F-14的主要项目开发规格。规范中有很多部分/内容：需求，定义，参考文档，词汇表，验证信息等。
需求是对产品或系统必须执行的操作的单一声明。一个规范可能有数百个要求。老派的方法学说，需求陈述必须使用“必须”一词，以将需求与事实陈述或定义分开。 （不确定那些刚开始使用敏捷的孩子是否遵守所有这些规定；挑剔的用法虽然有用，但有时有点麻烦。）
所以规范是一个充满要求的文档，另外其他一些支持和辅助信息。
评论
就像我在另一条评论中所说的那样，这对每个人都是非常模糊的，而且可能永远都是这样。但是基于我对这个确切主题的非常广泛的研究，我想说您的答案对我自己的发现/结论是最准确的。
–each
11年11月29日在18:04
始终对获得真正工程师的意见很有帮助。谢谢！
– LeWoody
2015年6月5日在16:28
另外，规范中可能有0个要求。对于非常具体的航空工程学科，您的示例是一个非常好的示例。我不确定它是否普遍适用于软件开发/编程领域。当大多数软件由业务需求驱动时，在评估技术约束和设计解决方案之前，先从详细的业务需求文档入手是有意义的。技术规范将遵循BRD，记录约束条件，并提供详细和特定的方法来满足BRD中的业务要求。
–小布莱恩（Bryan'BJ）
15年8月24日在6:16
@ Bryan'BJ'Hoffpauir我敢肯定，在某些情况下，文档带有标签说明，但没有要求，但我认为这是对术语的滥用。规范是需求文档-故事的结尾。它是航空航天和国防领域更多领域中广为接受的艺术术语，在系统工程（这是负责需求和验证的学科）之内也是不容置疑的。即使在您描述该术语适用的情况下：BRD是一种规范，技术规范听起来也很像，只是具有不同类型的要求。
–亚当·乌尔（Adam Wuerl）
15年8月25日在2:35
#4 楼
要求：
考虑到各个利益相关者可能相互矛盾的需求，确定满足新产品或变更产品的需求或条件。
规格：
它们提供了精确的要解决的问题的想法，以便他们可以有效地设计系统并估算设计替代方案的成本。它们为测试人员提供指导，以验证（鉴定）每项技术要求。
引文来自“系统工程基础知识*”。
要求基于利益相关者的需求，规格更多地是内部的详细的技术文件。它们是不同的，但是他们谈论的是同一件事。
*国防采购大学出版社，2001年。文本的PDF版本。
评论
我认为您的定义必须说明规范定义了问题，这一点很重要。这样，就需要一个问题规范。解决方案或设计规范是设计的一部分。
– LeWoody
2015年6月5日在16:28
#5 楼
要求是用户对成品在眼中应该做什么的描述。规范是解决方案的技术描述，涵盖了要求以及更多内容，例如。成本，技术性，问题等。
因此，主要要点之一是在编写规范之前，必须首先要求要求。
（请注意，术语-产品和解决方案-同一件事，但观点不同...）
评论
我将交换“产品”和“解决方案”这两个术语，因为解决方案通常是针对客户的问题，而产品通常是针对卖方（即技术实施者）。相似的对比是利益/功能，利益来自客户（对他们有什么用），功能取决于实现（实际上是什么，所以我们可以做到）。
– 13ren
11年11月29日在1:56
我明白你的意思，但我认为任何一个角度都足以说明情况。我认为客户会购买产品，就像您去商店时一样。然后，软件供应商将提供其针对根本问题的解决方案。如果我要出去购物以解决问题，我可能会想：“我需要一种能解决xyz问题的产品”，而不是“我需要解决abc问题的解决方案”。我认为这只是一个偏好问题。
– Arj
11年11月29日在10:33
有趣。建立产品类别后，我可以看到客户“正在寻找产品”。但是他们之所以寻求该产品，是因为他们已经解决了问题的解决方案，也就是说，他们寻求该产品的目的不是为了自己，而是作为解决方案。确实，供应商确实将其产品作为“解决方案”进行营销-但这是因为他们正试图与客户（他们寻求解决问题的方法）进行沟通，并构建所需的产品。实际构建产品（即事物本身及其功能与需要它们的原因无关）
– 13ren
2011年11月30日在2:23
在建立了既定的产品类别后，我可以看到客户“在寻找产品”-但是他们寻求将其作为解决他们所遇到的问题/需求的解决方案。供应商确实将其产品作为“解决方案”进行销售-因为他们正在与客户（需要解决方案的问题）进行沟通。在构建产品时（事物本身及其功能，而不是为什么要构建它们）。一个论点是，一个问题可以有非常不同的解决方案-但是产品是一件事。
– 13ren
2011年11月30日，下午2:33
[解释为什么有两个评论]：这样的评论太痛苦了-点击“返回”将提交评论，即使它是多行文本区域。而且，如果过了5分钟以上，它就不会接受修改。因此，您必须提交它作为第二条评论。我只是为了使其适合长度而进行编辑。叹。下次，我将首先发表两个评论……[无论如何，我同意观点-买方/卖方-是主要区别。我为您的术语感到困扰，但我想加深我的理解，以便阐明原因。]
– 13ren
2011-11-30 2:37
#6 楼
要求-系统或子系统应该（必须）做什么。规范-组件，子系统或系统是IS什么。
这对于医疗设备制造行业至关重要您必须根据您的要求（输入）进行验证，以证明您具有有效的规格（输出）。在这个行业中，典型的陷阱是：（1）公司忘记定义需求（因为他们不了解需求与规格之间的区别）； （2）仅根据规范进行验证，并且（3）不要确保将要求准确地转换为子装配体和组件规范。
完成所有这些操作后，您将需要验证用户产品的要求已得到满足。
#7 楼
规范是已经通过可行性并且可以实施的要求。它已经发展到设计阶段。
换句话说：
需求是“按计划”或“如意”的行为（或非行为）
规范是“要构建”或“已构建”的行为（或非行为）
示例：
要求：1.用户按下确定按钮2.系统打印发票
规范：1.用户按“确定”按钮2.系统打印发票
如您所见，两者的内容可以相同。区别在于需求是分析工件。该规范是设计工件。
在最终的竣工文档中，由于需求已转换为规格，因此通常会找到“规格”一词，而不是“需求”。
备注：由于设计约束，上面的示例包含设计元素。
#8 楼
也许是我听到的规范是业务需求规范文档或IEEE标准SRS（软件需求规范）文档引起的困惑。IEEE标准SRS模板示例
我也有
编辑：我只是注意到链接不正确，我会很快发布一个正确的链接。
评论
SRS条款的重点！
– LeWoody
2015年6月5日在16:30
现在，链接已完全断开。我不确定它指向什么，也不知道应该指向什么材料。
–user40980
2015年6月5日在16:35
#9 楼
要求是应用程序要做的事情规范是应用程序如何执行其工作。
它们必须正交！
产品经理写需求，总工程师写规格。
评论
我不确定至少在实践中它们是否完全正交。不幸的是有很多灰色。
– LeWoody
2015年6月5日在16:31
仅当您不使用修饰符时它们才是灰色的-业务需求，功能需求，非功能需求指的是系统的功能（它的作用）。技术规范与业务需求（如何执行）正交。
–小布莱恩（Bryan'BJ）
15年8月24日在6:08
#10 楼
一种查看它的方法，也许不是正确的方法：需求是可以为用户带来价值的事物（功能，功能，行为等）。不关心内部因素；在这里，只有盒子的输入和输出（可能还有大小，形状和颜色）很重要。
规范是使用户实现该价值的事物（能力，功能，行为等）。在此，盒子内部非常重要，因为它们与上面提到的外部接口和特性一起定义了整个系统。
评论
这只是您的意见，还是可以通过某种方式进行备份？
– gna
14年2月18日在10:40
@gnat，我以为在开场白中已经解决了？当然，这是从经验中得出的，我没有提出任何其他要求-根据我的收集，在一个相当主观的论坛上，这是一个有点主观的问题，这篇文章建议问题应尽可能客观，但很少提及答案。但是我有一个名字，你还有很多，所以我很愿意接受教育:-)
– Berad
14年2月19日在21:24
#11 楼
在我的研究中，我发现规格可用于专利和房屋建设（作为合同的一部分）。韦伯斯特无删节词典（第三版新国际版）的要求的定义是：
a）需要或需要的东西：必要性
b）需要或要求的东西：必要条件或必要条件：所需的质量，课程或培训种类
我认为以上内容明显不同。我想您可以称呼规范的较低级别的需求，但我认为这是对术语需求恕我直言的一种歪曲。
#12 楼
在先前创建商业产品的公司中，我们有以下区别：需求是系统必须要做的。它们可以是较低级别的详细要求，并且可以是功能性的或不起作用的。
规范是系统实际构建的那些功能。
例如您可能有一个要求，要求系统在–10°C下的行为为X。系统的实际规格可能是系统在–5°C下进行X；
在这种情况下，规格不符合要求。
#13 楼
想想，您将要在土地上建造高层建筑。现在您需要在开始之前考虑要求，例如：
建筑或设计工程师
土壤测试工程师
风压测试团队
除尘器
挖掘机
人力
供水
工人居住/休息区
足够的资金
项目管理
质量管理
安保和安全控制
等
现在以上内容已包含在其中建造高层建筑的要求。
从上述团队中，您可以获得技术成果，它们是专业人士的一部分。
这正是软件行业正在发生的事情，一组专业人士，负责提供知识以构建技术规范，例如从事UI设计，OO设计，数据库设计，图形设计，测试用例设计，编码，集成，部署团队等工作的人。
以上段落将是手册的一部分，您可以致电技术规范。
评论
我认为您在资源方面混淆了需求（en.wikipedia.org/wiki/Resource_%28project_management%29）。
–杰伊·埃尔斯顿（Jay Elston）
2012年11月16日，1：11
评论
我同意高票答案，但我也认为规范一词有时在软件行业中用作更通用的术语，指的是描述系统或软件的任何文档。作为证明-谷歌“需求规范”。当以这种方式使用它时，它表示指定某些内容的文档-即：指定对某个软件的要求。我不会判断这是否是该词的正确用法，我只是想指出，规范并不总是对每个人都具有相同的含义。是的，这就是为什么人们应该说“业务需求”和“设计规范” /“技术规范”之类的原因。单独的单词含糊不清。
这样想（粗略地说）：需求=需求文档和规范=用例/设计文档
您为什么不问您要为这些人服务的人？只有他们可以回答您特定情况下的需求。
本文提供了完整的答案：ece.cmu.edu/~koopman/des_s99/requirements_specs