根据IEEE软件工程标准词汇表(1997年)，软件需求被定义为：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
简而言之，软件需求分析的任务就是解决目标系统“做什么”的问题，但不涉及系统“如何做”的问题。但是软件需求往往是相对的，具有层次性。一个软件系统的需求可能是企业解决方案的一部分，而软件系统的总体设计方案同时也决定了子系统的需求。因此，脱离业务背景分析软件需求，是不现实的，不顾总体系统的设计方案，分析子系统的需求，也是没有意义的。
软件需求是连接问题域和方案域的桥梁，是当前软件工程中的关键问题，可以说没有明确的需求就没有正确的软件，很多软件项目失败就是因为需求存在问题。
最初，需求分析仅仅是软件工程的一个组成部分，是软件生命周期的第一个阶段。虽然大家也都知道需求分析对软件整个生命周期的重要性，但对它的研究远远没有对软件工程的其他部分的研究那么深入。
在传统软件工程生命周期中，需求分析的作用仅仅是：
1) 系统工程师描述软件的功能和性能，指明软件和其他系统成分的接口，并定义软件必须满足的约束；
2) 软件工程师求精软件的配置，建立数据模型、功能模型和行为模型；
3) 为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型；
4) 提供开发人员和客户需求规格说明，用于作为评估软件质量的依据。
但从当前的工程问题和研究现状来看，需求涉及的问题远不止这些。随着对需求的深入研究，需求已经从软件工程独立出来，从一个阶段发展为一个研究方向-需求工程。需求工程是系统工程和软件工程的一个交叉分支，包括需求获取、需求分析、需求确认及需求演化，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。
需求工程是软件工程中最复杂的过程之一，其复杂性来自于客观和主观两个方面。从客观意义上说，需求工程面对的问题几乎是没有范围的。由于应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。其客观上的难度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性。从主观意义上说，需求工程需要方方面面人员的参与（如领域专家、领域用户、系统投资人、系统分析员、需求分析员等等），各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。