目录
本复习笔记基于王玉林老师的课堂PPT与复习大纲，供自己期末复习与学弟学妹参考用。
分为三个部分讲解：需求分析、结构化需求分析方法、面向对象分析
- 软件需求表达了对解决现实世界中某类问题的产品的要求和约束
- 确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景
- 需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合
- 可验证性
- 需求是测试的依据（即能测试)
- 尽可能量化表述
- 不可验证:“软件应该是可靠的”;“软件应该对用户是友好的”
- 可验证:“在任何营业时间内出现一个致命错误的可能性低于1*10-8""
- 验证某个软件需求可能非常困难，代价很大。例如，呼叫中心软件验证吞吐量需求
需求除了行为属性外还有其他属性，如有优先级
折中: 根据需求紧迫程度和现有资源(人力、技术、资金等)安排需求的实现先后顺序，有些先做有些后做，甚至有些可以放在第二期或第三期来做。
- 功能性需求
- 描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务
- 非功能需求
- 指解决问题时的约束。非功能性需求有时也称为限制或质量要求
- 可进一步被分为性能要求、可维护性要求、安全需求、可靠性要求、可移植性要求、......
- 非功能需求限定了选择解决问题方案的范围，如运行平台、实现技术、编程语言和工具等
下面通过一个实例分析不同需求的区别
将飞机订票系统中的以下方面做如下的划分，F代表“功能性”，NF代表“非功能性”，X代表“不应当是需求”。简要的说明功能性或非功能性需求的种类。对于不应当是需求的方面，说明其原因。
·如何输入有关航班、乘客及订票信息 F:输入
·什么信息要出现在机票和报告中 F:输出
·如何计算乘机费用 F:计算
·什么信息必须存储在旅行社和其他人访问的数据库中 F:数据存储
·这个系统应该设计成可以处理旅行常客计划。 NF:增强的容限
·这个系统在任何时候都必须是可用的。一周中只允许有2分钟宕机时间 NF:可用性需求
·必须使用排序算法根据离开时间对航班排序 X:这是一个设计问题
- 需求获取
- 软件需求的来源以及软件工程师收集这些软件需求的方法
- 完整定义：指的是软件需求的来源以及软件工程师收集这些软件需求的方法。它也称为需求抓取、需求发现和需求获得
- 需求提炼
- 产生操作规格参数表，指明与其他系统元件的软件接口，确定软件必须遵循的约束
- 完整定义：对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成需求规格说明书。
- 需求描述
- 撰写需求规格说明书
- 完整定义：软件需求规格说明书(SRS)----是对待开发系统的行为的完整描述，包含了描述用户与软件交互的用例的集合。用例通常描述功能性需求，除了用例之外，SRS还包含非功能性需求。
- 需求验证
- 检查需求的正确性、完整性、非二义性、内部和外部的连贯性
- 完整定义：需求验证即检查需求的正确性、完整性、非二义性、内部和外部的连贯性。这不可避免地需要用户的参与，用户是问题的所有者，只有他们才能决定需求规格说明书是否恰当描述了他们的问题
结构化分析方法是一种建模技术，它建立的分析模型如图所示：
如上图所示，结构化分析建模的核心是数据字典
（数据流图 / 实体-关系图 / 状态-迁移图）
数据流图 —— 功能建模 —— DFD
实体-关系图 —— 数据建模 —— ERD
状态-迁移图 —— 行为建模 —— STD
* 表示只能两个同时存在
⊕ 表示只能有一个存在
+ 表示可以同时存在也可以只有一个存在，可以省略
仅包括要开发的目标系统，相当于确认系统在环境中的位置，确认与外部实体的边界。
按照系统的层次结构进行逐步分解,并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统
（我的理解是把目标系统内部的数据流逐步细化，一层一层分解。）
银行储蓄系统的业务流程:
- 储户填写的存款单或取款单由业务员键入系统
- 如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率、密码（可选）等信息并印出存单给储户
- 如果是取款而且开户时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户
- 要求画出分层的数据流图，并细化到2层数据流图
参考解答：
1. 识别外部实体以及输入输出数据流
2. 绘制顶层数据流图
3. 绘制一层数据流图（细化系统内部流程）
4. 绘制二层数据流图
对一层图中的“处理存款”及“处理取款”进行进一步分解，得到二层数据流图，即处理存款的数据流图和处理取款的数据流图
处理存款的数据流图
处理取款的数据流图
用例模型:用例和场景表示的功能模型(用例图)
对象模型:用类和对象表示的静态模型(类图)
动态模型:由状态图和交互图(如顺序图)表示的交互模型状态图:对一个对象建立，描述其状态及转换
交互图:对一个用例建立，描述多个对象间的动态交互
用例图的主要元素是用例(Use Case)、参与者(Actor)和它们之间的关系。
用例之间主要有三种关系：包含、使用、扩展
泛化：当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
包含：包含关系表示一个用例（基础用例，Base)所执行的功能中总是包括另一个用例(被包含用例)的功能。具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。被包含用例是可重用的用例——多个用例的公共用例。
即:当多个用例使用同一功能时，可将该功能单独提取成一个用例（被包含用例)
包含关系以指向被包含用例的虚线箭头表示
扩展：扩展关系指一个用例（基础用例，Base)的执行可能需要由其他用例(扩展用例，Extension)的功能来扩展。即，扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中
扩展关系以指向基础用例的虚线箭头表示
