软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通常，软件生存周期包括可行性分析与开发项计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动。
常用的三种软件生命周期（瀑布模型、迭代式模型和快速原型模型）中，需求分析中都占据了举足轻重的作用，是系统分析、软件编程、软件测试和系统维护的输入物。
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）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。小的变动影响不大，也不致影响进度，但是对于一些改动会引起设计重大改变的需求，需要在合同中清楚说明。
3.1.2 客户说不清楚需求，分析人员理解错误客户的计算机水平、对需求的理解、表达程度都参差不齐。有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。有些客户心里非常清楚想要什么，但却说不明白。有的客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。
不同性格、不同水平、与客户交流前准备情况不同的的系统分析师去跟客户讨论需求时，会得到很不不一样的结果。
作为系统分析师，可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。一个好的系统分析师，能从客户的一两句话中提出很多自己的观点或可进行拓展，进而进一步挖掘客户需求，或者若与之前的需求矛盾，可进行正确需求导向。
【对策】：若客户说不清楚需求，为了不造成理解错误，系统分析师可采用多次沟通的方式，例如第一次通过客户初步了解需求，回去分析哪些是合理需求，那些是自相矛盾或不合理的需求，以及哪些是需要进一步明确的需求。经过细化后，第二次交流可提供PPT或简单的Word文档与客户进行第二次深入交流。第三次交流可通过建立快速模型进一步与客户交流得到精确的需求。需求分析也可参考“迭代式模型”来进行不断迭代，一直到挖掘出客户所有的潜在需求为止。
3.1.3 客户在没看到原型或完整系统时，有一些潜在需求未被挖掘甚至有不少这样的客户，去进行需求沟通时提不出太多的需求，但是在你做完整个系统时，潜在需求突然迸发出来。
【对策】：为了避免此种情况对项目造成破坏性影响，建议相关人员为一些大的功能模块建立快速原型让客户进行确认，并在合同中一定要说清楚“做什么”和“不做什么”
3.1.4 多个相关方需求相互冲突，需求有二义性若些需求若牵涉客户不同部门，若有不一致意见，若私自按某一方的意见进行修改，很可能在后期涉及到按另一个部门的想法进行改造。
【对策】：对于这种客户内部有冲突的需求，需求组织客户方相关部门一起讨论，由客户更高领导层决定实现哪一方的需求，或者采用折衷方案。需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |