软件需求是用户解决问题或达到目标所需条件或权能、系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能，或者一种反映上面所述条件或权能的文档说明。中培教育《需求分析与管理最佳实践》培训专家郭老师就软件需求的分级和分类情况进行了详细介绍。
      一、根据不同阶段、不同属性、不同场景等特性，需求可以分为以下几类：
　　  1.业务需求（Business requirement）：
      反映了组织机构或客户对系统、产品高层次的目标要求。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标，使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
　　  2.用户需求（User requirement）： 描述的是用户的目标或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径，也就是说用户需求描述了用户能使用系统来做些什么。
　　  3.系统需求（system requirement）：是系统必须完成的事以及必备的品质，一般用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。系统需求包括功能需求、业务流程需求和非功能需求。
　　  4.功能需求（Functional requirement）：定义了开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
　　  5.业务流程需求：业务流程需求是根据业务目标对业务过程进行分解，说明业务的处理步骤、以及每个步骤的角色者，一般用活动图并辅以文字加以描述。业务流程需求通常还需要说明业务规则，也就是业务办理过程中的一些约束条件，包括输入数据的校验规则和业务处理的逻辑规则。
　　  6.非功能需求（Non-functional requirement）：非功能需求包括产品必须遵从的标准、规范和合约、外部接口的具体细节、性能要求、设计或实现的约束条件及质量属性等。非功能需求包括性能需求、接口需求、可靠性需求、可恢复性需求、易用性需求、安全性需求、GUI需求、可保障性（Supportable）需求、兼容性需求、部署需求、安装需求等。
　　  7.测试需求（Testing requirement）：确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。
　　  8.运营需求：运营需求是系统上线后对通过IT服务对业务的运营支撑，所反映出的用户对业务的接受度、订单量的波动情况、注册用户数的波动情况、有策划的市场活动对电子交易的贡献等信息状态。
　　  9.采购需求：采购需求是指对采购标的的特征描述。要实施采购就一定要搞清楚采购需求，好的采购需求能够合理、客观反映采购标的的主要特征以及要求供应商响应的条件，符合适用原则、非歧视原则，并能够切合市场实际。
　　  10.外包需求：将某项任务或服务的执行或管理责任转由第三方来完成的需求，称之为外包需求。
　　  11.接口需求：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。
　　  12.性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。
　　  13.安全性需求：用户在身份认证、授权控制、私密性、加密管理等等方面的要求。
　　  14.可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。
　　  15.可恢复性需求（Recovery testing）：是指系统从灾难或出错中可以很好恢复的需求，如遇到系统崩溃、硬件损坏或其他灾难性出错，应用程序和数据可以很快得到正确的恢复。可恢复需求通常需要关注恢复所需的时间以及恢复的程度。
　　  16.可保障性（Supportable）需求：用户在软件可配置性、可扩展性、可维护性、可移植性等方面的要求。
　　  17.易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。（行业标准）。
　　  18.GUI需求：从GUI设计的规范性、GUI布局的合理性、GUI风格的一致性、GUI界面操作课定制性等方面对界面设计提出要求。
　　  19.兼容性需求：是对软件从某一环境转移到另一环境的能力的具体要求，包括以下几方面：操作系统兼容性，异构数据库兼容性，新旧数据转换，异种数据兼容性，用软件兼容性，硬件兼容性等。
　　  20.部署需求：对软件系统运行环境的要求，包括操作系统、数据库、中间件等软件版本、硬件环境、网络等。
　　  21.安装需求：是对软件安装的具体要求，例如：软件在正常和异常情况的不同条件下，都可以正确安装，完整的或自定义的安装都能正常进行，系统升级可以正确进行，软件卸载可以正常进行。异常情况包括磁盘空间不足、缺少目录创建权限等系统会给出正确提示。
　　  22.业务规则：包括企业方针、政府条例、工业标准、会计准则和计算方法等，业务规则通常是隐性需求。
      二、不同类型需求之间的关系：

三、需求根据重要程度分类如下：
　　  1.非常重要--关键任务需求，在该需求上必须达成一致意见，且本期版本必须完美实现，软件才会被接受。
　　  2.重要--实现这些需求将增强系统的性能，如果忽略这些需求，系统也是可以被接受的，如果没有时间，也可以延迟到下一版本。
　　  3.一般--该需求实现或不实现均可，实现该需求可以使系统更完美，且该功能可以包含缺陷。
　　四、需求根据成熟度的不同有以下六个级别：
级别零：没有需求（no requirements）
      没有任何明确的需求被记录下来，相关人员假定知道要构建什么，希望节省需求的时间来做开发，这样做很可能会导致所做的产品并不是用户所需要的。
　　  级别一：被记录的需求(Written Requirements)从混乱的没有需求级别上升一步就是简单地写出需求。
　　  级别二：被组织的需求(Organized)需求的目的是为了清晰地与用户、客户和其他涉众（例如开发团队）等人就问题的解决方案进行沟通。级别二关注需求质量、格式化、安全和存储，以及版本管理。
　　  级别三：结构化需求(Structured)结构化需求是对需求进行归类，是功能性需求还是非功能性需求？是业务需求还是系统需求？是特性还是软件需求？客户、市场和用户需求是什么？区分这些可以帮助我们更好的理解和管理需求。之前级别都是用一些文字类语言来描述，而级别三是一种结构化需求，例如给需求添加一些属性。
　　  级别四：可跟踪性需求(Traced)需求本身是层级的，由用户需求到业务需求再到系统需求；而需求又与开发和测试有所关联，通过可跟踪性管理，我们可以知道在更改一个需求时，会影响到哪些子需求以及相关的同级需求，还能够分析出影响哪些开发和测试内容。
　　  级别五：集成化需求(Integrated)通常我们做了很多需求，但是并没有一种集成化的方法把需求直接引入开发中，可能导致实现出来的是另一回事。集成化需求管理流程可以直接由需求导入软件设计、变更管理、测试和项目管理。团队将需求作为主要输入，如果将需求模型化，我们则可以通过模型化需求来开发应用程序，通过建模来结构化需求，它的目标就是要做成能够让业务工程师来开发应用程序。