【干货】怎样做好需求分析 - 乔布简历
打开微信，扫描二维码
点击微信右上角，分享到朋友圈
需求工作作为产品研发的第一个环节，其重要性可见一斑。也有很多人将需求分析的工作归结为编写需求规格说明书，这种简化的做法往往成为导致项目后期层出不穷的问题的罪魁祸首。项目前期的需求收集过程的结果，会对产品产生最为直接的影响。需求工作大致可以分为需求收集、需求分析、需求描述以及需求管理这四个环节。
做好需求收集的工作，首先要建立正确的需求收集机制。从部门现状来看，需求的主要来源是：竞争产品分析、用户试用反馈及高层领导建议。
分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求。经常因为对隐含需求考虑的不够充分而引起需求变更；需求要符合系统的整体目标；需求项之间不应有矛盾。需求分析不仅针对新收集的需求，还应包括对产品研发过程中变更需求的分析。在产品研发过程中，需求变更不可避免。在需求变更后，需要准确分析此次变更对整个系统的波及，在这个过程中沟通成本巨大。但若分析不到位就有需求反复变更的风险。
产品需求文档应至少包含三部分：用户故事、产品功能列表、产品交互原型。用户故事描述用户的应用场景，说明产品对用户的价值。可描述用户使用产品之前的场景（用户的痛处在哪里），进而说明用户在使用产品之后的场景，通过产品得到了哪些价值。通过用户故事，可进一步编写产品功能列表。明确产品需具备哪些功能来实现其对用户的价值。主要可包括以下内容：概要说明（描述功能用途），业务规则（如输入框限制、日期显示方式等）。编写产品功能列表可采用逐步细化与分解的过程。细化的过程可结合产品交互原型的构思，采用Use Case的方法，内容主要包括：执行者、前置条件、后置条件、主流程。这样使功能的表述更清楚。产品交互原型明确了用户将如何使用产品来实现其价值的过程，可以与细化产品功能同步进行。
在产品研发过程中，需求变更不可避免。在准确分析完变更对整个系统的波及后，需做好对需求的管理工作。
一、需求变更后，需保证第一时间通知相关人员，并使其都能获取最近更新过的需求。并保证需求的一致性，避免出现需求项之间存在冲突的情况。可采用需求管理工具或使用版本管理工具（如SVN），保证产品需求文档的唯一性，并可查阅更新记录。
二、需求变更后，测试用例需随需求同步修改。方法：建立需求与测试用例的矩阵。便于查看需求变更后会引起哪些测试用例变更，测试用例是否完全覆盖已变更的需求。培训必须进行有效的需求分析
我的图书馆
培训必须进行有效的需求分析
培训作为企业的人力资本投资，其成败在很大程度上依赖于培训需求分析。因为培训需求分析是整个培训管理活动的第一个环节，它决定了培训能否瞄准正确的目标，进而影响到能否设计与提供有针对性的培训课程，因此对培训的有效性起着至关重要的作用。如果不进行有效的培训需求分析，企业培训的目标不准确，缺乏针对性的培训就会导致人力资本投资失败，带来资源的大量浪费。在越来越重视人力资本投资的今日，企业加大培训的投入力度虽有其必要性，但前提是必须进行有效的培训需求分析，否则就不能证明培训支出具有合理性。一些企业的培训效果不好，最重要的原因就在于缺少有效的培训需求分析。
然而，培训需求分析作为企业培训管理的关键环节，其成功又在很大程度上依赖于企业管理人员能够掌握一定的培训需求分析技术。随着信息经济的到来，培训需求分析技术已不仅是人力资源管理者而且也是直线管理者需要掌握的一项技能，这是一个明显的发展趋势。由于企业面对复杂多变的市场竞争，越来越需要依赖自己的员工能够迅速应对环境，这惟有通过培训来增进员工的各种能力(包括岗位技能、创新能力、适应能力和变革能力等)，才能不断保持企业竞争力。一方面培训内容的扩展，使培训需求分析的难度增大，它不但要求人力资源管理者而且也要求直线管理者参与到培训需求分析的工作中来，通过两者的配合去适时掌握员工培训需求：另一方面，迅速回应环境变化也需要有适合直线管理者和人力资源管理者(包括人力资源顾问)快速进行培训需求分析的方法和工具，以便他们能及时做出恰当的培训安排。
一般的培训需求分析技术是从组织分析、工作分析和人员分析入手，去查找绩效差距，这种系统的方法较适合大中型企业的人力资源部门进行年度或中长期的培训需求分析，而对于直线管理者则显得复杂了一些，也不适合企业进行短期或及时性的培训需求分析。因此，为了适应快速反应和直线管理者参与培训需求分析的需要，有必要开发操作性强又简便快捷的培训需求分析方法。本文在此介绍的快速进行员工培训需求分析的方法，正是为了满足这种需要。
一、培训需求分析的基本分析框架
培训需求分析可以使用复杂方法，也可以使用简单方法，简单方法来源于培训需求分析的基本分析框架，它可以归纳为有逻辑的三个步骤：
第一步，查找绩效差距。培训需求分析应从何入手，有关培训的理论认为应当从绩效差距入手：培训之所以必要，传统理论认为是因为企业工作岗位要求的绩效标准与员工实际工作绩效之间存在着差距；新的理论则认为也应包括企业战略或企业文化需要的员工能力与员工实际能力之间的差距，这种差距导致低效率，阻碍企业目标的实现。只有找出存在绩效差距的地方，才能明确改进的目标，进而确定能否通过培训手段消除差距，提高员工生产率。
第二步，寻找差距原因。发现了绩效差距的存在，并不等于完成了培训需求分析，还必须寻找差距的原因，因为不是所有的绩效差距都可以通过培训的方式去消除。有的绩效差距属于环境、技术设备或激励制度的原因，有的则属于员工个人难以克服的个性特征原因，只有在员工不是因为难以克服的个性特征原因而存在知识、技能和态度等方面能力不足的情况时，培训才是必要的。
第三步，确定解决方案。找出了差距原因，就能判断应该采用培训方法还是非培训方法去消除差距。企业根据差距原因有时采用培训方法，有时采用非培训方法，有时也采用培训与非培训结合的方法，一切都根据绩效差距原因的分析结果来确定。
二、快速进行员工培训需求分析的三个步骤与相应工具
培训需求分析的基本分析框架，指出了培训需求分析的方法可以归纳为简便快捷的三个步骤，只要配以一定的分析工具，获取必要的信息，并辨认信息的实际含义，就能帮助管理者完成相关分析。
1.查找绩效差距的方法与工具
绩效差距是培训需求分析的切入点，一旦发现员工在什么方面存在绩效差距，就等于确定了绩效差距领域，找到了要分析的目标。而确定绩效差距领域的关键途径是要获取什么人在什么方面存在绩效差距的具体信息，这主要可以从两个方面着手。
首先，从直线管理者获取信息是重要的途径之一。由于直线管理者对下属的情况熟悉，最了解下属工作绩效的问题在哪里，所以只要提供一定的工具，就能帮助他们或通过他们获取存在绩效差距的信息，由此辨别是什么领域存在绩效问题。具体办法是，使用一个空白的培训候选人名单，然后填上有关需要了解的信息，再从有关信息确定绩效差距领域。寻找绩效差距的提问表是一个获取信息的工具，可以帮助直线管理者和人力资源管理者通过提问发现有绩效问题的人是谁，问题存在于什么地方，问题的性质和严重性等具体情况(参见工具1)。
其次，直接从员工那里获取信息也是一个重要途径。由于员工对自己工作中的问题、障碍切身的感受，那么通过他们了解情况也能获取一定的重要信息，这些信息对于绩效差距问题的澄清有重要意义。当然，员工不一定完全清楚自己不懂什么或在工作上缺少什么，以及需要什么样的培训，这就需要由直线管理者给以确认和补充，才能保证信息的准确与完整。具体方法是通过直线管理者给员工发放培训申请表，由员工填写有关信息后，交给直线管理者加以补充，最后返回给人力资源管理部门(参见工具2)。
在这一分析步骤中，关键点在于保持开放心态和严谨态度，善于发现有价值的信息。不要急于马上就考虑解决的方案，也不要先入为主地确定问题所在，需要做的不过是收集存在绩效差距问题的有关信息，此时还远未到下结论的时候。因此在下一步骤开始之前，千万不要害怕花时间去收集信息、理解信息，有时还可以根据收集的信息，通过现场观察或对有关人员访谈进一步发掘信息。
2.寻找绩效差距原因的方法与工具
一旦收集了必要的绩效差距信息之后，就可以进一步分析存在绩效差距的原因是什么，以便确定解决方案。
以上已谈及绩效差距存在多种原因，培训并不是唯一解决方案，只有在员工不是因为难以克服的个性特征原因而存在知识、技能和态度等方面能力不足的情况时，培训才是必要的。因此在获取必要的绩效差距信息后，需要深入思考、反复斟酌，对产生颐效差距的真实原因做出判断，才能决定是否采用培训方案。查找绩效差距原因的方法可以采用绩效问题原因归类法。
绩效问题原因归类法是将绩效差距信息与一定的绩效问题原因分析表相比较，根据具体绩效差距信息显示的特征，通过比较与思考，最后将其归类于其中一种重要原因。绩效问题原因一般分为环境原因和个人原因两大类，环境原因包括生产技术设备落后、工作设计有缺陷、奖酬制度缺少激励性、沟通不足、上级指导不够等；个人原因也分为能力原因和难以改变的个人特征原因。只要发现绩效差距信息符合其中一个项目，就找到了绩效差距原因。如果原因是工作环境方面的或者个性特征方面的，那么即使进行了培训，问题也依然会存在。这样的话，培训部门就会出现工作无效率的情况，带来资源浪费，是应当尽力避免的。所以，在分析过程中主要是全力发现是否存在因员工能力不够而导致的绩效差距。绩效问题原因分析表不存在一个固定模式，它是可以变通的，既可以模仿，也可以根据企业自身实际情况加以省略或补充。在使用时，可以先遮挡解决方案提示的内容，以便在寻找原因时尽可能自己思考，不要马上就看提示得出结论。
3.制定解决方案
找出了差距原因之后，自然就容易得出解决问题的方案。工具3提供的可选择的解决方案实际上指出了一个基本思路，不过在操作时还需要进一步思考和细化，以便针对性更强一些。例如，“个性特征不适应工作”所涵括的范围很大，既可指员工个性与工作职位不匹配(如性格内向不适合销售工作)，也可以指员工个人懒散或进取精神不足，前者企业需要考虑采用调换工作岗位，后者则要考虑采用解聘去解决问题，在这里培训都不是恰当的补救措施。
即使确定了绩效差距是由于员工能力不足的原因引起，也需要考虑员工是否具备学习的条件。一个员工的学习动机不强烈，认为培训课程对自己的职业并不重要，他就不会积极努力地去学习。同时，受训员工存在家庭有小孩或病人需要照顾、个人的文化水平比较低等困难时，培训的效果也会打折扣。如果员工的学习动机不强烈，或存在阻碍学习的困难，让这样的员工参加培训，培训效果自然会受到削弱。所以，培训是一项昂贵的解决方案，需要认真考虑可能导致无效或减低效率的各种因素。如果员工缺乏完成工作的知识和技能而他的受训条件又具备的话，这时培训才是需要的。
如果员工具备完成工作的知识与技能，只是由于设备、沟通、激励等问题妨碍企业绩效的提高，那么培训就不是解决问题的最好方案。但要注意的是，当引进新的技术设备或激励制度时，或改进管理沟通时，就产生了新的培训需求，因为企业期望达到的绩效标准变了。尽管这类培训有时并不是针对所有员工，而是针对管理人员。
三、有效性与局限性
运用快速进行员工培训需求分析的方法，虽能有效克服一些企业存在的培训目标不明确的缺点，但是它也具有一定的局限性。这种方法用于目标小、人数少的及时性培训比较有效，而对于目标大、人数多、具有战略影响的培训则显得有效性较差。其原因就在于，它未能从企业战略和组织环境的角度全面对培训需求进行分析，而仅仅能分析反应性的培训需求(即现存绩效问题反映出的培训需求)，却无法根据企业长期发展和员工职业生涯发展来进行前置性的培训需求分析。因此，在运用这种方法时，如果能结合企业战略目标、企业组织上与技术上的重大变革进行考虑，那么有效性就可能进一步提高。
TA的推荐TA的最新馆藏[转]&[转]&[转]&[转]&如何采取有效的需求分析过程[1]
如何采取有效的需求分析过程[1]
　　对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)―开发者开发的与用户所想得到的软件存在着巨大期望差异。
　　在软件工程中，所有的风险承担者(stakeholder)(这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。 软件需求的定义
　　IEEE软件工程标准词汇表(1997年)中定义需求为：
　　(1)用户解决问题或达到目标所需的条件或权能(Capability)。
　　(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
　　(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
　　需求的层次
　　下面这些定义是需求工程领域中常见术语的定义说明。
　　软件需求包括三个不同的层次―业务需求、用户需求和功能需求―也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。
　　作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
　　Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：
　　开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
　　为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。
　　虽然听上去有些不可思议，但这是教训之谈，在我从事的项目之中，没有一个用户在软件接近完成的时候打电话对我说，我看了你们的软件，我想我必须改动一些地方。在那些日子中，我甚至得了一种电话铃音恐惧症。
　　需求风险
　　下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。
　　1. 无足够用户参与
　　客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。 最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。
　　2. 用户需求的不断增加
　　在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
　　产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。
　　最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。
　　3. 模棱两可的需求
　　模棱两可是需求规格说明中最为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。
　　模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&下次自动登录
现在的位置:
& 综合 & 正文
需求分析的重要性以及如何做好需求分析
需求分析的重要性以及如何做好需求分析
为什么以这个为主题写.是因为最近在做一个购物网,需求没有做好,导致做前台的时候商品与图片是1对1的关系,后台添加的时候有很大的弊端.和漏洞不好弥补.不是不好弥补.是牵扯的逻辑太多.如果说改了这个网站可以重做了.所以说很失败.
如果因为一个地方的失误.很可能导致整个项目的失败.那么你最近的所有努力将灰飞烟灭...
那么,如果在项目开始前做好充分的需求.而且需求要做的到位,需求的思维严谨程度至关重要..
一. 为什么要需求分析
需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
(这个问题是最典型也是最常见的,现在这个问题一般很好避免,都知道项目的一些敏感性的东西,例如想会有哪些地方设计的不好可能导致以后的使用出现BUG.)
二. 需求分析的任务
简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.
三. 需求分析的过程
需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
(1) 问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
(2) 分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
(3) 制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
四. 需求分析的方法
需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.
五. 需求分析的20条法则（本节摘自软件工程专家网）
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1. 分析人员要使用符合客户语言习惯的表达 　　
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2. 分析人员要了解客户的业务及目标 　　
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
3. 分析人员必须编写软件需求报告 　　
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4. 要求得到需求工作结果的解释说明 　　
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5. 开发人员要尊重客户的意见 　
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6. 开发人员要对需求及产品实施提出建议和解决方案 　　
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7. 描述产品使用特性 　　
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8. 许重用已有的软件组件 　　
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9. 要求对变更的代价提供真实可靠的评估 　　
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10. 获得满足客户功能和质量要求的系统 　　
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11. 给分析人员讲解您的业务 　　
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12. 抽出时间清楚地说明并完善需求 　　
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13. 准确而详细地说明需求 　　
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14. 及时作出决定 　　
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15. 尊重开发人员的需求可行性及成本评估 　　
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16. 划分需求的优先级 　　
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17. 评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18. 需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19. 遵照开发小组处理需求变更的过程 　　
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20. 尊重开发人员采用的需求分析过程 　　
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么 　　
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。” 　　
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。” 　　
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。” 　　
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
　　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
六. 点评需求分析误区
要想说什么是好的需求分析，不如说什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情况：
(1) 创意和求实
毋庸质疑的，每个人都会为自己的一个新的Ｉｄｅａ而激动万分，特别是当这个Ｉｄｅａ受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。
永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。
(2) 解剖的快感
几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。
永远别忘了：分解是必需的，但最终的目的是为了更好的组合，而不是为了分解。
(3) 角度和思维
经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都要用几百次甚至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？
永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。
(4) 员逻辑
从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。比如说１／０逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样，其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三分之一的情况占了９９％的比例，其它两种情况一年都不会遇到一次。实际中还有很多这样的例子，不一一列举了。
永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。
&&&&推荐文章:
【上篇】【下篇】