管理信息系统需求调研分析指南

摘要：本文是在管理信息系统需求调研实践和学习中的一些经验总结，有些是本身的体会，有些来自专家的书本或文章，但愿与你们分享，并起到一个抛砖引玉的做用，若有不妥之处欢迎指正。

1、软件需求的定义

IEEE软件工程标准词汇表（1997年）中定义的需求为：

（1） 用户解决问题或达到目标所需的条件或能力；

（2） 系统或系统部件要知足合同、标准、规范或其余正式规定文档所需具备的条件或能力；

（3） 一种反映上述条件和能力的文档说明。

2、需求分析的几个方面

需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括如下几个方面：肯定软件所指望的用户类；获取每一个用户的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件；了解相关质量属性的重要性；讨论得出实施优先级；将所收集的用户需求编写成需求规格说明和模型；评审需求规格说明，确保与用户达成共识。

软件需求的各组成部分以下图所示：

3、需求文档规范

A、三种编写方法

一、 用好的结构化和天然语言编写文本型文档；

二、 创建图形化模型，这些模型能够描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系；

三、 编写形式化规格说明，这能够经过使用数学上精确的形式化逻辑语言来定义需求。

多种编写方法可在同一个文档使用，根据须要选择，或互为补充，以可以把需求说明白为目的。

B、应有成果

一、 各业务手工办理流程文字说明；

二、 各业务手工办理流程图；

三、 各业务手工办理各环节输入输出表单、数据来源；

四、 目标软件系统功能划分（示意图及文字说明）；

五、 目标软件系统中各业务办理流程文字说明；

六、 目标软件系统中各业务办理流程图（模型）；

七、 目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。

八、 目标软件系统用户界面图、各式系统逻辑模型图及说明

C、文档工具推荐

一、 调研结果《需求分析说明书》格式参照开发文档模板；

二、 单位组织结构图、功能模块分解图用VISIO绘制，或直接用WORD中的画图工具；

三、 业务流程图用VISIO中的FLOWCHART模板绘制；

四、 系统逻辑模型使用ROSE绘制活用VISIO中的UML模板绘制；

五、 软件用户界面用VISIO中的WIN95 USER INTERFACE模板绘制；

六、 数据物理模型用POWERDESINER绘制；

D、需求文档编写原则

一、 句子简短完整，具备正确的语法、拼写和标点；

二、 使用的术语与词汇表中所定义的一致；

三、 需求陈述应该有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动做和可观察的结果；

四、 避免使用模糊、主观的术语，减小不肯定性，如“界面友好、操做方便”；

五、 避免使用比较性词语，如“提升”，应定量说明提升程度。

4、需求分析的任务与过程

需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“作什么”的问题，所要作的工做是深刻描述软件的功能和性能，肯定软件设计的限制和软件同其余系统元素的接口细节，定义软件的其余有效性需求，经过逐步细化对软件的要求描述软件要处理的数据，并给软件开发提供一种能够转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用户的各项要求，但不能全盘接受，只能接受合理的要求；对其中模糊的要求要进一步澄清，而后决定是否采纳；对于没法实现的要求要向用户做充分的解释。最后将软件的需求准确地表达出来，造成软件需求说明书SRS。其实现步骤如图：

(1) 得到当前系统的物理模型：首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用状况和平常数据处理过程，并用一个具体的模型来反映本身对当前系统的理解。此步骤也能够称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估理解他们的须要及将来系统要解决的问题，而后创建一个业务USECASE模型和业务对象模型。固然若是系统相对简单，也不必大动干戈区进行业务建模，只要作一些简单的业务分析便可。

(2) 抽象出当前系统的逻辑模型：在理解当前系统“怎样作”的基础上，取出非本质因素，抽取出“作什么”的本质。

(3) 创建目标系统的逻辑模型：明确目标系统要“作什么”

(4) 对逻辑模型的补充，如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其余限制等等。

需求分析各过程以下：

（1） 问题识别：解决目标系统作什么，作到什么程度。需求包括：功能、性能、环境、可靠性、安全性、保密性、用户界面、资源使用、成本、进度。同时创建需求调查分析所需的通讯途径。

（2） 分析与综合：从数据流和数据结构出发，逐步细化全部的软件功能，找出各元素之间的联系、接口特性和设计上的限制，分析它们是否知足功能要求并剔除不合理部分，综合成系统解决方案，给出目标系统的详细逻辑模型。经常使用的分析方法有面向数据流的结构化分析方法SA（数据流图DFD、数据词典DD、加工逻辑说明）、描绘系统数据关系的实体关系图ERD、面向数据结构的Jackson方法JSD、面向对象分析方法OOA（主要用UML）、对于有动态时序问题的软件能够用形式化技术，包括有穷状态机FSM的状态迁移（转换）图STD、时序图、Petri网或Z。每一种分析建模方法都有其优点和局限性，能够兼而有之以不一样角度分析，应该避免陷入在软件需求方法和模型中发生教条的思惟模式和派系斗争，通常来讲结构化方法用于中小规模软件、面向对象方法用于大型软件。

（3） 编制需求分析文档

（4） 需求评审

5、需求分析的要求

一、 必须可以表达和理解问题的数据域和功能域：系统的目的都是为了解决数据处理问题，就是将一种形式的数据转换（输入、处理、输出）为另外一种形式的数据。数据域应包括数据流、数据内容和数据结构。数据流式数据经过系统时的变化方式。对数据进行转换就是程序的功能或子功能，两个转换之间的数据传递肯定了功能间的接口。数据内容就是数据项，如人的数据项包括姓名、性别、出生日期等等。数据结构即各类数据项的逻辑组织，如是表格结构仍是树形结构、数据项间的相互关系

二、 必须按自顶向下、逐层分解的方式对问题进行分解和不断细化：软件的功能域和信息与都能作进一步的分解，能够是同一层次上的横向分解，也能够是多层次上的纵向分解。

三、 给出系统的逻辑模型和物理模型：逻辑模型给出软件要达到的功能和要处理的数据之间的关系；物理模型给出处理功能和数据结构的实际表示形式

6、需求调研方法

一、 会谈、询问：围绕软件目标提出具体问题；

二、 调查表：通过仔细考虑的书面回答可能比会谈中的回答更加准确；

三、 收集分析客户使用的各类表格、有关工做责任、工做流程、工做规范、相关数据标准、业务标准的各类文字资料；

四、 收集同类相关产品的宣传资料、技术资料、演示程序或软件程序；

五、 情景分析：利用情景分析诱导用户可以把它们的需求告知分析员（能够描述当前一项业务怎么作、也能够描述设想的系统中此项业务怎么作）；

六、 可视化方法：结和情景分析，利用画用户界面图、业务流程图、功能结构图、时序图等图形与客户进行讨论；

7、调研基本策略

一、 首先肯定用户的软件开发目标，肯定系统基本范围，而后围绕这一目标，肯定要访问的部门和人员，要了解的业务，在基本范围内展开调研；

二、 以部门职责为基础搞清各类现有业务、要填写的表簿册文档报表等，其数据来源及去向；

三、 以业务为主线，搞清每一个业务的每一个环节的流程关系、涉及部门、输入输出项；

四、 以数据为主线，搞清数据采集方式、数据流向、数据之间的内在联系；

五、 搞清哪些业务或数据是已建系统的，它们和新系统的关系是衔接仍是替换；

六、 应思考是否有新技术能够改进现有工做，用户提出的需求用现有技术可否实现。

8、结构化方法分析步骤

一、 画出数据流图。设计数据流图必须逐步求精；

二、 决定哪些部分须要计算机化和怎样计算机化（取决于用户投资限制和自身技术限制）；

三、 描述数据流细节，大型软件可使用数据字典描述全部数据元素；

四、 定义处理逻辑（加工逻辑：每一个加工处理作什么）；

五、 定义数据存储，即定义每一个存储的确切内容及其表示法（格式）；

六、 定义物理资源：如是文件需指定：文件名、组织结构（排序、索引等）、存储介质和记录；如是数据库需指定每一个表的相关信息；

七、 肯定输入输出规格说明，如输入内容、输入屏幕、打印输出格式、输出长度等等；

八、 肯定硬件所需有关数值，如输入量、打印频率、CPU、记录大小、数据量大小、文件大小等等；

九、 肯定软硬件接口和环境需求。

9、UML方法分析步骤

通常的应用系统又是各组成部分：问题论域、人机界面、数据管理、任务管理，在OOA阶段重点对问题论域进行分析，对人机界面、数据管理、任务管理等问题，OOA通常较少或没有分析，而是留待OOD阶段解决。

一、 调研、识别系统需求；

二、 分析问题领域：主要任务是充分理解领域问题和项目投资者及用户的需求，对需求进行抽象，提出高层次的解决方案）；

（1） 肯定系统范围和系统边界；

（2） 肯定系统的约束（环境和条件）；

（3） 定义活动者；

（4） 肯定系统的综合要求（功能、性能、运行）；

（5） 肯定系统的数据要求（名称、范围、类型、数量、特色）；

（6） 创建USE CASE模型、绘制USE CASE图；

（7） 绘制主要交互图；

三、 创建静态结构模型（对象类图、数据库模型、包图）；

四、 创建动态行为模型（顺序图、协同图、状态图、活动图）；

五、 创建系统物理模型（组件图、配置图）；

10、企业级信息系统调研分析步骤

企业级信息系统即着眼于整个企业的信息系统，是一个覆盖企业全部业务领域、适应企业不断发展的综合信息系统，它是一个统一的总体数据具备一致性，提升了系统的综合利用效率。

A、规划阶段

一、 构建高层次的企业模型

（1） 调查组织结构、创建组织关系层次图；

（2） 调查企业的任务、目标、战略重点和关键成功因素并予以分类；

（3） 识别每一个目标和关键成功因素所需的信息；

（4） 给出每一个目标完成的度量标准；

（5） 分析信息技术对企业业务的潜在影响；

（6） 创建高层次企业模型（描述业务处理的主题域及其关系、创建企业初始功能层次图）；

（7） 与企业中高层管理人员讨论，对所得信息和分析进行补充和确认；

二、 对功能进行分解（输出：功能层次图、功能关系图、功能／组织矩阵）；

三、 进行实体分析（输出：高层实体关系图、实体类／信息需求矩阵、业务功能／实体类矩阵）；

四、 评估企业当前环境（现有系统和数据存储的清单、信息结构的范围、信息需求列表、组织、技术环境）；

五、 识别和肯定预期的数据存储和业务系统，创建业务系统的结构图，肯定和记录业务领域；

B、业务领域分析阶段

一、 肯定业务范围、创建组织、制订计划；

二、 进行数据分析、创建详细的数据模型（详细实体关系图）；

三、 业务活动分析（分析业务过程细节、分解业务过程、分析过程间的依赖关系、分析业务交互做用、创建业务活动模型）；

四、 现有系统分析（操做程序分解表、数据流图、用户视图：用户感兴趣的字段集）；

五、 业务领域模型的确认（完整性、正确性、长效性）

11、调研说明与基本问题

很多行业的业务都是由一系列环节构成的业务流程组成的，有的简单只有一两个环节，有的复杂有多个环节，还可能有循环或分枝，系统软件不只要解决独立环节的业务问题，并且要可以自动把这些环节串联起来，但愿一个环节所作的工做可以自动被下一个环节利用，这就是最基本工做流的需求。例如一个案件从接案、立案、侦查、起诉，到执行由不一样的部门来完成。这些环节不是独立的，后面的环节不该该比前面的发生的早，也不能延迟过多，由于存在法律时限，而且流程中存在循环，也就是说某些环节可能重复屡次，再者每一个部门的流程种类又多，每一个工做人员可能要处理多个环节上的任务。所以咱们把每一个业务的每一个环节搞清楚，主要搞清如下几个基本问题：

每一个流程中的每一个环节是否已经不能再分解？

每一个流程中的每一个环节的主办（责任）部门是谁？

每一个环节要求的输入（项目、格式、方式）和输出（项目、格式、方式）是什么？

每一个环节的输入和输出之间的变化或关系是什么？

每一个环节的输入的数据来源是什么？

每一个环节的输出的数据去向是什么？

每一个环节的数据项目有无国家标准或部颁标准或其余标准？

每一个环节的数据项目的类型是什么？

每一个环节的责任人对本环节中数据项目的权限是什么？（可新建、可删除、可修改、只读、）

每一个环节的输入的数据项目有无检验规则？（如不能为空）

从一个环节到下一个环节的条件是什么？

从一个环节到下一个环节有无时间限制？是多少？

收集上来的表单用在哪一个业务中的哪一个环节？

多个表单间的关系：继承？关联？

12、需求管理

需求调研分析过程是一个由粗到细、渐进明晰、持续完善的过程。在指导后面系统设计，编码阶段时都应当不断完善修改需求文档，所以需求管理很是重要。需求管理包括在工程进展过程当中维持需求约定集成型和精确性的全部活动，它是CMM模型二级中的首要KPA（关键过程域），这些活动包括：

（1） 定义需求基线（需求文档的主体）；

（2） 评审提出的需求变动申请、评估每项变动可能的影响，从而决定是否实施变动；

（3） 以一种可控的方式将需求变动融入到项目中；

（4） 使当前的项目计划与需求保持一致；

（5） 分析变动所产生的影响并在此基础上协商出新的约定；

（6） 使每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪；

（7） 在整个项目过程当中跟踪需求状态及其变动状况。

   参考文献：

   《实用》第二版，郑人杰、殷人昆、陶永雷等著

   《软件需求》Soren Lauesen著，刘晓晖译

   《软件工程：实践者的研究方法》（第5版）Roger S.Pressman著

原文：http://blog.sina.com.cn/s/blog_53c53b7f0101oxxz.html