概念：软件开发的一种过程性框架
类型：瀑布模型、V模型、原型模型、增量式模型
瀑布模型：需求分析→设计→程序编码→软件测试→运行维护
基本概念：一种获取，组织并记录系统需求的系统化方法。以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程
层次特征：业务需求、用户需求、功能需求
主要过程：需求开发过程、需求管理过程
注：需求分析：解决什么业务问题
需求规格说明：所开发的系统提供什么功能，性能
概念：面对对象由对象、类、继承、通信四个概念组成。
**对象：**在现实世界时是客观世界中的一个实体；在面向对象程序中表达成计算机理解、可操纵、具有一定属性的行为和对象；在计算机世界中是一个可标识的存储区域
封装：把对象的全部属性和全部服务结合到一起，形成一个不可分割的独立单位（对象），尽可能隐藏对象的全部细节（信息隐蔽）
继承：使用已存在的定义做为基础建立新定义的技术
概念：基于面向对象的可视化的通用(General)建模语言
作用：描述系统的功能需求
组成：执行者(Actor)、用例(Use Case)、执行者用例的关系、用例之间的关系
用例之间的关系：泛化、使用、扩展关系
泛化：用例之间的一般与特殊关系
《include》：一个用例使用另外一个用例
《extends》：通过什么被扩展用例添加动作来扩展用例
类图包含了一组类似及他们之间的关系
组成：类、属性、操作
关系：
概念：用来描述一个特定对象的所有可能的状态以及状态转移的事件
状态：所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。
初态⚫：状态图的起点，只有一个初态。
终态◉：状态图的终点，可以有很多个终态。
中间状态：名字域+活动域
符合状态：可以进一步组合的状态
状态迁移："→"通常是由事件引起的
定义：描述了系统中各种活动的执行顺序
组成：活动、转移、对象流、泳道（采用分组的机制）
转移：转移用带箭头的直线表示，可标注执行该转移的条件，无标注表示顺序执行。
泳道：一个道代表一组对象
对象流：活动图中可以出现对象，对象作为活动输入/输出。（用虚箭头表示）
概念：用来描述对象之间动态的交互行为，着重体现对象之间信息传递的时间顺序。（水平轴→对象，垂直轴→时间）
组成：
愿景（描述项目核心价值【老大】）、涉众、投入、风险、可行
没有度量指标的目标没有意义
什么是愿景：在老大看来为什么要开发这个系统
愿景的两个要点：1、一定来自老大的想法 2、一定要有度量指标
例如：愿景→实现电子速汇款 度量指标→数据到账时间短
同一件事不同利益视角，探索系统的需求就是探索涉众利益的平衡点
划分原因：系统需求易变，业务需求(涉众利益)不变
客户是最大的涉众
划分涉众优先级
业务执行者：业务执行者在业务外面，业务工人在业务里面
概念：一个组织或人群
例：淘宝网业务单元为淘宝网公司及内部人员，业务实体则是淘宝网站
有效的完整目标
只针对业务执行者，为业务执行者提供价值(内部活动不是业务用例)
用例命名：执行者视角→动词+宾语
用例的粒度：用例要有路径，路径要有步骤，而这一切都是可观测的
概念：业务对象模型（也叫领域模型）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象
业务建模的目的：描述现实，帮助发现软件需求
UML业务建模：用业务用例模型和业务对象来描述现实
需求文档编写步骤：
用例文档即为需求文档
系统执行者：谁使用系统的主要功能、谁需要系统的支持已完成日常工作任务、系统需要应付和处理哪些设备、系统需要和哪些外部系统交互、谁对系统运行产生的结果感兴趣、有没有自动发生的事件
业务范围：指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在
系统范围：软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集
补充：
系统外，交互的功能需求
有多少执行者就代表有多少接口
RUP：系统用例实例（某人用系统做什么）是在系统中执行的一系列动作后（步骤），这些动作将产生执行者可见的价值结果（目标），一个用例定义了一组用例实例（路径）
系统用例：
形式：[执行者]使用系统来[用例]
例：
1、用例编号
2、用例名 （水电站财务部项目）
提交费用单
3、执行者
其他部门人员
4、前置条件 (一个用例开始之前系统所必须的环境和状态)
其他部门人员已经登录系统
5、后置条件 （一个用例成功结束后系统应该具备的状态）
系统已保存费用单
6、涉众利益
其他部门人员（3）-----------希望操作简单，尽快把费用单交给会计。
部门领导（上游）（1）----担心搞错费用的金额和用途。
会计（下游）（2）-----------担心有重复有错误增加工作量。
括号内的数字为涉众的优先级。
前置条件：开始用例前所需的系统及其环境状态
后置条件：用例成功结束后系统应具备的状态
基本路径：用户最想看到、最关心的路径
例：
拓展路径：系统要处理的意外和分支
补充约束：
字段列表：
"+"→数据序列 “[ ]”→可选项 “{}*”→多个
{|||}→可能取值 “A=B”把B的结构赋给A
用表达式表示：
业务规则
非功能需求
交互四部曲：动作→验证→改变→回应
书写用户文档：
拓展：分离扩展路径
包含：提取公共步骤，便于复用
泛化：同一业务目的的不同技术实现
何时使用扩展关系：
例：
用例排序
大量用例时的分包：按执行者分包、按主题分包、按开发团队分包、按发布情况分包
包图:
只在软件的开发过程中存在
表示：
“+”——是公共的，对所有包可视
“#”——保护，只能对该包的子包可见
“-”——私有，对外包不可视
包的联系：
调研需求：
需求调研内容：功能、接口、用户使用环境、重要性要求、稳定性要求、易用性、性能
需求调研方法:问卷调查、访谈、观察、开会、制作示意图、角色扮演、原型开发
随着系统上线，用户提出的问题和新的需求
易用性问题：界面布局、操作方式、文字表达、排序条件等细节问题，这些问题不解决的话会降低用户体验，此类问题一般应尽量解决。
拒绝变更：
常见问题：
对于符合需求的易用性方面的要求，应尽量满足。
有些问题可通过改善管理办法来解决。
客观条件做不到的、技术上做不到的，应予以拒绝。
超出范围的要求，可引导客户做第二期。
有些问题需要同时在软件和管理办法上做工作来改善。
”老大“提出的新需求
”老大“的需求必须满足
”老大“提出的需求方案只是一种解决方案，可以通过分析用不同解决方案满足”老大“的根本需求。
需求认知曲线
两种需求认知曲线
敏捷过程希望尽快得到可以发布的软件版本，尽快得到反馈
三要素：角色，功能，价值（按“作为一个…，可以…，以便…”）
作用：
作为进度跟踪的依据
作为和人交谈的备忘录，敏捷过程提倡足够就好，避免浪费
