文章目录
版本管理和版本规划
1. 需求收集与分析
什么是需求
-
需求的定义:
IEEE软件工程标准词汇表(97年)中定义需求为:
用户解i决问题或达到目标所需的条件或权能(Capability)。
系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能.
一种反映上面(1)或(2)所描述的条件或权能的文档说明。 -
软件需求包括以下几个层次:
业务需求
用户需求
功能需求
非功能需求、软件需求规格说明等
需求的管理流程
1. 需求收集:
- 原始需求----通过收集----用户需求
- 需求收集方法: 访谈、调查问卷、 需求讨论会 、竞品分析、 文档与数据(大数据挖掘)、 原型
2.需求分析:
①针对待开发软件提供完整、清晰、具体的需求,确定软件必须实现那些任务。
②分析软件:《影响地图》
2. 基于用户故事的需求拆分与澄清
需求层级
用户故事
- 用户故事是描述需求的一种表达形式,从用户的角度来描述用户渴望得到的功能。
- 用户故事三要素:角色、活动、价值
- 角色:谁要使用这个功能
- 活动:需要完成什么样的功能。
- 商业价值:为什么需要这个功能,这个功能带来什么样的价值。
- 用户故事格式:
英文:
As a, l want to , so that
中文:
作为一个<角色>,我想要<活动>,以便于<商业价值>
举例:
作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益".
用户故事的3C原则
- 卡片(Card)-用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。
- 交谈(Conversation)-用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
- 确认(Confirmation)-通过验收测试确认用户故事被正确完成。
用户故事验收标准AC
- 验收标准:代表了用户故事3C中的Confirmation准则,同时INVEST属性的Testable的具体体现。
在用户故事Card中,AC一般用Given-When-Then 公式来书写
① Given 用户触发操作之前处于的系统状态
② When触发系统结果的操作
③ Then系统预期返回的结果 - 用户故事: 作为((As)一个“网站管理员”,我(I)想要“统计每天有多少人访问了我的网站”,以便(So)于“我的赞助商了解我的网站会给他们带来什么收益。”
- 验收标准AC:
① Given: 网站运行一天后
② When: 当我点击首页访问人数按钮时
③ Then: 我可以看到这一天一共有多少人访问了网站
需求拆分
需求拆分满足INVEST原则:
需求澄清与评审
需求评审:
- 产品定稿会:—种仪式和承诺,项目各团体确认需求;
- 产品负责人责任——产品设计初稿、召集评审、产品定稿归档;
- 技术负责人(开发、测试)责任——参加review、提出意见确保逻辑完备性;
3. 需求优先级与排期
需求优先级
排优先级的方法:
- MoSCoW法则(Must/Should/Could/WouldNot)
- 矩阵分析法:
- 重要且紧急>重要不紧急>紧急不重要>不重要也不紧急-满足核心用户需求的优先(二八原则) - 满足核心业务的投入产出比最大的需求优先(ROI最大化)
需求排期
发布(版本)与迭代