需求编写的一些基本原则
首先要搞清楚的是需求的编写重点是描述清楚现实而不是去抽象，因此需求应该能够明确的描述清楚业务。最忌讳讲需求编写为类似于系统操作手册之类的文档。
对于结构化需求规格说明书要描述清楚场景，角色，输入，输出，处理和数据字典。对于涉及到业务流程的应该由完整的分角色的业务流程图，对于涉及较多数据处理的应该由相对应的数据流图。对于面向对象的需求文档则重点是用例的描述，应该保护背景，前提，基本流，扩展流，异常，业务规则等重要内容；应该能够给出业务用例图和相关的业务对象模型。
符合需求的最基本特征和SMART原则，需求必须是正确，完整，无歧义，可验证和测试，可实现的。
需求文档必须是可验证和可测试的，因此测试用例一般需要根据需求文档制定。
在编写需求文档过程中不要忽视了系统的性能，安全，冗余，可扩展性，效率等非功能性需求。这些对系统架构有着重要的影响。
编写需求过程中业务需求编写和后续的界面建模最好分离，避免一开始就陷入到界面操作的细节而忽视了重要的业务规则。
需求语句最好是主动的动宾结构，语句要简短但又清晰，对于经常出现的术语应该统一抽取到词汇表或数据字典中进行描述。
需求中不要出现可能，应该，估计，最佳，比较，易用等无法测试和实现的词语。
高质量的需求要考虑到用户或业务需求可能发生的变化，系统的可扩展性不是从设计阶段才开始的事情，而应该在需求阶段就综合考虑。
高质量的需求不是简单对用户需求的描述，而是需要对用户需求进行挖掘，真正搞清楚用户的潜在需求。
需求应该有相应的重要级别和优先级别的定义。
需求最好能够转换为一条条的简短语言描述，以便于需求的测试和实现。便于需求的修改，便于需求的追踪。
对于结构化需求规格说明书要描述清楚场景，角色，输入，输出，处理和数据字典。对于涉及到业务流程的应该由完整的分角色的业务流程图，对于涉及较多数据处理的应该由相对应的数据流图。对于面向对象的需求文档则重点是用例的描述，应该保护背景，前提，基本流，扩展流，异常，业务规则等重要内容；应该能够给出业务用例图和相关的业务对象模型。
符合需求的最基本特征和SMART原则，需求必须是正确，完整，无歧义，可验证和测试，可实现的。
需求文档必须是可验证和可测试的，因此测试用例一般需要根据需求文档制定。
在编写需求文档过程中不要忽视了系统的性能，安全，冗余，可扩展性，效率等非功能性需求。这些对系统架构有着重要的影响。
编写需求过程中业务需求编写和后续的界面建模最好分离，避免一开始就陷入到界面操作的细节而忽视了重要的业务规则。
需求语句最好是主动的动宾结构，语句要简短但又清晰，对于经常出现的术语应该统一抽取到词汇表或数据字典中进行描述。
需求中不要出现可能，应该，估计，最佳，比较，易用等无法测试和实现的词语。
高质量的需求要考虑到用户或业务需求可能发生的变化，系统的可扩展性不是从设计阶段才开始的事情，而应该在需求阶段就综合考虑。
高质量的需求不是简单对用户需求的描述，而是需要对用户需求进行挖掘，真正搞清楚用户的潜在需求。
需求应该有相应的重要级别和优先级别的定义。
需求最好能够转换为一条条的简短语言描述，以便于需求的测试和实现。便于需求的修改，便于需求的追踪。