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

王翊珩

已于 2023-12-21 19:12:51 修改

阅读量643

点赞数

分类专栏：软件系统架构设计文章标签：需求分析架构

于 2023-09-21 18:37:37 首次发布

本文链接：https://blog.csdn.net/m0_63230155/article/details/133143281

版权

软件系统架构设计专栏收录该内容

10 篇文章 4 订阅

订阅专栏

文章目录

系统需求分析

系统需求分析

需求采集

研究现有文档与系统

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

组织机构图

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

系统规划文档

组织机构的使命陈述、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…1	表示另一个类的一个对象只与该类的一个对象有关系
0…*	表示另一个类的一个对象与该类的零个或多个对象有关系
1…*	表示另一个类的一个对象与该类的一个或多个对象有关系
0…1	表示另一个类的一个对象没有或只与该类的一个对象有关系
m…n	表示另一个类的一个对象与该类最少m，最多n个对象有关系 (m≤n)

分析类图建模步骤

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

抽取类的方法

用例驱动方法

从用例模型抽取类的方法:
- 分析用例图模型，抽取含有业务数据的实体，作为系统的第一批实体类，如Grades类和ReportCard类。
- 将用例的参与者作为第二批实体类，如Teacher类、Student类和Administrator类。
名词短语方法抽取类
- 阅读需求文档陈述，从中找出包含数据信息的名词短语
- 每个名词短语可以作为一个候选类
- 将候选类分为相关类、模糊类
例：采用名词短语方法从大学注册系统的需求陈述进行类抽取
- 大学的每个学位都设置了多门必修课程和选修课程
- 每门课程设定了级别及学分
- 同一课程可以是多个学位的组成部分
- 每个学位都规定了完成所要求的最低总学分值
- 学生可以对学位培养的开设课程进行选修，形成适合自己需要的学习计划。当通过这些课程学习的考核评价后，就能获得他们所注册的学位。
采用名词短语方法抽取的类如下:

相关类模糊类
Course CompulsoryCourse
Degree ElectiveCourse
Student StudyProgram
CourseOffering
说明:
1）名词短语方法抽取的类是否完整，取决于需求文档陈述的完整性和正确性。

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

根据对象分类理论来识别业务领域通用的概念、事件、组织、人员、地点等术语来定义类。
- 概念类，如专业（Major)、课程目录（Curricula）、课程（Course)
- 事件类，如选课(SelectingCourse）、重修课程（RetakeCourse)
- 组织类，如学院（College)
- 人员类，如教师(Teacher)、学生(Student)
- 地点类，如办公室(Office)
CRC(Class-Responsibility-Collaborator，类-职责-协作者)方法

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

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