| 固件规格书检查单 | |||||||||
| 项目名 | LPDT | 审计人 | 日期 | ||||||
| 审计项 | 0 | 通过项 | 0 | 不通过项 | 0 | 免检项 | 0 | ||
| 说明 | |||||||||
| 序号 | 检查项 | 执行情况 | 问题跟踪 | 关闭日期 | 说明 | ||||
| 固件设计规格 | |||||||||
| 1 | 是否对项目作整体说明? | ||||||||
| 2 | 是否描述了产品包需求中定义的功能性需求? | ||||||||
| 3 | 每个功能需求是否有时序图/用例图/操作场景？ | ||||||||
| 4 | 每个功能需求是否描述了正常情况的处理？ | ||||||||
| 5 | 每个功能需求是否描述了异常情况的处理？ | ||||||||
| 6 | 是否定义了功能需求的输入？ | ||||||||
| 7 | 是否标识了功能需求的输出？ | ||||||||
| 8 | 是否有冗余的信息？是否一个需求被定义了多次？ | ||||||||
| 9 | 需求的描述是否有明确的规格，是否有“大概、也许、较好、较易用、很清晰、很友好、很完善”等模糊、理解难一致的用语? | ||||||||
| 10 | 需求描述是否覆盖外部接口？ | ||||||||
| 11 | 是否描述了可服务性需求？ | ||||||||
| 12 | 是否描述了可重用需求？ | ||||||||
| 13 | 是否描述了可测试性需求？ | ||||||||
| 14 | 是否对所有功能与时间因素有关的方面都作了明确说明和规格上的量化？（如超时时长、响应时限等）它们的时间准则是否都说明了？时间准则的最大、最小执行时间是否都定义了？ | ||||||||
| 15 | 是否定义了系统输入、输出的精度？ | ||||||||
| 16 | 是否清楚地定义了所有的外部接口需求？ | ||||||||
| 17 | 是否清楚地定义了所有的内部接口需求？ | ||||||||
| 18 | 是否阐述了已有类似系统的现状、需求上的差异、新需求的侧重点和适用条件、老需求在新系统中的考虑和体现 | ||||||||
| 19 | 各个需求项之间是否一致？是否有冲突和矛盾？ | ||||||||
| 20 | 需求是否可以验证？ （即是否可以检验软件是否满足了需求）？ | ||||||||
| 21 | 是否需求足够清楚以至于移交给一个独立的组实现并且仍然可以理解? | ||||||||
| 22 | 是否有术语定义一览表？ | ||||||||
| 23 | 语言是否有歧义性？ | ||||||||
| 24 | 需求定义是否足够清楚和明确，使其能够作为开发设计的基础？ | ||||||||
| 25 | 需求定义是否足够清楚和明确，使其能够作为设计系统测试用例的基础？ | ||||||||