软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当，问题包括：信息收集不正规；功能隐晦；对假设功能有理解上的分歧；需求指定不明确以及变更过程不正规。客户需求和管理客户需求过程中用户输入不足和有误是造成项目失败的罪魁祸首。
软件需求的本质
软件开发项目中可能会遇到如下经历：
- 从来没有清晰制定过项目的业务目标、愿景和范围。
- 客户太忙，没有时间与分析师或开发人员共同处理需求。
- 团队无法与用户代表直接互动，不理解他们的具体需要。
- 客户认为所有的需求都很关键，因此没有对需求排定优先级。
- 开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。
- 开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。
- 需求从来没得到客户的认可。
- 客户认可了某个发布或者迭代的需求，但事后又不断更改。
- 不断接受客户的需求变更请求，项目范围随之扩大，由于没有增加资源或者删减功能，进度最后完全被打乱。
- 有人提出了变更请求，但被忽略，没人知道特定变更请求的具体状态。
- 客户提出特定的功能要求，而且开发人员也建好了，但就是没有人用过。
- 在项目接近尾声时，虽然满足规范说明，却不满足客户或业务的目标。
一些软件开发项目由于在初期阶段对需求工作不够重视，就匆忙开展后续工作，致使项目最终受到严重后果的惩罚，例如，用户对交付的产品不满意，由于不适用不得不返工，延期再交付。然后，返工导致的额外成本投入不仅会使开发组织的高管人员失望，开发人员也因要付出更多的劳动而怨声载道，最终导致开发组织的声誉受到影响。
客观原因上：
- 软件人员对项目提出的业务领域知识和相关技术并不熟悉。
- 并且软件人员通常并不只是面对一个应用领域，而是常常在开发一个产品，初步熟悉一个领域之后，下一个开发任务又会面临另一个全新的领域。
- 此外，当今各应用领域的技术和市场情况大多处于迅速发展和演变之中。
主观原因上：
- 软件开发人员未能在项目的需求阶段很好地和用户配合，充分吸收和听取用户的意见。
- 未接受应用领域知识和技术的培训。
- …
软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当，问题包括：信息收集不正规；功能隐晦；对假设功能有理解上的分歧；需求指定不明确以及变更过程不正规。客户需求和管理客户需求过程中用户输入不足和有误是造成项目失败的罪魁祸首。
软件项目中，所有干系人（客户、用户、业务分析人员和开发人员）的利益交界点主要集中在需求方面。处理得当，这种交接既可让客户满意，又能鼓舞开发人员。处理不当，则会引发误解和摩擦，最终降低产品质量和业务价值。需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。
需求的开发和管理贯穿于：
- 开发新系统；
- 改进、替换以及重构项目；
- 融合商业现成品的（COTS）打包解决方案项目；
- 遵循敏捷开发过程渐进式构建产品增量，也要理解每一个增量所涉及的需求。
软件需求的定义
- 说法1：“需求是任何能够驱动设计做出选择的东西”。
- 解读：开发需求的目的就是要做出合适的设计选项，最终满足客户需要。
- 说法2：“需求是产品所必备的属性，目的是向干系人提供价值”。
- 解读：没错，但不准确。
- 说法3：“需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。”
- 解读：认为“需求”是多种不同类型的信息的统称，涵盖来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征，它们包含系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手。不要妄想项目中的所有干系人都能对需求达成统一的认识。提前确立定义，以便大家能够达成共识。
需求的优先级
软件需求包含一个时间维度，可能是描述目前系统性能的现在时，或者他们可能是近期（高优先级）、中期（中等优先级）或者想象中（低优先级）的未来。甚至可能是过去时，也就是那些曾经被人指定但后来又被舍弃的需要。我们没必要浪费时间争论某个东西是否是需求，即使知道自己会为了某个合理的业务原因而永远不执行它。需求就是需求。
需求的层次和种类
| 需求领域常用术语 | |
| 术语 | 定义 |
| 业务需求 | 开发产品的组织或者获取产品的客户所需的高层次业务目标 |
| 业务规则 | 策略、纲领、标准或者制度，能够定义或者约束某些方面的业务。虽然本身并不是软件需求，但它却是一些类型的软件需求的鼻祖 |
| 约束 | 对开发人员在产品设计和构建上的限制条件 |
| 外部界面需求 | 对软件系统和用户、其他软件系统和硬件设备间的关联进行说明 |
| 特性 | 单个或者多个用户提供价值的、有逻辑关系的系统性能。可以通过一个功能需求集合进行描述 |
| 功能需求 | 描述系统在特定条件下展现的行为 |
| 非功能需求 | 描述系统必须展现的属性或者特性，或者必须遵守的约束 |
| 质量属性 | 一种非功能需求，描述的是服务或者一个产品的性能特征 |
| 系统需求 | 包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件 |
| 用户需求 | 特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性 |
软件需求有三种不同的层次：业务需求、用户需求和功能需求。每个系统都包含某种类别的非功能需求。不同种类的需求如下图中的模型所示。虽然“一切模型都是错误的，但有些还是有作用的。”这个模型也许并不全面，但提供的方案非常实用，可以帮助组织需求方面的知识。
| 需求层次 | 解读 | 样例 | 记录位置 |
|---|---|---|---|
| 业务需求 | 组织为什么要执行系统（组织希望获得的业务收益）。关注点在于组织或者提出系统要求的客户有哪些业务目标。 | 例如，航空公司打算将机场柜台工作人员成本降低25%，常想到的是建一个自助服务终端供乘客自行检票，项目出资方、目标客户、实际用户的管理层、市场部门或者产品规划部门一般都会有业务需求， | 记录在愿景或者范围文件之中。还有一些战略性指导文件有时也会用于此目标，包括项目图标、业务实例以及市场（或者营销）需求文件。 |
| 用户需求 | 描述了用户使用产品必须完成的目标或者任务，并且这个产品要能够为人提供价值。由实际用户代表提供，表达的是用户通过系统来完成哪些具体工作。 | 乘客的用户需求：“我想办理登机手续以便能够登机”。（大多数项目都有若干个用户类别和其他干系人，我们还必须获取他们的需求。要在这个层级集中注意力，理解实际用户要用这个产品完成哪些具体目标） | |
| 功能需求 | 主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求） | 常将功能需求记录为传统意义上的“应当”句式：“乘客应当能够随时打印自己已经办好登机手续的所有航段的登机牌”或者“如果乘客信息没有指定作为偏好，航班预定系统就应当为他分配” | 记录在软件需求规范说明（Software Requirements specification, SRS（已为行业标准术语，ISO/IEC/IEEE 2011））之中，尽可能详尽地描述人们对软件系统的预期行为。SRS可以是一个报告，由存储在需求管理工具中的信息生成。 |
其他：
| 术语 | 解读 |
|---|---|
| 系统需求 | 描述了人们对某个产品的需求，而这个产品由多个组件或者系统子集组成（ISO/IEC/IEEE 2011）。所有软件或软件、硬件系统子集都可以算是系统。甚至人和过程都可以算是系统。 |
| 业务规则 | 包括公司政策、政府法规、工业标准以及计算算法。业务规则本身并不是软件需求，因为它的存在已经超出了任何特定软件应用的范围。却又经常决定着系统为了切合相关规则而必须包含哪些功能，有时又引申出具体的质量特性，这些特性又以功能的方式由开发人员实现，因此，特定的功能需求可以追溯到具体的业务规则。 |
SRS还包含某些类别的非功能需求：
| 术语 | 解读 |
| :— | :— |
|质量属性|从不同角度描述产品特征，例如性能、安全性、易用性和可移植性，这些对于用户、开发人员和维护人员来说都非常重要|
|系统与外部世界的接口|包括与其他软件系统、硬件组件、用户以及沟通界面的关联|
非功能需求到底是什么？
- 功能需求描述的是系统在不同条件下能够被用户观察到的行为。
- 功能之外的需求强调的不是系统要做什么而在于系统做得有多棒，包括易用性、安全性和性能。设计和实现约束也是非功能需求，以及外部接口。
- 还有一些其他的非功能需求，描述的是系统运行环境，例如平台、可移植性、兼容性和约束。很多产品还受监管和发行许可的影响，甚至还要考虑到产品的地域性需求，例如用户的文化、语言、法律、货币、专有名词、拼写和其他特征。业务分析师仍然可以从非功能需求中获得大量功能，以确保系统的所有行为和属性符合用户的预期。
- 非功能需求也要保证被纳入需求获取和分析活动，因为交付的产品虽然囊括所有预想的功能，但用户还是不喜欢，因为它不符合人们对其产品质量（通常未明确表达）的预期。
一个特性包含一个或者多个逻辑上有关联的系统功能，由一组功能性需求来共同描述。例如，网页浏览器的书签、拼写检查、为运动器械设定定制锻炼程序、杀毒软件中病毒库的自动升级，都是典型的特性。特性包含多种用户需求，每种需求都表示特定的功能需求必须实现，以便用户能完成用户需求中所描述的任务。下图为一个特性树，也可以说是一个分析模板，展示的是特性如何层层分解为更小的特性组，这些小特性与具体的用户需求关联，最终引出功能需求。
例如，假设在开发某个文本编辑程序的新版本。“在6个月内将非美国地区的销量增加25%”可以算是一种业务需求，市场部发现参与竞争的产品只有英语拼写检查器，因此决定新版本要包括一个多语种拼写检查特性，对应的用户需求可能包含诸如“为拼写检查器选择语言”“发现拼写错误”和“将词添加到字典”这样的任务。拼写检查器有很多独立的功能需求，涉及的操作包括高亮拼写错误的单词、自动纠错、显示建议替代选项、用正确的单词整体代替拼写错误的单词。易用性需求明确指定如何使用特定语言和字符集来定位软件的使用区域。
处理三种层次的需求
下图展示了不同的干系人如何参与获取三种层次的需求。
还要认识到以共享方式记录关键需求信息的重要性，而不应只是用传统的口述形式。记录下客户的需求，免得用户代表被不同的对接人反复询问。三种主要的需求交付物：愿景和范围文档、用户需求文档和软件需求规范说明。无需独立创建，特别对于小型项目，有必要将这类信息融合在一起。但还要注意这三种交付物包含着不同的信息，要在项目的不同点进行开发，开发人员也可能不同，目的和目标受众也不相同。
需求变更，做“影响分析”来保证合适的人（项目发起方、项目经理或产品负责人）做出可靠的业务决策，确定哪些变更可接受，解决时间、资源或特性权衡所关联的成本。