体系需求剖析

需求收集

研究现有文档与体系

  • 安排机构图
  • 体系规划文档
  • 作业规范文档
  • 事务单据
  • 数据报表
  • 反应定见
  • 范畴常识
  • 现有体系

安排机构图

安排机构图供给了安排机构的部分、关键岗位与角色构成,并能反映它们之间的所属联系。

电子科大软件体系架构规划——体系需求剖析

体系规划文档

安排机构的使命陈说、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)

电子科大软件体系架构规划——体系需求剖析

电子科大软件体系架构规划——体系需求剖析

电子科大软件体系架构规划——体系需求剖析

剖析类图建模步骤

  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并发用户
  • 该体系应724小时持续运转

接口需求

  • 用户接口:界说了用户运用软件时的接口需求,如用尸是迪过饰令仃处是图形用户界面运用体系。
  • 软件接口:指待开发软件与其他软件体系之间的接口。如体系调用API服务接口完结体系功用集成。
  • 硬件接口:描绘本软件与硬件设备之间的接口,如设备驱动、接插件规范等。
  • 通信接口:描绘体系与其他体系之间的通信办法与协议,如局域网违信协议、蓝牙4.0协议、WIFI协议等。

四、需求规范阐明事例

  • 《四川省疾病控制中心法定传染病监测陈说规范化办理平台》需求规范阐明书
  • 《智慧酒店物品追寻体系》需求剖析陈说

需求办理

一、需求办理内容

需求办理首要包括两方面内容:

  • 对需求阐明进行规范化处理;
  • 对需求的改变进行流程化办理,避免呈现需求改变带来的项目失利危险

当需求数目比较少时,选用需求依靠矩阵是一种发现需求矛盾或需求重叠的有用技能办法。

电子科大软件体系架构规划——体系需求剖析

二、需求改变办理

在体系开发生命周期的任何阶段,需求都可能发生改变。若没有对这些改变进行办理,将会给项目办理带来麻烦。需求选用需求改变办理东西进行存储与跟踪办理。

电子科大软件体系架构规划——体系需求剖析

需求改变追寻办理:

电子科大软件体系架构规划——体系需求剖析

需求改变控制流程:

电子科大软件体系架构规划——体系需求剖析

需求改变办理东西:

三、需求危险剖析与优先级

需求危险剖析是承认那些很可能在开发阶段发生困难或导致项目失利的需求。典型的需求危险类型:

  • 技能危险
  • 功用危险
  • 安全危险
  • 数据库完好性危险
  • 开发进程危险
  • 易变性危险
  • 法令危险
  • 政治危险

需求优先级是承认各个需求在项目中的重要程度。当项目面对延误时,运用优先级安排体系开发完结需求的先后顺序。

电子科大软件体系架构规划——体系需求剖析

需求剖析事例

一、事例阐明

以一个简化的银行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种方式:单选/多选问题、点评问题、(排序问题)。

用例图包括的元素有用例、联系、(角色)。

需求规范阐明书中非常重要的三部分内容分别是功用性需求,(非功用性需求)、接口需求。

一个类包括三方面要素:类名、特点、(办法)。