有效软件需求分析

测试积点老人

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 ｔｏ Ｈａｖｅ 需求）

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

<7>管理需求变更