zqrain http://zqrain.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 《掌握需求过程》读后感(二) zqrain 作者: zqrain  链接：http://zqrain.javaeye.com/blog/99840  发表时间: 2007年07月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

需求分析师
分析师是解释者，他必须理解用户所说的关于工作的事情，并将其解释为一个产品的需求规格说明。

需求分析师的几个工作内容
  1. 观察和学习该项工作，从用户的角度来解释它；
  2. 解释该项工作；
  3. 发明完成工作的更好办法；
  4. 以需求规格说明和分析模型的方式来记录结果。

对于以上几点，具体的含义是：
  1. 学习和研究工作，不仅是用户现在做什么，还有为什么这么做！这样才能从用户角度理解工作。
  2. 解释工作的时候，需要对用户的描述进行过滤，跳过对当前技术和做事方式的描述，发现该项工作的实质，而不是它的表象。“人们总是以解决问题的方式来描述问题”，很多时候，听者很容易受到某些问题描述的误导，导致在项目中产生“技术化石”，并从一代产品进入下一代产品。
  3. 在理解工作的实质的基础上，分析师有时候需要给出比目前工作方式更好的解决办法。这么做，不仅仅是帮助客户得到更好的工作方式，或者开发更好的产品；还要考虑，因为用户不成熟，或者对技术不熟悉，他们在需求调研前期，容易忽略很多实际上对他们有用的需求。如果分析师不去主动发现这一部分需求，很可能导致项目后期，随着对系统认识的加深，用户不断提出新的需求，或者修改对系统实现的要求，使得项目走向失败。
  4. 完成以上工作，还需要一个固化的输出，那就是设计师工作的输入，需求规格说明。然而，在敏捷项目中，这个步骤可以忽略，重点师开发者理解真正的需求，是否固化为正规的文档，或是草图替代方案，完全由开发团队自己视情况而定。


“有意识的需求是客户头脑最上层的需求，它们常常代表着客户想改经的东西。无意识的需求是客户常常忘记表述的需求，因为他们对这些需求知道得太多，并假定别人都有同样的知识。做梦都没有想到过的需求是一些有用的需求，但客户没有意识到实际它是可能的.”

在需求分析过程中发现所有的需求更有效，代价更小。在这个工程中没有发现的需求最终会显露出来，也许是在用户开始操作产品的时候。在后面的阶段，为这些新发现的需求所做的修改将更为昂贵。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 11 Jul 2007 14:58:00 +0800 http://zqrain.javaeye.com/blog/99840 http://zqrain.javaeye.com/blog/99840 《掌握需求过程》读后感(一) zqrain 作者: zqrain  链接：http://zqrain.javaeye.com/blog/99724  发表时间: 2007年07月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

第三章 事件驱动的用例

在本章中，作者强调了理解用户工作本质的重要性。同时，作者提出了一系列概念，用于确定系统的范围，对系统需求调研的工作目标进行分解，以获得最终“产品用例”。

这个本质包括，用户做什么，这么做的目的是什么，用户如何做，为什么采用目前的做法，用户最终的目标是什么。越是理解了用户工作的本质，越有可能生产出用户需要的软件系统。

先看一下概念：
  1. 工作：业务活动发生的整个系统。如书店卖书
  2. 相邻系统：与工作发生联系的所有东西。包括受工作影响和影响工作的所有系统，实体和人。如购书的读者，出版社，书批发商等(他们可以是人，也可以是计算机系统)。
  3. 业务事件：完成业务活动时发生的事件。如买卖一本书。
  4. 业务用例：对业务事件的响应。如书店卖书业务事件对应的业务用例：读者拿着他想购买的书去收银台，售货员扫描条码并收银，然后打印发票，将发票和找零给读者。
  5. 产品用例：拟建产品做出的影响，对业务用例的一种计算机实现。
我们最终需要得到的是产品用例，以指导我们的开发工作，而产品用例是业务用例的一种计算机实现，所以我们需要首先得到业务用例。考虑业务用例是由业务事件驱动的，我的目标变成寻找所有的业务事件。

作者提出了一个经验法则：从越远的地方看预期的系统，就越可能发现产品的有用和创新之处。具体来说，首先从相邻系统开始，来认识工作。在需求调研的开始阶段，工作是模糊的，不明确的，我们需要更具它与外部的联系来认识它，界定它。从外部，我们看相邻系统是如何参与工作的，这正是用户所熟知的“业务事件”。

从本章可以学习到：
  1. 用相邻系统和工作的交互，认识工作上下文和工作的本质。
  2. 不是看内部，而是从外部看，这样我们能够很清楚地发现划分工作的最有效的方式。
  3. 不是以产品为中心考虑问题，而是考虑工作的本质。
  4. 不要把思考局限于计算机系统边界，而是应该试着去发现所有可能影响工作的东西。
  5. 如果太沉溺于目前的技术和业务现在的工作方式，有时就难以发现业务事件。
  6. 需求分析师必须超越那些显然的东西，这意味着理解工作的真实本质。

本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 11 Jul 2007 14:56:00 +0800 http://zqrain.javaeye.com/blog/99724 http://zqrain.javaeye.com/blog/99724