• 保持语句和段落的简短。
• 采用主动语态的表达方式。
• 编写具有正确的语法、拼写和标点的完整句子。
• 使用的术语与词汇表中所定义的应该一致。
• 需求陈述应该具有一致的样式，例如“系统必须⋯⋯”或者“用户必须⋯⋯”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。”
• 为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说“用户友好”或者“快”或者“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。
• 避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“ 处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。由于需求的编写是层次化的，因此，可以把顶层不明 确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的 需求影响了设计。如果你能用不同的方法来满足需求且这种方法都是可接受的，那么需求的详细程度也就足够了。然而，如果评审软件需求规格说明的设计人员对客 户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。
• 编写可测试需求文档 。 需求文档的编写人员总是力求寻找到恰如其分的需求详细 程度。一个有益的原则就是编写单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求能够正确地实现，那么就达到了合理的详细程度。如果你 预想的测试很多并且很分散，那么可能就要将一些集合在一起的需求分离开。已经建议将可测试的需求作为衡量软件产品规模大小的尺度（Wilson 1995）。
• 文档的编写人员必须以相同的详细程度编写每个需求文档。我曾见过在同一份软件需求规格说明中，对需求的说明五花八门。例 如，“组合键C o n t r o l - S代表保存文件”和“组合键C o n t r o l - P代表打印文件”被当成两个独立的需求。然而，“产品必须响应以语音方式输入的编辑指令”则被作为一个子系统，而并不作为一个简单的功能需求。文档的编写 人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用 “和/或”，“等等”之类的连词。文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这 也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。在软件需求规格说明中交叉引用相关的各项，在进行更改时有助于保持它们之间的同步。让独立性强的需求在需求管理工具或数据库中只出现一次，这样可以缓和冗余问题。
================可有可无的分割线================
首先，应重视需求分析的目的（意义），编写目的明确，写的详细，能确保文档的质量有所提高。
下面是一段需求分析意义的范例，希望对大家有所帮助。
1.6进行需求分析的意义
1. 本说明书将对用户生产信息管理的业务、对系统要实现的主要功能、性能等需求进行全面地阐述，以便帮助用户判断所要开发的软件是否符合他们的要求。该说明书将在软件开发目标和需求方面为用户和开发者之间创建一个共同的基础和共识。
2. 由 于需求说明书要有用户的审核、修改完善、认定的过程，在这个过程中可以使用户在软件设计之前广泛地征求各业务部门的意见、提出有关系统建设的建议、对自己 的需求和要求进行周密地思考，并要把这些意见和建议反映到用户需求说明书中。这样就能减少事后重新设计、重新编码和重新测试的返工行为。
3. 用户需求的调查分析过程也是用户对自己的业务和管理进行总结和规范的过程，通过用户需求说明书把用户更加规范的管理反映到了软件开发中，从而使用户的管理更加完善和规范。
4. 需求说明书是开发者进行软件设计的依据，软件设计要依据本说明书将进行系统分析、数据库设计、模块设计、接口设计、输入输出格式设计等。
5. 需求说明书使开发者在软件进行设计和开发之前，能够充分了解和熟悉用户的要求，并判断这些要求是否有不能解决的技术问题，若有应提出一个用户认可的代替解决方案。以免出现设计出的一个目标不能在开发过程中实现的问题
6. 在需求调查和分析期间可以搜集有关系统开发的有关原始数据和代码，以便在系统开发中建立开发环境时应用
7. 在软件开发方面为用户和开发者提供一个标准，为系统开发结束进行确认和验收提供一个双方认可的依据。
8. 便于软件的维护和提高，为软件维护和为今后对所开发的软件进行完善扩充提供进一步分析的基础。
总之，用户需求说明书的编写是软件工程中的非常关键的一个环节，用户说明书也是软件工程中的非常重要的一个文档。一个好的用户需求说明书不但能够提高软件开发的效率、保障软件开发的质量，而且有利于系统的验收和以后软件的维护及扩充。
• 采用主动语态的表达方式。
• 编写具有正确的语法、拼写和标点的完整句子。
• 使用的术语与词汇表中所定义的应该一致。
• 需求陈述应该具有一致的样式，例如“系统必须⋯⋯”或者“用户必须⋯⋯”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。”
• 为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说“用户友好”或者“快”或者“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。
• 避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“ 处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。由于需求的编写是层次化的，因此，可以把顶层不明 确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的 需求影响了设计。如果你能用不同的方法来满足需求且这种方法都是可接受的，那么需求的详细程度也就足够了。然而，如果评审软件需求规格说明的设计人员对客 户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。
• 编写可测试需求文档 。 需求文档的编写人员总是力求寻找到恰如其分的需求详细 程度。一个有益的原则就是编写单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求能够正确地实现，那么就达到了合理的详细程度。如果你 预想的测试很多并且很分散，那么可能就要将一些集合在一起的需求分离开。已经建议将可测试的需求作为衡量软件产品规模大小的尺度（Wilson 1995）。
• 文档的编写人员必须以相同的详细程度编写每个需求文档。我曾见过在同一份软件需求规格说明中，对需求的说明五花八门。例 如，“组合键C o n t r o l - S代表保存文件”和“组合键C o n t r o l - P代表打印文件”被当成两个独立的需求。然而，“产品必须响应以语音方式输入的编辑指令”则被作为一个子系统，而并不作为一个简单的功能需求。文档的编写 人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用 “和/或”，“等等”之类的连词。文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这 也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。在软件需求规格说明中交叉引用相关的各项，在进行更改时有助于保持它们之间的同步。让独立性强的需求在需求管理工具或数据库中只出现一次，这样可以缓和冗余问题。
================可有可无的分割线================
首先，应重视需求分析的目的（意义），编写目的明确，写的详细，能确保文档的质量有所提高。
下面是一段需求分析意义的范例，希望对大家有所帮助。
1.6进行需求分析的意义
1. 本说明书将对用户生产信息管理的业务、对系统要实现的主要功能、性能等需求进行全面地阐述，以便帮助用户判断所要开发的软件是否符合他们的要求。该说明书将在软件开发目标和需求方面为用户和开发者之间创建一个共同的基础和共识。
2. 由 于需求说明书要有用户的审核、修改完善、认定的过程，在这个过程中可以使用户在软件设计之前广泛地征求各业务部门的意见、提出有关系统建设的建议、对自己 的需求和要求进行周密地思考，并要把这些意见和建议反映到用户需求说明书中。这样就能减少事后重新设计、重新编码和重新测试的返工行为。
3. 用户需求的调查分析过程也是用户对自己的业务和管理进行总结和规范的过程，通过用户需求说明书把用户更加规范的管理反映到了软件开发中，从而使用户的管理更加完善和规范。
4. 需求说明书是开发者进行软件设计的依据，软件设计要依据本说明书将进行系统分析、数据库设计、模块设计、接口设计、输入输出格式设计等。
5. 需求说明书使开发者在软件进行设计和开发之前，能够充分了解和熟悉用户的要求，并判断这些要求是否有不能解决的技术问题，若有应提出一个用户认可的代替解决方案。以免出现设计出的一个目标不能在开发过程中实现的问题
6. 在需求调查和分析期间可以搜集有关系统开发的有关原始数据和代码，以便在系统开发中建立开发环境时应用
7. 在软件开发方面为用户和开发者提供一个标准，为系统开发结束进行确认和验收提供一个双方认可的依据。
8. 便于软件的维护和提高，为软件维护和为今后对所开发的软件进行完善扩充提供进一步分析的基础。
总之，用户需求说明书的编写是软件工程中的非常关键的一个环节，用户说明书也是软件工程中的非常重要的一个文档。一个好的用户需求说明书不但能够提高软件开发的效率、保障软件开发的质量，而且有利于系统的验收和以后软件的维护及扩充。
下面正式谈一下我对需求文档的一些写作思路：
首先要对用户机构机构有清晰的了解，写出各机构所涉及的业务，画出相应业务的用例图；之后提取出相应的业务流程，画出相应的流程图。通过业务流程，即可抽 象出系统需实现的功能。再将各业务（功能）涉及到对象（如人员，物品等）信息描述出来，根据提取出的信息将功能以IPO表（即输入、处理、输出表）的形式 进行描述，逐项定量和定性地叙述对软件所提出的功能要求，详细的说明输入什么量、经怎样的处理、得到什么输出，并说明待开发软件应支持的终端数和应支持的 并行操作的用户数。需求文档的主要部分就这样完成了。
====================完全没有必要的分割线=====================
引用topic: