理解需求

理解需求

概念

在开始任何技术工作之前，为工程任务创建一系列需求都是个好主意。

重要性

如果软件解决的问题是错误的，那么即使软件再精巧也满足不了任何人的要求。

噩梦

我们努力从客户那里获取需求，却难以理解获取的信息。我们通常采用混乱的方式记录需求，而且总是花费极少的时间检验到底记录了什么。 我们容忍变更控制自己，而不是建立机制去控制变更。总之，我们未能为系统或软件奠定坚实的基础。这些问题中的每一个都是极富挑战性的，当这些问题集中在一起时，即使是最有经验的管理人员和工作人员也会感到头痛。但是，确实存在解决方法。

需求工程

需求工程（Requirement Engineering）是指致力于不断理解需求的大量任务和技术。
需求工程包括七项任务：起始，获取，细化，协商，规格说明，确认和管理。

起始

定义将要解决的问题的范围和性质

如何开始一个软件项目？通常来说，大多数项目都是在确定了商业要求或是发现了潜在的新市场、新服务时才开始的。

获取

帮助利益相关者定义需要什么，建立业务目标

询问客户、用户和其他人以下问题： 系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作。这些问题看上去非常简单，但实际上并非如此，回答它们是非常困难的。

细化

精确定义和修改基本需求

细化任务的核心是开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。细化实在获取过程中由一系列用户场景建模和求精任务驱动的。
细化固然是一件好事，但你需要知道什么时候停止细化，细化的关键在于如何设计建立牢固的基础，一旦能够清楚地描述这个问题，就可以停止细化，不要迷恋不必要的细节。

协商

如何定义优先次序？什么是必需的？何时需要？

业务资源有限，而客户和用户却提出了过高的要求，这是常有的事。另一个相当常见的现象是，不同的客户或用户提出了相互冲突的需求，并坚持“我们的特殊要求是至关重要的”。你必须通过协商来调解这些冲突。

规格说明

以某种形式明确说明问题

在基于计算机的系统（和软件）环境下，术语规格说明对不同的人有不同的涵义。规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。
有人建议应该开发一个“标准模板”并将之用于规格说明，认为这样将促使以一致的、更易于理解的方式来表示需求。然而，在开发规格说明时，保持灵活性有时是必要的。规格说明的形式和格式随着要构造的软件的大小和复杂性而变化。

确认

经过评审或确认以保证软件工程师和利益相关者对于问题的理解是一致的

需求管理

用于帮助项目组在项目进展中标 识、控制和跟踪需求以及变更需求的一组活动。