需求研发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文件等所有活动。需求研发活动包括以下几个方面：

　　确定产品所期望的用户类别。

　　获取每个用户类的需求。

　　了解实际用户任务和目标及这些任务所支持的业务需求。

　　分析源于用户的信息以差别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

　　将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。

　　了解相关质量属性的重要性。

　　商讨实施优先级的划分。

　　将所收集的用户需求编写成文件和模型。

　　评审需求规格说明，确保对用户需求达到一起的理解和认识，并在整个研发小组接受说明之前将问题都弄清晰。

　　需求管理需要“建立并维护在软件工程中同客户达成的合同”。这种合同都包含在编写的需求文件和模型中。客户的接受仅是需求成功的一半，研发人员也必须能够接受他们，并真正把需求应用到产品中。通常的需求管理活动包括：

　　定义需求基线（迅速制定需求文件的主体）。

　　评审提出的需求变更、评估每项变更的可能影响从而决定是否实施他。

　　以一种可控制的方式将需求变更融入到项目中。

　　使当前的项目计划和需求一致。

　　估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体目前项目解决方案上。

　　让每项需求都能和其对应的设计、原始码和测试用例联系起来以实现跟踪。

　　在整个项目过程中跟踪需求状态及其变更情况。

　　以上几点说明是我总结了成功实施项目后系统分析人员的经验，同时也根据国内外的其他系统实施的相关成功经验，进行了总结。

　　4．需求的类型

　　下面这些定义是需求工程领域中常见术语的定义。

　　软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。

　　1．业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标需求，他们在项目视图和范围文件中予以说明。

　　2．用户需求(userrequirement)文件描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文件或方案脚本说明中予以说明。

　　3．功能需求(functionalrequirement)定义了研发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

　　在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在研发、测试、质量确保、项目管理及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。

　　作为功能需求的补充，软件需求规格说明还应包括非功能需求，他描述了系统展现给用户的行为和执行的操作等。他包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能需求；设计或实现的约束条件及质量属性。所谓约束是指对研发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和研发人员都极为重要。

　　下面以一个字处理程式为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文件中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文件中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器更有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框及实现整个文件范围的替换。

　　从以上定义能发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求和这些没有关系，他关注的是充分说明你究竟想研发什么。项目也有其他方面的需求，如研发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但他们并非本书所要讨论的。