功能需求调研

《功能需求调研》由会员分享，可在线阅读，更多相关《功能需求调研（18页珍藏版）》请在装配图网上搜索。

1、功能需求调研-工作报告功能需求调研一:功能需求分析随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。网站项目管理（WpM）的含义为Web-based projectManagement，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web服

2、务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。专业定制大中型网站求职招聘到黑龙江人才网买网站去超市明智的选择网络公司的技术支撑息在本文中，笔者将网站项目管理（WpM）与软件工程的统一过程管理（RUp）进行参照比较，并结合实际工作经验，力求将网站工程管理（WpM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。按照笔者的经验，网站项目管理可以分为以下七个阶段进行控制：1. 需求分析及变更管理2. 项目模型及业务流程分析3. 系统分析及软件建模4. 界面设计、交互设计及程序开发5. 系统测

3、试和xx编写6. 客户培训、技术支持和售后服务需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、xx编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。如何做好网站建设需求分析及变更管理？业务员与客户进行的沟通，撰写如何做好网站建设需求分析是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。企业如何成功建设网站包括以下内容：一. 让客户畅所欲言，罗列出所有的需求 二. 透过现象分析潜在的需求三. 利用自然的语言描述项目模型 四. 利用示意图和图表将用户的需求表现出来。五. 什么人要看需求分析报告？六. 建立需求变更日志，制作新版

4、本的需求分析报告。 七. 本阶段重点工作角色 八. 总结一：让客户畅所欲言，罗列出所有的需求让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕勾引起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你

5、却不知道客户的系统是要承受每天100万独立Ip的访问，而你原来想当然的以为了不起就是1万独立Ip访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！二：透过现象分析潜在的需求很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发

6、过程中变更及今后应用中可能进行修改升级的潜在需求。比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个搜索其他网站相关新闻的按钮，并

7、且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。三：利用自然的语言描述项目模型在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。请比较以下两份关于需求的描述，用户在访问首页的时候可以在点击客户通道按钮，弹出填写用户名和密码的窗口，输入

8、正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。 四：利用示意图和图表将用户的需求表现出来需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。制作示意图可以有很多种方式，用powerpoint或Visio制作流程示意，用htmlxx制作界面示意都是可行的，最简单利用画图

9、和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。在RUp中有这样的描述：利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。以用户友好的方式帮助收集并改进用户需求。鼓励更有创造性、更加创新的设计解决方案。鼓励团队复审，并避免所有人都不希望出现的特征。确保以可理解

10、、直观的方式实施特征。使访谈过程变得轻松，避免出现访谈没有结果的现象。简单地说，制作示意图就是使用工具向用户 (主角)说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。协调员将初始示意板展示给小组，小组成员提供意见。之后，在举办研讨班期间，示意板也进行实时演进。所以，您需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或powerpoint。五：什么人要看如何做好网站建设需求分析项目经理、系统分析员、开发经理、交互设计师、测试人员、xx人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。我们经常会遇到业务人员辛辛苦

11、苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。例如：项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；界面设计人员根据项目的性质和定位确定表现方式。测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；通过下表，我们可以看的出不同角色根

12、据需求的变更所进行的工作流程：六：建立需求变更日志，制作新版本的需求分析报告尽管我们费了许多功夫在如何做好网站建设需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。七：本阶段重点工作

13、角色 在如何做好网站建设需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。在实际工作中，很多项目失败的起因都和需求分析有关。客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。以下提供一份需求管理计划的模板可作为参考： 八：总结根据笔者的经验，要尽快做好如何做好网站建设需求分析掌握以下要点，也许能事半功倍

14、： 仔细聆听，罗列客户的所有要求； 将如何做好网站建设需求分析进行分析，确认可操作的系统模型； 利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意； 迅速确定网站的用户角色；比如访客、会员、重要客户、前台管理员、网站管理员、业务员等； 分析确定每个角色的权限及可操作的功能；比如会员可以查看特别信息、修改个人信息、退出登陆等；前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等；网站管理员可以更改栏目、修改网站界面等； 制作流程图和示意图将需求表现出来； 让客户参与到示意图的设计中，及时正确的反应出需求变更。 制作需求变更日志，保留升级版本，通过版本控制进行需求管理； 通

15、过需求管理计划书使每个参与人员看到共同的努力目标。 功能需求调研二:需求分析方法 项目需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。为了保证项目的成功，监理方必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的

16、基石。在以往建设失败的项目中，80是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用承建方的软件。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、开发范围上有发言权。如何进行需求分析需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为S）的涉及面可能很广，可以按不同

17、的问题域（记为D）分类，每个问题域对应于一个软件子系统。S=D1，D2，D3，Dn问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。Di=P1，P2，P3，Pm问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。Pj=F1，F2，F3，Fk需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题：1.最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。重点监控需求分析

18、由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。客户说不清楚需求有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。此时，用户就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。需求自身经常变动根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需

19、求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。分析人员或客户理解有误软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致

20、以后的开发工作劳而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光有趣的是，车里住着一种叫作人的寄生虫，这些寄生虫完全控制了车。”所以分析人员知识的专一性也会造成需求分析的误解和失败。这时，咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。需求分析方法论根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。第一阶段：“访谈式”（Visitation）这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上

21、把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。实现手段：访谈、调查表格输出成果：调查报告、业务流程报告第二阶段：“诱导式”（Inducement）这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易

22、性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。实现手段：拜访（诱导）、原型演示输出成果：调研分析报告、原型反馈报告、业务流程报告第三阶段：“确认式”（Afirm）这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、xx签字确认。实现手段：拜访（回顾、确认），提交业务流程报告、数据项表

23、；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。功能需求调研三:项目的需求调研应该怎么做效果好？大家常说万事开头难，这个道理不言而喻，事情确实都是开头比较困难些，但万事有开头，如果开好这个头，后面就会简单很多，今天就给大家聊一

24、聊项目早期要做的一件事需求调研。需求调研是最早与用户正式交互的机会，也是快速与用户方建立顺畅的沟通和熟悉业务需求，获得用户认可的关键，同时也是后续系统设计和实现的基础。很多用户不仅仅是业务专家，也是技术和体验方面的专家，需求调研已不再是倾听用户描述业务需求，而是必要做好功课、做足准备。以下结合自己的工作经历（IT类项目），简单做个总结。一需求调研的前期准备1. 制定需求调研计划一直给大家强调万事始于计划，计划永远是先行的，一份需求调研计划可以清楚描述在什么时间完成哪些任务，需求调研计划的目的是与用户沟通确认之后，作为甲乙双方一致遵循的承诺，以需求调研计划为双方在需求调研工作中的协作约定，提高工

25、作的执行效率。2. 需求调研提纲和问题准备需求调研过程中，什么情况都有可能发生，比如不清楚从哪里开始调研，或者调研之后，发现一楼了一些需要调研的内容，或者忘记最终确认一些待确认的问题等，由于与用户面对面需求调研的机会和时间有限，我们一定要在有限的机会内，达到最优质的需求调研效果，这需要我们在需求调研之前详细准备需求调研提纲，罗列出调研的思路，确定从哪些方面开展调研，同时准备需求调研问题列表，对一些需要尽快沟通确认的问题，例如描述模糊的需求，或者有歧义或竞争的需求，需要额外的关注和重视。3. 悉相关的行业和背景知识需求调研之前，需要快速了解和熟悉行业标准及相关业务信息，至少要达到入门层次，能够正

26、常理解用户所表达出的术语和场景，这一点做不到或者做的不好，在需求调研工作中的感觉就如鸭子听雷，你听不懂，用户也讲不出来，造成需求调研的失败。以前曾经经历过一个项目，原计划需求调研为5周，结果最终进行了11周时间，用户耗费大量的时间给需求调研人员讲解行业知识、相关的行业标准和政策，用户后来反馈，这次的需求调研很累，不仅要提出需求，还要先对我们的需求调研人员培训，这就是前期的准备工作没有做到位的影响。4.确认用户类型，规划需求管理模式确认好用户类型对后续的需求调研和需求管理工作都很重要，用户类型基本上决定了用户对需求的态度和变更的程度，一般政府用户多数政治觉悟高，做事谨慎认真，考虑的事情比较全面，

27、需求多数来至于相关领域的政策解读，要求准确性很高，但外延性不高，一般不会突破我们的合同边界，后期的需求变更也比较可控一些。而企业用户一般会本着花最少的成本，获得最大的回报的原则，需求基本上犹如滔滔长江水，绵绵不绝，而且对交付产品的实效性要求较高，后期一般会有比较频繁的需求变更，这就需要调研团队对需求的内容和方向有个预判，规划好后期的需求变更管理流程。二需求调研工作开展1. 明确调研的目的在调研开始时可以和用户一起简述此次调研的目的，明确需求调研的范围，以免用户不清楚目的和范围，发散调研会议议题，甚至跑偏，造成需求调研工作出现问题。2. 邀请用户业务骨干参加需求调研会议参加需求调研的用户最好为业

28、务骨干，能够明确的提出要求，同时能回答我们的问题，并且能够做出决定，保证需求调研的质量和沟通顺畅。同时，要有人数控制，人数太少，可能调研结果不够全面，人数过多，决策统一周期可能过长，一般情况下3-5人的焦点小组会议比较合适。3. 调研过程中认真、专心听取用户的陈述认真的聆听是对用户表示尊重的一种良好方法，尽量在沟通中不打断用户的陈述，同时认真详细的进行记录，表达我们关注他所表达的内容，这样可以提高用户对我们的亲切感和信任度，好处就是用户更喜欢和我们说，我们也就更容易收集到用户的需求。4. 分清用户“需求”还是“想要”很多时候，用户给我们讲出来的想法和要求，根本不是他们的“需求”，而是他们的一种

29、“想要”，“需求”是用户最根本的待解决的问题，而“想要”只是用户已经帮我们想好的一些解决“需求”的办法而已，在需求调研过程中，务必要挖掘到用户的“需求”，通过我们的设计去实现用户的“需求”，而不是盲目的跟从用户的“想要”，结果被用户带到了沟里出不来。5. 界面原型设计是关键多数情况下，很多朋友都会认为在需求调研阶段设计系统界面原型很耗时间和精力，认为没有太大的必要，与用户面对面沟通好需求，系统界面回去设计和开发就可以了，但这样做的结果是你将面对源源不断的界面完善需求变更。如果工期不是非常紧张，建议还是在调研阶段准备界面原型，而且要花心思去设计，这样与用户实际要求的贴合度才会好，后续设计的工作量

30、也会相应减少，而且非常有利于需求确认的达成，开发人员也可以直接参照界面原型来开发，这么一劳永逸的事情，何乐而不为呢？6. 做好需求的引导和管控，避免需求的蔓延用户提出的需求，如果在我们的建设范围内，则要进一步详细的调研和分析，如果不在我们的建设范围内或当时无法确定是否在范围内，也需要先进行记录好，后期可以引导用户通过增加合同内容或者其他途径实现，不要在调研阶段直接“枪毙”用户的需求。7. 每天召开内部讨论会议调研小组可能会分为几组去调研，调研后最好当天完成集体总结讨论，以免调研的关键信息遗漏，并且可以让所有成员全面了解目前需求调研进展，总结并确认一些调研成果。调研小组成员可以把遇到的问题提出来，大家一起讨论做应对策略，从而使后续的调研更有效且更有针对性。结语以上是对需求调研工作的一些简单的总结，希望对大家的工作有所帮助，也欢迎各位朋友一起讨论。最后分享一句自己非常喜欢的话：在前进中摸索，在摸索中实践，在实践中总结，在总结中继续向前。时间不停在流转，机会更多的留给有准备的人。需求调研亦如此，项目管理亦如此，人生亦如此。附：需求调研成果物列表：需求调研计划需求调研问题列表需求调研提纲需求调研记录表（可以配合录音）需求调研总结需求确认单（需用户签字盖章）需求规格说明书（项目范围说明书）文字作者 | 李大鹏本期编辑 | 小圱