问在规范中，我应该描述一个产品做什么(理想情况下)或者它应该/必须做什么吗？

EN

这种事件流程与我所处理的非常相似。然而，在术语上有一些差异，我认为这可能会导致一些问题。

客户提供的不是需求文档。它可能是视觉文件或行动构想(CONOPS)。这些文档可以显示系统的主要功能，但它们是从客户或用户的角度编写的，而且往往不像技术客户或用户那样具有技术性(尽管如果它们来自技术客户或用户)，或者与设计工程师或质量保证工程师执行其工作所需的一样明确。

通常，这些文档倾向于描述客户的系统目标--他们打算如何使用它，他们想要完成什么，等等，但在他们的业务语言中，使用业务术语和概念。这种类型的内容很可能不适合工程人员进行系统的构建和设计，因此需要对其进行转换。

工程师将获取客户的视觉文档或CONOPS (您称之为需求文档)的输入，并创建一个需求规格。这是对功能性和非功能性需求、质量标准、任何设计约束和用例的正式陈述，其方式可以为设计的其他部分所理解。实现和测试团队。不管客户输入的结构和格式如何，规范中记录的需求应该具有良好需求的特征：

• 每个需求都涉及一件事(衔接)。
• 每项要求在一个地点充分说明(已完成)
• 需求之间或需求与外部文档之间没有矛盾(一致)。
• 每个要求都不包含连词，例如“和”(原子)。
• 每个需求可以链接到一个或多个涉众的业务需求(可跟踪)
• 每项要求都不是过时的(当前)
• 每一个要求都是明确的，缩略词被定义，是客观的，避免消极的陈述(明确的)
• 每项要求都清楚地说明了其重要性。
• 每个需求的实现可以通过检查、演示、测试和/或分析(可验证)来确定。

本文档是产品的需求规范。它准确地说明了产品完成后必须能做什么。如果您有可选的需求，那么这些需求将明确地标识为可选的，并说明项目应该或可能做什么。这就是写要求作为“应”语句的想法的来源。可选要求将“应”改为“可”或“可”，“应”、“可”和“可”的含义应在文件中加以界定，以便设计者、实施者和测试人员了解每项要求的相对重要性。

通过精确定义产品的行为方式，您实际上是在为设计人员、测试人员和(在某种程度上)实现者提供指导。他们从一个系统开始，这个系统还没有完成所有的事情，并且被告知当它完成时，它将做什么。设计和实现可以(以各种方式)与本规范进行比较，以确保它完全符合客户的意图。

每个人都有自己的风格，在一天结束时，最好是“和带你来的人一起跳舞”，(按照付钱的人说的去做)。

话虽如此，我觉得这都是一个抽象层次和受众的问题。假设这是芯片设计。下面的答案同样适用于软件，并修改了具体的示例，以满足当今的词汇量和上下文。好的，回到抽象的层次。

在为系统设计人员和验证/测试工程师指定约束时，应该使用“必须”语句。因此，您可能在规范中看到以下内容：

SRAM缓冲器的吞吐量至少为每秒8 Mbit，必须使用与TSMC fab兼容的9 nm CMOS技术来实现。

说明书作者写到了设计的一部分，设计人员需要在设计中运用自己的工艺/创造力(缓冲区的吞吐量)，比那些没有回旋余地的制作过程中使用的更轻松。