特别是关于设计和实现的信息，稍不注意就会介入，所以需要特别注意。如果需求中包含关于设计和体系结构的信息，则会被其信息所限制，对于应用程序来说就不能选择最合适的设计方法。但是，有时系统内部已经确定的场合也有。例如，因为组织许可方面的因素，明确了数据库必须使用DB2，这种情况下作为“设计限制（Design Constraints）”进行描述。
重要的是尽量减少设计上的限制。那样，开发者只在最小限度的限制下能够实现必要的功能、设计出满足性能和可靠性的系统。
需求的详细分类
关于软件需求之前了解的情况，使用一句话来概括也会有多种。特别是可以按如下所示分为3种。
1)功能需求
2)非功能需求
3)设计限制
另外，如图3所示通常取出Functionality（功能性）、Usability（易用性）、Reliability（可靠性）、Performance（性能）、Supportability（易支持性）的开头字母以FURPS+形式来分类。FURPS+中最后的+表示不包含在FURPS中的设计方面的限制。该FURPS+用上述3种分类来说的话，各自相当于F是功能需求、URPS是非功能需求、+是设计限制。
根据上述形式进行分类，形成识别需求时和评价对需求的理解时的检验一览表，可以防止遗漏和不完整性。
软件非功能需求
到前一节为止我们了解了所说的“软件需求”就是把系统在详细基准下定义的需求，从黑匣子的观点来描述系统能力的需求。另外软件需求可以用FURPS+方式分类。但是对于开发能够让客户满意的系统不仅仅是软件需求，掌握利害关系者的需求也是非常重要的。（利害关系者：拥有与项目有相关利害关系的人、特别是系统的用户被列举为重要的利害关系者）
众所周知，为了有效地执行需求管理，作为详细标准需求的“软件需求”以外也作为需求来掌握，这一事项在经验上是很有效的。也就是说，把需求的语言对象不仅仅是系统详细定义的“软件需求”，也扩大到了利害关系者的“原始需求(Needs)”。并且另外一点，作为比软件需求抽象标准更高的需求，把“功能特性(Features)”也作为需求来掌握。有点麻烦但是倒入“需求类型”这一概念，其类型之一包括“原始需求”、“功能特性”，“软件需求”。由于功能特性比软件需求的抽象度要高，所以如果利用功能特性的话，就能很容易地把握系统整体，也就能轻松地管理开发范围。
软件非功能需求
到前一节为止我们了解了所说的“软件需求”就是把系统在详细基准下定义的需求，从黑匣子的观点来描述系统能力的需求。另外软件需求可以用FURPS+方式分类。但是对于开发能够让客户满意的系统不仅仅是软件需求，掌握利害关系者的需求也是非常重要的。（利害关系者：拥有与项目有相关利害关系的人、特别是系统的用户被列举为重要的利害关系者）
众所周知，为了有效地执行需求管理，作为详细标准需求的“软件需求”以外也作为需求来掌握，这一事项在经验上是很有效的。也就是说，把需求的语言对象不仅仅是系统详细定义的“软件需求”，也扩大到了利害关系者的“原始需求(Needs)”。并且另外一点，作为比软件需求抽象标准更高的需求，把“功能特性(Features)”也作为需求来掌握。有点麻烦但是倒入“需求类型”这一概念，其类型之一包括“原始需求”、“功能特性”，“软件需求”。由于功能特性比软件需求的抽象度要高，所以如果利用功能特性的话，就能很容易地把握系统整体，也就能轻松地管理开发范围。
那样的话，如图4所示可以把原始需求、功能特性和软件需求在3段的金字塔状中按照每个需求类型进行体系化描述。以订单管理业务的应用程序为例，如图5所示按照各自的需求类型分别描述需求样本。
