搜索
SRS检查单WW－CMM－RM－F02NO：项目产品经理文档版本号检查内容检查结果1.兼容性界面需求是否使软硬件系统具有兼容性？2.完备性需求定义是否有关文件（质量规划报告等）中所规定的需求定义应包含的所有内容？需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有要求？功能需求是否覆盖了所有非法处理？是否对各种操作模式（如正常、非正常、有干扰等等）下的环境条件做了规定。是否对所有功能和时间有关的方面都作了考虑？是否识别出了所有与时间因素有关的功能？它们的时间准则是否都说明了？时间准则的最大、最小执行时间是否都定义了？是否识别并定义了在将来可能会变化的需求？是否定义了系统所有的输入？是否标识清楚了系统输入的来源？是否说明了系统输入、输出的类型？是否说明了如何进行系统输入、输出的值域、单位、格式等等？是否说明了如何进行系统输入的正确性检查？是否定义了系统输入、输出的精度？是否定义系统性能的各个方面？在不同负载情况下，系统的执行效率如何？在不同的情况下，系统的响应时间如何？系统对软件、硬件或电源故障必须做什么样的反应？是否充分定义了人机界面的需求？3.一致性各个需求之间是否一致？是否有冲突和矛盾？所规定的模型、算法和数值方法是否相容？是否使用了标准的术语和定义形式？需求是否与软件对应的系统和环境相容？是否说明了软件对其系统和环境的影响？是否说明了环境对软件的影响？4.正确性需求定义是否满足标准的要求？算法和规则是否有科技文献或其他文献作为基础？有哪些证据说明用户提供的规则或规定是正确的？是否定义了对错误、危险分析中所识别出的各种故障模式和错误类型所需的反应？是否参照了有关的标准？是否对每一个需求都给出了理由？理由是否充分？对设计和实现的限制是否都有论证？5.可行性需求定义是否使软件的设计、实现、操作和维护都可行？所规定的模型、数值方法和算法是否对待解决问题适合？是否能够在相应的限制条件下实现？是否能够达到关于质量的要求？6.易修改性对需求定义的描述是否易于修改（例如，是否采用了良好的结构和交叉引用表等等）？是否有冗余的信息？是否一个需求被定义多次？7.健壮性是否有容错的需求？是否有可移植性的需求？8.易追溯性是否可从上一阶段的文档查找到需求定义中的相应内容？需求定义是否明确地表明前阶段中提出的有关需求和设计限制已经被覆盖了（例如，使用覆盖矩阵或交叉引用表）？需求定义是否便于向后续开发阶段查找信息？9.易理解性是否每一种需求都只有一种理解？功能性需求是不是以模块方式描述的，是否明确地标识出了其功能？是否有术语定义一览表？是否使用了形式化或半形式化语言？是否有歧义性？需求定义中是否足够清楚和明确，使其能作为开发设计规约和功能性测试数据的基础？需求定义的描述是否将对程序的需求和所提供的其他信息分离开了？易测试性和或验证性需求是否可以验证（即是否可以检验软件是否满足了需求）？是否对每一个需求都指定了验证过程？数学函数的定义是否使用了精确定义的语法和语义符号？检查人日期