如何分析企业管理信息系统的需求

张靖笙旧作新改

摘要:

    文章分析了企业管理信息系统需求的特点，结合作者在工作实践中分析了传统需求分析方法在开发企业管理信息系统中遇到的问题，提出相应的解决方法。

关键字:

    软件工程，需求分析，企业管理信息系统

前言:

作者曾在一家大型国有商业银行担任软件工程师工作多年，按照软件工程理论组织开发工作一直是我对于自己的要求，但为单位开发信息系统的过程中工作实践中，我发现严格套用传统软件工程理论在需求分析方面的规范比较困难。

传统需求分析规范在实践中的遇到的矛盾

需求分析阶段关系到一个软件开发的成败，这已经得到了普遍的认识,然而，根据作者在实际开发工作的自身经历，以及作者曾主动地和许多同行的交流中发现，发现现在国内的许多软件开发的需求分析阶段，基本没有按照严格的软件工程的规范要求，可以说，在许多开发项目中，按照传统软件工程规范要求的需求分析往往是一个非常尴尬的过程，为什么呢?

    这是因为软件开发人员没有工程观念吗？国际软件工程理论和技术引入我国也差不多二十年了，特别是在二十世纪九十年代，我国计算机软件产业得到了长足的发展，涌现了大量成功的软件开发成果,培养了相当规模的软件开发队伍。作为软件开发生力军的年轻的软件工程师大多数是刚刚从学校毕业的大学生，学校教育中软件工程是一门非常重要的课程，可以说现在的绝大部分程序员在这方面经过了严格的教育和训练，而为什么在实际工作中出现了很大的偏差?

根据我在实际工作中的经验,问题主要来自以下方面：

1.需求分析本身的难度。需求的任务是了解和描述软件用户对软件的需求，即明确做什么。但在实际的软件开发中，用户了解他们的专业领域，但计算机知识，特别是软件知识往往比较薄弱,而开发人员与此恰好相反，而在需求分析的过程中，双方面对的往往不是一个可见的产品，而只是头脑中的构思和想象，由于专业的差异和沟通的有限，用户的许多需求对开发人员来说往往是难于理解的和准确把握。

2.传统软件工程规范没有量化需求分析工作。传统软件工程理论中对需求分析工作的要求只是对软件要求整体上的分析，不要求陷入实现上的细节。但实际工作中，在许多类型的应用系统开发中，许多技术细节本身就关系到需求能否实现或正确实现，如有企业管理信息系统程序开发经验的人谁都知道，根本不可能抛开数据类型去定义一个数据实体的属性。所以在实际的工作中忽略这些至关重要的细节的需求分析往往是不完整的，造成的混乱往往严重影响后续的开发。所以需求分析工作到底深入到什么程度，这个并没有确定的标准。

3. 传统软件工程规范在需求分析的严格执行有实际管理上的难度。在广大的应用软件开发部门，软件开发工作的地位往往只是本单位业务的辅助，一般没有专职的而且非常有经验的系统分析员，需求分析往往由主管经理和开发程序员简单进行，而领导往往重成绩多于重过程，对于一个没有显效的需求分析过程，领导的耐心往往有限，这就造成了对需求分析缺乏严格的管理和要求。

4.严格按照传统规范要求进行需求分析在时间和开发成本的限制。由于用户对软件技术的认识水平，他们对软件的开发在时间上往往要求过高，他们狠不得明天就可以使用软件。如果你在那里分析来分析去不动手，在实际工作中，特别当用户是单位的上层领导，他们往往觉得这种对他们而言空洞无物的分析是开发人员的纸上谈兵,时间一长不免就会流露出不满。这令开发人员非常尴尬，往往非常严重地打击他们的自信心和士气。

综上所述，传统软件工程规范中需求分析理论在实践中的矛盾是成本，效率和规范要求间的矛盾。而忽略规范要求的代价也是惨重的，那我们能找到一种方法解决以上矛盾吗？我觉得提高软件工程规范要求中在需求分析阶段的可操作性是解决问题的关键。当然由于计算机应用的多样性，我们不可能找到能医百病的灵丹妙药，但在开发比较常见的企业管理信息系统中，下文试图提出一种比较有针对性的需求分析方法。

企业管理信息系统程序的需求特点

    数据库技术的核心思想是数据的独立与共享，所以开发企业管理信息系统，就是利用计算机数据库技术来组织，管理和使用企业经营和管理活动中的各种信息。不同形式的企业管理信息系统可谓多种多样，但功能需求的核心是围绕着数据库管理的信息来展开的。笔者曾开发过多个不同应用领域的数据库的应用，我发现在企业管理信息系统中虽然功能很多，许多功能在逻辑上相似，往往只是处理的数据不同，很多时候，信息管理软件功能基本上是数据的查询，更新，维护,并不需要复杂的算法。所以，我认为企业管理信息系统需求分析应该围绕数据(信息)，而不是功能展开。这与传统的需求分析中以分析功能需求为核心有明显的不同。从这个意义上，如果传统需求分析阶段是“做什么”，在企业管理信息系统需求分析阶段就是先要解决“有什么”，然后再明确“做什么”。

企业管理信息系统的需求特征

    需求分析作为软件工程的第一阶段，是整个软件开发项目进行设计和实现的基础，决定了一个项目的成败。但是需求分析不能只看成是一个独立的阶段，第一个阶段了解的需求也只是初步的需求，对需求的了解贯穿整个项目的始终，了解需求的过程是一个逐步细化，逐步深入的过程，整个项目自始而终都需要与用户交流。

    既然企业管理信息系统需求以数据为中心，在需求分析阶段就强调数据和数据结构的分析一点也不过分。所以，对于企业管理信息系统系统，应该把数据库的详细设计向前移，即从传统软件工程阶段的详细设计阶段提前到需求分析阶段进行。

    需求分析大体上分为以下几个阶段：

    1)模型需求分析(总体设计)

    2)概念需求分析(概念设计)

    3)细节需求分析(详细设计)

    4)输入输出需求分析(界面设计)

    这些需求分析贯穿整个项目的各个环节中，与设计是穿插在一起。

需求分析过程活动

1)模型需求分析

    这个阶段体现了系统的总体构思与设计，任务是了解系统的组织形式和功能需求概貌，解决“是什么”的问题。我认为模型需求分析主要任务是系统架构的定义，这涉及到硬件，用户环境，系统功能等多方面的全局考虑。如系统是C/S模式还是Internet模式，如何进行功能的分层。这些都需要在模型需求分析过程中决定。

    模型需求分析工作是项目的早期，所以对功能的描述应该有高度的抽象性，在理想的情况下，一个系统最好由一句话或一张纸内描述，便于开发人员对系统目标的整体把握，也保持了与用户交流的灵活性和一致性。所以在项目初期，我不赞成用功能模块图对功能需求做太多层次的金字塔式罗列，特别如果是系统的分布式分层设计，详细的功能模块图在项目早期没有什么实际意义，反而容易舍本求末。

    我们完全可以把完整的功能模块图放在细节需求分析阶段完成。

2)概念需求分析

    概念需求分析的任务是对系统中涉及的概念进行调查和分析，分析有什么信息，如何组织和描述数据，数据由那些数据项组成，各数据项是什么含义，数据的走向是什么样的？概念需求分析的目的是建立系统的概念模型，主要是建立描述数据的静态模型和描述系统运行流程的动态模型，解决“有什么”问题。

    当完成模型需求分析后，就要进入到概念需求分析。做概念需求分析，首先要收集原始资料，然后请用户讲述手工的工作流程，根据用户提供的原始资料和对工作流程的了解的基础上，我们才可以着手进行概念设计。

3)细节需求分析

   细节需求分析要在完成概念设计之后进行，这个阶段是分析如何具体实现用户需求,就是解决“怎么做”的问题。这个阶段要对用户的需求完整而清晰地确定下来，所以与用户的交流比前两个阶段多，交流的内容应该更加具体。

   细节分析的具体任务是要根据概念设计定义的概念模型制定具体的实现细节。对于静态模型，要给出详细的数据字典，包括了表，数据项，数据项限制条件等详细信息。对于动态模型，要给出具体的状态定义，事件定义，状态改变的流程，对数据所有操作的定义等等详细的设计信息。要求根据细节需求分析的成果应该能成为编码和建库的依据。

4)输入输出需求分析

   用户能否用好软件最终决定项目的成败，良好的用户使用界面是不可忽视的。用户界面的好坏并不是追求界面的花巧(这是程序员经常犯的毛病),而是界面的设计是否能提高用户使用软件的效率，这需要了解用户的使用环境，操作水平，操作习惯，个人喜好等多方面。输入输出需求分析要做到界面设计和概念设计的相互独立，不能因为界面的表示影响概念设计的稳定，同时也要保持能适应用户各种不同操作要求的灵活性。具体可以先和用户共同草拟一些界面设计大纲，在开发过程中邀请用户试用软件，根据反馈意见不断改进和修改。

分析信息内容的工具选择

    我们分析“有什么”信息，传统的需求分析理论用数据流图和数据字典来表达“有什么”信息。数据流图核心是功能，而在许多企业管理信息系统特别是信息管理系统开发初期，在没有清晰完整的信息构成分析前，功能的需求往往难以稳定。在开发企业管理信息系统的需求分析初期，我不提倡使用数据流图，因为在企业管理信息系统中，数据流图往往不能令人满意地说明信息构成问题，而且随着数据的增加，功能流程的变迁需要经常修改早期的设计，这会造成工作的反复。数据字典可以表达数据的构成，但却没有定义数据的类型。在一个企业管理信息系统中，数据的类型的通过字段类型表达，有开发经验的人应该知道，清楚每一个数据字段的含义和类型在开发企业管理信息系统中有重要的意义，试想一下，如果一个字段是图象型，对数据的功能需求不言而喻。而传统的需求分析过程不要求确定数据的具体类型，而在开发一个企业管理信息系统时，需求分析阶段忽略了这一步就会毫无疑问地造成对需求理解的模糊，并使得需求分析变成空洞无物的纸上谈兵。

小结

    设计过程更要和人工智能，知识库，程序语义等最新研究成果结合起来，实现用逻辑方法检验数据库设计的完整性，用推理方法使许多设计步骤可以自动进行，并开发自动编码功能，把详细设计的成果直接转换成SQL代码，更大地提高开发效率。进一步我们应该把这些成果产品化，开发一系列CASE工具，最终发展成为一个全功能的软件开发平台。

参考文献:

[1]中山大学软件所:设计规范与实例分析

[2]张海藩:软件工程导论,清华大学出版社，1998年1月

[3]Roger S.Pressman:Software engineering,a practitioner’sapproach,Fourth Edition,McGraw-Hill ,1997

[4]郑人杰，殷人昆，陶永雷:实用软件工程第二版,清华大学出版社，1997年4月

注：本文的原稿2001年6月2日发表在核心学术杂志《中国计算机工程与应用》，当时作者是在读中山大学软件研究所硕士研究生。