版本管理和版本规划

1. 需求收集与分析

什么是需求

1. 需求的定义：

   IEEE软件工程标准词汇表(97年)中定义需求为:

   用户解i决问题或达到目标所需的条件或权能(Capability)。
   系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能.
   一种反映上面(1)或(2)所描述的条件或权能的文档说明。

2. 软件需求包括以下几个层次：

   业务需求
   用户需求
   功能需求
   非功能需求、软件需求规格说明等

需求的管理流程

1. 需求收集：

• 原始需求----通过收集----用户需求
• 需求收集方法： 访谈、调查问卷、 需求讨论会 、竞品分析、 文档与数据（大数据挖掘）、 原型

2.需求分析：
①针对待开发软件提供完整、清晰、具体的需求，确定软件必须实现那些任务。
②分析软件：《影响地图》

2. 基于用户故事的需求拆分与澄清

需求层级

用户故事

• 用户故事是描述需求的一种表达形式，从用户的角度来描述用户渴望得到的功能。
• 用户故事三要素:角色、活动、价值
  • 角色:谁要使用这个功能
  • 活动:需要完成什么样的功能。
  • 商业价值:为什么需要这个功能，这个功能带来什么样的价值。
• 用户故事格式:
  英文:
  As a, l want to , so that
  中文:
  作为一个<角色>，我想要<活动>，以便于<商业价值>
  举例:
  作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益".

用户故事的3C原则

• 卡片(Card)-用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
• 交谈(Conversation)-用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
• 确认(Confirmation)-通过验收测试确认用户故事被正确完成。

用户故事验收标准AC

1. 验收标准：代表了用户故事3C中的Confirmation准则，同时INVEST属性的Testable的具体体现。
   在用户故事Card中，AC一般用Given-When-Then 公式来书写
   ① Given 用户触发操作之前处于的系统状态
   ② When触发系统结果的操作
   ③ Then系统预期返回的结果
2. 用户故事: 作为(（As)一个“网站管理员”，我(I)想要“统计每天有多少人访问了我的网站”，以便(So)于“我的赞助商了解我的网站会给他们带来什么收益。”
3. 验收标准AC:
   ① Given: 网站运行一天后
   ② When: 当我点击首页访问人数按钮时
   ③ Then: 我可以看到这一天一共有多少人访问了网站

需求拆分

需求拆分满足INVEST原则：

需求澄清与评审

需求评审:

1. 产品定稿会:—种仪式和承诺，项目各团体确认需求;
2. 产品负责人责任——产品设计初稿、召集评审、产品定稿归档;
3. 技术负责人（开发、测试)责任——参加review、提出意见确保逻辑完备性;

3. 需求优先级与排期

需求优先级

排优先级的方法：

• MoSCoW法则(Must/Should/Could/WouldNot)
• 矩阵分析法:
  - 重要且紧急>重要不紧急>紧急不重要>不重要也不紧急-满足核心用户需求的优先（二八原则)
• 满足核心业务的投入产出比最大的需求优先(ROI最大化)

需求排期

发布（版本）与迭代