编写需求文档是软件开发过程中非常重要的一步，它可以确保开发团队对软件的需求和功能有清晰的了解。以下是编写需求文档的一般步骤：
需要注意的是，不同的项目可能有不同的需求文档类型和格式要求。在实际编写过程中，应根据具体情况进行调整和适应。
需求开发的最终结果是客户和开发小组达成一致协议，该协议综合了业务需求 4、用户需求和软件功能需求。项目视图和范围文档包含业务需求，使用实例文档包含用户需求。必须编写从使用实例派生出的功能需求文档，以及产品的非功能需求文档，包括质量属性和外部接口需求。只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。
可以采用以下三种方法编写软件需求规格说明 5：
虽然形式化规格说明具有很强的严密性和精确度，但所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。因此，大多数软件工程中仍采用结构化的自然语言编写需求文档。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。
本文介绍了软件需求规格说明的目的和结构，包括一个建议性的文档模板。同时还提供了编写功能需求规格说明的原则，并附带讲述几个不完善的需求陈述以及改进建议的例子。本文并不深入介绍形式化需求方法；若要深入讨论形式化需求方法，可参考Alan Davis编著的《软件需求：对象、功能和说明》。
软件需求规格说明，也称为功能规格说明、需求协议和系统规格说明，精确描述了软件系统必须提供的功能和性能以及考虑的限制条件。它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。除了设计和实现上的限制，软件需求规格说明不应包含设计、构造、测试或工程管理的细节。
许多读者使用软件需求规格说明来达到不同的目的：
软件需求规格说明作为产品需求的最终成果必须具有综合性，必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。
在开始设计和构造之前编写出整个产品的软件需求规格说明是必要的。你可以反复地或以渐增方式编写需求规格说明，这取决于以下几个因素：是否可以一开始就确定所有的需求，编写软件需求规格说明的人是否将参与开发系统，计划发行的版本数量等等。然而，每个项目针对要实现的每个需求集合必须有一个基准协议，基准是指正在开发的软件需求规格说明向已通过评审的软件需求规格说明的过渡过程。必须通过项目中所定义的变更控制过程来更改基准软件需求规格说明。
所有的参与者必须根据已通过评审的需求来安排工作以避免不必要的返工和误解。例如，一个项目突然接到测试人员发出的错误灾难的报告。结果是他们测试的是老版本的软件需求规格说明，而他们觉得错误的地方正是产品所独有的特性。他们的测试工作是徒劳的，因为他们一直在老版本的软件需求规格说明中寻找错误的系统行为。
高质量需求文档所具有的特征包括：完整性、一致性、可更改性和可跟踪性。构造并编写软件需求规格说明，并使用户和其他读者能理解它。牢记以下可读性的建议：
为了确保软件需求规格说明的可跟踪性和可修改性，每个软件需求都必须具有唯一标识。这种唯一性使得在变更请求、版本控制、交叉引用或需求跟踪矩阵中能够快速准确地定位到特定的需求。由于单一项目列表难以满足这一要求，下面将介绍几种不同的需求标识方法，并分析各自的优缺点，以便您根据实际需要选择最合适的方案。
这是应用较为广泛的一种方法。例如，功能需求位于软件需求规格说明书第3.2部分，则可能被标记为3.2.4.3。数字层级越深，表明需求越具体和详细。该方法简洁明了，许多文档处理软件也能自动编排序号。然而，在大型或中型项目中，此类编号可能会变得非常冗长，并且不提供需求目的的直接信息。插入或移除需求时，会导致后续需求编号的调整，这可能导致其他地方对需求引用的失效。
改进的层次化编码法是在主要部分采用层次化编号，而在各部分中的单个功能需求则用简短的文字代码加序列号进行标识。例如，“第3.2.5部分—编辑功能”的需求编号可以表示为ED-1、ED-2等。这样既保持了层次性和组织性，又使得标识符简短、有意义且不受位置变化影响。
有时候，你可能会感觉到缺少某些特定需求的信息。在解决这个不确定性之前，可能需要与客户商讨、检查与其他系统的接口或者定义另一个需求。你可以使用“待确定”符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷。通过这种方法，你可以在软件需求规格说明中查找需要澄清的部分。记录谁将解决哪个问题、怎样解决以及何时解决。给每个待确定项编号并创建一个待确定列表，这有助于方便地跟踪每个项目。
在进行构造需求集合之前，必须解决所有的待确定问题，因为任何遗留下来的不确定问题都会增加出错的风险和需求返工的可能性。当开发人员遇到一个待确定问题或其他模糊之处时，他们可能不会返回到原始需求来解决它。他们多半会进行猜测，但并不总是正确的。如果有待确定问题尚未解决，而你又需要进行开发工作，那么尽可能推迟实现这些需求，或者解决这些需求的开放式问题，把产品的这部分设计得易于更改。
把用户界面的设计编入软件需求规格说明既有好处也有坏处。
消极方面，屏幕映像和用户界面机制是解决方案的描述，而不是需求。如果你在完成了用户界面的设计之后才能确定软件需求规格说明，那么需求开发 6的过程将会花费很长的时间。这将会使那些只关心需求开发时间的经理、客户或开发人员失去耐心。用户界面的布局不能替代定义功能需求。不要指望开发人员可以从屏幕中推断出潜在的功能和数据关系。把用户界面的设计加入软件需求规格说明还意味着开发人员在更改一个用户界面的元素时必须相应更改需求的过程。
积极方面，探索潜在的用户界面有助于你精化需求并使用户-系统的交互对用户和开发人员更具有实在性。用户界面的演示也有助于项目计划的制定和预测。根据以往类似开发活动的经验，你可以数清图形用户界面的元素数目或者计算与每个屏幕有关的功能点数目，然后估计实现这些屏幕功能所需的工作量。
一个合理的权衡点是：在软件需求规格说明中加入所选择的用户界面组件的概念映像草图，而在实现时并不一定要精确地遵循这些方法。通过使用另一种方式来表示需求，从而增强相互交流的能力，但并不增加对开发人员的限制，也不增加变更管理过程的负担。例如，一个复杂对话框的最初草案将描述支持需求部分的意图，但是一个有经验的设计者可以把它转化为一个功能点是对一个应用程序中用户可见功能的数量的测量，而与如何构造功能无关。你可以根据内部逻辑文件、外部接口文件以及外部输入、输出和请求的数量，从对用户需求的理解中估计功能点。带有标签组件的对话框或使用其它方法以提高其可用性。
软件需求规格说明（SRS，Software Requirements Specification）模板是开发过程中规范和明确软件产品功能、性能和其他非功能需求的重要文档。IEEE 830-1998标准提供了推荐的SRS结构框架，以下是对这个标准进行改写并扩展后的模板概述：
软件需求规格说明模板
a. 引言 - a.1 目的：明确指出软件需求规格说明的目的，定义所描述产品的软件需求版本及修订情况。如果仅涉及整个系统的一部分，则需指明文档针对的部分或子系统。 - a.2 文档约定：阐述撰写文档时采用的标准、格式规范，包括正文样式、提示符号等，并说明优先级 7是否继承等问题。 - a.3 预期的读者和阅读建议：列出不同类型的读者群体（如开发人员、项目经理、市场营销人员、用户、测试人员和文档编写者），概述文档结构，为每类读者提供适合的阅读建议。 - a.4 产品的范围：简要介绍指定软件及其目的，包括其价值和目标，并将其与企业战略 8或业务目标关联起来，可引用项目视图和范围文档而无需重复全部内容。 - a.5 参考文献：列举撰写SRS时引用的所有资料和资源，提供详细信息以便查阅，包括标题、作者、版本号、日期、出版单位或来源。
b. 综合描述 这部分对产品进行全面概览，涉及运行环境、用户特征、限制、假设和依赖性等内容。 - b.1 产品的前景：描绘产品背景、起源，说明产品是否属于系列升级、替代旧产品还是全新独立产品，以及与整体系统的关系及其接口。 - b.2 产品的功能：概括产品的主要功能特性，具体内容将在d部分详细说明，此处可采用列表形式粗略总结并使用图形表示主要需求分组之间的联系。 - b.3 用户类和特征：识别并描述可能使用该产品的不同用户类别及其特点，区分重要用户类和次要用户类。 - b.4 运行环境：描述软件运行所需的硬件平台、操作系统、相关软件组件及共存的应用程序环境。 - b.5 设计和实现上的限制：列出影响开发自由度的因素，并解释为何成为限制，包括技术选择、开发规范、政策法规、硬件限制、数据转换格式标准等。 - b.6 假设和依赖：列举影响需求陈述的假设因素以及对外部因素的依赖，例如商业组件、开发环境问题等，并确保这些假设的一致性和准确性。
c. 外部接口需求 - c.1 用户界面：声明所需用户界面的软件组件及其逻辑特性，包括界面标准、屏幕布局限制、标准控件、快捷键、错误信息显示规则等。 - c.2 硬件接口：描述软件与硬件间交互的特征，涵盖支持的硬件类型、通信数据和控制信息性质以及使用的通信协议。 - c.3 软件接口：定义产品与其他外部组件（数据库、操作系统、工具、库和商业组件）间的连接要求，说明服务需求、内部组件通信性质及共享数据机制。 - c.4 通信接口：规定与产品相关的通信功能需求，如电子邮件、Web浏览器、网络通信协议等，定义消息格式、安全加密问题、传输速率和同步通信机制。
d. 系统特性 按照系统特性组织功能需求，通过使用实例、运行模式、用户类、对象类或功能等级等方式进行分类，并分别说明每个特性的名称、说明、优先级、激励/响应序列和详细功能需求。
e. 其它非功能需求 - e.1 性能需求：阐述性能指标，如处理能力、响应时间、并发用户数、存储需求等，并尽可能量化和细化。 - e.2 安全设施需求：详述与潜在损失、破坏或危害相关的安全保护措施和行动，明确遵循的安全标准和策略。 - e.3 安全性 9需求：涉及系统安全性、数据保护等方面的需求，包括身份验证和授权规则，并可能涉及完整性和保密性策略。 - e.4 软件质量属性 10：列出其它重要的质量特性，如易用性、可靠性、可移植性等，强调它们的重要程度和可验证性。 - e.5 业务规则：列举操作规则，虽然不是功能需求但可能暗示某些功能需求，以保证特定环境下正确的操作权限。 - e.6 用户文档：列明随软件一同发行的用户文档组成部分，如用户手册、在线帮助和教程，明确交付格式或标准。
f. 其它需求 涵盖未在其他部分出现的需求，如国际化需求、法律要求等，还可以增加关于安装配置、维护管理等方面的额外需求。
附录：
注意：在实际编写SRS时，可以根据项目的具体情况增删或调整上述章节内容。对于不适用的部分，应保留标题并注明“不适用”，以保持文档的完整性。此外，任何软件项目文档都应当包含内容目录和修订历史记录，以便跟踪需求变更的过程和原因。
编写优秀的需求文档没有固定的方法，但可以根据经验进行。从过去所遇到的问题中，可以让你受益匪浅。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。在编写软件需求文档时，应牢记以下几点建议：
由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的需求影响了设计。如果你能用不同的方法来满足需求且这种方法都是可接受的，那么需求的详细程度也就足够了。然而，如果评审软件需求规格说明的设计人员对客户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。
需求文档的编写人员总是力求寻找到恰如其分的需求详细程度。一个有益的原则就是编写单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求能够正确地实现，那么就达到了合理的详细程度。如果你预想的测试很多并且很分散，那么可能就要将一些集合在一起的需求分离开。已经建议将可测试的需求作为衡量软件产品规模大小的尺度。
文档的编写人员必须以相同的详细程度编写每个需求文档。我曾见过在同一份软件需求规格说明中，对需求的说明五花八门。例如，“组合键 Control-S 代表保存文件”和“组合键 Control-P 代表打印文件”被当成两个独立的需求。然而，“产品必须响应以语音方式输入的编辑指令”则被作为一个子系统，而并不作为一个简单的功能需求。
文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”、“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”、“等等”之类的连词。
文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。在软件需求规格说明中交叉引用相关的各项，在进行更改时有助于保持它们之间的同步。让独立性强的需求在需求管理工具或数据库中只出现一次，这样可以缓和冗余问题。
文档的编写人员应考虑用最有效的方法表达每个需求。考虑符合如下句型的一系列需求：“文本编辑器应该能分析定义有<管区>法律的<格式>文档。”对于 12 种相似的需求中，<格式>所取的可能值有 3 种，<管区>所取的可能值有 4 种。当你评审与此类似的需求时，很难发现遗漏了一个需求，例如“文本编辑器应该能分析定义了国际法的无标记文档。”就像表 9-1 所示那样，可以用表中的这种格式表示需求，以确保你没有遗漏掉任何一个需求。更高层的需求可以这样描述：“ED-13 文本编辑器应该能分析定义有不同管区法律的多种格式的文档，如表
高质量的需求陈述应当具备完整性、正确性、可行性、必要性、优先级设定的清晰性以及可验证性。以下是针对您提供的例子进行的分析和改进方案：
原需求： “产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于 60 秒”。
该需求存在不完整性和不可验证性问题，如您所述，它没有明确指出状态消息的内容、触发条件、持续显示时长及具体涉及的产品部分。
改写后的需求：
后台任务状态更新要求： 后台任务管理器应确保在后台任务启动后每隔 60 秒，在用户界面指定区域自动更新一次与当前任务相关联的状态消息，并保证其连续可见，即消息不会因为更新而消失。
进度展示要求： 当后台任务正在进行时，后台任务管理器应在同一指定区域实时显示已完成的任务百分比。
任务完成通知： 当后台任务成功完成后，后台任务管理器需立即替换当前状态消息，显示一个清晰的“已完成”提示信息。
错误处理要求： 如果后台任务中止或出现错误，后台任务管理器需及时显示一条描述错误情况的消息。
通过将原始需求分解为多个独立且具体的需求点，每个需求都具有了更清晰的定义和可测试性。这样有助于在软件设计和构造过程中避免遗漏，并允许开发人员针对每个需求灵活选择最佳的设计实现方案，而非过早地限制设计空间，从而提高产品的整体质量和适应性。同时，这样的需求表述也能更好地支持后续的测试用例编写和验收过程。
原需求: “产品必须在显示和隐藏非打印字符之间进行瞬间切换”。
该需求存在不完整性和不可行性问题。首先，“瞬间”这一时间概念对于计算机而言是无法实现的，因为任何操作都需要一定的处理时间。其次，需求中没有明确说明触发状态切换的原因、条件以及具体涉及的内容范围（例如文本选择区域）。另外，“非打印”字符的含义也没有详细定义，可能是指隐藏文本、格式标记或其他控制字符。
改进后的需求: “用户在编辑文档时，可以通过激活特定的用户界面元素，在所选内容或整个文档范围内显示和隐藏所有HTML标签之间进行切换。”
改进后的表述明确了以下几点：
这样的需求描述更具有完整性、可行性和可验证性，有助于软件设计人员更好地理解并实现功能，同时也能方便测试人员编写详细的测试用例以验证切换操作是否正确执行。
原需求：“分析程序应该能生成 HTML 标记出错的报告，这样就可以使 HTML 的初学者使用它来迅速排错。”
这个需求存在问题：
改进后的需求拆分为两个清晰的部分：
这样的表述消除了原有的模糊性和不完整性，提供了更具体的要求和预期结果，使得设计人员可以据此设计相应的功能，并且测试团队能够基于这些要求编写可执行的测试用例来验证生成的错误报告是否满足需求。同时，通过定义何时生成报告以及报告的具体内容，也确保了需求的可验证性。
原需求：“如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。”
这个原始需求中，“如果可能的话”这一表述模棱两可，没有明确指出该功能是否为强制性要求或其实施的具体条件。此外，它并未说明在确认成功或失败时系统应该如何响应。
改进后的需求：
“系统必须具备在线查询并验证输入的货物编号的功能，通过与最新的主货物编号列表进行比对。当用户输入的货物编号无法在主列表中找到时，系统必须立即显示错误信息，并且不允许提交订货请求。”
对于异常情况的补充描述：
“在网络连接正常的情况下，系统在尝试确认货物编号时，若由于任何原因导致主货物编号列表不可访问，则系统应记录该事件，暂时保存待验证的订单信息，并向用户显示一个友好的提示消息，告知用户当前无法完成实时验证，请稍后再试或联系客服以人工方式进行核验。”
这样改进后的描述消除了模糊性，明确了系统的功能要求、预期行为以及在遇到异常状况时的处理方式，有助于开发团队准确地实现需求并确保产品的一致性和可靠性。
原需求：“产品不应该提供将带来灾难性后果的查询和替换选择。”
改写后的更具体明确的需求：
通过这样的改进，我们不仅消除了“灾难性后果”这一模糊描述，还为开发团队提供了更加清晰明了的设计指导，并确保最终产品能更好地保护用户的数据安全与完整性。同时，明确了反面需求的具体应用场景和解决方案，有助于提升软件产品的稳定性和用户体验。
在过去的项目中，我曾遇到过一个物流追踪系统开发案例，在此过程中，三个不同的开发人员对同一数据属性采用了各异的变量命名、长度规范和有效性校验规则。这一情况导致了对核心数据字段定义的混淆，并且当存储空间不足以容纳完整数据时会发生数据截断问题，进而增加了维护工作的复杂性。我们亟需的是一个物流数据字典——一个共享资源库，用于精确地记录并统一整个应用中所有数据元素和结构的含义、类型、大小、格式、计量单位、精度以及有效取值范围。
数据字典能够将不同需求文档与分析模型紧密结合。假如所有开发团队成员都能遵循数据字典的一致标准，则能显著减少集成难题。为了消除冗余与不一致性，应当为该项目创建一个独立的数据字典，而不是分散在各个需求文档中单独定义每个数据项。数据字典应独立于软件需求规格说明书进行维护，并确保项目生命周期内所有相关干系人都能随时查阅。
在物流数据字典中，可以采用标准化符号来表示各类数据项。数据项名称写在等号左侧，其详细定义置于右侧。这种符号化方法可用于描述基础数据元素、构成复合结构的复杂数据元素、重复的数据条目、具有枚举值的数据项以及可选的数据项。以下例子是基于“物流货物追踪系统”改编的：
基础数据元素：不可再分的基础数据元素可以被赋予数值。基础数据元素的定义必须明确指出其数据类型、大小、允许的取值区间等信息。例如： 货运单号=8位系统自动生成的连续数字，以“00”开头，作为唯一标识每个货运请求
复合结构：一个数据结构或记录可能包含多个数据项。若某个数据项在结构中为可选项，则用括号标注： 货运详情=货运单号+货物编号+数量+数量单位（供应商 14名称） 此结构明确了与跟踪特定货物货运相关的全部信息。其中，供应商名称为可选项，因为查询方可能并不关心货物的具体来源。该结构中的每一个数据项都应在数据字典中有详尽定义，且结构本身也可以嵌套其他结构。
重复数据项：如果某数据项可能出现多次，使用花括弧将其包围，并在括号前注明最小与最大重复次数： 货运请求=货运单号+订单编号+1:5{货运详情} 这个实例表明，一个货运请求至少包括一种货物的详情，但最多不能超过5种。每个请求还包括一个唯一的货运单号和订单编号，它们的具体格式会在数据字典的其他部分予以说明。
枚举选择项：如果原数据项只能取有限的离散值，则列出这些可选值： 数量单位=[“克”|“千克”|“箱”] 注释解释了与所追踪货物数量相对应的计量单位 表明数量单位的文本字符串仅允许从上述三种单位中选取。
建立数据字典和词汇表所投入的时间成本，将大大抵消由于项目参与者对关键信息理解不一致而造成的延误。只要保证词汇表和数据字典内容准确无误，它们将成为贯穿整个系统维护阶段及未来相关产品开发过程中极其宝贵的参考工具。
从软件需求规格说明中提取一页功能需求说明，并检查每个语句是否符合良好的需求特性。如果公司没有标准的格式，则召集一个小的工作组讨论并决定采纳一个标准的软件需求规格说明模板。从模板开始，并根据项目和产品的需求进行改编。在标识需求方面保持一致。
召集一个由3到7个项目的风险承担者组成的小组，正式评审项目中的软件需求规格说明。确保每个需求规格说明都是清晰、可行、可验证且无二义性的等等。寻找规格说明中不同需求之间的冲突，以及软件需求规格说明中可能遗漏的部分。通过检查软件需求规格说明，确保纠正了在软件需求规格说明及其后续产品中可能出现的错误。
本文同步发表在 软件需求探索的https://srs.pub/theory/xu-qiu-wen-dang-de-bian-xie.html