敏捷需求分析过程

用户原始需求得到总体方案构想(即系统原理)以及关键技术方案(阐述关键需求实现技术)。
最后基于系统总体方案及关键技术实现方案分解系统需求即SR,最后到AR,Story,task。
注意在单个子系统的当前所有AR明确之后,需要对子系统作详细设计。即软件模块化或组件化设计

也可以直接从SR到Story,task。
这种情况就基于story做软件设计。story的粒度通常较小。要求开发人员能够在10天内完成开发。

我们讨论大型系统的需求分析方法。
通常大型系统采用用例加上用户故事的需求分析方法

用例是对系统之间或以及一或多个用户之间交互的一般表述。执行者要么是用户,要么是系统。用例多一个主要成功场景与多个扩展场景组成。每个场景代表了从执行者发起请求开始到响应的一条完整路径。

用户故事可以基于用户主要成功场景划分。通过故事验收测试去覆盖扩展场景

在用例复杂度高时,也可每个用例划分多个故事。

在基于story流程去做任务拆分。
这种流程主要是
用例到用户故事到任务
这种适合于微服务或简单一点的系统。即系统到模块或组件的两层体系。互联网个人应用大多可以可以采用这种

还有一种是
用例(SR即系统需求)到 AR (子系统需求)再到Story(基于AR的) 最后到task。
这种方式适合大型系统子系统架构。流程较长的系统。这样每个子系统基于AR去做Story分析可以让每个子系统更加聚焦完成自己系统的需求分解。以及各个子系统分工协作。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值