第三章结构化需求分析.ppt

第三章 结构化需求分析 3.3 需求验证 3.3 需求验证 需求分析阶段的工作结果是开发软件系统的重要基础。 软件系统中15%的错误起源于错误的需求。 为了确保软件开发成功，提高质量和降低费用，一旦对目标系统提出一组需求之后，就必须严格验证这些需求的正确性。 主要工作：验证软件需求规格说明书（Software Requirements Specificationg，简称为SRS） 1．正确性 正确性指的是SRS中陈述的每个需求都表达了将要构造的系统的某种要求。 目前尚不存在有效的技术来保证这个质量，因为它完全依赖于当前的应用系统。 例如，如果软件必须在5秒钟内对所有的按键事件作出相应，而SRS中陈述“软件应在10秒钟内对所有的按键事件作出响应”，则该需求描述是不正确的。 左边的圆圈表示用户的实际需求，右边的表示SRS中陈述的需求。 如果SRS是正确的，则区域C为空 即SRS中的每个需求都表达了未来系统的某种要求。 2．无二义性 无二义性指的是：SRS中陈述的每个需求对所有的读者都只能有一个明确统一的解释。 由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。 避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。 3．完整性 如果一个SRS能满足下列要求，则该SRS就是完整的： （1）期待未来系统所做的任何事情都包括在SRS的陈述中。 如果一个SRS既是完整的又是正确的，那么区域A和C同时为空，两个原是重合的。 完整性是所有属性中最难以保证的，原因是不完整意味着有些东西不在SRS中，这样检查材料很难发现其中不存在的东西 诊断不完整性的一个有效技术就是开发原型。 （2）SRS中应包括未来软件系统在所有可能情况下对所有可能的输入的相应，所有的输入包括有效和无效输入。 SRS必须建立从输入域（I）和状态域（S）的笛卡尔乘积到输出域（O）和状态域（S）笛卡尔乘积的完整映射。 SRS：I×S?O×S (3)SRS中没有任何内容被标为“待定” 任何一个使用“待定”的SRS都是不完全的。 a. 若万一遇到使用“待定”一词时，作如下处理： （1） 对产生“待定”一词的条件进行描述，使得问题能被解决； （2） 描述必须干什么事，以删除这个“待定”； b. 包含有“待定”一词的任何SRS的项目文件应该： （1） 标识与此特定文件有关的版本号或叙述其专门的发布号； （2） 拒绝任何仍标识为“待定”一词的SRS章节的许诺。 例如：明天做，包含负责人员的名字和日期。 4．可验证性 指的是SRS中陈述的每个需求都是可验证的。 任何二义性必然导致不可验证性 例如： “产品应有易于使用的用户界面” 使用不可度量的量 例如：“通常”或“时常”， “当按下按钮时，系统通常应亮起红灯” 任何等同于停机问题的需求是不能被验证的 例如：“程序将不会进入一个无限循环” 5．一致性 当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的。 6．可理解性 为了使一个SRS减少二义性、增强可验证性、完整性和一致性，我们应努力追求高度形式化的表示法。 7．可修改性 如果一个SRS的结构和风格在需求有必要改变时是易于实现的、完整性的、一致的，那么这个SRS就是可以修改的。可修改性要求SRS具备以下条件： a. 具有一个有条不紊的易于使用的内容组织，具有目录表，索引和明确的交叉引用表； b. 没有冗余。即同一需求不能在SRS中出现多次。 （1）冗余本身不是错误，但是容易发生错误。冗余可增加SRS的可读性，但是在一个冗余文件被更新时容易出现问题。例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改一个地方，于是SRS就变得不一致了。 （2）不管冗余是否必须，SRS一定要包含一个详细的交叉引用表，以便SRS具备可修改性。 8．可被跟踪性 指的是SRS中的每个需求的出处都是清楚的，这意味着SRS中包含对前期支持文档的的引用表。 例如：系统应对任何一次X请求在20秒内响应。测试的响应时间为60秒。 两种解决方案 对软件进行重新设计或编码，以使其效率更高。 把需求从20秒改为60秒。 9．可跟踪性 如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该SRS就是可追踪的。建议采用如下两种类型的追踪： a. 向后追踪（即向已开发过的前一阶段追踪）。根据先前文件或本文件前面的每一个需求进行追踪。 b. 向前追踪（即是向由SRS派生的所有文件追踪）。根据SRS中具有唯一的名字和参照号的每一个需求进行追踪。 当SRS中的一个需求表达另一个需求的一种指派或者是派生的，向前、向后的追踪都要提供。例如： （1）从总的用户响应时间需求中分配给数