软件工程part02-软件需求与需求规约
文章目录
-
- 课程简介
- 考试大纲
- 软件需求与需求规约
-
- 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部分软件需求与需求规约。