许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当，包括信息收集方式不正规，没有明确提出想要的功能，假设是未经过沟通的错误假设，需求的定义不够充分，以及未经仔细考虑进行需求变更等。在软件开发中遇到的问题时，人们常常轻率地将其忽略。软件项目中40%~60%的缺陷都是由需求分析阶段的过失所致。如果处理得当，各方利益的相互作用就能使产品获得成功，同时使客户感到满意，并使开发人员充满成就感；否则就会导致误解、挫折和矛盾，从而降低产品的质量的商业价值。由于需求是软件开发和项目管理活动的基础，所以涉众必须遵循有效的需求过程。
但是开发和管理需求绝非易事，没有任何捷径与魔法。由于很多组织被一些同样的问题所困扰，所以我们可以寻找共同的解决方法，以用于不同的情况。软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。对同一项需求，不同的人会有不同的描述，称其为用户需求，软件需求，功能需求，系统需求，技术需求，业务需求或产品需求。客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。定义多样性导致了令人迷惑或沮丧的沟通问题。需求必须被记录成文档。
软件需求包括3个不同的层次——业务需求，用户需求和功能需求。除此之外，每个系统还有各种非功能需求。需求开发可进一步细分为获取，分析，规格说明和确认，这些子学科涵盖了为软件和软件相关产品收集，评估和记录相关的所有活动。关于需求来源和需求收集方法，软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。需从不同用户代表和来源收集需求，这说明了需求工程是以相互交流为核心的性质。下面是几个软件需求的典型来源。
1）. 访问并与有潜力的用户探讨为找出新软件产品的用户需求，最直截了当的方法是询问他们。
2）. 把对目前的或竞争产品的描述写成文档
文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。
3）. 系统需求规格说明
一个包含软、硬件的产品需要一个高档次的系统需求规格说明以介绍整个产品。系统需求的子集被分配到每个软件子系统中（Nelsen 1990） 。附加的详细软件功能需求将从有关软件
的系统需求里获得。
4）. 对当前系统的问题报告和增强要求指导用户和提供技术支持的工作人员是最有价值的需求来源。
收集用户在使用现有系统过程中所遇到问题的信息，并接受用户关于系统改进的想法。
5）. 市场调查和用户问卷调查
调查有助于从广大有潜力的用户那里获得大量定量的数据，务必调查相关的用户并询问一些能产生反响的好问题。
6）. 观察正在工作的用户
对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998） 。比起仅仅简单地询问用户，并记下用户在处理任务时的步骤来说，直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动，以确保所获得的需求具有普遍性，而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。
7）. 用户任务的内容分析
通常通过开发具体的情节（s c e n a r i o）或活动顺序（有时称作“情节” ） ，可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求，这是使用实例方法的精髓。
关于需求开发活动指导方针这一部分，作者对于需求开发没有一个简单的、公式化的途径，列出了下面13个步骤，我们可以利用它们指导自己的需求开发活动。
1）. 定义项目的视图和范围
2）. 确定用户类（比如市场人员、财务人员、生产人员等）
3）. 在每个用户类中确定适当的代表
4）. 确定需求决策者和他们的决策过程
5）. 选择你所用的需求获取技术
6）. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级
7）. 从用户那里收集质量属性的信息和其它非功能需求
8）. 详细拟订使用实例使其融合到必要的功能需求中
9）. 评审使用实例的描述和功能需求
10）. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解
11）. 开发并评估用户界面原型以助想像还未理解的需求
12）. 从使用实例中开发出概念测试用例
13）. 用测试用例来论证使用实例、功能需求、分析模型和原型