功能部分
那个阶段引入的缺陷最多
需求阶段 56%
设计部分 27%
编码 10%
其他 7%
公司的挑战
高层的要求 - 交付慢, 接单周期长
策划案缺少 1. 异常流 2.肺功能需求描述 3.系统依赖和边界 4.整体业务流
需求文档缺乏或不规范, QA编写测试用例无指导.
需求澄清速度慢, 周期长, 往返次数多.
需求分析重要性 / 需求分析的流程和分工 / 基本方法 / 标准文档输出.
什么是需求:
1. 高层决策/验证需求
2. 业务需求: 客户/组织为什么要开发这个系统. 立项阶段,输出项目愿景/范围 --> 项目负责人
特征: 定义系统目标, 反映组织/客户对系统/产品高层次的目标要求, 一般为项目发起方提供的纯粹的业务描述, 用来解决遇到的问题(如投诉量大, 客户流失率高)或者顺应时代潮流(电子商务化, 移动支付/移动办公等)
3. 用户需求: 用户做什么,满足什么业务,获得什么价值. 输出用户故事/特征清单 --> 策划人员
特征: 通过用户访谈,调查,分析用户工作场景. 从不同角度/层次/力度分析. 解决存在的矛盾包括个体差异,片面思想,盲人摸象. 从而产生用户故事被用户认可.
4. 软件需求: 开发人员要实现什么,满足那些质量,
产物: SRS 需求分析与建模 --> 项目经理
特征: 指导开发过程中的功能, 对需求分析整理出规格化的描述, 进行结构和逻辑的描述.
5. 功能需求/ 非功能需求,
用户需求
软件需求
===========================================================
有效需求分析方法
===========================================================
系统上下文:
理清边界和范围. 找出待建系统和所在环境之间的关系, 即定义待建系统和系统外部实体(人员,设备,其他系统)之间的边界和接口.
上下文模型直观反映系统用户是谁, 用户用系统做什么, 系统依赖谁.
一般在需求分析前确定系统上下文模型, 然后进行用例建模. 即先定义在分析.
1. 上下文中的“用户”，可作为用例模型中的Actor；
2. 上下文图中的“连接器“，可直接作为用例模型中的 UseCase，也可作为一个业务事件
的流程分析线索；
3. 上下文图中的“外部系统”，可以作为需求文档中的外部依赖输，也可以作为架构设计
中的外部接口设计重要输入；
4. 上下文图是一个与非技术干系人进行沟通好工具。
===========================================================
用例分析:
从用户的角度上看, 他们并不想了解系统的内部结构和设计, 他们关心的系统能提供的服务,即系统如何被使用.
特征:
行为序列: sequences of actions: 一个用例由一组产生特定结果的行为构成, 这些行为不可再分解.(例如用户输入, 执行,产生结果等)
系统执行: system performs 系统为外部角色提供服务
价值结果: 可观测的, 有价值的结果 observable result of value.
特定角色: particular actor: 人/设备/外部系统 等 能够触发某些行为.
1. 识别并描述参与者(actor) - 同系统交互的所有事物, 包括人/外部系统/硬件设备/时钟等等.
例如: 谁/外部系统 使用/维护/安装/关启系统? 谁从本系统获取/提供信息? 自动事件发生?
2. 识别用例(use case), 并给出简要描述
从分析系统的参与者开始, 考虑每个参与者是如何使用系统的, 系统给用户提供哪些课件的价值结果. 即:
actor 希望系统提供什么功能.
系统是否存储和检索功能, 有的话由那个参与者触发
系统改变时是否通知参与者
是否存在外部触发事件, 由谁触发.
3. 识别参与者于用例的关系: 一般包括关联关系/泛化关系/包含关系/扩展关系
用例的粒度是个性化的东西, 无严格标准, 需要根据经验和项目复杂度判断用例粒度.
举例:
系统管理员 -> 维护用户信息. 其中的用户的增删改查是否需要独立为用例?
4. 每个用例的详细描述
用例名称: 唯一标识, 一般为动宾格式. 如 登记课程、管理商品、获得竞拍位、查询消费额
用例简述: 用例快速总结. 但不宜过于简单. 例如
登记课程: 学生登记本学期需要学习的课程。在学期开始的阶段，学生也可以修改或删除他所选择的课
程。课程目录系统提供了本学期开设的所有课程列表。本用例的主参与者是学生。课程目录
系统是这个用例的一个辅助参与者.
用例简述的基本套路
? 谁在…条件下做了…事情，实现…；
? 还可以做…，实现…；
? 异常情况有…、…；
? 主要参与者是…，辅助参与者是…
前置条件、后置条件: 系统必须满足的 条件 或 状态
前置条件: 说明用例执行的约束, 方便写测试用例, 便于挖掘/识别隐含的用例(因为前置条件往往是其他用例的执行结果.). 一般可以是: 权限足够? 时间或规则限制?等等
后置条件: 业务方和技术方的验收标准. 一般要注意actior的利益均得到满足, 系统的状态发生变化,所有的事件流都有完整的状态.
用例步骤描述——事件流
步骤教书准则:
1. 主语…..谓语动词….直接宾语……前置短语
例如：
? 学生，从有效的课程列表中选择某一门课程。
? 账户系统，从A账户转移n个BT币到B账户中。
2. 尽量站在用户的角度来描述步骤，而不是描述系统内部的实现细节
签到的反例
1. 用户点击签到；
2. 任务系统读取签到任务状态，设置签到状态为完成；
3. 任务系统添加n个积分到用户的积分帐号；
? 签到的正例
1. 用户点击签到；
2. 任务系统显示当月的签到列表，并提示获得n个积分
3. 描述执行者的意图而不是动作. 通过操纵系统的用户界面来描述用户的动作，这是在编写用例时常见的一种严重错误, 例如:
4. 用例中描述一个步骤是为了表现一个事务，在事务中通常包含四个相互作用的部分：
1. 主执行者向系统发送请求和数据
2. 系统验证请求和数据
3. 系统更改内部状态
4. 系统向执行者返回结果
5. 准则内应该是"确定", 而不是"检测/检查与否等"
例如: 创建群”用例步骤描述：
1. 用户输入创建群的相关信息：群成员、群名、密群方式、群类型；
2. 系统 验证/确认/确保 了群名称是正确的；
3. 系统显示群聊界面，并通知其他群成员；
上述步骤描述了一个正常的场景，异常情况需要在备选流中继续补充完整。为了保证基本流的简洁，不应该使用判断语句。
用例步骤描述——备选流 Alternative Flow
备选事件流包括与正常行为相关的可选行为，同时也包括正常行为的各种变形。备选事件流看作是基本事件流的“绕行道”，有些备选事件流将返回到基本事件流，而有些将结束此用例的执行。
异常流: 异常流是基本流的异常情况，不能达成用例目标
5. 细化用例模型
检查, 检查用例的细节, 备选/异常流. 多用例之间相互引用关系. 用例粒度,复杂度的评估.
===========================================================实际案例
===========================================================
===========================================================
===========================================================
===========================================================
