《《软件需求管理》美K.E.维格斯Karl+E.Wiegers著007》由会员分享，可在线阅读，更多相关《《软件需求管理》美K.E.维格斯Karl+E.Wiegers著007（8页珍藏版）》请在金锄头文库上搜索。
1、下载第 7章 寻找客户的需求如果你赞成客户的参与是发布一个优秀软件的关键因素，在项目的开始阶段就会努力致力于为你的项目征求各个客户的意见。软件需求的成功，和软件开发的成功都取决于开发者是否尽可能地采纳客户的意见。在第 6章讨论了一种类型的客户 项目主持者 ( s p o n s o r )、项目的幻想者 ( v i s i o n a r y )或市场部门 他们提供了项目的商业需求。本章将集中介绍需求的第二级 用户需求。为了征求客户的意见，必须采取以下几步： 明确项目用户需求的来源。 明确使用该产品的不同类型的用户。 与产品不同用户类的代表进行沟通。 遵从项目的最终决策者的意见。客户参与是避免
2、期望差异 (expectation gap)的唯一途径，这一期望差异表现在客户期望得到的产品与开发者所设计的产品之间不相符。然而，在项目的开始阶段仅仅简单地问一两个客户的需求，然后就开始编码，这样做是不够的。如果开发者仅仅为了客户的最初需求去开发软件，那么，他们可能要重新进行开发，因为，客户常常不知道他们的真正需要，而开发者也不知道。用户提出“需要”的特性并不总是与用户利用新产品来处理他们的任务 ( t a s k )时所需的功能相等价。因此，当你收集到用户的意见后，必须分析、整理这些需求意见，直到你理解它为止，并把你的理解写成文档，然后与用户一起探讨，这是一个反复的过程， 并且需要花费时间。
3、如果你不在这一方面花时间，对预期产品一致的看法未达成共识 最终的后果可能是返工，并且产品不尽人意。7.1 需求的来源软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。需从不同用户代表和来源收集需求，这说明了需求工程是以相互交流为核心的性质。下面是几个软件需求的典型来源。1. 访问并与有潜力的用户探讨为找出新软件产品的用户需求，最直截了当的方法是询问他们。本章讨论如何寻找合适的用户代表，而在第 8章讲述从这些代表中获取需求的技巧。2. 把对目前的或竞争产品的描述写成文档文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。3. 系统需求规格说明一个包含软、硬件的产品需要一
4、个高档次的系统需求规格说明以介绍整个产品。系统需求的子集被分配到每个软件子系统中（ Nelsen 1990） 。附加的详细软件功能需求将从有关软件的系统需求里获得。4. 对当前系统的问题报告和增强要求指导用户和提供技术支持的工作人员是最有价值的需求来源。他们收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。5. 市场调查和用户问卷调查调查有助于从广大有潜力的用户那里获得大量定量的数据，务必调查相关的用户并询问一些能产生反响的好问题。6. 观察正在工作的用户对当前系统的用户和将来系统的有潜力的用户，分析员观察“日常工作”以获得经验，这些经验能提供很有价值的信息。分析
5、员可通过观察用户与所关联的任务环境的工作流程来预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程的方面（ McGraw and Harbison 1997; Beyer and Holtzblatt 1998） 。比起仅仅简单地询问用户，并记下用户在处理任务时的步骤来说，直接观察用户的工作流程可以对他们的活动有更正确的理解。分析员必须抽象和总结用户的直接活动，以确保所获得的需求具有普遍性，而不仅仅代表单个用户。一个富有技巧的分析员还可以为改进用户的当前事务处理过程提出一些见解。7. 用户任务的内容分析通常通过开发具体的情节（ s c e n a r i o）或活动顺序（有
6、时称作“情节” ） ，可以确定用户利用系统需要完成的任务，分析员由此可以获得用户用于处理任务的必要的功能需求。这是使用实例方法的精髓（参看第 8章） 。7.2 用户类产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异，你可以把这些不同的用户分成小组。比起其他用户，其中某些用户类的需求可能对你更为重要（ Gause and Lawrence 1999） 。每一个用户类都将有自己的一系列功能和非功能要求。比如：一个没有经验或偶尔使用电脑的用户关心系统是否简单易用，
7、因此，菜单、提示符和向导是很重要的。然而，对于那些一天使用几小时产品的用户，他们更关心产品的易用性和高效性，所以他们喜欢使用快捷键、宏以及脚本功能 (scripting facility)。有一些受产品影响的人并不一定是产品的直接使用者，而是通过报表或其它应用程序访问你产品的数据和服务。这些非直接的或次级 ( s e c o n d a r y )的用户也有他们的需求，于是他们组成了附加的用户类。就像我的同事 K a t h y所说的： “只要一日是你的用户，则终身都是你的用户。 ”用户类不一定都指人，你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程
8、序接口，可以帮助你确定产品中那些与外部应用程序或组件有关的需求。在项目中，要尽早为产品确定并描述出不同的用户类，这样，就能从每一个重要的用户类代表中获取不同的需求。我听说过一个给 6 5个团体用户开发一个专门的业务产品的公司，当他们意识到可以把用户分成 6个截然不同的用户类时，这些用户对未来发行的产品的需求就被简化了。在软件需求规格说明中，把这些用户类和他们的特征编写成文档。现举一例，在前面所讨论的“化学制品跟踪系统”中，项目的管理者所确定的用户类和他们的特征如表 7 - 1第 7章 寻找客户的需求 53下载所示。表 7-1 “化学制品跟踪系统”的用户类药剂师 药 药剂师将使用系统请求来自供应
9、商和仓库的化学制品。药剂师每天多次使用系统，主要用于跟踪进出实验室的化学制品容器。药剂师需要在供应商目录中查找指定化学制品采购者 药 采购者在采购部门处理其他用户所提交的化学制品请求，他们与外部的供应商建立联系，制定并发出订单。采购者对化学制品几乎不了解，因此将需要简单的查询机制来查找供应商目录。采购者不使用系统中容器跟踪这一特性。每个采购者平均每天使用系统 1 0次化学制品仓库人员 药 化学制品仓库人员包括三个技师，管理着多达 500 000种化学制品容器。他们将处理来自药剂师的请求并提供可用的容器，向供应商请求新的化学制品以及跟踪进出仓库的所有容器的流向，他们是货存清单和化学制品使用报告特
10、性的唯一使用者。由于交易量大，化学制品仓库人员所使用的系统功能必须是自动化并且高效卫生和安全人员 药 卫生和安全人员使用系统是为了生成符合官方关于化学制品使用和处理规则的季度报表。这些报表必须提前定义，并不需要特别查询能力，当官方的规则改变时，卫生和安全管理人员可能每年多次要求变化报表中的内容。报表变更优先级最高7.3 寻找用户代表每种类型项目 包括企业信息系统、商业应用程序、集成系统、软件嵌入式产品、 We b开发程序和签约合同的软件 在获取（ e l i c i t a t i o n）用户需求时需要挑选合适的用户代表来反映各类用户的需求。用户代表必须参加整个软件开发生存周期，而不仅仅是只
11、参加开始的需求阶段。虽然你必须把重点放在最重要的用户代表身上，但是你还是需要广泛的用户参与者来代表不同的用户类和不同的专业层次。当公司开发应用程序时，最容易接近真正的用户。然而，如果你正在开发商业软件，可能要在开发过程的早期阶段，从目前的 b e t a测试版或先前版本产品的使用者中收集需求意见。建立现存的长期客户关系或组成一个核心用户组，它是由目前产品的用户组或竞争产品的用户组组成的。如果建立起一个用户组，必须明确，这些参与者是否真正代表了各个方面的用户，而这些用户的需求是否可以促进产品的开发。核心用户组必须包含各种用户类型，不仅包括知识渊博的用户，还应包括缺乏经验的用户。如果核心用户组仅代
12、表早期的需求提供者或空想家，那么将会遇到一系列复杂和技术上困难的需求，这些需求与目标市场没有太大的关系。图 7 - 1描述了用户的需求和开发者之间的一些典型的信息关联。当开发者能直接与有关的用户对话时，就产生了最直接的交流；非直接联系一般是无效的（ Kiel and carmel 1995） 。就象孩子们“打电话”的游戏一样，在用户和开发者之间插入一些中间层，会增加他们之间交流信息时产生错误的可能性。例如：如果开发者只向最终用户的管理者获取意见，那么这些需求就不太可能正确反映用户的需要。你必须确信，插入的这些层次是具有价值的，就像一个有经验的需求分析员可以与用户或其他参与者一起工作，为开发者收
13、集、评价并组织整理需求信息。必须确信你明白你所承担的风险，这个风险就是使用市场人员或其他人员作为用户真正需求的代理人，你还要判断这些风险是否值得承担。虽然要获得最优的用户代表是困难的，且可能要花很多钱，然而，54 第二部分 软件需求工程 下载如果你不与能提供最佳信息的人交流，那么你的产品和用户将蒙受损失。图 7-1 用户和开发者之间的可能通讯路径7.4 产品的代表者许多年前，我曾经是一个软件开发小组的成员，这个开发小组支持着一个大公司的科学研究活动。当我们组建开发组时，决定我们的每一个工程项目都包括为数不多的核心参与者，这些参与者来自相关的用户团体，并提供客户的需求。我们称这些人为产品的代表者
14、（ project champion）或项目的代表者， （ Wedgers 1996a） 。通过产品代表者这一途径，可以提供一个有效的方法来使客户 开发者之间的伙伴关系结构化和形式化。每一个产品代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。产品代表者必须是真正的用户，而并不是用户的代理人，如主办者、产品客户、市场人员或者软件组成员充当用户。产品代表者从他们所代表的用户类中收集需求信息。每个产品代表者都负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。目的就是由每个产品代表者与分析员合作，为那个用户类整理出统一的需求意见。虽然分析员通常起草需求文档，但需求的收集
15、与整理是分析员和一些核心客户的共同责任。一个优秀的产品代表者对新系统有明确的认识并有极大的热情，因为他们知道新产品将使他们以及他们的伙伴受益。产品代表者必须是有力的交流者，且是同组成员的代表者。他们必须对应用领域有彻底的了解，并在软件方面具有足够的经验，他们知道在当前技术背景下，什么是可行的；在运行环境中，什么是可实现的。通常，许多产品代表者在工作中又去承担其它的任务，因此，你必须有令人信服的观点，阐明一些特殊个人的参与对项目的成功具有重要意义。如果产品代表者有足够的权利为他们所代表的用户作出共同的决定，那么他们将会很好地发挥作用。如果产品代表者的决策总是受到管理者或软件开发小组的否决，那么他
16、们所花的时间和心思 ( g o o d w i l l )就白白浪费了。然而，产品代表者必须牢记，他们不是唯一的用户。我曾经见过产品代表者工作失误，因为充当核心联络角色的产品代理者没有与他们的同行进第 7章 寻找客户的需求 55下载开发人员需求分 析者市场人员采购者用户产品代表用户管理者系统设计者帮助桌面行充分的交流，而仅仅代表了他们自己的需求和对产品的概念。7.4.1 寻求产品代表者如果你正在开发业务软件而不是内部软件，就很难在你的公司之外寻找可以充当产品代表者的人。但是，如果你与一些大公司的用户有着紧密的工作伙伴关系，那么他们会很乐意或（要求）参与用户需求获取。此时，你将面临着一个挑战：如何避免片面地听取某些产品代表者的需求而忽视了其他代表者的需求。如果有一个广泛的客户基础，那么你就有可能先确定代表所有客户的核心需求，而后确定对于特定个体客户和用户类的附加需求。只有在产品代表者通过商业展示会或其它专业上的交流相互联系之后，他们才可能与其它公司的产品代表者相互交流。不过，这样存在
