njthnet

[导入]需求文档中的要素

软件开发中的需求文档不仅仅需要文字描述,还需要用图形来形象的描述,因为你的需求文档阅者的比重客户占55%以上,最主要的读者对象是客户. 如果是一大堆文字看的人眼花缭乱还需要去理解,显然不够直观。反之简明扼要的图形更容易让人理解,降低读者对文章理解的二义性,提高大家的可沟通性。 我们最常使用的手段用3种图来表达:     1.用例图 (User Case)  可以让大家知道系统中每个功能的 前置(前提)条件,边界,主要的异常状态,有几个角色在里面。                  2.数据流程图 (DFD)  系统中每个功能模块中 输入/输出的数据是什么跑的,如果能跑通,说明逻辑上不会有太大的问题。   查看大图请点击这里     3.模块展示图(Molde WBS)  从整个系统,到各个功能模块是怎么划分的,这项设计可以牵涉到可用性和可伸缩性。 查看大图请点击这里 我们做一个比方,如果是一篇英文的文档需要你去阅读,很多文字,英文能力一般的人会比较吃力,但是删掉这个文章里面的很多文字,换成几幅图,就算你的英文水平很烂,我想一般人也能明白这个文章是在说什么了吧,这样说是不是能明白图的作用了? 另外,在编写需求文档的时候,并不是1-2个Leader在忙,而且整个团队在忙,测试也需要早早的加入,还有那个叫DBA 和 SysAdmin家伙,自从我们推广了敏捷后,每次需求编写、讨论的时候他们也没有脱离我们半步。至少我经历过非常顺利交付的项目他们都是和开发团队一起讨论、编写。 切记,只要你的客户还存在你的联系人名单上,需求文档对每个成员来说,就不会是一项被完成的工作。 相关文章: 敏捷的态度 –end–
文章来源:http://www.javabloger.com/article/requirements-document-key.html?source=rss

posted on 2010-03-10 23:03 njthnet 阅读(139) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 

导航

<2025年7月>
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

统计

留言簿

文章档案

新闻档案

搜索

最新评论