51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师【周活动】 找茬--心里圈的故事 !【长期招募】博为峰网校招聘兼职讲师!横扫BAT,Python全栈测试开发技能大全
【105期】:敏捷流程下的测试理论及探索性测试 【征稿】提交你的测试成绩单! 【专题】用尽一切办法只为让你学好用例 自学软件测试那点事
查看: 702|回复: 0

[转贴] 有效软件需求分析

[复制链接]
  • TA的每日心情
    慵懒
    2019-6-25 09:35
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2018-12-26 09:38:38 | 显示全部楼层 |阅读模式

    1. 现状
    缺陷按阶段引入的比例:需求-56%; 设计-27%; 编码-10%; 其他-7%;<需求和设计引入近85%的缺陷,编码实现只引入10%的缺陷>
         --〉控制需求和设计是关键,控制需求就是有效需求分析,得到完整一致的需求规格说明书;控制设计就是软件的架构。
       
    在上面提到的需求-56%部分,导致需求缺陷的原因比例:不一致-49%; 冗余-31%; 错误-13%; 歧义-5%; 遗忘-2%;
         --〉需求分析阶段,消除需求的不一致和冗余是关键。

    ......Even the most perfect programming verification can only satified their specifications,
    while the most difficult part of software developments is to obtain specifications with completeness and consistency.
    Many essential works of program construction are to remove defects in specifications.

    再优秀的产品,也只能承载有限个需求!

    Do things right 把事情做对 (暗示事情的准确性)
    Do the right things 做正确的事 (暗示做事的方向性)

    ***有效需求第一要务:我们交付的不是产品本身,而是产品的价值***
    需求分析过程需要考虑,产品,价格,应用场景,用户体验,产品生态,维护服务等,所以相关方的参与至关重要。

    客户希望需求分析者做到的有哪些?
    <1>需求分析者讲述的是业务领域的语言
    <2>需求分析者学习和熟悉客户,熟悉客户的业务和目标
    <3>围绕着需求与实现方案,需求分析者在倾听的基础上提出概念和备选方案
    <4>需求分析者提供可以使产品变得好用的概念和备选方案

    关于需求开发和需求管理的三个基本问题
    <1>我是谁,即:我做什么?
    <2>我的产品卖给谁&他们为什么买我的产品/不买我的产品
    <3>我的产品谁在用&他们为什么喜欢用/不喜欢用我的产品

    2.培训大纲
    ------需求开发-------
    <1>需求的基本概念--需求是what to do 不是 how to do
    需求的定义:功能性需求(做什么);非功能性需求(有多棒);设计与实现的约束条件(必须满足的条件);
    非功能性需求,注意的是不干什么;
    需求:Stakeholder Needs 相关方的需求;用户需求;产品需求(用户需求转化为开发者的语言之后的需求);产品组建需求(产品完成系统架构之后的需求);
    白云级需求 --价值-- 〉风筝级需求 --价值-- 〉场景级需求

    <2>需求开发,捕捉和挖掘需求 --- 〉关键是要抽象出需求的价值(建设目标)
    需求开发的技术和方法:访谈;业务逻辑捕捉;联合需求工作会议-workshop;问卷调查;相似系统的演示-竞品分析 ;原形;

    <3>需求的分析--需求分析:从用户提出的需求出发,挖掘用户内心真正的目标,并转为为产品需求的过程。
    *****需求分析的最高原则是:使之收敛;*****
    需求分析的技术和方法:
    方法1:用户故事/用户故事地图;
        As a <Role>, i want to <Activity>, so that <Business Value>;作为一个<角色>,我想要<活动>,以便于<商业价值>;
        用户故事六个特性:INVEST;<Independent,Negotiable,Valuable,Estimate,Small,Testable>
        使用用户故事分析需求的确定:只见树木不见森林;因为用户故事特性要求必须可测试,所以用户故事方式只能分析功能性需求
        用户故事地图--- > 行走的骨骼; 子系统-- 〉功能项 -- 〉用户故事

    方法2:Use Cases(用例编号;用例标题;参与者;功能描述;正常事件流;异常事件流;使用/包含业务用例;优先级;业务规则;特别要求;未决问题;)
           Use Case的作用:将系统模型从业务模型中完全的抽取出来; 有利于测试;容易转换成用户手册;

      方法3:原形法--非功能性需求分析最好采用原形法
           草图(低保真) --- 〉保真(彩图效果) --- 〉切图(动画)
           需求平衡和优先级:253原则(20%关键需求;50%可选需求;30% Nice to Have 需求)

    -----需求管理---------
    <4>需求的建模和规格化
    需求建模的技术方法:数据流图/ER图/状态迁移图等图解方式
       需求规格说明书的要素:正确性;明确;完整;可验证;一致;易于相关方理解;可修正的;可跟踪的;与设计无关的;简明的;有组织的;
      
    <5>需求的分解和跟踪
      产品需求到产品组件需求的分解, 分解的过程就是架构设计;
      我们是按照产品的需求向客户收钱的;却是按照产品组件需求去花钱的;
    <6>需求的评审与确认

    <7>管理需求变更


    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /2 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2019-8-24 02:03 , Processed in 0.059328 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2019 Comsenz Inc.

    快速回复 返回顶部 返回列表