|
为了减少维护文档的工作量，有些需求工程师喜欢用一个文档记录所有需求相关的信息。这当然不是不可以，但上文提到，需求文档的读者其实很多，用户、客户、系统分析员、需求工程师、开发工程师、质量工程师、项目经理等[3]。事实上，每个角色看文档的目的是不一样的，因此他们各自对文档的要求也是不一样的。从“为读者着想”的指导思想出发，高质量的需求文档，需要让读者一眼就能明白哪些是他关心的内容，他需要详细阅读，哪些是写给其他角色看的，他可以跳过不看，而不是等他读完了才发现这些信息和他无关。也就是说，即使只有一个需求文档，在文档中间也应该很用明确的标识来标记目标读者是谁。
当然，如果有些目标读者关心的内容有很大的不同，那么完全没有必要硬把所有内容放在一个文档里。因为那样会造成文档的冗长，极其容易让读者没有耐心去看。项目管理者联盟
建议二：利用模板，但不要被模板束缚项目管理者联盟
无论是RUP，IEEE还是Vorath，都提供了软件开发文档的模板，其中就包括需求相关的文档模板。模板是可以也应该根据项目和企业的实际情况进行裁减的，这是业界普遍认同的。但是随意翻阅一些软件项目的需求文档，尤其是通过了CMM/CMMI Level 3或更高级评定的软件项目，不难发现，文档中很多方面的内容流于形式。例如用例目的(Objective)大多都是“通过这个用例用户可以****”，****就是用例名或其近义词，又如，在系统响应速度的要求中，大多数都是“3秒内”或“平均3秒，最坏情况5秒”。这样的需求文档实际上是没有质量的。二出现这种情况的主要原因就是需求工程师觉得没什么可写，但又必须填一些内容。项目经理博客
事实上，在撰写需求文档时，发现任何一个段落(Section)的内容经常不知道怎么填，而随手写一句话或几个词的时候，就应该把问题拿出来分析。探讨一下这个段落是不是真的有用，那个角色会关心这个段落，是不是可以不要这个段落，如果还是有保留意义的话，那应该怎样写才能起到该段落的作用。如讨论对系统响应速度的要求，需求工程师们就会发现，在商业系统中，数据量对系统的响应速度影响很大，因此，宽泛的说3秒完成一个动作是不合适的。相反，需求工程师应该详细给出诸如“70%的集装箱装载的货物在100种以内，要求3秒内用户可以在系统界面上看到集装箱内的全部货物信息，100-200种货物的集装箱信息要求在5秒以内显示，若货物条目超过200条的情况系统可以不考虑。”项目管理者联盟
建议三：多些业务信息、假设(Assumption)项目管理者联盟
描述事物的方法无外乎两种方法，一种是描述对的情况，把对的信息一条条叠加，就能看到对的事物的全貌。第二种是描述排外情况，把世界比作一个大空间，那些排除出去的以外就是人们需要的事物了。大部分情况下，需求文档都用第一种方法来描述需求，即需求是什么。然而，世界太大，每一件事物可以从许许多多不同的角度来描述。而需求文档是有限的，人的思维也有一些定式。因而需求文档一定做不到完美——无一遗漏、一网打尽。这时候，建议用两种方法结合的方式，来对需求进行描述，就会更好。项目管理者联盟
假设信息实际上有很重要的作用。根据投资回报率理论，系统目标解决80%的业务，而不是100%，因此遇到一些特殊情况，很有可能在需求讨论的时候已经有决策，即不需要系统处理这些情况。其实这些排外情况也是需求的一部分。应该要在需求文档中得到体现。笔者接触的很多项目都忽视了这点，因而造成日后在系统运行过程中用户和开发团队产生分歧，用户觉得是系统缺陷，而开发团队觉得需求就是如此，但苦于没有文档作证。项目经理圈子
前文的例子中，“70%的集装箱装载的货物在100种以内”就是对“对的”需求的描述，而“若货物条目超过200条的情况系统可以不考虑”就是一种排外情况。两者结合起来，才能让开发工程师和质量工程师知道应该怎么进行。项目管理者联盟
多描述业务还有几个好处[4]，其一，业务其实很少改变或者说改变得很慢，但系统是很容易就需要改变的，多描述业务实际上可以降低文档的维护工作量。其二，尤其对于商业应用系统，如果能够尽可能的让开发工程师和质量工程师明白业务是怎么回事，那么开发工程师可以从需求中看到业务，在进行设计、编码的时候，为业务长远的发展预留空间，而质量工程师可以更多地设计符合80%业务的测试用例，而不仅仅按照测试理论来设计测试用例，那么这样的测试能够更有针对性和效率。项目管理者联盟
建议四：规范用词，提供适当的阅读指南项目管理者联盟
大部分关于用例模板、需求规约模板中都有“词汇表”这个部分，的确这是一个规范用词的做法，词汇表实际上也是对一些专有名词进行注解，以方便读者理解。然而，用词的规范，应该不仅仅只是专用名词、术语，更可以推广到动词和句式。pmp.mypm.net
需求文档作为技术文档的一种，和普通文艺作品截然不同。文艺作品讲究重复强调主题，但又需要用很多不同的近义词来凸显主题。而作为技术文档，同义词只会引起一些敏感的开发、测试人员的疑惑。例如“编辑Edit”、“更改Modify”、“修改Amend”、“维护Maintain”究竟在文档中表明一个意思还是各有不同，的确是一个值得揣摩的问题。需求撰写人的随意用词会给认真的读者带来很多遐想空间，这在文艺作品来说可能是一种效果，然而技术文档不需要。如果需求文档撰写人对这些近义词的用法能够有一个说明，并且在所有文档中保证用法一致，那么无疑会受到读者的好评。因为这样一致的做法可以确保无二义性的产生。项目管理者联盟
需求文档在句式上也可以用一些方法来规整[5]。比如，表示用户想要开始进行某项操作时，不写成“用户进入**菜单”，而写成“用户想要进行**操作/工作”。那么，当一份文档里第三次出现这个句式时读者就能直奔主题，直接阅读中间是什么核心内容，而不再需要阅读前后的辅词。转自项目管理者联盟
其实，这样做同样能给需求文档撰写人带来好处也是很明显的。在撰写需求文档的时候，一个词可以表达一种确切的含义，甚至可以超出词语的本意，而不需要每次洋洋洒洒重复介绍;同样的句式可以把重点放在主题上，让工作更有效率，在以后的维护中，也可以用工具帮助查找同样的词或句式，保证没有遗漏。项目管理者联盟
建议五：善用各种工具进行版本管理项目管理者联盟
由于需求文档的可修改特性，文档的版本管理也是相当重要的。专门用于文档管理的工具有VSS，Sharepoint等，但是没有这些专业工具并不表示就不能进行文档的版本管理了。Microsoft Word加上合理创建文件夹结构就可以很好地解决文档版本管理的难题。club.mypm.net
对于文档版本的管理，有两个主要目标，一是总能找到最近的一个版本，也就是最后更新的，这个文档能够给任何团队外的咨询者或者团队中的新成员以足够的信息，所谓最后更新，即能够在没有任何修改或情况说明的情况下，提供文档让需要者去阅读，而不会因为某些需要者提出要求才去修改更新文档。二是能够快速定位某年某月的某个版本究竟有哪些改动，改动之前是怎样的，改动之后又是怎样的。如果哪个版本恰巧和软件产品的一个发布版本吻合，那么开发工程师和质量工程师们实际上只要关注那些改动的部分就足够了。换言之，达到以上两个目标就很好地解决了现象三种的两难境地。项目管理者联盟
善加使用Microsoft Word中的Track功能是一个很好的建议。当决定文档需要保留一个版本的时候，就应该把当前的文档另存，并修改文件名，增加版本信息，例如“需求规约v2.3.doc”。 而主文件名保持没有版本信息的状况“需求规约.doc”。当开始新一个版本周期v2.4工作的时候，第一件要做的事情就是全部接受(Accept All changes in document)上一个版本所做的所有改动，然后再根据实际情况进行文档修改。如此一来，所有v2.4的更新都会被Word记住，以方便读者在需要的时候，通过(showing markup)或修改区域(Reviewing Pane)进行快速寻找定位。此外，不建议每个版本周期创建一个文件夹，存放该版本所有文档的做法。因为有些文档可能由于该版本没有被改写而不会出现在该文件夹中，造成被人忽视，或找不到的情况。建议文档可以在一个文件夹里全部找到最后更新版本，同样在这个文件夹下，可以找到被归档的以往的版本文件。项目管理者联盟
6 结束语项目管理者联盟
近年来，敏捷过程、敏捷文档是被广泛提及和研究的论题。然而，敏捷的提出并非打着“敏捷”的幌子逃避文档的编写、管理的问题[6]。笔者以为，敏捷，实际上指的是敏捷的撰写文档，还要加上敏捷地阅读文档。项目经理博客
关于如何提高需求文档的质量，其实还有很多小建议，例如从文档排版角度如何提升文档的可读性，从文档结构角度应该要提供一个文档指引，从文档管理角度如何使用文档之间的相互链接(文件夹有进行整理、移位的可能)等等。项目管理者联盟
真正做到心中有读者，在编撰文档的时候，应该总是考虑读者想看什么，怎样可以快速看文档，怎样可提高文档的有效利用率却又不过分地夸大一个文档的作用，诸如此类。能够用这种服务的心态去编写需求文档，一定能编撰出高质量的需求文档，为整个软件项目成功做好第一步。项目管理者联盟 项目管理者联盟
|
