标签：数据   问题   时间   as   设计   用户   信息   测试   软件   

针对功能需求

• 是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？
• 是否详细定义了系统的全部输出，包括目的地、精度、取值范围、出现频率、格式等？
• 是否详细定义了所有输出格式（web页面、报表等）？
• 是否详细定义了全部外部通信接口，包括握手协议、纠错协议、通信协议等？
• 是否列出了用户想要做的全部事情？
• 是否详细定义了每个用户所用的数据，以及每个人物得到的数据？

针对非功能需求（质量需求）

• 否是为全部必要的操作，从用户的视角，详细描述了期望相应时间？
• 是否详细描述了其他与计时有关的考虑，例如：处理时间、数据传输率、系统吞吐量？
• 是否定义了安全级别？
• 是否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等？
• 是否详细定义了机器内存和剩余磁盘空间的最小值？
• 是否详细定义了相互竞争的特性之间的权衡——例如，健壮性与正确性之间的权衡？
• 是否避免在需求中规定设计（方案）？
• 需求是否在详细程度上保持相当一致的水平？有些需求应该更详细地描述吗？开发者也这么想吗？
• 每个条款都与待解决的问题及解决方案相关吗？能从每个条款上溯到它在问题域中对应的根源吗？
• 是否每条需求都是可测试的？是否可能进行独立的测试，以检验漫步满足各项需求？
• 是否详细描述了所用可能的对需求的改动，包括各项改动的可能性？

需求的完备性

• 对于是否详细定义了系统的可维护性，包括适应特定功能的变更、操作系统的变更、与其他软件的接口的变更能力？
• 是否包含对“成功”的定义？“失败”的定义呢？
• 需求是用用户的语言写的嘛？用户也这么认为吗？
• 每条需求都不与其他需求冲突吗？
• 对于在开始开发之前无法获得的信息，是否详细描述了信息不完全的区域？
• 需求的玩被堵是否能达到这种程度：如果铲平满足所有需求，那么他就是可接受的？
• 你对全部需求都感到很舒服吗？你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西？

需求核对表

标签：数据   问题   时间   as   设计   用户   信息   测试   软件   

原文地址：http://www.cnblogs.com/wlmLinker/p/4095759.html