0°

优化SRS编写,让SRS更高效沟通

这两天看了一本书《敏捷可执行需求说明》。


如果你的团队正在使用敏捷,而你作为团队内部的PO或者BA,推荐你完整的看一下这本书,除了第七章可以略读。

如果你的团队没有使用敏捷,而你作为团队的BA,建议你仔细的阅读一下第六章。

如果你是技术转BA,第七章也可以做一些了解。



因为我说不上对敏捷有多么的精通,对于敏捷的流程以及PO/BA在敏捷中的工作内容还是比较清楚的。

所以我比较有体会的是第六章的内容。之前的内容都主要介绍的是一些我已经清楚的内容,如果有兴趣的我们可以另外开一篇文来讨论。



前两天,我们团队进行详细设计评审。

虽然我一直强调SRS中最好用图表来做说明,但是不可避免的我也会进行大段的文字描述。

详细设计评审中,我发现开发在设计的时候使用了一种表格将我的大段描述,特别是业务逻辑的描述清晰的表达出来了。

后来和开发确认,他们也会觉得这种方式更方便他们的理解。

测试人员也表示,这种方式更适合他们来写Case。



其实这种方法在很多书中都有介绍,包括《实例化需求》等,只是展现形式各有不同。

今天在这本书中找到了官方的名字FIT表格,FIT是一种集成测试框架。

所以我们在编写需求规格时,如果一段业务逻辑描述过长,我觉得超过3行,就可以考虑用FIT表格来表达。

书中还介绍了另外一种方法:BDD行为驱动开发的“已知-当……时-那么 ”


下面是我写的一个简单的例子:

特征:项目管理

          场景1:

          已知     用户是项目管理员

          当  用户创建一个项目时

          那么 

编号 名称 结果
01 不使用模板 空项目
02 使用模板-包含计划 新项目中包括计划
…… …… ……

用户故事:作为项目管理员,我想要创建一个项目,这样我就可以开始进行项目管理了

  场景2:

          已知     用户是项目管理员

当       用户启动一个项目时

           那么       项目被团队成员可见

           和     项目状态为“启动”

用户故事:作为项目管理员,我想要启动一个项目,这样项目就可以开始进行了。




后面我会尝试在SRS中使用这种方法进行描述。这也算是结构化思维的一种实践。




(完)


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论