需求工程过程的输入包括存在的系统信息、需求干系人的需要、领域规章条例、领域信息，其输出为已经得到需求干系人同意的系统需求的总体描述、软件需求规格说明和需求模型。需求工程过程涵盖了与需求相关的所有活动，这些活动可分为需求开发与需求管理两大类。需求开发包括了软件类产品中需求收集、评价、编写文档等活动，可进一步分为需求获取、需求分析与协商、需求规格说明和需求验证4种活动。需求管理活动就是管理需求的变化和需求变化带来的影响。

需求获取是指发现系统需求的活动。在需求获取活动中，需求工程师、系统开发人员、客户和最终用户一起找出待解决的问题、系统要提供的服务、系统性能要达到的要求、系统要满足的软硬件和网络资源约束。在需求获取过程中，需求工程师和需求提供者要紧密合作，形成良好的合作关系，要跨越组织边界、知识领域和水平差异、沟通的习惯差异等障碍。为了跨越这些障碍并使需求获取活动更有效，人们提出了许多需求获取方法，包括面谈、工作坊、问卷、观察法、情景法、原型法和用户界面分析等。

需求规格说明活动是将所获得的原始需求按规范的文档格式形成标准文档的过程。这个标准文档就是需求规格说明，又称需求文档、需求定义、功能规格说明、系统需求规格说明等。一般来说，需求规格说明包含如下内容：系统应该提供的服务和功能；系统运行要满足的约束条件；系统的全局特性；系统与交互的其他系统的接口描述；系统所属应用领域的背景信息；系统开发过程要满足的约束条件。为了保证所有要求的信息都包含在其中，开发组织可以定义自己的需求规格说明标准模板，以便设定必须包含的章节。电气电子工程师学会（IEEE）组织发布了IEEE/STD 830-1993和IEEE/ANSI 830-1998两组标准模板。

需求分析与磋商就是发现需求规格说明中的问题，并就其中的问题进行磋商和决策，使所有干系人对需求规格说明达成一致意见的过程。需求分析最主要的活动是需求建模。需求工程师通过采用不同的建模方法识别、理解、挖掘需求提供者对系统的期望，从而构建软件系统的结构模型、行为模型、数据模型，或者其他描述待开发软件的不同特性的模型。需求的分析模型能提供不同的信息与关系，这有助于找到不正确的、不一致的、遗漏的和冗余的需求。在项目实践中还经常采用一些需求分析技术，包括需求检查表、需求关联矩阵和数据操作需求矩阵（CRUD矩阵）等，来帮助需求工程师发现需求规格说明中可能存在的问题。当发现需求文档中有需求之间冲突时，由于这些需求来自不同的需求提供者，要消除这些冲突必须要让需求提供者进行磋商。磋商过程围绕冲突需求展开讨论，并寻找所有干系人都能接受的解决方案。解决冲突有3种方式：合作解决，如磋商和培训等；竞争解决，如比较和竞争等；引入第三方权威解决，如仲裁和权威机构等。

需求验证是需求开发的最后一个活动，其目的是检查需求规格说明，以确定文档中包含的需求是否表达了待开发系统的可接受的描述。这个活动的参与者包括所有的系统需求干系人，主要任务是检查需求规格说明，以保证需求没有问题、遗漏和二义性。需求验证的输入包括需求规格说明、组织知识和组织标准等，输出是问题列表和被检验通过的需求规格说明。其中，需求规格说明是需求的完整的格式化描述，而不是未完成的文档草稿。组织知识包括此组织使用的术语以及开发和使用这个系统的人员的实践技能。组织标准包括系统设计的相关企业标准。问题列表是从需求规格说明中发现的问题列表。一致同意的行为是验证过程涉及的人员一致同意的解决问题的行为。需求验证的主要技术包括人工审查、原型法、模型检测和需求测试等。

需求管理就是管理需求的变化和其带来的影响。需求管理有广义和狭义之分。需求管理包括在工程进展过程中维持需求文档集成性与精确性的所有活动。需求管理强调：控制对需求文档的变动；保持项目计划与需求一致；控制单个需求和需求文档的版本情况；管理需求和联系链之间的联系或管理单个需求和其他项目可交付品之间的依赖关系；跟踪需求文档中需求的状态。

需求开发的过程模型是软件的生命周期模型的一部分。最经典的软件生命周期模型——瀑布模型定义了严格顺序执行的分阶段软件开发过程，每个阶段之间具有比较明确的分工，也有特定的制品作为阶段开始和结束的标志。按照瀑布模型的方式划分软件需求工程过程，可以得到线性的需求工程过程模型，将软件需求工程过程中的活动组织成一个分阶段的过程。由于软件开发过程本质上是迭代的，软件需求工程过程模型也需要迭代。大多数需求工程过程采用迭代过程模型，包含了需求开发的各项活动，并刻画了这些活动之间的关系。

在项目开发实践中，上述迭代模型可以随活动关注点的变化调整，比如关注活动中的角色，则可以建立角色-活动模型。需求工程师或者研发团队可以在此过程框架上添加关注点，形成带有自己特色的迭代过程模型。