3.3需求验证1．正确性2．无二义性3．完整性（2）SRS中应包括未来软件系统在所有可能情况下对所有可能的输入的相应，所有的输入包括有效和无效输入。SRS必须建立从输入域（I）和状态域（S）的笛卡尔乘积到输出域（O）和状态域（S）笛卡尔乘积的完整映射。SRS：I×SO×S(3)SRS中没有任何内容被标为“待定”任何一个使用“待定”的SRS都是不完全的。a.若万一遇到使用“待定”一词时，作如下处理：（1）对产生“待定”一词的条件进行描述，使得问题能被解决；（2）描述必须干什么事，以删除这个“待定”；b.包含有“待定”一词的任何SRS的项目文件应该：（1）标识与此特定文件有关的版本号或叙述其专门的发布号；（2）拒绝任何仍标识为“待定”一词的SRS章节的许诺。例如：明天做，包含负责人员的名字和日期。4．可验证性5．一致性6．可理解性7．可修改性8．可被跟踪性9．可跟踪性跟踪方法：给每个段落按层次编号，在任何段落中都不包括多于一个需求。在SRS中出现的每个需求都编以唯一的序号。使用一种指示的惯例表示法，即总在包括一个需求的句子中使用“shall”系统级需求，其他重要文档10．设计无关性11．注释总结3.4需求分析文档例1这里提出一个方法使我们能重写需求文档来表述这些缺点（从我们与客户一致的目标出发作出一些猜测）即：后台任务管理器（BTM）应该在用户界面的指定区域显示状态消息。a.在后台任务进程启动之后，消息必须每隔60（±10）秒更新一次，并且保持连续的可见性。b.如果正在正常处理后台任务进程，那么后台任务管理器（BTM）必须显示后台任务进程已完成的百分比。c.当完成后台任务时，后台任务管理器（BTM）必须显示一个“已完成”的消息。d.如果后台任务中止执行，那么后台任务管理器（BTM）必须显示一个出错消息。我把原先的需求分割成多个需求，因为每个需求都需要独立的测试用例并且使各个需求都具有可跟踪性。如果把多个需求都集中在一个段落中，那么在构造软件和测试时就很容易忽略其中某个需求。注意，修改之后的需求并没有精确地说明是怎样显示状态信息的。这是一个设计问题，如果你在这个地方详述该问题，那么就会给开发人员带来设计上的一些限制。过早地限制设计上的可选方案将会给编程人员带来不利因素，并可导致产品设计的失败。例2用如下的语句描述这个需求可能会更好一些：“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换”。现在，指代关系就清楚了，非打印字符指的是HTML标记。修改过的需求指明了是用户触发了显示状态的转换，但是它并没有对设计造成限制，因为它并没有精确定义所使用的机制。当设计人员选择好一种触发机制（例如热键、菜单命令或语音输入）时，你就可以编写详细的测试用例来验证这种转换操作是否正确。例3让我们使用另一种方式表述这个需求：a.在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。b.如果在分析过程中未发现任何错误，就不必生成出错报告。现在我们知道了任何生成出错报告及其所包含的内容，但是我们已经把该需求提交给设计人员，让他们来决定报告的形式。我们还指明了一种例外情况：如果没有任何错误，就不生成出错报告。例4例5