〈畅销书〉市场营销书籍集萃0235-获取用户需求十大技巧.pdf

更多资料请登陆 获取用户需求十大技巧 成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用 户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解 决，而开发人员开始帮助用户解决这个问题，沟通就开始了。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的 活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就 是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成 的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的 这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边 界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。 其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个 系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统， 而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好， 也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以 一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发 人员之间的交流很容易出现障碍，忽略了那些被认为是很明确的信息。最后是 需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。 为了克服以上的问题，必须有组织的执行需求的获取活动。 需求获取活动建议要完成的 11 个任务或者说步骤分别是确定需求过程、编 写项目视图和范围文档、用户群分类、选择用户代表、选择用户代表、建立核心 队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查 问题报告和需求重用。当然应该根据组织和项目的具体情况进行适当的裁减，比 如根据项目和用户情况把需求获取会议改成问卷调查或者座谈等等。 更多资料请登陆 1、编写项目视图和范围文档 系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能 性需求。业务需求说明了提供给用户新系统的最初利益，反映了组织机构或用户 对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户 需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本 说明中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完 成他们的任务，从而满足了业务需求。 非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反应速度、 容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户 需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文 档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问 题解决方案的商业和技术可行性，所有的使用实例和功能需求都必须遵从的标 准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目 相关人员对项目的目标和范围能达成共识，整个项目组都应该把注意力集中在项 目目标和范围上。 2 、用户群分类 系统用户在很多方面存在着差异，例如：使用系统的频度和程度、应用领域 和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上 的布局以及个人的素质和喜好等等。根据这些差异，你可以把这些不同的用户分 成不同的用户类。与 UML 中Usecase 的Actor 概念一样，用户类不一定都指人， 也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成 为系统需求。将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任 务状况，将有助于需求的获取和系统设计。 更多资料请登陆 3、选择用户代表 不可能对所有的用户都进行需求获取，这样做时间不允许效果也不一定好， 所以要识别出能够确定需求和了解业务流程的用户作为每类用户的代表。每类用 户至少选择一位能真正代表他们需求的人作为代表并且能够作出决策，用户代表 往往是本类用户中三类人：对项目有决定权的领导、熟悉业务流程的专家、系统 最终用户。 每一个用户代表者代表了一个特定的用户类，并在那个用户类和开发者之间 充当主要的接口，用户代表从他们所代表的用户类中收集需求信息，同时每个用 户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。 4 、建立核心队伍 通