「不要再管什么需求了，时间有限，今天就开始建系统了！」这句话很熟悉吧？没错，许多从事软件开发的人大概都曾听过或讲过这句话。因为软件开发的时间总是很紧迫，既然都已经有人跟客户谈定了，若不赶快动工，怎来得及？
是的，一切莫如「赶快敲定，赶快开始，赶快交差，最后 —— 赶快收钱」来得重要，所以许多软件开发团队在派出项目经理或业务经理去「搞定」客户需求之后，大伙儿就立刻一头栽入整个开发流程，你分析、我撰写、他测试，众人忙得不亦乐乎，只求工作如期完成，大家就可以开庆功宴了。
遗憾的是，真实世界的状况不是如此。所以常会看到庆功宴开不成，反倒以斗争大会代之，大家交相指责，而其中又以项目经理或业务经理成为众人锁定的目标，因为大家一致抱怨：「就是你们搞不清楚客户需求，才让大家白忙一场！」
「搞清楚客户需求」说起来容易，实际上却不轻松，否则斗争大会的召开频率也不会那么高。
需求很重要，原因除了确保庆功宴得以举办，另外还有一个重要因素，就是避免成本突然失控、导致案子失败。根据统计，同样一个问题，当它发生在最前面阶段与最后面阶段时，需要投入的解决成本的平均比例是 1 比 200 。需求通常出现在流程前期，因此这正是要重视「需求管理」的原因。
需求如何管理？
许多人认为，需求不过就是「客户讲的话」；不过，在 RUP （ Rational Unified Process ）作业准则里，需求的定义是：「一个系统必须遵循的条件或能力；而这些条件或能力可以来自使用者需求，或合约规范中的文字陈述，或其它经确认的正式文件」。另外， RUP 对于需求管理的定义是：「导引、文件化、组织及追踪需求变动的系统化过程」。
特别赋予定义是为了让「双方完全确定与完全掌握」「客户讲的话」。
此外，需求可能来自客户端不同层级与不同人员，自己开发团队里的成员也有可能分别协助处理，因此必须确定所有人对需求的「认知」都相同。另外，为了避免「令出多门」，必须特别厘清客户需求的真正决策者 —Stakeholder （行动主体）。
再来谈谈什么才是「正确」的需求陈述。
在 RUP 里，需求陈述必须满足以下条件：明确（ Verifiable ）、可以排定重要性先后顺序（ Ranked for importance and stability ）、可修订（ Modifiable ）、可追踪（ Traceable ），以及可以被理解的（ Understandable ）。此外，对任何一条需求陈述而言，它还必须是正确（ Correct ）、完整（ Complete ）、一致（ Consistent ）且清楚的（ Unambiguous ）。
列出这么多条件，并不是要把需求搞得很复杂，相反地，是为了让需求「清楚、简单、而且可以被完全理解与检验」。
举例来说，我常常听到客户要求：「系统必须很稳定才行」，但如果直接将此付诸文字可就麻烦了，因为该如何界定「稳定」呢？所以这个需求陈述是错误的。正确的作法可以是这样：与客户进一步沟通后，写成「系统必须可以满足一千个使用者同时上线；当使用者提交一个要求时，系统送出回复的时间必须小于五百微秒；系统必须可以适用于连续七天与每天二十四小时的运作环境」。因为这些陈述都很清楚，也可以被检验。事实上，这个过程就是一种需求管理的实践，因为正确的需求被「导引」出来，并诉诸「正式文件」。
陈述这些需求管理的原则与作法的目的是：「在既定的预算与时间内，交出符合客户真正需求的优秀产品」。只要达到这个目的，项目就百分之百成功了。
虽然这个目的简单又明了，真正能达成的却不多；最常发生的状况就是预算或时间意外失控，导致预算膨胀、交货延迟，甚至整个案子胎死腹中。要避免以上的状况，有两点原则值得特别注意。
