图1 获取用户需求的活动
　⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；
　⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
　● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：
　⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；
　⑵使需求符合系统的整体目标；
　⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
　分析用户需求
　在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。分析用户需求需要执行下列活动：
　● 以图形表示的方式描述系统的整体结构，包括系统的边界与接口；
　● 通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；
　● 系统可行性分析，需求实现的技术可行性、环境分析、费用分析、时间分析等；
　● 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。

我提需求给分析人员，分析人员总是说我提的不清楚，其实我按照我的业务都已经提交了，我怎么了解他们开发的知识，还总质疑我。经常因为隐含需求他们没考虑到，来质疑我需求变更

churongw 发表于 2012-7-19 11:04
个人觉得：获取客户需要时后，做需求的人员最好结合已有的开发平台做初步分析，因为最终实现的东西还是在平 ...

@嘟嘟猪 @alex

帮忙解答

我想“christina.wang”的角色类似我们的产品策划专员，他们通过调研、收集市场信息、客户需求、产品升级需求等方式进行产品策划工作的开展， 通过多种方式去收集需求信息，保留过程记录，编制《立项建议书》或《产品需求规格书》，经过开会确认能否给公司带来利益，公司现有技术平台是否可以满足等。。。。。。
《产品需求规格书》要描写明确的要求，尽量不要含糊，而且要专门和项目组一起进行对标。哪些指标可以做，哪些做不了，如果做不了，可在允许的范围内裁剪，如果同意做，则在验收阶段则必须一一验收确认。

“christina.wang”提到已经按照流程提交了，但分析人员却说不清楚，这存在着理解上的差异或者流程还可以进行优化。指标尽量量化。如：外观小巧，则可以在定指标的时候写：厚度≤4cm等。且会后要形成报告，通过流程进行“会签确认”。后续再有争执，就有证明了，一般人不会出尔反尔滴。
(*^__^*) 嘻嘻……不知道这样的解答是否有用。。。。。。[ ome.php?mod=space&uid=10791]@christina.wang[/url] [ ome.php?mod=space&uid=291]@gogoat[/url]