|
采访持重要信息的人是需求分析中一个必不可少的过程。但在一个大的系统中许多人必须被采访，这需要许多时间和金钱，但最重要的是这个过程最可能显示现有的业务流程与新系统中的业务流程之间的差别。不同的顾客有可能有不同的或甚至相对的需求，在这种情况下分析员必须协调各方的需要。 www.mypm.net
需求工作会 项目管理者联盟
出于上述原因一般假如一个系统非常复杂的话需求分析最常用的方法是召开需求工作会，在需求工作会上分析员和持重要信息的人一起分析系统的需要和发展解决方案。 项目管理者联盟
这样的工作会最好不要再采访对象的工作场进行，这样采访对象不会被打扰。工作会有一个负责人来保持会议的进程，一个记录员来记录会议的讨论，投影仪和相应的软件是常用的工具。一般需要进行多次会议后才能得到最终结果。 bbs.mypm.net
一般认为需求工作会可以节省不少时间，因此是一个非常有用的工具，但是往往很难同时将所有的持重要信息的人聚集到一起。 项目管理者联盟
一个常见的缺陷是一些持重要信息者在这样的会议上不十分积极，因此他们的需求没有获得必要的重视。这样得到的解决方案必然有限。此外需求工作会是一个很好的分析现有系统的工具，但用它来寻求解决方案就不是十分有用了。 项目管理者联盟
将需求列成合同式的文件 项目管理者联盟
最常见的纪录需求分析的方式是将顾客需求列入一个合同式的表。一个复杂的系统的文件可以数百页长。现代的分析员不愿使用这样的列表，因为它们被证明相当无用，但它们依然相当常见。 training.mypm.net
优点： 项目管理者联盟
·提供一份需求的清单。 项目管理者联盟
·提供一份顾客和开发者间的合同。 项目管理者联盟
·对一个大的系统来说它提供了一份高级的描写。 项目管理者联盟
缺点： 项目管理者联盟
·这些列表可以长达上百页，实际上没有人能够完整地阅读这样的文件来获得一个完整的系统理解。 pmp.mypm.net
·列表中的需求一般都很抽象和缺乏列出的需求互相之间的关联 项目管理者联盟
·这样的列表一般表示不出列出的需求之间怎样组成一个整体。 项目管理者联盟
·从列表中很难看出哪些需求更重要。 talent.mypm.net
·抽象后的列表为读者提供了许多理解的余地，因此不同的读者对文件的理解可能不同。一个项目越大，读者越多，理解的方式就越多。 项目管理者联盟
·从抽象后的列表中很难看出它是否完全。它们往往忽视了许多细节。 项目管理者联盟
·顾客和开发者对这个列表的理解往往完全不同。 项目管理者联盟
·这样的合同式的列表给顾客一个错误的安全的感觉，好像他们的要求都已列入了。但是由于这些列表本身对细节问题不能细述因此许多关键的细节问题实际上并未列出和解决。这些问题一直到后来软件开发时才被发现。那时开发者一般要与顾客再次讨论这些问题并试图按他们的意愿和条件来解决这些问题。 bbs.mypm.net
·这个列表对此后的系统设计不提供任何帮助，它们的结构无法直接进入新软件。 项目管理者联盟
原型（Prototype） 项目管理者联盟
从1980年代中开始，越来越多的人将作原型看作是解决需求分析的困难的办法。原型模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，而实际上在这些屏幕显示的背后还一切都空着呢。这样顾客可以在系统还没有建立之前就做出设计决定。当原型首次被使用的时候它们的效果被视为非常惊人。引入原型往往提高顾客与开发者之间的信息交换。原型的屏幕显示后来往往很少被改变，因此可以大大地降低费用。 项目管理者联盟
但此后十多年的实际应用证明虽然原型是一种有用的技术，但它也有它的缺陷： blog.mypm.net
|
