【系统分析师之路】系统分析师必知必会（需求分析篇）

系统分析师必知必会需求分析篇

【系统分析师之路】系统分析师必知必会（需求分析篇）
- 1.什么是软件需求
- 2. 需求分类
- - 2.1）业务需求
  - 2.2）用户需求
  - 2.3）系统需求
  - 2.4）非功能需求与设计约束
  - 性能（Performance）
  - 信息（Information）
  - 经济（Economic）
  - 控制（Control）
  - 效率（Efficiency）
  - 服务（Service）
  - 4.1）用户访谈
  - 4.2）问卷调查
  - 4.3）现场观摩
  - 4.4）联合需求计划
  - 4.5）情节串联版
  - 4.6）收集资料
  - 4.7）参加业务实践
  - 4.8）阅读历史文档
  - 4.9）抽样调查
- 5. 可行性分类
- - 经济可行性
  - 技术可行性
  - 法律可行性
  - 用户使用可行性
- 6. 成本分类
- - 1）固定成本
  - 2）变动成本
  - 3）混合成本
  - 4）直接成本
  - 5）间接成本
- 7. REST的概念
- 8. REST有五个原则
- 9. 负载均衡技术
- 10. 有状态和无状态
- 11. 业务流程建模的方法
- 12. 面向对象的基本概念
- 13. UML的概念
- - 1）结构事物
  - 2）行为事物
  - 3）分组事物
  - 4）注释事物
- 14. UML图的分类
- - 1）类图
  - 2）对象图
  - 3）构件图
  - 4）部署图
  - 5）制品图
  - 6）包图
  - 7）用例图
  - 8）顺序图
  - 9）通信图
  - 10）定时图
  - 11）状态图
  - 12）活动图

1.什么是软件需求

软件需求是指用户对系统在功能，行为，性能，设计约束等方面的期望。
软件需求是指用户解决问题或达到目标所需的条件和能力，是系统或系统部件要满足的合同，标准，规范，或其他正式规定文档所具有的条件或能力，以及反映这些条件或能力的文档说明。
软件需求可以分为需求开发和需求管理两个大类。其中需求管理由四个部分组成：变更控制，版本控制，需求跟踪和需求状态跟踪；而需求开发也可以再细分为四个阶段：需求收集，需求分析，需求定义和需求验证。需求管理是用来支持需求开发的，需求开发和需求管理通过需求的基线联系在一起。

2. 需求分类

需求有两种大的分类方式。第一种基本的分类方式将需求分为了三个大类：用户需求，业务需求和系统需求。其中系统需求是计算机化的需求，它又分为功能，非功能和设计约束三种。

2.1）业务需求

面向整体全局的需求。它是反映企业或客户对系统高层次的目标要求，通常来自项目投资人，购买产品的客户，客户单位的管理员，市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定基础。

2.2）用户需求

面向用户的视角的需求。
它描述了用户的具体目标，或用户要求系统必须完成的任务。也就是说用户需求描述了用户能使用系统来做些什么。

2.3）系统需求

是从系统的角度来说名软件的需求，它包括了功能需求，非功能需求和设计约束等。
功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务的要求。

2.4）非功能需求与设计约束

非功能需求是指系统必须具备的属性或者品质，又可以分为软件质量属性和其他非功能需求。
设计约束也称为限制条件或者补充规约，通常是对系统的一些约束说明。

### 3. PIECES框架
PIECES框架是对系统非功能需求分类的一种技术。

性能（Performance）

用于描述企业当前的运行效率，可以分析当前业务的处理速度。

信息（Information）

信息和数据指标用于描述业务数据的输入，输出，以及处理方面存在的各种问题。

经济（Economic）

主要是从成本与收益的角度分析企业当前存在的问题。

控制（Control）

提高信息系统安全和控制的水平。

效率（Efficiency）

提高企业人，财，物等的使用效率。

服务（Service）

提高企业对客户，供应商，合作伙伴，顾客等的服务质量。

### 4. 需求获取方法

4.1）用户访谈

1对1-3，有代表性的用户。用户访谈是最为基本的一种需求获取手段。其形式包括了结构化和非结构化两种。用户访谈是通过1对1（或3）的方式，与用户进行面对面的沟通，以获取用户需求。用户访谈具有良好的灵活性，有较为宽广的应用范围。但是也存在一些困难，例如，用户平时较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要一些技巧，同时需要系统分析师具有足够的知识领域等；另外，在访谈时还会遇到一些对于企业来说比较机密和敏感的话题。因此这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

4.2）问卷调查

用户多，无法一一访谈，与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许调查者匿名填写，大多数用户可能会提供真实信息，问卷调查的结果比较好整理和统计，但问卷调查最大的缺点就是缺乏灵活性。

4.3）现场观摩

针对的是较为复杂的流程和操作。想获取系统中较为复杂的流程和操作过程，则现场观摩方法比较的合适。对于一些较为复杂的流程和操作而言，是比较难用语言和文字进行表达的，对于这种情况可以去客户现场，一边观察一边听用户讲解，从而更加直观的了解客户的需求。

4.4）联合需求计划

高度组织的全体会议，各方参与，成本较高，为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来取代大量独立的访谈，JRP是一个通过高度组织的群体会议，来分析企业内的问题，并获得需求的过程。它是联合应用开发的一部分。

4.5）情节串联版

一系列图片，通过图片来讲故事。

4.6）收集资料

把系统有关的，对系统开发有益的资料收集起来。

4.7）参加业务实践

有效的发现问题的本质和寻找解决问题的方法。

4.8）阅读历史文档

对收集数据性的信息较为有用。

4.9）抽样调查

降低成本。采样是指从种群中系统的选出有代表性的样本集的过程。通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档文件就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。抽样能够提高需求获取的效率，但是抽样往往是由系统分析师来抽的，所以会受到他的主观因素的影响。

5. 可行性分类

经济可行性

成本收益分析，包括建设成本，运行成本以及项目建设后可能的经济收益。

技术可行性

技术风险分析，现有的技术能否支持目标的实现，现有资源（员工，技术积累，构件库，软硬件设备）是否足以支持项目的实施。

法律可行性

也叫做社会可行性，不能与国家法律和政策相抵触。

用户使用可行性

执行可行性，从信息系统用户的角度评估系统的可行性。
管理可行性：
系统与现有管理系统的一致性，改革的可能性。
运行可行性：用户方便使用的程度。

6. 成本分类

1）固定成本

不随产量变化。管理人员的工资，办公费，固定资产折旧费，员工培训费，广告费，技术开发经费等。

2）变动成本

随着产量变化而变化。如直接材料费，产品包装费，外包费用，开发奖金等；

3）混合成本

水电费，电话费，质量保证人员工资，设备动力费等；

4）直接成本

直接投入在项目上。项目组人员工资，材料费用。

5）间接成本

分摊到项目上。如水电费，员工培训费等。

7. REST的概念

REST是表述性状态迁移，是一种只使用Http和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性；

8. REST有五个原则

1）网络上的所有事物都被抽象成了资源；
2）每个资源对应一个唯一的资源标识；
3）通过通用的连接件接口，对资源进行操作；
4）对资源的各种操作不会改变资源标识；
5）所有的操作都是无状态的；

9. 负载均衡技术

1）应用层负载均衡：Http重定向，反向代理服务器；
2）传输层负载均衡：DNS域名解析负载均衡，基于NAT的负载均衡；
3）硬件负载均衡：F5；
4）软件负载均衡：LVS，Nginx，HAProxy；

10. 有状态和无状态

1）无状态服务是对单次请求的处理，不依赖其他的请求，也就是说处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
2）有状态服务则相反，它会在自身保存一些数据，先后的请求是有关联的。

11. 业务流程建模的方法

1）标杆瞄准
2）IDEF一系列建模，分析和仿真方法的统称
3）DEMO组织动态本质建模法
4）Petri网
5）业务流程建模语言
6）基于服务的BPM

12. 面向对象的基本概念

对象：属性（数据）+方法（操作）+对象ID
类：控制类/实体类/边界类。
继承与泛化：复用机制。
封装：隐藏对象的属性和实现细节，仅对外公开接口。
多态：不同对象收到同样的消息产生不同的结果。
接口：一种特殊的类，它只有方法定义没有实现。
重载：一个类可以有多个同名而参数类型不同的方法。
消息和消息通信：消息是异步通信的；

13. UML的概念

UML由构造块，规则和公共机制三部分所组成。其中构造块又包括了：事物，关系和图三个部分组成。
事物一共有四种类型：

1）结构事物

它是在模型中属于最静态的部分，代表概念上或者物理上的元素，UML有七种结构事物，分别是类，接口，协作，用例，活动类，构件和节点。
2.1）类是描述具有相同属性方法，关系和语义的对象的集合，一个类实现一个或者多个接口：
2.2）接口是指类或构件提供特定服务的一组操作的集合，它描述了类或构件的对外的可见的动作；
2.3）协作定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
2.4）用例是用来描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的。
2.5）构件是物理上或可替换的系统部分，它实现了一个接口的集合；
2.6）节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
2.7）活动类的对象有一个或者多个进程或者线程。活动类和类很相似，只是他的对象代表的事物的行为，和其他事物是同时存在的；

2）行为事物

它是UML行为模型中的动态部分，代表时间和空间上的动作。UML有两种主要的行为事物：第一种是交互，交互是指一组对象之间在特定的上下文当中，为达到特定目的而进行的一系列消息交换而组成的动作；交互中组成动作的对象的每个操作都要详细的列出，包括消息，动作次序，连接；第二种是状态机，状态机由一系列对象的状态组成。

3）分组事物

是UML模型的组织部分，可以把它们看成是个盒子，模型可以在其中进行分解，UML只有一种分组事物，叫做包；包是一种将有组织的元素分组的机制。与构件不同的是包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统的运行阶段。

4）注释事物

是UML模型的解释部分。

14. UML图的分类

UML图可以分为静态图和动态图两大类。
静态图（结构图）有：类图，对象图，构件图，部署图，制品图，包图，组合结构图；
动态图（行为图）有：用例图，顺序图，通信图，定时图，交互概览图，状态图，活动图；

1）类图

类图描述一组类，接口，协作和它们之间的关系。

2）对象图

一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。

3）构件图

构件图描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部内容。构建图用于表示系统的静态设计实现视图。
对于由小的部件构建大的系统来说，构件图是很重要的，构件图是类图的一个变体。一个封装的类和它的接口。

4）部署图

部署图描述对运行时的处理节点及在其中生存的构建的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图，软硬件之间的映射。

5）制品图

系统的物理结构

6）包图

由模型本身分解而成的组织单元，以及它们之间的依赖关系。

7）用例图

系统与外部参与者之间的交互

8）顺序图

顺序图是一种交互图，它强调对象之间消息发送的顺序，同时显示对象之间的交互。它强调按照时间顺序。

9）通信图

它也叫协作图。它也是一种交互类型的图。它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构。

10）定时图

强调实际的时间

11）状态图

它是用来描述一个状态机，它由状态，迁移，事件和活动组成。状态图给出了对象的动态视图。它对于接口，类或协作的行为建模尤为重要。而且它强调事件导致的对象行为，这非常有助于对反映式系统建模，状态转换变迁。

12）活动图

将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。它类似于程序流程图。