系统需求的获取

5.3　系统需求的获取

5.3.1　需求获取过程

需求获取过程大体可以分为如下几项活动：发现和分析问题、获取需求、归档和需求管理。

1．发现和分析问题

一个成功的系统分析员必需要具备的一项素质就是熟练掌握问题分析技术。在问题分析阶段一般没有经验的系统分析员在试图分析问题的时候，总是把症状当成问题来分析，这是一个十分严重的错误。这样的话分析员在没有解决原来问题的前提下又可能引起新的问题。在问题分析时开发团队一般使用鱼骨图来确定、分析和解决问题。鱼骨图是由日本管理大师石川馨先生所发展出来的，故又名石川图。鱼骨图是一种发现问题“根本原因”的方法，它也可以称之为“因果图”。鱼骨图有三种类型，我们一般用整理问题型鱼骨图（各要素与特性值间不存在原因关系，而是结构构成关系，对问题进行结构化整理），如图5-1所示。

2．获取需求

在前一个阶段的基础上，系统分析员找出了问题。下面分析员要做的是来定义客户的需求。分析员要成功地定义系统需求，就要熟练地掌握收集信息的方法。调查研究就是这么一项有效的方法。虽然它在整个开发周期过程中都要用到，但在需求分析的时候特别重要。调查研究结束之后，其成果（如数据、过程和对象模型）将最终用来记录用户事实和从事实中得出结论。

图5-1　鱼骨图

3．归档需求

在调查研究活动时，系统分析人员必须要有组织的、可理解的和有意义的方式归档信息。这些初始文档为系统分析员使用的建模技术提供指导，系统分析员使用建模工具分析需求，以便确定项目的确切需求。等需求确定下来，系统人员就在文档中将那些需求形式分类，用户则将检查并批准这个文档。

4．需求管理

在项目的开发过程中，即使需求定义文档已经被批准了，新需求的出现及现有的需求的改变仍是很常见的。从以前的经验来看，在系统投入运行以前，有超过一半以上的需求将发生变化。这对于开发团队来讲是一个十分头痛的问题。为了解决在解决需求变化过程中可能引起的众多问题，进行需求管理是必要的。需求管理主要涉及需求变化如何被处理的策略、规程和过程。

5.3.2　对现有文档、表和数据进行分析

对现有系统进行研究时，系统分析员可以通过研究其文档、表和文件建立对该系统的感性认识。一般这个过程要分为两个阶段：从现有的文档中收集事实和文档的抽样。

（1）从现有的文档收集事实：分析员其实第一步要做的是找出结构图。组织结构图列出了在系统中的关键所有者和用户，以及他们之间的关系。分析员需要收集的文档是描述问题的文档。如：信息系统项目请求、公司任务陈述、可能对建议的系统产生约束的政策条款、手册和计算机数据库样本、分析员要将所有收集的文档进行分析以确定信息的时效性。

（2）文档和文件抽样：在研究一个文件或数据库中的每个记录是不切实际的。所以分析员通常使用抽样的技术获得一个样本集，以确定系统中可能会发生什么情况。系统分析员应尽力用抽样表示数据的全部特性和复杂性的表。研究文档来自数据库的表记录时，应该研究足够多的样子，确定所有可能的过程条件。统计抽样技术可以确定样本大小是否足以具有代表性。

5.3.3　调研和实地访问

这种调查研究技术是全面地研究问题领域。在项目开发时很多的问题都不是独一无二的，其他在我们之前可能已经解决了的。组织经常联系或实地考察对类似问题有经验的单位，这些单位愿意共享信息，分析员可能从中获得有价值的信息，这样可以节省大量的开发成本。

5.3.4　调查表

系统分析员可以大量印刷文档并分发给被调查者，然后被调查者可以在自己有时间的时候填写调查表。调查表使得系统分析员可以从一大群人了解事实。很多系统分析员认为调查表技术收集的数据缺少可靠性和有用信息。但是调查表仍然是一种有效的数据收集方法，对调查表的批评许多都可以归因于系统分析不合适的使用调查表。

5.3.5　面谈

一般来讲系统分析员最重要和最常用的调查研究技术就是面谈，面谈可以直接、面对面的交互获取需求。面谈可以用来实现下列目标：了解事实、验证事实、澄清事实、激发热情、让最终用户参与、确定需求以及征求想法。

5.3.6　原型法

另一类调查研究技术就是用于快速应用开发的获取原型法（RAD）。原型化背后的概念是建立用户需求的一个小型的模型。原型化技术通常是一种设计技术，但是这种方法能够应用于系统开发生命周期的早期，以进行需求分析。获取原型是以确定需求为目的的构成原型的过程。

原型法意义是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型法投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，通过和客户充分交流原型，还可以提高客户满意度。

人们发现，要想详细而精确地定义任何事情都是有困难的。实际上，用户很善于叙述其目标、对象以及他们想要前进的大致方面，但对于他们要如何实现那些事情的细节却不甚清楚和难以确定。对于所有参加者，建造一个系统都是一个持续不断地学习和实践的过程。原型技术今天存在于各种形式的开发活动中。如果“原型”可以快速地构造，那么就可以测试一个“好的设想”。如果设想有错，那么就把它丢掉，而不致于造成大的损失；如果设想是对的，就可以进一步求精，而对于想法、概念、观点和要求的正确性，都可以在原型试验室中加以验证，而这一切都必须借助于快速生成工具的支持。目前所谓应用生产器（AG）和第四代生产语言（4GL），都是原型法的有力支持工具。原型法有以下优点：

增进用户与开发人员之间的沟通。在传统的开发方法中，客户主要靠阅读大量的文件了解系统，然后向系统分析员表达他们对系统需求的意见。原型法展示给用户的是可以实际运行的原型系统，用户看得见，摸得着，可以很清楚地把他们的意见告诉给系统分析员。

用户在系统开发过程中起主导作用。结构化方法强调了面向用户的观点，但用户参与较多的是系统分析阶段。而采用原型法进行系统开发，用户在整个开发过程中起主导作用，随时提供现场的第一手资料，帮助开发者认识用户的真正需求。

辨认动态的用户需求。我们知道，系统分析的困难之一是用户与开发者之间的沟通，尤其对一些动态需求，不容易用语言文字来描述。可以实际运行的系统原型有助于开发者发掘和验证这类不易用一般语言来规范交谈的动态需求。在系统投入运行之前，有些功能用户也无法预先知道。复印机刚发明时，人们曾认为其功能只是代替复写纸，在使用实践中才认识到远非如此，复印机才得以有今天这么广泛的应用。信息系统也有类似情况。衍生式的需求是指当系统投入运行之后，用户有了使用经验而提出的需要。在整个开发过程中，原型系统可以启发用户的这些衍生的新需求，并把这些需求告诉开发者。决策支持系统就常有这类需求，适合用原型法进行开发。

缩短开发周期和降低开发风险。原型法以用户为主导，更有效地辨认用户需求，不仅使系统分析的时间大为缩短，而且减少了开发人员对用户需求的误解，从而降低了系统开发的风险。

当然原型法也有不足之处。原型法不如结构化生命周期法成熟和便于管理控制。原型法需要有自动化工具加以支持。由于用户的大量参与，也会产生一些新的问题，如原型的评估标准是否完全合理。原型的开发者在修改过程中，容易偏离原型的目的，使用者在看到原型的功能逐步完备之后，以为原型可以联机使用了，而疏忽了原型对实际环境的适应性及系统的安全性、可靠性等要求，便直接将原型系统转换成最终产品。这种过早交付产品的结构，虽然缩短了系统开发时间，但损害了系统质量，增加了维护代价。原型法的优点主要在于能更有效地辨认用户需求。对于分析层面难度大、技术层面难度不大的系统，适合于用原型法开发。而对于技术层面的困难远大于其分析层面的系统，则不宜用原型法。一般将原型法与结构化生命周期法结合起来使用，用原型法进行需求分析，以经过修改、确定的原型系统作为系统开发的依据，在此基础上完善系统说明书。

5.3.7　联合需求计划

在很多的组织中用小组工作会议代替大量的独立的面谈。小组工作会议就是联合需求计划（JRP）的一个例子。其中高度结构化的小组会义被用来分析问题并定义项目需求。为了能按预期的那样工作，这项技术及类似技术通常需要大量的技术培训。但它可以极大地减少在生命周期阶段中调查研究所花的时间。JRP技术在系统分析和系统计划阶段越常用，可以用来获得小组关于问题、目标和需求的一致的。

JRP要包括一些不同的参与者和角色，期望每个参与者能够参加并主动地参与整个JRP。其主要包括的人员和其角色为：负责人、主持人、用户和管理人员、记录员、IT职员等。

5.3.8　调查研究策略

分析员要使用一种有组织的方法收集事实。一些没有经验的分析员经常直接采用面谈技术。其实这么做不是完全正确的，这些分析员没有认识到一个事实：人们必须完成每天的工作，你的工作不是他们的主要责任，你对他们的时间需求就是金钱损失。所以，为了把分析花的大部分时间用在用户身上，不要直接进行面谈。应该采取如下一些策略：

（1）了解现有文档、表格和文件，在没有同任何人接触的情况下了解很多。

（2）适当地观察工作环境。通过你已经收集到的事实，设计并分发调查表，了解没有完全理解的事情，进行面谈。

（3）作为备选，对于没有完全理解的功能需求进行构造获取原型。

这些策略并不一成不变的，应该为系统每个有关阶段开发一个统一的研究策略，但是每个项目都具有独特性，所以有时有些策略可能是不合适的。