草刈民代发行全裸:IT售前咨询白皮书——分析客户需求

来源:百度文库 编辑:九乡新闻网 时间:2024/04/29 07:28:12
4.1 业务理解此部分内容旨在阐述公司对客户业务的理解,通过项目背景、业务架构、问题与变革三部分分析,说明客户的业务现状、遇到问题和未来可能的变革,以实现在业务层面与客户的共鸣。4.1.1 项目背景分析项目背景分析包括竞争环境分析、业务标杆分析和信息化标杆分析三部分内容:竞争环境分析。竞争环境包括宏观环境和任务环境,其中宏观环境包括政治、经济、社会和技术环境等,任务环境是指与企业直接有关的产业环境,通常可采用波特的竞争力模型进行分析。波特认为影响行业竞争结构及竞争强度的主要因素包括行业内现有企业、潜在的进入者、替代品制造商、供应商和顾客(产品购买者)。业务标杆分析。基准化分析法(benchmarking)就是将本企业各项活动与从事该项活动最佳者进行比较,从而提出行动方法,以弥补自身的不足,是一种评价自身企业和研究其他组织的手段。信息化标杆分析。针对相关信息化领域,提供信息化标杆分析。 4.1.2 企业现状和业务架构分析业务架构分析包括企业基本情况、业务战略、组织架构、业务模式及关键流程和信息化现状分析等五部分内容:企业基本情况分析。企业生产经营概况,包括公司简介、主要业务和效益情况、在同行业内所处的地位等。企业业务战略分析。企业的使命、目标、价值观和企业的竞争战略(量化的竞争目标和竞争实施计划)。企业组织架构分析。企业的组织架构设置情况、组织各单元的主要职能、关键岗位设置和岗位职责情况。业务模式及关键流程分析。本部分内容是关键,采用价值链理论进行业务模式分析,并采用编目的方法进行流程描述和说明。信息化现状分析。描述企业相关的应用系统、软/硬件设备投入情况,以及企业信息化管控模式。 4.1.3 问题定义与变革分析问题定义与变革分析包括三部分内容:宏观问题。根据环境和标杆分析,指出企业业务模式各环节存在的问题及改进建议。业务流程存在的问题。根据业务流程现状分析,分析企业业务流程存在的问题和改进建议。企业未来可能的变革分析。根据问题分析、企业战略和标杆分析,指出企业未来业务可能存在的变革。

解决方案的路径是说明问题——分析问题——解决问题的过程。

编制解决方案的过程是从业务理解到技术方案编制的过程,即通过业务架构分析,了解组织的战略、相关业务的组织结构和职能、关键流程,从而构建企业的应用系统架构,并根据应用系统需求提供技术解决方案。

根据此理解,解决方案的编写路线如下:


整个技术解决方案包括五部分:

分析客户需求(概述)(2008-07-20 11:11:11)转载 标签:

售前

售前顾问

售前咨询

烟草信息化

咨询顾问

it

分类: IT售前咨询白皮书 软件开发是由系统构思、需求分析、系统设计、编码实现、系统测试、系统培训、系统部署和系统维护等一系列定义良好的阶段构成的,每个阶段都有不同的目标、输入和输出,整个过程应该是无缝的,在整个开发过程中,要使用相同的概念和表示方法。 UML(统一建模语言,Unified Modeling Language)是一种面向对象的建模语言,采用图形表示法来表示OO的概念。通过UML,可以构建一种应用模型,并在设计过程中增加细节。从分析到设计再到实现使用的是相同的无缝表示法,这样一个开发阶段增加的信息就不会在下一阶段中丢失了。 需求分析的过程是将企业业务模型到企业信息模型的映射的过程,实现从业务模式向信息模型的转变、业务需求向信息功能的映射、企业基础数据向企业信息的抽象,通过抽象和建模,将企业业务实体抽象成为信息对象、业务运作模式抽象成为信息对象的属性和方法,建立面向对象的企业信息模型。UML通过构造模型来更加深入地理解需求,分析的目标就是指明必须实现什么的规格说明,它描述了系统的行为、特性或属性,是在开发过程中对系统的约束(而不是如何完成这些内容)。 需求是开发者和用户交互的一个过程,任何一方的不投入都会导致项目的失败。由于售前咨询的定位,必然存在着客户沟通和客户合作态度的问题(再者用户不是专业人士),因而开发者需要以积极的态度告诉客户需求开发的方法,以获取客户的支持。
3.1 软件需求层次软件需求包括三个不同的层次——业务需求、用户需求和功能需求,也包括非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求,在项目视图与范围文档中予以说明。用户需求描述用户使用产品必须要完成的任务,可使用用例文档或场景脚本予以说明。功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。 无论哪个层次的需求,其目的都是为了说明系统要完成的内容,可采用不同的模型进行分析和展现:• 业务需求,通过业务建模(即采用业务架构理解客户业务),对企业目前的业务流程进行描述和评估• 用户需求,重心就是如何收集用户的需求上,即确定角色和角色的用例,通过用例和场景说明客户的工作内容和信息化需求• 功能需求,依赖于用户需求,是用户需求在系统上的一个映射(Mapping)。在这个层次上,为用户做一个软件原型是一个不错的方法 

3.2 UML与相关模型

UML是一种图形化的面向对象建模语言,通过不同的图形表示来捕捉系统静态结构和动态行为的信息,建立起对象模型。

考虑到售前咨询过程更多的是理解和阐述客户需求,因而可以将注意力聚焦在用例和活动图上,即通过层次化的用例(Use Case)模型和时序模型描述企业范围内各种应用的功能需求;通过逐级分解的活动模型(业务过程、子过程、活动)来细化描述业务。当然也可适当考虑类模型的分析,借此说明企业相关的实体和关系。

3.2.1 UML概述

UML的概念包括了UML语义(Semantics)和UML表示符(Notation)两个部分,UML语义定义了三种模型(类模型、状态模型和交互模型),UML表示符提供了完整的语义定义,UML的表示符包括了下面的几种主要的图:类图、用例图、顺序图、协作图、状态图、活动图和部署图。

三种模型从不同的视角来描述系统:

• 类模型。描述了系统内部对象及其关系的静态结构——它们的标识、与此同时其他对象的关系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的概念是类、关联和泛化。

• 状态模型。描述的是对象当中与时间相关的内容,如表明变化的事件,以及那些界定了事件上下文的状态。状态模型是由多张状态图所构成的,一个类有一张状态图,每张状态图都包含了一些重要的时序行为。

• 交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视图。交互可以在不同的抽象层次上建模。在高层上,用例描述的是系统如何与外部参与者交互(用例表示功能片段,有助于捕获非形式化的需求);顺序图提供更多的细节,显示交互的对象,以及对象交互的时间顺序;活动图提供最详尽的细节,以显示某次活动中处理步骤之间的控制流。

 

3.2.2 用例模型

用例是从用户的角度看待系统,用例标识系统的功能,并根据用户的观点组织这些功能。用例模型包括参与者、用例和用例图三部分构成:

• 参与者(Actor)。系统的直接外部用户——直接与系统通信的一个对象或一级对象,但并不是系统的一部分。

• 用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能,每个用例会涉及一个或多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起,包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。

• 用例图。UML用一套图形表示法来总结用例,如下图。其中矩形包含了系统的用例,参与者列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火柴人”图标表示参与者,参与者的名称列在图标下方或者临近图标的地方。实线连接用例及其参与者。

<此节也需要重新编写>

3.2 UML与相关模型

UML是一种图形化的面向对象建模语言,通过不同的图形表示来捕捉系统静态结构和动态行为的信息,建立起对象模型。

考虑到售前咨询过程更多的是理解和阐述客户需求,因而可以将注意力聚焦在用例和活动图上,即通过层次化的用例(Use Case)模型和时序模型描述企业范围内各种应用的功能需求;通过逐级分解的活动模型(业务过程、子过程、活动)来细化描述业务。当然也可适当考虑类模型的分析,借此说明企业相关的实体和关系。

3.2.1 UML概述

UML的概念包括了UML语义(Semantics)和UML表示符(Notation)两个部分,UML语义定义了三种模型(类模型、状态模型和交互模型),UML表示符提供了完整的语义定义,UML的表示符包括了下面的几种主要的图:类图、用例图、顺序图、协作图、状态图、活动图和部署图。

三种模型从不同的视角来描述系统:

• 类模型。描述了系统内部对象及其关系的静态结构——它们的标识、与此同时其他对象的关系、属性以及操作。类模型提供了放置状态模型和交互模型的基本框架。类模型中最重要的概念是类、关联和泛化。

• 状态模型。描述的是对象当中与时间相关的内容,如表明变化的事件,以及那些界定了事件上下文的状态。状态模型是由多张状态图所构成的,一个类有一张状态图,每张状态图都包含了一些重要的时序行为。

• 交互模型。描述的是对象如何协作以达成某种结果。交互模型是跨越了许多对象的整体视图。交互可以在不同的抽象层次上建模。在高层上,用例描述的是系统如何与外部参与者交互(用例表示功能片段,有助于捕获非形式化的需求);顺序图提供更多的细节,显示交互的对象,以及对象交互的时间顺序;活动图提供最详尽的细节,以显示某次活动中处理步骤之间的控制流。

 

3.2.2 用例模型

用例是从用户的角度看待系统,用例标识系统的功能,并根据用户的观点组织这些功能。用例模型包括参与者、用例和用例图三部分构成:

• 参与者(Actor)。系统的直接外部用户——直接与系统通信的一个对象或一级对象,但并不是系统的一部分。

• 用例。用例是系统通过与参与者的交互可以提供的一段连贯的功能,每个用例会涉及一个或多个参与者以及系统本身。用例把与此一部分系统功能相关的所有行为组合在一起,包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。

• 用例图。UML用一套图形表示法来总结用例,如下图。其中矩形包含了系统的用例,参与者列在矩形外面。系统的名称可以写在矩形的某条边的附近。椭圆内部的名称表示用例。“火柴人”图标表示参与者,参与者的名称列在图标下方或者临近图标的地方。实线连接用例及其参与者。