文章目录
- 课程简介
- 考试大纲
- 软件需求与需求规约
- 2.0 可行性分析
- 2.1 需求概述
- 需求分类
- 2.2 需求工程步骤
- 2.3 需求获取
- 2.4 需求规约
- 2.4.1 逻辑模型和物理模型
- 2.4.2 需求分析过程示意
- 2.4.3 结构化分析模型
- 2.4.4 E-R图是数据建模的基础
- 2.4.5 数据流图
- 2.4.5.3 数据流命名规则
- 2.4.5.6 DFD的层次分解:
- 2.4.5.7 画分层DFD指导原则:
- 2.4.6 数据字典
- 2.4.6.1 数据流条目
- 2.4.6.2 数据存储条目
- 2.4.6.3 数据项条目
- 2.4.6.4 加工条目
- 2.5 UML需求规约
- 2.5.1 UML构成
- 2.5.2 用例图
- 2.5.3 用例描述
- 2.6 需求规格说明书(SRS)
- 总结
课程简介
“软件工程”课程是软件工程专业的核心课程,是用工程化方法指导软件开发、维护与管理的一门综合性课程,内容涉及软件分析、设计、实现、维护及项目管理相关的理论、技术、方法和CASE工具。
考试大纲
⚫重点掌握
软件工程的基本概念
和基本原理
;
⚫结合当前我国软件企业对软件开发的需求,掌握并能运用
软件工程的基本原理
和实用的软件开发技术
和基本的管理技术
;
⚫了解
软件工程学科的知识结构
。
⚫(一) 软件工程概念与软件工程的基本要素
⚫(二) 软件过程
⚫(三) 软件需求与软件需求规约
⚫(四) 系统规约及软件设计
⚫(五) 软件测试
⚫(六) 软件工程管理
⚫(七) 软件质量、质量特征以及软件质量保证
⚫(八) 计算机辅助软件工程CASE 工具与环境
软件需求与需求规约
2.0 可行性分析
可行性研究的主要任务是“了解客户的要求及现实环境,从技术、经济和社会因素等三方面研究并论证本软件项目的可行性,编写可行性研究报告,制定初步项目开发计划。”
2.1 需求概述
UR SR BR参考:https://www.zhangshilong.cn/work/307775.html
软件需求描述软件产品要实现的软件服务(功能需求)以及需要满足的约束条件(非功能需求)。用户利用这些服务来完成工作任务,满足业务需求。
**SR(System Requirments,系统需求)是需求分析和建模的产物,由系统分析人员对UR(User Requirements,用户需求)**进行分析、提炼、整理,从而生成指导开发的、更准确的软件需求。
SR撰写在“软件需求规格说明书” ,SRS(Software Requirement Specification,软件需求规格说明书) 中,完整了表达了软件项目的预期特征,为接下来的软件设计和测试提供了依据和基础。
需求分类
用户需求分类:
(1)功能性需求: 定义了系统做什么
(2)非功能性需求:定义了系统工作时的特性
用户需求内容:
(1) 功能
(2) 性能
(3) 环境
(4) 界面
(5) 用户或人的因素
(6) 文档
(7) 数据
(8) 资源
(9) 安全保密
(10) 成本消耗与开发进度
(11)质量保证
功能需求:
系统做什么?
系统何时做什么?
系统何时及如何修改或升级?
性能需求(软件开发的技术性指标)
存储容量限制
执行速度、相应时间
吞吐量
环境需求 :
硬件设备:机型、外设、接口、地点、分布、温度、湿度、磁场干扰等
软件: 操作系统、网络、数据库
界面需求:
有来自其它系统的输入吗?
到自其它系统的输出吗?
对数据格式有规定吗?
对数据存储介质有规定吗?
用户或人的要素:
系统做什么?
用户类型?
各种用户熟练程度?需受何种训练?
用户理解、使用系统的难度?
用户错误操作系统的可能性?
文档需求:
需哪些文档?
文档针对哪些读者?
数据需求:
输入、输出数据的格式?
接收、发送数据的频率?
数据的准确性和精度?
数据流量?
数据需保持的时间?
资源需求:
软件运行时所需的数据、软件。内存空间等资源。
软件开发、维护所需的人力、支撑软件、开发设备等。
安全保密要求:
需对访问系统或系统信息加以控制吗?
如何隔离用户之间的数据?
用户程序如何与其它程序和操作系统隔离?
系统备份要求?
软件材料成本消耗与软件开发进度要求:
开发有规定的时间表吗?
软硬件投资有无限制?
质量保证:
系统的可靠性要求?
系统必须监测和隔离错误吗?
规定系统平均出错时间? ?
出错后,重启系统允许的时间?
系统变化如何反映到设计中?
维护是否包括对系统的改进?
系统的可移植性?
2.2 需求工程步骤
2.3 需求获取
目的
(1) 清楚地理解所要解决的问题;
(2) 完整地获取用户需求。
需求获取方法
(1)面谈和问卷调查
(2)小组讨论;
(3)情景串联;
(4)参与、观察业务流程;
(5)现有产品和竞争对手的描述文档;
2.4 需求规约
模型是对对象系统的形式化的特征抽象,概括性或近似地表示;形式化语言:数学语言、图形等;构造模型的过程是一个抽象、分析的过程。
2.4.1 逻辑模型和物理模型
2.4.2 需求分析过程示意
(1) 通过对现实环境的调查,获当前系统的具体模型(物理模型)
(2) 去掉具体模型中的非本质因素,抽象出当前系统的逻辑模型。
(3) 分析当前系统与目标系统的差别,建立目标系统的逻辑模型。
(4) 对目标系统进行完善和补充,并写出完整的需求说明;
(5) 对需求说明进行复审,直到确认文档齐全,并且符合用户的全部需求为止。
2.4.3 结构化分析模型
2.4.4 E-R图是数据建模的基础
2.4.5 数据流图
Data Flow Diagram,DFD,是描绘系统逻辑模型的优秀工具,用图形符号方式描述系统里面数据的流动方向及处理情况 。数据输入到系统后,经过一些列的加工处理,最后输出新的数据。
基本构成:
数据流,加工,文件,源点与终点。
问题描述:
某工厂的采购部每天需要一张订货报表,报表按零件编号排序,表中列出所有需要再次订货的零件。对于每个需要再次订货的零件,应该列出下述数据:零件编号,零件名称,订货数量,目前价格,主要供应者,次要供应者。零件入库或出库称为事务,通过存放在库房的CRT终端把事务报告给定货系统。当零件库存量少于库存量临界值,决定再次订货。
问题分析:源点/终点,处理,数据存储,数据流
1)源点/终点:系统之外的实体(人,物,系统)
源点:仓库管理员 终点:采购员
2)处理:
需要报表-> 产生报表
处理日常事务-> 事务处理
3)数据存储: 订货信息 库存清单
4)数据流:
订货报表:零件编号、名称、数量…
事务:零件编号、事务类型、数量…
2.4.5.3 数据流命名规则
1)顶层的处理可以使用软件项目的名称。
2)名字最好由一个谓语动词加上一个宾语构成。如“计算手续费”,“检查合法性”等。
3)名字应该反映整个处理的功能,而不能是其中的一部分,否则应该将其分解为多个处理。
4)不要使用意义空洞的名字。如“计算”“处理”
5)如果命名时遇见困难,很可能是分解不当造成,应考虑重新分解。
分层数据流图中,数据存储一般局限在某一层或某几层
命名方法与数据流相似
2.4.5.6 DFD的层次分解:
2.4.5.7 画分层DFD指导原则:
(1) 父图与子图的平衡
模型细化时必须保持数据流的连续性,即每个细化部分的输入和输出必须保持不变(父图和子图输入数据和输出数据应一致)。
2.4.6 数据字典
2.4.6.1 数据流条目
给出DFD中某个数据流的定义,
通常包括:
数据流标识
数据流来源
数据流去向
数据流的数据组成
流动属性描述:频率、数据量
2.4.6.2 数据存储条目
2.4.6.3 数据项条目
2.4.6.4 加工条目
对于基本处理过程给出加工逻辑,也包括一些与加工有关的信息,如执行
条件、优先级、出错处理等。
加工逻辑描述工具:
1)用结构化语言
2)用判定表描述
3)用判定树描述
2.5 UML需求规约
2·5 UML需求规约UML(Unified Modeling Language,统一建模语言),是为面向对象软件开发方法定义的一种可视化建模语言,为工业界标准建模语言。标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护。
2.5.1 UML构成
2.5.2 用例图
2.5.3 用例描述
2.6 需求规格说明书(SRS)
1 前言
1.1 目的
1.2 范围
1.3 定义、缩写词、略语
1.4 参考资料
2 任务概述(项目概述)
2.1 产品描述
2.2 产品功能
2.3 用户特点
2.4 一般约束
2.5 假设和依据
3 具体需求
3.1数据描述(DFD、DD)
3.2功能描述
3.3接口
3.4 性能需求
3.5 属性
3.6 其它需求
总结
本系列博客是软件工程的相关博客,本文是第2部分软件需求与需求规约。