系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求 。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统 。
人也可以是系统的一部分，因此某些系统功能可能要由人来承担 。业务规则 包 括企业方针、政府条例、工业标准、会计准则和计算方法等 。
业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围 。然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能 。
有时，功能中特定的质量属性（通过功能实现）也源于业务规则 。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则 。
功能需求记录在软件需求规格说明（SRS）中 。SRS完整地描述了软件系统的预期特性 。
SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库 或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片 。开发、测试 、质量保证、项目管理和其他 相关的项目功能都要用到 SRS 。
除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求） 。组织级需求： 一 般代表着组织的愿景和目标 。
对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告 。比如在ITSM或者企业信息化这方面 。
典型 的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等 。业务需求： 是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求 。
业务需求服从于组织需求 。用户需求： 用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求 。
我们在软件需求规格说明书中表述的需求其实主要是这一部分需求 。功能需求： 同样，它代表着产品或者软件需求具备的能力 。
一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言） 。所有的用 户需求都必须符合业务需求 。
需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能 。开发人员则根据功能需求和非功能需求设计解决方案，在约束条 件的限制范围内实现必需的功能，并达到规定的质量和性能指标 。
当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内 吗？” 。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于 。
但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定： 是否扩大项目范围以容纳新的需求 。这是一个可能影响项目进度和预算的商业决策 。
二、需求的三个方面 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述 。质量属性 （quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性 。
这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或 开发人员都很重要 。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束 。
还有一项称为可用性（usability）的质量属性，它规 定了业务需求中“有效”（efficiently）一词的含义 。约束（constraint）限制了开发人员设计和构建系统时 。