用户需求分析 User Requirement Analysis
在系统设计之前和设计开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据.
把握用户需求，才能做出用户真正喜欢的网站。如果不考虑用户需求，网站的页面设计得再漂亮，功能再强大，也只能作为摆设，无法吸引到用户，更谈不上将网站用户变为你的客户。
1、用户类型划分
对用户需求的分析，首先要考虑的，就是用户类型。
网站是面对国外客户，还是国内客户？
网站是面对经销商，还是面对终端客户？
网站是面对家庭购置者，还是面对个人消费者？
网站是效劳老客户为主，还是吸引新客户？
面对不同的用户类型，网站需要满足的用户需求也不同。
2、用户需求分析
确定好用户类型之后，接下来就是研究用户所关注的内容了。怎样确定用户关注哪些内容呢，除了向企业的销售人员调研，也可以做一个简单的“角互换〞思考，如果你是用户，那么你会从哪些方面来考察企业呢？如果你是用户，你会希望看到怎样的网站？
用户有哪几类？每一类用户的核心需求是什么？〕
  谁是用户：〔什么样的人会使用我们的产品？〕
  用户分类：〔将拥有共同特征或行为的用户聚类，形成典型用户〕
  用户特点：〔人口统计信息、性格、爱好、需求特征等〕
  用户行为：〔行为时间、地点、频率、习惯、消费等〕
1〕用户的明确需求
如产品的展示、公司的介绍、效劳介绍等等，这些是属于用户最根底的需求，一般的企业网站都会有，但是不同网站之间的差异在于细节，比方产品应如何展示才更美观？公司介绍要怎样写才能突出企业优势呢？只有将细节做好，才能打动用户。
  2〕用户的潜在需求
除了满足用户的根底需求，网站筹划者还要深入挖掘用户的潜在需求。比方，一种复杂的技术型产品，用户很可能需要及时的“技术咨询〞以帮助了解；而一款家庭清洁的日化产品，如果网站有“家庭清洁常识〞的介绍，相信会比单纯的产品介绍更吸引用户。
从“ 网络调研 〞到“ 网站诊断〞，再到“用户需求分析〞，网站筹划者完成了网站规划前必要的准备工作，而接下来，才真正到了考验网站筹划者功力时候了
风险躲在需求的迷雾之后
      以上我们看到的是某客户工程经理与系统开发小组的分析人员讨论业务需求。在工程开发中，所有的工程风险承当者都对需求分析阶段备感兴趣。这里所指的风险承当者包括客户方面的工程负责人和用户，开发方面的需求分析人员和工程管理者。这局部工作做得到
位，能开发出很优秀的软件产品，同时也会令客户满意。假设处理不好，那么会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和工程管理的根底。
拨开需求分析的迷雾
      像这样的对话经常出现在软件开发的过程中。客户工程经理的需求对分析人员来讲，像“雾里看花〞般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
1)·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在工程定义与范围文档中予以说明。
开发网站需要什么软件
2)·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
3)·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
4)·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、标准和约束，操作接口的具体细节和构造上的限制。
5)·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告〞在开发、测试、质量保证、工程管理以及相关工程功能中起着重要作用。
      前面提到的客户工程经理通常说明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其它任何说明都应遵循“业务需求〞的规定，然而“业务需求〞并不能为开发人员提供开发所需的许多细节说明。
      下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
      经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求〞。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
      在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否那么不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
      优秀的软件产品建立在优秀的需求根底之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
      由于工程的压力与日俱增，所有工程风险承当者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
客户的需求观
      客户与开发人员交流需要好的方法。下面建议20条法那么，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦〔如一方要求而另一方不愿意或不能够满足要求〕。
      1、 分析人员要使用符合客户语言习惯的表达
      需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语〔例如：采价、印花商品等采购术语〕教给分析人员，而客户不一定要懂得计算机行业的术语。
      2、分析人员要了解客户的业务及目标
      只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并到达期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改良之处。`
      3、 分析人员必须编写软件需求报告
      分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及标准、功能需求、质量目标、解决方法和其它信息。通过这些分析，客户就能得到一份“需求分析报告〞，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地
表达其需求。一份高质量的“需求分析报告〞有助于开发人员开发出真正需要的产品。
      4、 要求得到需求工作结果的解释说明
      分析人员可能采用了多种图表作为文字性“需求分析报告〞的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
      5、 开发人员要尊重客户的意见
      如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听那么明〞。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为工程成功所付出的时间，同样，客户也应对开发人员为工程成功这一共同目标所做出的努力表示尊重。
      6、 开发人员要对需求及产品实施提出建议和解决方案
      通常客户所说的“需求〞已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改良方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
      7、 描述产品使用特性
      客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要 “接口友好〞或“健壮〞或“高效率〞，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
      8、 允许重用已有的软件组件
      需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相
符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发本钱和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
      9、 要求对变更的代价提供真实可靠的评估
      有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、本钱和得失等。开发人员不能由于不想实施变更而随意夸大评估本钱。
      10、 获得满足客户功能和质量要求的系统
      每个人都希望工程成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么〞所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否那么，开发人员开发出的产品很可能无法让您满意。
      11、 给分析人员讲解您的业务
      分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识〞。
      12、 抽出时间清楚地说明并完善需求
      客户很忙，但无论如何客户有必要抽出时间参与“头脑顶峰会议〞的讨论，接受采访或其它获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。