需求分析

1. 需求分析是解决做什么的问题，全面理解客户的各项要求，并准确的表达所接受的客户需求
2. 输入时目标、问题、场景，输出是形式化的功能规约、质量属性和设计约束，分析过程要考虑众多涉及的利益和DFX属性（性能、可靠性、可扩展性、响应时间）
3. 非功能需求主要指不明确的功能需求，分析过程需要将不明确的功能需求细化成功能需求，但是想竞争力需求是商业领域关注的，不属于软件需求

需求分析方法

1. 功能恩杰发
2. 结构化分析法
3. 信息建模法
4. 面向对象

分析过程

1. 提出问题
2. 细化功能需求、非功能质量属性需求，确定需求优先级
3. 输出需求规格说明书
4. 评审，达成共同的理解和认识以及需求描述的正确性、完整性和清晰性

基于use-case技术需求分析方法

1. 利用建模分析需求，需要交付用例图、用例规格说明
2. 需求分级方法，入选与落选法、三层分级法、kano模型法、两两比较并排序法

识别actor

1. 确定在系统边界外部与系统进行有意义交互德人物
2. actor可以是人、硬件、外部系统
3. 使用提问方式确定actor
   • 谁使用系统，谁从系统获取信息
   • 谁为系统提供信息
   • 谁来维护和管理系统
   • 其他系统与你的系统交互的信息是什么
   • 在某一预定时间，是否有什么事自动发生
4. 用例是用Actor视角描述一个功能，要有功能完成会对actor提供什么样的价值

整理场景

1. use case会包含一个或者多个场景
2. 场景分为主场景、可选场景、异常场景

描述用例

1. 基本用例图描述了actor和用例之间的交互关系
2. 实际系统中要确定Actor和Acotr、用例和用例之间的关系，利用关系调整用例，将公共信息进行提取
3. actor之间存在泛化关系
4. 用例之间存在包含、扩展、泛化关系

描述用例

1. 用例描述即写用例规约
2. 用例规约组成
   • 用例名（主谓、动宾短语组成）
   • 用例标识
   • 涉及的参与者
   • 描述
   • 用例规格说明（前置条件、后置条件、正常事件流、异常事件流）
   • 其他，肺功能需求，设计约束、尚存在的问题
3. 前置后置条件
   • 前置条件约束系统满足什么条件，才能开始
   • 后置条件，用例执行后系统达到什么装填
   • 用例依赖其他用例，可以视为前置条件
   • 前置、后置条件是状态不是动作，必须是系统能检测的
   • 有助于识别漏掉的用例，如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例

需求用例

用例内容	用例解释	写作举例
用例名称	给用例一个名称	记录员工工时
用例编号	便于管理	xxx.yyy.zzz.001
简要说明	用例的概要描述	当员工上班时需要刷卡，系统记录下员工工时
actor	用例的所有actor	员工
前置条件	启动用例前，系统满足的条件	系统管理员已启动工时系统，显示刷卡界面
最小保证	用例对系统的最低要求	工时系统在pc上稳定运行、读卡器正常工作
后置条件	用例完成后，系统输出或达到的状态	如果员工刷卡，则记录本次刷卡的时间
触发时间	启动用例的事件	当员工刷卡时，触发用例
基本场景	完成用例目标需要的一系列基本动作	1. 员工刷卡，读卡器读取员工卡信息，输入到系统 / 2. 系统获取刷卡事件，并将员工刷卡信息录入系统 \ 3. 系统将员工刷卡信息持久化\ 4. 系统界面显示员工刷卡信息（刷卡成功）
扩展场景	非基本的成功场景和失败场景	1. 如果员工信息在系统不存在，界面提示，员工不存在\ 2. 如果员工刷卡方式不正确，导致读卡器未督导员工卡信息，界面提示，请重新刷卡 3.如果工时系统运行出现故障，界面提示：系统故障
DFX属性	该用例涉及的DFX属性的要求和各架构的目标	1. 员工刷卡后，在0.5s内在界面显示刷新信息 2.已刷卡成功的员工信息，系统重启不丢失

需求分析输出的质量要求

1. 完整性，对于一个目标，考虑完整的场景，没有遗漏任何actor、dfx属性、满足所有设计规范
2. 正确性，
   • 相关涉众确认了需求的正确性，
   • 无歧义
   • 原子的，每个需求描述不可太简洁，
   • 最新的，需求反应了系统当前的实现状态，不会跟随cr变更而更改
3. 可验证性
4. 一致性，多个需求间没有自相矛盾，可追踪，需求来源、演化及其在后续开发阶段的影响和使用时可追踪的

!名词释义rr、ir、sr、cr、ar

需求管理

1. 需求管理是一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程
2. 需求管理主要是针对需求相关活动的规划、控制和变更管理

需求管理实践

1. 变更控制
   • 需求变更需要经过正式的评估来决定是否批准
   • 保持项目计划与需求同步
   • 以可控制的方式将需求变更融入到项目中
   • 估计变更需求产生的影响，并协商新的约定
2. 状态跟踪
   • 整个项目过程中，始终跟踪需求状态及变更情况
3. 版本控制，使项目团队和用户达成共识，定义需求极限
4. 需求跟踪
   • 将没想需求都能与对应的设计、源代码、测试用例联系起来，实现需求跟踪

需求变更

1. 需求变更定义，需求说明书一般经过论证，如果在需求说明书经过论证后，需要在原有的基础上追加或者补充新的需求或对原有需求进行修改和削减，均属于需求变更
2. 需求变更影响，影响研发效能；增加项目的人员、费用开支，影响研发速度；影响软件质量；影响开发者与用户间的合作关系