论软件项目需求文档的撰写
作者:网络转载 发布时间:[ 2011/2/11 14:03:13 ] 推荐标签:
前文的例子中,“70%的集装箱装载的货物在100种以内”是对“对的”需求的描述,而“若货物条目超过200条的情况系统可以不考虑”是一种排外情况。两者结合起来,才能让开发工程师和质量工程师知道应该怎么进行。
多描述业务还有几个好处[4],其一,业务其实很少改变或者说改变得很慢,但系统是很容易需要改变的,多描述业务实际上可以降低文档的维护工作量。其二,尤其对于商业应用系统,如果能够尽可能的让开发工程师和质量工程师明白业务是怎么回事,那么开发工程师可以从需求中看到业务,在进行设计、编码的时候,为业务长远的发展预留空间,而质量工程师可以更多地设计符合80%业务的测试用例,而不仅仅按照测试理论来设计测试用例,那么这样的测试能够更有针对性和效率。
建议四:规范用词,提供适当的阅读指南
大部分关于用例模板、需求规约模板中都有“词汇表”这个部分,的确这是一个规范用词的做法,词汇表实际上也是对一些专有名词进行注解,以方便读者理解。然而,用词的规范,应该不仅仅只是专用名词、术语,更可以推广到动词和句式。
需求文档作为技术文档的一种,和普通文艺作品截然不同。文艺作品讲究重复强调主题,但又需要用很多不同的近义词来凸显主题。而作为技术文档,同义词只会引起一些敏感的开发、测试人员的疑惑。例如“编辑Edit”、“更改Modify”、“修改Amend”、“维护Maintain”究竟在文档中表明一个意思还是各有不同,的确是一个值得揣摩的问题。需求撰写人的随意用词会给认真的读者带来很多遐想空间,这在文艺作品来说可能是一种效果,然而技术文档不需要。如果需求文档撰写人对这些近义词的用法能够有一个说明,并且在所有文档中保证用法一致,那么无疑会受到读者的好评。因为这样一致的做法可以确保无二义性的产生。
需求文档在句式上也可以用一些方法来规整[5]。比如,表示用户想要开始进行某项操作时,不写成“用户进入**菜单”,而写成“用户想要进行**操作/工作”。那么,当一份文档里第三次出现这个句式时读者能直奔主题,直接阅读中间是什么核心内容,而不再需要阅读前后的辅词。
其实,这样做同样能给需求文档撰写人带来好处也是很明显的。在撰写需求文档的时候,一个词可以表达一种确切的含义,甚至可以超出词语的本意,而不需要每次洋洋洒洒重复介绍;同样的句式可以把重点放在主题上,让工作更有效率,在以后的维护中,也可以用工具帮助查找同样的词或句式,保证没有遗漏。
建议五:善用各种工具进行版本管理
由于需求文档的可修改特性,文档的版本管理也是相当重要的。专门用于文档管理的工具有VSS,Sharepoint等,但是没有这些专业工具并不表示不能进行文档的版本管理了。Microsoft Word加上合理创建文件夹结构可以很好地解决文档版本管理的难题。
对于文档版本的管理,有两个主要目标,一是总能找到近的一个版本,也是后更新的,这个文档能够给任何团队外的咨询者或者团队中的新成员以足够的信息,所谓后更新,即能够在没有任何修改或情况说明的情况下,提供文档让需要者去阅读,而不会因为某些需要者提出要求才去修改更新文档。二是能够快速定位某年某月的某个版本究竟有哪些改动,改动之前是怎样的,改动之后又是怎样的。如果哪个版本恰巧和软件产品的一个发布版本吻合,那么开发工程师和质量工程师们实际上只要关注那些改动的部分足够了。换言之,达到以上两个目标很好地解决了现象三种的两难境地。
善加使用Microsoft Word中的Track功能是一个很好的建议。当决定文档需要保留一个版本的时候,应该把当前的文档另存,并修改文件名,增加版本信息,例如“需求规约v2.3.doc”。 而主文件名保持没有版本信息的状况“需求规约.doc”。当开始新一个版本周期v2.4工作的时候,第一件要做的事情是全部接受(Accept All changes in document)上一个版本所做的所有改动,然后再根据实际情况进行文档修改。如此一来,所有v2.4的更新都会被Word记住,以方便读者在需要的时候,通过(showing markup)或修改区域(Reviewing Pane)进行快速寻找定位。此外,不建议每个版本周期创建一个文件夹,存放该版本所有文档的做法。因为有些文档可能由于该版本没有被改写而不会出现在该文件夹中,造成被人忽视,或找不到的情况。建议文档可以在一个文件夹里全部找到后更新版本,同样在这个文件夹下,可以找到被归档的以往的版本文件。
6 结束语
近年来,敏捷过程、敏捷文档是被广泛提及和研究的论题。然而,敏捷的提出并非打着“敏捷”的幌子逃避文档的编写、管理的问题[6]。笔者以为,敏捷,实际上指的是敏捷的撰写文档,还要加上敏捷地阅读文档。
关于如何提高需求文档的质量,其实还有很多小建议,例如从文档排版角度如何提升文档的可读性,从文档结构角度应该要提供一个文档指引,从文档管理角度如何使用文档之间的相互链接(文件夹有进行整理、移位的可能)等等。
真正做到心中有读者,在编撰文档的时候,应该总是考虑读者想看什么,怎样可以快速看文档,怎样可提高文档的有效利用率却又不过分地夸大一个文档的作用,诸如此类。能够用这种服务的心态去编写需求文档,一定能编撰出高质量的需求文档,为整个软件项目成功做好第一步。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11