1.需求获取1.1 获取过程  动获取需求和被动受理需求的过程和方法基本相同 1.2 需求层级 从由浅入深来看，需求又分为4层： 1) 业务需求（business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。 2) 用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。 3) 功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。 4) 系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。 1.3 目标内容 需求分析师应在需求获取前明确需要获取的需求信息，以确保在实施需求获取时有的放矢。 通常需求获取要获取的信息包括三大类： 1) 与问题域相关的背景信息（如业务处理流程及过程文件资料、角色、岗位职责、组织结构图等）； 2) 与要求解决的问题直接相关的信息； 3) 用户对系统的特别期望与施加的任何约束信息（如完成时间、质量、技术要求等）。 1.4 获取渠道 需求分析师在明确了所需要获取的信息之后，应确定获取需求信息的来源与渠道，以提高需求分析师在需求获取阶段的工作效率，使得所收集的信息更加有价值、更加全面。需求信息的来源通常包括： 1) 公司内部的业务需求，客户或合作伙伴 2) 竞品分析：竞争对手的产品优势与不足 3) 专业交流：专家交流，行业交流 4) 实施过程中需要衍生出的支撑需求或额外需求 1.5 获取方法 在明确须获取什么需求、需求的来源与获取渠道后，应选择至少一种需求获取技术获取相关的需求，作为需求分析的依据。需求获取技术包括但不限于： 1) 客户访谈 2) 需求讨论会 3) 现场观摩用户的工作流程，观察用户的实际操作 4) 同行对标，竞品分析，行业交流 5) 社会化媒体：搜索引擎、IM、BBS、Blog、SNS社区、Blog、Twitter、百度知道等社会化新媒体 6) 客户调查 7) 用例模型 8) 原型 1.6 采集要求 根据所采用的需求获取技术，在需求获取过程中将产生不同的记录和原始资料，项目组应将这些记录纳入开发库进行配置管理（SVN）。需求获取的记录与资料包括但不限于： 1) 需求背景/目的/环境 2) 需求采集计划； 3) 用户访谈的访谈纪要； 4) 需求研讨会的会议纪要； 5) 用户需求清单； 6) 业务规划材料：业务逻辑图、业务计划等； 7) 业务作业流程资料：业务作业过程中的表单、流程规范等； 8) 用户编写的原始需求文档； 9) 需求原型； 10) 用户填写的需求调查表； 11) 相关的政策法规文件以及行业标准文件。 1.7 获取原则 1) 永远不要显得比客户更聪明 第一条：了解需求，而不是去批评客户； 第二条：客户比你更熟悉业务的环境； 第三条：客户总是知道问题在哪儿，你的工作就是要让他们自己愿意说出来； 2) 尊重用户的现实选择 第一条：客户永远是对的； 第二条：提供最合适的解决方案，而并非最好或最贵的方案； 第三条：不要把客户当傻瓜； 3) 转述需求的人也是客户 第一条：转述者一般会把自己想象成设计者； 第二条：转述者可能会遗漏或补充一些额外的需求； 第三条：对转述者的自由发挥不应抱怨和生气，而是将其视为客户； 4) 客户和用户要区别对待 第一条：产品为最终用户设计，需求的功能转换为最终用户的使用要求而确定； 第二条：为客户寻找价值上的需求； 第三条：用户的利益高于一切； 5) 用最简单的文字工具记录需求 第一条：所有人都能懂的东西，最不容易出错； 第二条：不需要再学习的东西，最不容易出错； 第三条：不要希望客户能花更多的时间来了解需求转换后的模型； 第四条：保持沟通的通畅，是了解需求的保障； 6) 天下没有免费的午餐 第一条：客户从来没有不合理的需求； 第二条：客户的要求都是可以实现的； 第三条：我们能做这事－这是所需的成本； |
|
|
