3） 可修改性：需求会因为各种原因而发生变化，这是无可奈何的现实，需求文档总是体现需求，因此需求文档必须是可以被修改的。

　　4） 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，

　　5） 作为文档，可阅读性、可维护性、无二义性也都很重要。

　　6） 可阅读性：一般说来，第一眼看去版面规整、长度适当的文档是读者愿意阅读的。再看内容条理清楚、层次分明、能容易抓住重点的文档是读者在初读之后还愿意继续往下读的关键。

　　7） 可维护性：相同的内容如果无数次的出现并散落在文档各处无疑会给文档的长期更新带来隐患，可维护性反映在维护文档的人能够很容易的知道应该更新文档的哪些地方并且如何根据实际需要去更新。

　　8） 无二义性：文字的魅力在于丰富多样，而文字的挑战同样在这里，如何让读的人接收到写的人想要交代的信息，不多不少刚刚好，是一个很大的难题。

　　5 “想着读者”撰写需求文档的建议

　　建议一：每个文档或每段文字都要有明确的目标读者

　　为了减少维护文档的工作量，有些需求工程师喜欢用一个文档记录所有需求相关的信息。这当然不是不可以，但上文提到，需求文档的读者其实很多，用户、客户、系统分析员、需求工程师、开发工程师、质量工程师、项目经理等[3]。事实上，每个角色看文档的目的是不一样的，因此他们各自对文档的要求也是不一样的。从“为读者着想”的指导思想出发，高质量的需求文档，需要让读者一眼能明白哪些是他关心的内容，他需要详细阅读，哪些是写给其他角色看的，他可以跳过不看，而不是等他读完了才发现这些信息和他无关。也是说，即使只有一个需求文档，在文档中间也应该很用明确的标识来标记目标读者是谁。

　　当然，如果有些目标读者关心的内容有很大的不同，那么完全没有必要硬把所有内容放在一个文档里。因为那样会造成文档的冗长，极其容易让读者没有耐心去看。

　　建议二：利用模板，但不要被模板束缚

　　无论是RUP，IEEE还是Vorath，都提供了软件开发文档的模板，其中包括需求相关的文档模板。模板是可以也应该根据项目和企业的实际情况进行裁减的，这是业界普遍认同的。但是随意翻阅一些软件项目的需求文档，尤其是通过了CMM/CMMI Level 3或更高级评定的软件项目，不难发现，文档中很多方面的内容流于形式。例如用例目的（Objective）大多都是“通过这个用例用户可以****”，****是用例名或其近义词，又如，在系统响应速度的要求中，大多数都是“3秒内”或“平均3秒，坏情况5秒”。这样的需求文档实际上是没有质量的。二出现这种情况的主要原因是需求工程师觉得没什么可写，但又必须填一些内容。

　　事实上，在撰写需求文档时，发现任何一个段落（Section）的内容经常不知道怎么填，而随手写一句话或几个词的时候，应该把问题拿出来分析。探讨一下这个段落是不是真的有用，那个角色会关心这个段落，是不是可以不要这个段落，如果还是有保留意义的话，那应该怎样写才能起到该段落的作用。如讨论对系统响应速度的要求，需求工程师们会发现，在商业系统中，数据量对系统的响应速度影响很大，因此，宽泛的说3秒完成一个动作是不合适的。相反，需求工程师应该详细给出诸如“70%的集装箱装载的货物在100种以内，要求3秒内用户可以在系统界面上看到集装箱内的全部货物信息，100-200种货物的集装箱信息要求在5秒以内显示，若货物条目超过200条的情况系统可以不考虑。”

　　建议三：多些业务信息、假设（Assumption）

　　描述事物的方法无外乎两种方法，一种是描述对的情况，把对的信息一条条叠加，能看到对的事物的全貌。第二种是描述排外情况，把世界比作一个大空间，那些排除出去的以外是人们需要的事物了。大部分情况下，需求文档都用第一种方法来描述需求，即需求是什么。然而，世界太大，每一件事物可以从许许多多不同的角度来描述。而需求文档是有限的，人的思维也有一些定式。因而需求文档一定做不到完美??无一遗漏、一网打尽。这时候，建议用两种方法结合的方式，来对需求进行描述，会更好。

　　假设信息实际上有很重要的作用。根据投资回报率理论，系统目标解决80%的业务，而不是，因此遇到一些特殊情况，很有可能在需求讨论的时候已经有决策，即不需要系统处理这些情况。其实这些排外情况也是需求的一部分。应该要在需求文档中得到体现。笔者接触的很多项目都忽视了这点，因而造成日后在系统运行过程中用户和开发团队产生分歧，用户觉得是系统缺陷，而开发团队觉得需求是如此，但苦于没有文档作证。