有效需求分析

2860阅读 0评论2019-08-16 iibull
分类:其他平台

功能部分
    那个阶段引入的缺陷最多
        需求阶段      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. 细化用例模型
    检查, 检查用例的细节, 备选/异常流. 多用例之间相互引用关系. 用例粒度,复杂度的评估.

===========================================================实际案例

===========================================================

===========================================================
===========================================================
===========================================================































上一篇:ubuntu 上多个摄像头的设置
下一篇:有效需求分析二: 非功能性需求&需求管理部分