需求规定产品必须做到什么，是以文件形式记录下来的、对项目实施结果的期望。这份文件既记录客户的期望，也记录研制方对程序、其功能以及整个项目的期望。需求涵盖特性、成本、进度与风险。因此，需求就是对需要研制什么的表述，或者说是对项目实施后期望得到什么的精确定量描述。需求确定得不好，是项目执行过程中出现问题的首要原因。
需求规定应当做什么、做到什么程度、在哪些约束之下完成。需求若有误，项目与产品必有缺陷。需求、约束与假定把问题分解为若干部分，而这决定着项目的总体成败。
需求的类型：
- 功能需求规定某一系统要素必须做什么。
- 性能需求规定系统所执行相应功能的定量参数。
- 约束性需求源自使用工况的限制、环境条件、安全考虑或法规符合性要求。
- 验证需求用以确信系统在实际使用环境中具备既定的特性。
- 接口需求规定全部接口的功能、特性、公差与约束。
- 运行需求规定系统的使用准备状态，着眼于系统的效能，同时也规定系统如何与用户交互。
为便于记住良好需求的特征，人们使用英文缩写 SMART。
- Specific（具体）——一项需求只应涉及项目的一个方面或系统的一项特性。表述时应当说明做什么、做到什么程度，而绝不应涉及可能的解决办法，即如何去做。
- Measurable（可测量）——可测量的参数以客观、定量的方式表达。
- Achievable（可达成）——需求必须在合理的成本下技术上可以达成。
- Relevant（相关）——需求必须与所选定的系统层级相对应。
- Traceable（可追溯）——较低层级的需求必须明确地由较高层级的需求推导出来及／或得到其支持。没有“上位”需求的需求被视为“孤儿”，须评估其实现的必要性。
必要性。如果拿不准某项需求是否必要，只需自问：“如果这项需求不列入清单，系统会受到什么损害？”若答不上来，这项需求多半就是多余的。
可验证性。需求一经表述，就必须确定如何对它进行验证；为此须选定相应的符合性准则。
可达成性。一项需求要能够达成，就必须在给定的进度与预算内、并在附加约束之下技术上可行。若对某项需求的技术可行性没有把握，就须进行相应的研究或进一步考察；即便如此仍无把握，那就应当表述为目标而不是需求。显然，即使某项需求技术上可行，也可能因成本、进度或其他约束（例如重量）而无法达成。为办不到的事情提出需求毫无意义，务须务实。
清晰性。每一项需求都应当只表达一个意思，并且简洁、简单。需求必须清楚而无歧义，这一点很重要。好的需求往往只需要简单句就够了。
需求应当以肯定的方式表述，绝不应以否定开头。它必须语法正确，没有错字和遗漏。系统的各个层级必须使用一致的术语。