1.软件生命周期
最经典也是最早提出的软件生命周期模型是瀑布模型，它给出了一个系统的严格顺序的软件开发方法，每个阶段之间具体比较严格的划分，也有固定的制品作为阶段开始和结束的标志。其他软件生命周期模型包括，增量式模型，演化式模型等，基本上都是在瀑布模型的基础上演化出来的。从瀑布模型上演化出来后面的这些模型，是因为在实际的项目中很少能严格遵循这些活动之间的顺序。比如，增量式模型是以迭代的方法运用瀑布模型，以解决不能一次性完成所有软件需求，而必须以一种增量的方式不断丰富和完善软件产品。而演化式模型则用来应对初始的软件需求没有明确的定义，需要不断与软件需求提供方沟通，逐步使软件需求明确化和完整化，或者刻画软件系统随时间的推移而演化的过程。
随着软件技术的进步和软件加强型系统应用深入和普及，瀑布模型本身也在不断发展，如下图所示，早期的版本一般按分析、设计、编码、部署划分的生命周期。而在（Pressman，2005）中的一个比较新的版本是按沟通、策划、建模、构建和部署等五个阶段划分软件生命周期。读者可以从中看到，由于软件设计和编码技术的发展和成熟，软件开发的核心任务或活动已经转向与软件需求相关的活动，在早期瀑布模型中，第一个活动“分析”与软件需求相关，而在后来的瀑布模型中，有三个活动“沟通”、“策划”和“建模”都与软件需求相关。这样的认识上的变化，一方面说明了软件需求工程的必要性已经得到普遍的认可，另一方面也说明了软件需求工程的方法和技术将在软件开发过程中起到越来越重要的作用。
2.系统工程
除了软件工程之外，软件需求工程的一个重要的起源是系统工程，因为在软件加强型系统中，软件系统是围绕它的一个更大的系统的子系统，对它的需求来自于这个更大的系统，也就是说，软件系统的需求从系统需求中导出。可以通过如下几类典型的软件系统来说明这一点：
·信息系统：这可以说是最常见的一类软件应用系统，这类系统主要关注企业信息的处理。有人可能会认为，这些系统只是一些围绕数据库的应用系统，因为其中的信息一般存储在数据库中。但是不能忽略的是，有许多这样的系统。其中，信息流构成企业运作的基础。例如，ERP系统所管理的物流、资金流以及对参与者的控制和约束等对企业运作本身起到了至关重要的作用。对信息系统的软件需求来自于对真个企业系统的运行需求。
·嵌入式系统：在嵌人式系统中，软件作为某些特殊含硬件的控制器，它可以是一些简单硬件系统的控制器，如电梯控制，也可以是一些复杂的硬件系统的控制器，如飞行控制器等。它们常常要依赖于某种专用的硬件，提供一些专用的接口供控制者操纵整个系统的运行。因此，对其中的软件系统的需求是由对整个系统的控制要求所导出。
·复杂人机交互系统：所谓复杂人机交互系统基本上是信息系统和嵌入式系统的合成物。强调它的目的是为了说明其复杂的方面。这里即包含人控制一些硬件设备的场景，又包含处理其所处于的大系统的信息流，包括存储、检索、辅助决策等，如飞机交通控制系统，火车信号系统等都具有这样的一些特征。这类系统中的软件系统的需求明显地也是来自对整个系统的需求。
因此，软件需求工程过程，除了处于软件生命周期，还与系统工程过程有密切的关系。经典的V形过程模型（下图）展示了软件需求工程过程在系统工程过程中的位置。这个系统工程过程跨越了从系统需求的初步说明到特定软件需求的转换和开发，直到实现系统的集成和验证等完整步骤。
3.软件需求工程过程
到目前为止，我们知道，需求工程过程即是软件生命周期中的部分，又是系统工程过程的子过程。这两个更大的过程约束了软件需求工程过程的边界。更直接地说，软件生命周期模型规定了软件需求工程过程的产出，而系统工程过程则给出了软件需求工程的输入。下图具体刻画了软件需求工程的输入输出边界。
其中，一致同意的需求、系统规格说明、系统模型这三项是软件开发后续阶段需要的信息。虽然有时这三个术语常常被混用，但将它们区别开有其必要性。首先，从包含的内容上看，一致同意的需求是关于系统需求的总体描述，并且已经得到所有需求相关者的同意。系统规格说明则是可以被实现的系统功能的详细规格说明。而系统模型则可能包含一组按不同系统建模原理构建的系统模型，如数据流模型、过程模型、实体-关系模型、目标模型等等。其次，从三者的表示形式上说也有区别，一般来说，一致同意的需求常常是自然语言的形式，没有严格的规范，是需求相关者可理解的。系统规格说明则需要按照某种文档规范书写。而系统模型则严格按照结构的或形式化的模型原语来构造。
领域信息和部分领域规章条例属于问题领域特性，而需求相关者的需要对应对软件加强型系统的需求。存在的系统包含两个类，一类存在的系统是待开发的软件系统将与之交互的物理世界的实体，它们限定了待开发的软件系统将处于的现实世界环境。另一类存在系统是当前已经在使用的，将与待开发系统连接起来形成一个整体的现有系统，它们的能力和使用场景也会对待开发系统的能力提出要求。
规定了软件需求工程过程的输入和输出，则划清了该过程的边界。我们知道，在软件需求工程阶段应对软件系统复杂性的方法是分解。软件需求工程过程的建模也是一样，由于从输入到输出之间并没有明确可定义的或可操作的变换对应关系，说明这个变换必须要分解成更细粒度的或者具有可操作性的变换，使得可以比较明确地说清楚这个变换过程要实现的任务。也就是要将这个黑盒过程分解成一系列的活动，使得每个活动有其明确可操作的任务定义。这就是过程建模的任务。