句和段落的简短。
采用主动语态的表达方式。
编写具有正确的语法、拼写和标点的完整句子。
使用的术语与词汇表中所定义的应该一致。
需求陈述应该具有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的库存清单。”
为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、简单、有效、、最新技术、优越的、可接受的等。当用客说“用户友好”或者“快”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。
避免使用比较性的词汇，定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。
文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”，“等等”之类的连词。
8．需求分析的过程
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系。然后，你可以使客户信息结构化，并编写成文档和示意图。下一步，就可以让客户代表评审文档并纠正存在的错误。这四个过程贯穿着需求开发的整个阶段。
由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面列出了1 4个步骤，你可以利用它们指导你的需求开发活动。对于需求的任何子集，一旦你完成了第十三步，那么你就可以很有信心地继续进行系统的每一部分的设计、构造，因为你将开发出一个好的产品:
1. 定义项目的视图和范围。
2. 确定用户类。
3. 在每个用户类中确定适当的代表。
4. 确定需求决策者和他们的决策过程。
5. 选择你所用的需求获取技术。
6. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级。
7. 从用户那里收集质量属性的信息和其它非功能需求。
8. 详细拟订使用实例使其融合到必要的功能需求中。
9. 评审使用实例的描述和功能需求。
10. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解。
11. 开发并评估用户界面原型以助想像还未理解的需求。
12. 从使用实例中开发出概念测试用例。
13. 用测试用例来论证使用实例、功能需求、分析模型和原型。
14. 在继续进行设计和构造系统每一部分之前，重复6~1 3步。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
