软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通常，软件生存周期包括可行性分析与开发项计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动。
常用的三种软件生命周期（瀑布模型、迭代式模型和快速原型模型）中，需求分析中都占据了举足轻重的作用，是系统分析、软件编程、软件测试和系统维护的输入物。
1.1 瀑布模型瀑布模型由于酷似瀑布闻名，（Waterfall Model）首先由Royce提出。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。
瀑布模型图示如下：
从上图可看出，需求分析的产出物《需求规格说明书》（有的项目组还会产出软件原型，例如静态HTML原型等）是后续设计、编码、测试和系统维护的基础。
可将瀑布模型的“需求分析”阶段细分为“软件概念”和“用户需求分析”两个阶段，前者用于收集用户的原始需求，包括用户在功能、行为、性能、设计约束等方面的期望，并经过初步分析后形成《用户需求说明书》，而后经过进一步分析，将用户需求精确化、完全化，最终形成《需求规格说明书》。
可将瀑布模型中的“系统设计”细分为“架构设计”和“详细设计”两个阶段，前者在总体上把握，更关注架构层面，包括系统的总体架构，以及各个子系统或各个模块之间的关系。后者更注重细节，包括系统设计的方方面面都要在详细设计中有所体现。
作为系统分析师，或系统架构师，主要在“需求分析”和“系统设计”阶段体现自己的作用，后续的各个阶段主要通过与项目组成员的沟通贯彻自己的设计。
1.2 迭代式模型迭代式模型是是RUP（Rational Unified Process，统一软件开发过程，统一软件过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程（编码流程）和测试工作流程。实质上，可将它理解为多个小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
迭代式原型图示如下：
在每一个迭代中，“需求分析”阶段与瀑布模式一样，是后续系统分析、编码和测试阶段依赖的基础。如果需求分析有较大偏差，势必造成迭代过程中产生的一个产品子集有较大偏差。
1.3 快速原型模型快速原型（Rapid Prototype）模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。
在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。
在快速原型模型中，原型最重要的目的是为了确定用户的真正需求。从某种程度上，可以将快速原型理解为需求分析的一种更直观的方式，也是业界比较认可和取得良好效果的一种方式。
2、需求分析的目标通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。
需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
需求分析的目标，说得通俗一点，就是确定“做什么，不做什么”。但需求分析却不像想象的那么简单，主要因为如下原因：
3.1.1 客户需求自身经常变动这世间的一切，只有“变化”是绝对的，从这点来理解，软件系统的需求不断变化也是可以理解的。老听设计人员和开发人员抱怨客户的需求老是变化，其实应该将“需求变化”理解为一种常态。
引起需求变化的原因诸多，例如：
（1）因为某些前置条件未满足，之前按照“妥协”方案实现，但若在某个时间点上这些前置条件被满足，于是引起了需求的变化。
（2）某个后台操作之前不需要走审批流程，但因为客户的某个内部流程改变，需要走审批流程，势必引起需求 -> 设计 -> 编码 -> 测试的一系列变更。
【对策】：因为需求变动无可避免，系统分析师在进行需求分析时需要明确：
（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。小的变动影响不大，也不致影响进度，但是对于一些改动会引起设计重大改变的需求，需要在合同中清楚说明。
| 欢迎光临 思步网 (http://www.step365.com/) | Powered by Discuz! X3.2 |