★按照非功能性需求的起源，可将其分为三大类——产品需求、机构需求、外部需求，进而还以细分。产品需求对产品的行为进行描述；机构需求描述用户与开发人员所在机构的政策和规定；外部需求范围比较广，包括系统的所有外部因素和开发过程。
◆非功能性需求的分类如下表：
非
功
能
性
需
求
产
品
需
求
可用性需求
eg：系统操作界面友好，操作人性化；
效率需求
性能需求
eg：系统对“提交”动作响应时间应该少于2s；
空间需求
eg：系统初始化安装后，磁盘空间占用不超过1G；
可靠性需求
eg：通过系统界面提交的数据，再次查看时能准确无误的显示；
可移植性需求
eg：系统具有跨平台特性，在windows操作系统或者Linux操作系统上均可部署；
机构需求
交付需求
eg：系统必须在2016年9月1日前交付实施；
实现需求
eg：系统交付时，功能和界面均要符合需求规格说明书的要求；
标准需求
eg：系统（电信计费系统）中数据格式要符合行业标准定义；
外部需求
互操作需求
eg：计费系统和账单管理系统中的数据可以交互；
道德需求
eg：系统中不能出现政治敏感词语；
立法
需求
隐私需求
eg：系统测试数据要对外保密；
安全性需求
eg：不能通过修改Web浏览器上的URL地址访问数据库；
6、需求规格说明书编写要求：
●需求是一个详细地描述一个应用程序外在的功能和特性。需求应该是清晰的、完整的、详略得当的、紧密的、可获得的和可测试的；
◆来看下面两项需求的描述：
1)、实现用户的增、删、改、查功能
2)、本系统需要较高的反应速度和一定的可扩展性。
分析：开发工程师可以根据第一条需求的描述，完成数据库的设计并完成程序编码吗?验收系统时，如果客户对系统的反应速度不满意而拒绝支付合同余款，这份需求规格说明书可以帮开发者解决纠纷吗？
◆再看看下面两条需求描述：
1)、用户信息包括用户编码 (系统自动生成的流水号)、用户名、用户部门、用户密码和用户状态。系统需要提供用户添加的功能，用户名、用户部门和用户密码为必输项；密码不能少于六位，新建后，用户状态为 '正常’。 系统提供用户信息修改的功能，除用户名和用户状态外的信息都可修改。系统需要提供删除用户功能，删除用户时，仅把用户状态改为 ’已删除’。并不物理删除数据，系统需要提供用户查询功能，可以根据用户名和用户部门查询，用户名支持模糊查询，用户部门查询条件可以从下拉列表框中选择输入；