电子科大软件系统架构设计——系统需求分析

系统需求分析

需求采集

研究现有文档与系统

• 组织机构图
• 系统规划文档
• 工作规范文档
• 业务单据
• 数据报表
• 反馈意见
• 领域知识
• 现有系统

组织机构图

组织机构图提供了组织机构的部门、关键岗位与角色构成，并能反映它们之间的所属关系。

系统规划文档

组织机构的使命陈述、IT战略、信息化目标、建设方案、技术路线等。

工作规范文档

组织管理上的各种制度与规范，如客服服务流程规范文件、财务报销规定、采购规定、设备入库管理规定、出差补贴规定等。

业务单据

不同业务的单据，比如进销存业务有采购申请单、进货单、发货单、到货单、到货检验单、销售订单。

报表

不同业务的报告，如采购周报、库存月报、销售日报、销售月报、生产日报、生产月报、应收帐月报等。

问题描述文档

这些文档包括反映业务往来的函件、研究报告、建议单、反映意见表等。

领域专业知识

业务处理涉及的专业领域知识，比如一个化工企业相关的专业知识是化学工程，一个银行相关的专业知识是存贷、理财产品、投行等。

现有相关软件系统

现有软件系统相关的流程图、设计文档、程序文档、用户使用手册、界面、数据库表等材料。

与客户及相关人员进行面谈

面谈法是通过与客户直接面谈交流，获取需求的调查方法。

访谈对象:

• 客户:周期、预算、质量要求、预期收益
• 用户:功能需求、非功能需求
• 领域专家:领域知识
• 客户的上下游合作伙伴:对业务协作与接口

正式面谈

• 正式面谈需要提前预约，有特定的参与对象。
• 需求调研人员需要提前准备要面谈的问题，有些问题有预设答案，供被面谈对象进行选择与确认，有的是开放式的,无法提前准备可选答案。

非正式面谈

• 非正式面谈是正式面谈的补充，时间、地点、形式都不确定，更多是日常交流，没有预设的问题。
• 在轻松的面谈环境下，被访谈对象更可能说出自己真实的想法，或提及调研人员没有想到的问题和事实。

典型访谈问题

1）请问公司（部门)的组织结构是怎样的?

2）您能描述一下您的岗位职责有哪些吗?

3）请问是收货过程是先计量、质检，然后再开收货单吗?

4）借款的审批流程是怎么样的，不同额度是不是有不同审批流程?

5）生产日报中产量的单位是什么?

6）目前对客户关系的维护与管理有哪些?

7）有没有业务相关的资料（包括表格、表单、文档、报表等）可以提供?

8）目前工作中您觉得存在什么样的问题?

9）对现在的信息系统您满意吗?希望在哪些方面进行改进?

10）您对整个系统的期望定位是什么?

11）对我们将要开发的系统您有什么建议或期望?

优缺点

优点:

通过面对面的谈话与聊天，能比较深入地了解被面谈者对问题的看法与回答，并能够根据被面谈者的回答动态地调整面谈内容。

缺点:

需要提前预约，由于每个岗位平时都在忙于处理自己的业务，面谈时间可能不一定能及时安排，且面谈后需要整理，并尽量得到被面谈者的书面确认，这也需要一定时间周期，这会导致调研过程时间较长。

问卷调查法

问卷调查法是通过向被调查者发放预先设计的调查表格，请求被调查者填写表格内容，然后收集整理分析的一种需求调查方法。

适用场景:

• 对于那些目标清晰、业务相对简单的项目，调查表是一种高效的、低成本的需求采集方法。
• 当需要调查很多人的观点而他们又不在同一个地方的时候，调查表更能获取更多人员的需求。

调查表问卷设计

调查表问卷可以设计两类问题:封闭式问题（有备选答案）、开放式问题（没有备选答案）。

封闭问题类型:

• 单选/多选问题。被调查者需要从提供的备选答案中选择一个或多个答案;
• 评价问题。一类特殊的单选问题，表达被调查者对问题的态度或观点，如“强烈同意、同意、中立、不同意”;
• 排序问题。对所提供的备选答案按优先级排序，可以是序号、百分比等排序方式。
• 判断问题。被调查者对问题打勾或打叉。

开放式问题类型：填空题、问答题

问卷调查表应用方式

• 传统方法
  采用纸质问卷表格采集需求，人手工填写，效率低、成本高，难以异地。
• 新型渠道方法
  采用网页问卷、微信问卷、电子邮件等方式采集需求，具有高效、准确、便于统计等优点。

案例：办公OA系统需求调查问卷

观察法

观察法是一种通过观察业务工作及其活动，了解业务过程与相关领域知识，进一步获取业务需求的调查方法。

• 旁观式观察
• 解释式观察
• 参与式观察

头脑风暴法

头脑风暴法是一种激发参与者脑力活动，产生新思想或者提出问题解决方案的会议技术。

头脑风暴的作用:

• 激发参与者产生新思想
• 启发用户的潜在需求
• 对来自不同人员的需求达成一致意见

原型法

原型法是一种利用快速构建的原型演示系统启发用户需求或验证用户需求的方法，从而可获得用户的需求反馈。

原型法的用途:

• 了解用户对原型系统的反馈信息
• 启发用户的潜在需求
• 获取用户的真实需求

原型方法分类

进化式原型目标:将原型系统逐渐地演化为产品系统。

• 进化式原型必须具有健壮性的系统架构设计。即便系统多次迭代修改，系统都应具有稳定性。
• 进化式原型也必须采用可扩展性的系统设计原则，以支持版本升级与功能扩展。
• 建立进化式原型比建立抛弃式原型需要更多时间。

抛弃式原型目标:通过原型系统获取用户的明确需求。

• 在原型达到预期目的以后将它抛弃，可以花费较少的代价导引出系统需求。
• 抛弃式原型方法适合解决需求中的不确定性、二义性、不完整性或含糊性问题，以减少在继续开发时存在的风险。
• 抛弃式原型可帮助用户和开发者激发需求，并可以发现需求中的漏洞。

原型法开发过程

1）确定用户基本需求。

• 基本功能

• 典型输入/输出数据。

• 基本界面形式

2）快速构建原型系统

• 采用所见即所得的快速开发工具实现基本功能界面（如WebBuilder等)
• 采用界面原型设计工具（如Mockplus,Axure RP等）实现演示系统

3）对原型运行与评价

• 用户试用原型系统，反馈问题
• 确定系统的真实需求
• 启发用户的新需求

4）修正和改进原型系统

• 根据用户反馈问题，确定修改方案
• 改进原型系统
• 用户再试用与评价，再修改，直到满意为止

快速应用开发

快速应用开发（Rapid Application Development，RAD）是一种通过快速开发并发布软件版本，以便用户及时反馈潜在需求的软件开发过程方法。该方法可以用于复杂系统的需求导引,也可用于系统迭代开发。

快速应用开发的用途:

• 尽快得到系统原型，验证用户的真实需求。
• 通过系统原型使用，启发用户的潜在需求。

RAD融合了进化型原型法和头脑风暴方法，其基本思想为:

• 让用户更主动地参与到项目分析、设计和构造活动中;
• 组织一系列重点需求问题解决的研讨会，由投资方、用户、系统分析员、系统设计人员和开发人员一同参与；
• 通过一种迭代过程方法加快需求分析和设计阶段进展，
• 让用户尽快看到一个可运行的系统。

RAD组合了5个方面的技术:

• 进化原型迭代开发技术
• CASE（计算机辅助软件工程）工具支持
• 拥有能使用先进工具的专门人员
• 利用头脑风暴会议解决重点需求问题
• 严格按照项目进度要求实施开发活动

RAD方法的不足:

• RAD需要足够的人力资源，并投入相当的精力;
• 开发人员和客户必须在很短的时间内完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败;
• RAD 不适合技术风险很高的场景。当一个系统开发要采用很多新技术或需较多人员配合时， RAD 方法会面临较大风险；
• RAD可能产生难以维护与扩展的软件;
• RAD难以有足够时间去完成文档工作，其开发文档不足。

可视化需求建模

一、为什么开展需求可视化建模

• 从用户收集到的需求信息通常是一大堆杂乱的文字信息，即使你对它们进行了分类，这些组织好的信息还不足够使开发人员对需求完全理解。
• 用户需求通常是一些宽泛的文本描述，难以对信息系统开发给出明确的、详细的、标准的需求规格定义。
• 需求可视化UML建模可以直观地、形式化展示系统需求要求，可帮助分析人员解决需求说明中不一致性、模糊性等问题。

二、业务流程建模
业务流程模型是用来描述业务活动处理过程的模型，基于BPMN建模语言可以实现业务处理过程的可视化建模。

业务流程建模

普通流程建模

• 私有业务流程——属于某个特定组织内部的业务流程。在BPMN建模时，使用单个泳池组织业务流程活动。

• 公开业务流程——反映公众参与者与服务机构业务之间的交互。在BPMN建模时，需使用多个泳池组织业务流程活动。

合作流程建模

合作流程是指有多个组织或部门参与者在业务流程中协作完成工作。一个合作流程通常包含两个或更多泳池，每个泳池关联到一个合作中的参与者对象。泳池之间通过消息流表示相应参与者之间交换的消息。

编排流程建模

编排流程也是描述多个参与者之间交互的流程建模方法，但编排流程取消掉了泳池的概念，它通过多个参与者之间直接的消息交互描述业务流程。

实践练习：医院门诊就医业务流程建模

业务用例建模

业务用例模型是一种描述业务功能的模型，它需要直观地抽象出业务工作的功能、人员角色以及业务边界，可采用面向对象的UML业务用例图进行建模。

系统用例图建模

针对复杂系统或大型系统进行功能需求分析，可采用面向对象的UML用例图建模方法。

活动图建模

在系统需求分析中，除了定义功能用例外，还需要描述该功能用例的内部处理流程。这就需要采用UML活动图建模用例的行为过程。

分析类图建模

在系统分析阶段，除了建立用例图与活动图模型外，还可进一步建立分析类图模型，用于描述系统由哪些分析类来实现用例功能。

补充：
多重性关联 ：多重性关联关系又称为重数性（Multiplicity）关联关系，表示两个关联对象在数量上的对应关系。在 UML 中，对象之间的多重性可以直接在关联直线上用一个数字或一个数字范围表示。

分析类图建模步骤

1. 从问题领域抽取类
2. 定义类名及属性
3. 确定类之间关联
4. 增量迭代完善类图

抽取类的方法

1. 用例驱动方法

   从用例模型抽取类的方法:

   • 分析用例图模型，抽取含有业务数据的实体，作为系统的第一批实体类，如Grades类和ReportCard类。
   • 将用例的参与者作为第二批实体类，如Teacher类、Student类和Administrator类。

   

2. 名词短语方法抽取类

   • 阅读需求文档陈述，从中找出包含数据信息的名词短语
   • 每个名词短语可以作为一个候选类
   • 将候选类分为相关类、模糊类

   例：采用名词短语方法从大学注册系统的需求陈述进行类抽取

   • 大学的每个学位都设置了多门必修课程和选修课程
   • 每门课程设定了级别及学分
   • 同一课程可以是多个学位的组成部分
   • 每个学位都规定了完成所要求的最低总学分值
   • 学生可以对学位培养的开设课程进行选修，形成适合自己需要的学习计划。当通过这些课程学习的考核评价后，就能获得他们所注册的学位。

   采用名词短语方法抽取的类如下:

   相关类	模糊类
   Course	CompulsoryCourse
   Degree	ElectiveCourse
   Student	StudyProgram
   CourseOffering

   说明:
   1）名词短语方法抽取的类是否完整，取决于需求文档陈述的完整性和正确性。

   2）从大量文字描述中，抽取准确的、完整的类名称是较困难的事情。

3. 公共类模式方法

   根据对象分类理论来识别业务领域通用的概念、事件、组织、人员、地点等术语来定义类。

   • 概念类，如专业（Major)、课程目录（Curricula）、课程（Course)
   • 事件类，如选课(SelectingCourse）、重修课程（RetakeCourse)
   • 组织类，如学院（College)
   • 人员类，如教师(Teacher)、学生(Student)
   • 地点类，如办公室(Office)

4. CRC(Class-Responsibility-Collaborator，类-职责-协作者)方法

   CRC方法是一种基于业务领域知识卡片去发现类、描述职责和定义协作者的类识别方法。

   类名代表相似对象的集合名称。职责是指对象完成职责所需要数据和操作。协作者是为对象完成职责需要配合的其它类。

   

定义类属性

一旦抽取出系统的基本候选类列表后，就可以使用建模工具进行类图定义。首先，需要定义各个类的属性。

建模类之间的关系

分析类之间的业务关系，如类之间的关联关系、依赖关系、泛化关系、聚合关系等。

在系统类图建模中，还可对类之间关联进行修饰说明。

在系统类图建模中，一些类之间存在公共特性（属性和操作），则需要对公共部分进行抽象定义，并建立继承关系，或称为泛化关系。

在系统类图建模中，一些类之间若存在“整体-部分”语义关系，则需要建立类之间的聚合关系或复合关系。

增量迭代完善类模型

在现有类模型基础上，进行增量迭代完善。

需求文档化

一、需求规格说明书

在建立系统需求模型后，还应对系统需求模型进行规范化的文档描述，即编写需求规格说明书。

二、需求规格说明标准

1. IEEE830-1998系统需求规格说明
2. GB9385-2008 计算机软件需求规格说明规范
3. 企业IT系统需求规格说明

三、系统需求组成

功能性需求

功能性需求指系统应该提供什么样的服务、如何对输入进行处理以及系统在特定条件下的行为等描述。

功能性需求类型:

• 系统需提供什么服务?

• 系统需做什么处理?

• 有哪几种操作模式?

• 必须执行什么计算或数据转换?

功能性需求是描述系统的具体功能要求。除采用用例图建模描述，还需使用规约表、活动图、时序图等模型之一对功能用例进行详细描述。

非功能性需求

常见的系统性能需求指标:

1.响应时间

对请求的响应时间。包括客户端响应时间、服务器响应时间、网络响应时间。

2.吞吐量

单位时间内处理多少事务量/数据量。

3.并发用户数

支持多少用户同时执行一个操作的能力。

4.资源使用率

CPU占用率、内存占用率、磁盘I/0、网络I/0。

例：一个图书借阅管理系统基本需求内容

基本功能需求

• 图书查找
• 图书借阅
• 图书归还
• 图书预订

基本非功能需求

• 1-3秒内完成图书查找
• 支持200并发用户
• 该系统应7×24小时持续运行

接口需求

• 用户接口:定义了用户使用软件时的接口需求，如用尸是迪过饰令仃处是图形用户界面使用系统。
• 软件接口:指待开发软件与其他软件系统之间的接口。如系统调用API服务接口实现系统功能集成。
• 硬件接口:描述本软件与硬件设备之间的接口，如设备驱动、接插件标准等。
• 通信接口:描述系统与其他系统之间的通信方式与协议，如局域网违信协议、蓝牙4.0协议、WIFI协议等。

四、需求规格说明案例

• 《四川省疾病控制中心法定传染病监测报告规范化管理平台》需求规格说明书
• 《智慧酒店物品追踪系统》需求分析报告

需求管理

一、需求管理内容

需求管理主要包括两方面内容:

• 对需求说明进行规范化处理;
• 对需求的变更进行流程化管理，避免出现需求变更带来的项目失败风险

当需求数目比较少时，采用需求依赖矩阵是一种发现需求矛盾或需求重叠的有效技术方法。

二、需求变更管理

在系统开发生命周期的任何阶段，需求都可能发生变更。若没有对这些变化进行管理，将会给项目管理带来麻烦。需要采用需求变更管理工具进行存储与跟踪管理。

需求变更追踪管理:

需求变更控制流程:

需求变更管理工具：

• 腾讯敏捷研发协作云平台(https://www.tapd.cn/)
  

• 数知鸟(https://shuzhiniao.com)
  

三、需求风险分析与优先级

需求风险分析是确认那些很可能在开发阶段产生困难或导致项目失败的需求。典型的需求风险类型:

• 技术风险
• 性能风险
• 安全风险
• 数据库完整性风险
• 开发过程风险
• 易变性风险
• 法律风险
• 政治风险

需求优先级是确认各个需求在项目中的重要程度。当项目面临延误时，使用优先级安排系统开发实现需求的先后顺序。

需求分析案例

一、案例说明

以一个简化的银行ATM机系统为例进行需求分析，给出此系统的UML用例图、活动图和类图。银行ATM机系统具有用户身份认证、余额查询、取钱、存钱和转账这五个基本功能。

二、业务用例图建模

三、系统用例图建模

用户身份验证用例规约：

余额查询用例规约：

取款用例规约：

四、活动图建模

活动图与用例图对应，因此，可以为每个用例的内部处理要求建模一个活动图。

用户身份验证用例的活动图：

余额查询用例的活动图：

取款用例的活动图：

五、分析类图建模

分析类图建模ATM机系统的数据需求。

课堂作业与作业练习

1．下面哪种需求采集方法是通过触发问题的想法发挥作用的?B

A．调查表法

B．头脑风暴法

C．原型法

D．研究现有文档与系统

2．下面哪种关系不出现在UML用例图中?D

A．包含

B．扩展

C．泛化

D．复合

3．下面哪种关系在类图中表示一个类是另一个类的一部分? A

A．聚合

B．扩展

C．泛化

D．关联

4．活动图包含下面哪个元素?D

A．活动

B．分支

C．并发

D．以上都是

5．以下哪种不是非功能性需求? A

A．录入成绩

B．安全性需求

C．可扩展性

D．可靠性需求

1.BPMN的编排流程中没有泳池。（√)

2.UML用例之间的表示扩展关系的箭头是从扩展用例指向被扩展用例。(√)

3．活动图无法表达并发执行的活动。（×)

4．类图中两个类之间的泛化关系是指两个类之间的一般与特殊关系。(√)

5．需求变更管理需要有专门的变更过程控制。(√)

观察法分为旁观式观察、解释式观察、(参与式观察)。

调查表中的封闭式问题有3种形式:单选/多选问题、评价问题、(排序问题)。

用例图包含的元素有用例、关系、(角色)。

需求规格说明书中非常重要的三部分内容分别是功能性需求，(非功能性需求)、接口需求。

一个类包含三方面要素:类名、属性、(方法)。