一.概念
需求的定义包括从用户角度(系统的外部行为)，及从研发者角度(一些内部特性)来阐述需求。
关键的问题是一定要编写需求文件。我原来目睹过一个项目中途更换了所有的研发者，客户被迫和新的需求分析者坐到一起。系统的分析人员说：“我们想和你谈谈你的需求。”客户的第一反应便是：“我已将我的需求都告诉你们前任了，目前我要的就是给我编一个系统”。而实际上，需求并未编写成文件，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。
需求的另外一种定义认为需求是“用户所需要的并能触发一个程式或系统研发工作的说明”。有些需求分析专家拓展了这个概念：“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性：
需求是指明必须实现什么的规格说明。他描述了系统的行为、特性或属性，是在研发过程中对系统的约束。
从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。
所有文件形式的需求(例如如下将要描述的需求规格说明书)仅是个模型，一种描述。
二.需求分析的任务
研发软件系统最为困难的部分就是准确说明研发什么。最为困难的概念性工作便是编写出周详技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对他进行修改也极为困难。
目前，国内产品的庞杂，一家企业可能有几个系统并立运行，他们之间接口是系统研发人员最头痛的问题。
对于商业最终用户应用程式，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。不过对于我们研发人员来说，并没有编写出客户认可的需求文件，我们怎么知道项目于何时结束?而如果我们不知道什么对客户来说是重要的，那我们又怎么能使客户感到满意呢?
然而，即便并非出于商业目的的软件需求也是必须的。例如库、组件和工具这些供研发小组内部使用的软件。当然你可能偶尔勿需文件说明就能和其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文件的代价，这些血的教训正在国内的软件研发者身上发生。
近来，我遇见一个研发小组研发包括代码编辑器在内的一套内部使用的计算机辅助软件。不幸的是，当他们研发完这个工具后，发现这个工具不能打印出原始码文件，使用者当然希望有这个功能。结果这个小组只好手工抄写原始码文件以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文件，软件达不到期望目标也只能是咎由自取了。
相反的情况，我曾见一个要集成到“错误跟踪系统”中的简单界面写了一页需求说明。而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用。他们依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现所有错误。
事实上，需求文件在研发过程中一直起指导作用。
三.需求分析过程
可把整个软件需求工程研究领域划分为需求研发和需求管理两部分更合适
需