需求有几个重要的特性：场景性，需求是针对特定业务环境的需求，使用的业务术语也具有明确的业务环境相关性。清晰明确性，需求会在整个需求规格说明书中具有唯一的解释，每一项需求都是被简洁、简单的语言进行描述的。并且是被所有人理解为同样的含义，此外这也解释了为什么在需求规格说明书中还要具有术语表的原因。正确性，需求正确的描述了系统要交付的功能，并且最后是得到用户验证的，例如在项目中需求都是调研访谈得来的，而不是创造出来的，和产品不同，很多产品的需求是创造出来或想出来的。可行性，在已知的能力条件下，需求是可以实现的。例如iPhone刚刚出现的时候，客户就要求在winphone中实现同样的功能和效果，这是不现实和不可行的。必要性，小即是美，很多情况下，用户只需要完成需要完成的工作即可，并且，系统的每一项设计都会有明确的需求来源，如果超出了，那么这个需求很可能就是不必要的，会浪费工作量，换一个角度来说，需求是价值和利益导向的，没有价值则没有必要。优先性，为每一项需求建立优先权，尽管用户可能会说，每一项功能都是具有最高优先权的，但从系统来说，我们要清晰，交付此系统的最小子集是什么，这些就是最具有优先权的功能。可证实性，是能被客户、用户所认可，也能通过设计、测试和交付的功能所反向追踪和验证的。
需求的具体描述，不同类型的工作对需求的描述是不同的，例如咨询类工作和软件系统的需求工作所描述的需求是不一样的。软件系统可以采用结构化的语言，例如用户在进行某场景操作时，应具有某些功能，在什么地方得到某些信息。例如：用户在进行系统登录的时候，应具有可以看到密码的复选框功能，如果选择了此功能，则用户可以在密码输入框中看到自己输入的密码。例如：用户在提交表单时，应在1秒至6秒内得到是否完成的信息，完成信息显示在屏幕的指定位置上。系统在处理过程中，系统光标显示正在进行处理的信息。系统处理如果出现问题，则出错信息显示在屏幕的指定位置上。而咨询类工作的需求是以问题和核心的，以清晰定义问题的需求为主要的目标。
在实际的软件项目需求规格说明书的编写过程中，是存在两种需求规格说明书的，一种是用户需求说明书，一种是软件需求规格说明书，软件需求规格说明书是基于用户需求说明书编写的，其格式取决于所采用的开发和管理方式，例如按流程开发的方式、面对对象的开发方式和敏捷项目所采用的需求规格说明书是不同的。在需求规格书说明书的编写中，是和业务需求分析紧密结合在一起的，最简单的包括需求的分类，满足业务域或业务类别，还有一些业务改进和过程改进的内容，还有一些内容是行为分析的内容。虽然需求不是设计，但需求多多少少还有一些系统最终实现后的影子，为此有一些功能性需求的编写过程中已经对功能结构进行了初步的组织。需求不一定一定要用用例图来描述，采用灵活清晰的规格化的文档描述来编写具体的需求，但避免过于复杂，例如出现很多分支。如果在需求规格说明书中放入系统原型，则是对系统界面的实现进行约束。
