业务需求调研大纲1.doc

业务需求调研大纲1

业务需求调研大纲

Revision Record
修订记录

Date
日期
Revision Version
修订版本
CR ID /Defect ID
CR/ Defect号
Sec No.
修改章节
Change Description
修改描述
Author
作者

Catalog
目 录
1 需求调研流程 4
1.1 调研整体流程 4
1.2 组成部分关系 5
1.3 分析过程 6
2 需求调研和分析的方法、策略和步骤 7
2.1 如何调研 7
2.2 如何分析 7
2.3 调研方法 8
2.4 基本策略 8
2.5 结构化方法分析步骤 9
2.6 UML方法分析步骤 9
3 需求调研相关要求 10
3.1 文档规范 10
3.2 需求管理 12
3.3 调研成果 12

1 需求调研流程
1.1 调研整体流程

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

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

l 编制需求分析文档

l 需求评审
1.2 组成部分关系

需求分析可分为问题识别、分析与综合、编制需求分析文档、需求评审等四个阶段，包括以下几个方面：确定软件所期望的用户类；获取每个用户的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析员与用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件；了解相关质量属性的重要性；讨论得出实施优先级；将所收集的用户需求编写成需求规格说明和模型；评审需求规格说明，确保与用户达成共识。
1.3 分析过程
需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的问题，所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求描述软件要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用户的各项要求，但不能全盘接受，只能接受合理的要求；对其中模糊的要求要进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户作充分的解释。最后将软件的需求准确地表达出来，形成软件需求说明书SRS。

l 获得当前系统的物理模型：首先分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估理解他们的需要及未来系统要解决的问题，然后建立一个业务USECASE模型和业务对象模型。当然如果系统相对简单，也没必要大动干戈区进行业务建模，只要做一些简单的业务分析即可。

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

l 建立目标系统的逻辑模型：明确目标系统要“做什么”。

l 对逻辑模型的补充，如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。
2 需求调研和分析的方法、策略和步骤
2.1 如何调研
需求调研涉及三个问题：

　　一是如何确定调研对象；

　　二是如何确定被调研对象；

　　三是采用何种调研方法；

　　调研对象的组成应以互补为原则，至少要由三类人员组成：技术人员、业务专家和管理者。被调研对象主要是人员和业务两类，其间主要涉及人与人、人与事物、事物与事物等三种关系。

　　其中，关键是确定调研范围。调研范围包括关键域和关键活动。而关键活动又由关键流程加关键点构成。

　　找到关键域，明确关键流程和关键点，对需求调研至关重要，需要专家或咨询顾问介入。而能否把握这一时机并找准需求提炼的关键点，是考验需求调研人员的重要方面。优秀的需求调研人员不仅能认识问题之所在，还能藉此获取足够多的知识，最后成为问题领域的专家。

　　需求调研非常困难，必须引起重视。因为：

　　● 缺乏专门领域的知识，同时应用领域中的许多问题通常模糊，很难界定；

　　● 机构实践存在默认知识，难以描述；

　　● 多个知识源或信息源既有冲突又有重合；

　　● 被调研对象可能有认知偏见或者欠缺或有时不愿提供确切信息。

　　这些都会给需求调研人员带来障碍和困难。在这种情况下，掌握必要的方法与技巧非常重要。
2.2 如何分析
需求工程是继软件工程之后的又一热点工程。从理论上说，包括调研需求、模拟和分析需求、需求描述、需求认可、需求演进这五个层次，并且逐层递进、螺旋式上升。需求分析是需求工程的核心，贯穿于系统整个生命周期。

　　需求分析的出发点在于：对调研的需求进行进一步提炼并指导需求的抽取；帮助需求分析人员发现问题。需求模拟则帮助检查验证对问题的理解。需求分析和模拟又包含三个层次的工作：需求定义、需求建模、需求模拟。

　　需求定义，是对经调研获取的需求进行初步整理，抽取其中基本需求和关键需求予以界定，并为需求建模提供必要的需求元素。

　　需求建模，是把抽象的需求通过概念、符号、数学模型及逻辑结构表现出来。表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的优点，但不利于捕获模型语义；半形式化表示可捕获结构和一定的语义，也可进行一定的推理和一致性检查；形式化表示具有精确的语义和推理能力，但构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。相对而言，图表形式的需求模型直观常用，比如组织结构图、系统流程图、网络拓扑图等。

　　良好的需求概念模型应包括以下几个特点： 实现的独立性、足够抽象、足够形式化、可构造性、利于分析、可追踪性、可执行性、最小冗余性。
2.3 调研方法
1、 会谈、询问：围绕软件目标提出具体问题；

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

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

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

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

　　6、 可视化方法：结和情景分析，利用画用户界面图、业务流程图、功能结构图、时序图等图形与客户进行讨论；
2.4 基本策略
1、 首先确定用户的软件开发目标，确定系统基本范围，然后围绕这一目标，确定要访问的部门和人员，要了解的业务，在基本范围内展开调研；

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

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

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

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

　　6、 应思考是否有新技术可以改进现有工作，用户提出的需求用现有技术能否实现。
2.5 结构化方法分析步骤
1、 画出数据流图。设计数据流图必须逐步求精；

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

　　3、 描述数据流细节，大型软件可以使用数据字典描述所有数据元素；

　　4、 定义处理逻辑（加工逻辑：每个加工处理做什么）；

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

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

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

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

　　9、 确定软硬件接口和环境需求。
2.6 UML方法分析步骤
一般的应用系统又是各组成部分：问题论域、人机界面、数据管理、任务管理，在OOA阶段重点对问题论域进行分析，对人机界面、数据管理、任务管理等问题，OOA一般较少或没有分析，而是留待OOD阶段解决。

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

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

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

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

　　　（3） 定义活动者；

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

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

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

　　　（7） 绘制主要交互图；

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

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

　　5、 建立系统物理模型（组件图、配置图）；
3 需求调研相关要求
3.1 文档规范
A、三种编写方法

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

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

　　3、 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

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

B、应有成果

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

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

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

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

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

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

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

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

C、文档工具推荐

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

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

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

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

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

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

D、需求文档编写原则

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

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

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

　　　4、 避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”；

　　　5、 避免使用比较性词语，如“提高”，应定量说明提高程度。
3.2 需求管理
需求调研分析过程是一个由粗到细、渐进明晰、持续完善的过程。在指导后面系统设计，编码阶段时都应当不断完善修改需求文档，因此需求管理非常重要。需求管理包括在工程进展过程中维持需求约定集成型和精确性的所有活动，它是CMM模型二级中的首要KPA（关键过程域），这些活动包括：

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

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

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

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

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

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

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

3.3 调研成果
调研项
调研数量
调研成果
业务专业词汇
15
词汇描述记录
同行对比项目
10
项目对比描述及优劣势分析
技术参考资料
20
参考资料描述