8 是否定义了系统所有的输入？ 9 是否标识清楚了系统输入的来源？ 10 是否标识出了系统的输出？ 11 是否说明了系统输入、输出的类型？ 12 是否说明了系统输入、输出的值域、单位、格式等？ 13 是否说明了如何进行系统输入的合法性检查？ 14 是否定义了系统输入、输出的精度？ 15 是否定义了系统性能的各个方面？ 16 在不同负载情况下，是否规定了系统的处理能力？ 17 在不同情况下，是否规定了系统的响应时间？ 18 是否充分定义了关于人机界面的需求？ 19 是否对需求定义进行了可行性分析和相关文件（资料）是否已归档？ 20 是否对影响需求实现的因素进行了调查，调查结果是否已归档？ 21 是否有经济效益分析，分析结果是否已归档？ 22 是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性？ 23 是否评估了本项目对用户、其它系统、环境的影响特性？ 24 是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序？ 1-3：采用以下检查表检查软件需求规格文档中需求的兼容性。
序号 问题 1 界面需求是否使软硬件系统具有兼容性？ 2 需求定义的文档是否满足项目文档编写标准？在矛盾时，是否有适当的标准可供选择？ 1-4：采用以下检查表检查软件需求规格文档中需求的一致性。
序号 问题 1 各个需求之间是否一致？是否有冲突和矛盾？ 2 所规定的模型、算法和数值方法是否相容？ 3 是否使用了标准的术语和定义形式？ 4 需求是否与其软硬件操作环境相容？ 5 是否说明了软件对其系统和环境的影响？ 6 是否说明了环境对软件的影响？ 7 所采用的技术是否与用户要求的技术一致？ 1-5：采用以下检查表检查软件需求规格文档中需求的正确性。
序号 问题 1 需求定义是否满足标准的要求？ 2 算法和规则是否有科技文献或其它文献作为基础？ 3 是否定义了对在错误、风险分析中所标识出的各种故障模式和错误类型所需的反应？ 4 是否参照了有关的标准？ 5 是否对每一个需求都给出了理由？理由是否充分？ 6 对设计和实现的限制是否都有论证？ 1-6：采用以下检查表检查软件需求规格文档中需求的可行性。
序号 问题 1 需求定义是否使软件的设计、实现、操作和维护都可行？ 2 所规定的模型、数值方法和算法是否对待解决问题合适？是否能够在相应的限制条件下实现？ 3 是否能够达到关于质量的要求？ 1-7：采用以下检查表检查软件需求规格文档中需求的易修改性。
序号 问题 1 对需求定义的描述是否易于修改（如是否采用良好的结构和交叉引用表等）？ 2 是否有冗余的信息？是否一个需求被定义了多次？ 1-8：采用以下检查表检查软件需求规格文档中需求的健壮性。
序号 问题 1 是否有容错的需求？ 1-9：采用以下检查表检查软件需求规格文档中需求的易追溯性。
序号 问题 1 是否可从上一阶段的文档中找到需求定义中的相应内容？ 2 需求定义是否明确地表明前阶段中提出的有关需求和设计限制都已被覆盖了？ 3 需求定义是否便于向后继开发阶段查找信息 1-10：采用以下检查表检查软件需求规格文档中需求的易理解性。
序号 问题 1 是否每一个需求都只有一种解释？ 2 功能性需求是否以模块方式描述的？是否明确地标识出了其功能？ 3 是否有术语定义一览表？ 4 是否使用了形式化或半形式化的语言？ 5 语言是否有歧义性？ 6 需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？是否过分细致了？ 7 需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础？ 8 需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了？ 1-11：采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。
序号 问题 1 需求是否可以验证（即是否可以检验软件是否满足了需求）？ 2 是否对每一个需求都指定了验证过程？ 3 数学函数的定义是否使用了精确定义的语法和语义符号？ 1-12：采用以下检查表检查软件需求规格文档中的性能需求描述。
序号 问题
是否精确的描述了所有的性能需求和可容忍的性能降低程度？对每一个性能应包含两方面的内容： 1 a. 在最坏情况的执行结果 2 b. 本性能失效后，对系统产生的影响 1-13：采用以下检查表检查软件需求规格文档中功能需求描述。
序号 问题 1 是否清楚、明确地描述了所有的功能？ 2 所有已描述的功能是否是必须的？是否能满足任务书或系统目标的要求？ 1-14：采用以下检查表检查软件需求规格文档中的接口需求描述。
序号 问题 1 是否清楚地定义了所有的接口？ 3 所有接口是否必须？各接口间的关系是否一致、正确？ 1-15：采用以下检查表检查软件需求规格文档中的数据需求描述。
序号 问题 1 在某异常数据（如条件、标志等）下，是否有真正没有考虑到的结果？ 2 对异常数据产生的结果是否作了精确的描述？ 1-16：采用以下检查表检查软件需求规格文档中的可维护性需求描述。
序号 问题 1 需求定义中是否包括了可行的系统维护方法？ 2 软件系统间的关系是否是松耦合的（即能否保证在对某部分修改后，产生最小的连锁效应）？
2 软件项目计划
2-1：软件项目计划必须以产品/软件的需求规格为基础。当发生需求更改时，必须修订软件开发计划。
说明：软件项目计划必须依据需求规格进行制定。项目计划中的工作产品和工作任务应保证能完全实现需求规格的定义。当需求更改时，必须考虑需求更改的相关性，修订相应软件开发计划。 2-1：制定软件项目计划的活动制定，必须遵守“软件项目计划规范”。 2-2：软件经理对软件项目计划的制定和结果负责。
2-3：软件经理和相关参与软件项目计划的制定和评审的人员，在参与计划制定之前必须经过软件工程和软件项目计划制定流程的培训。
2-2：对于软件项目计划中各项工作产品和工作任务，必须进行规模和工作量的软件估计，并在软件项目计划文档中记录估计的方法和估计数据。
说明：参考建议2-4到2-8。
2-4：可以使用PERT统计估计、专家判定平均法、经验类比估计、公式计算等方法，或以上方法的组合，进行软件估计。
示例：PERT统计估计和经验类比估计的结合
PERT统计估计值＝ (最大估计＋4×期望估计＋最小估计〕/ 6 估计记录如下： 工作产品任务 最大估计 规模 文档页数:45;增加、修改模块设计数目:12 工作量 12天 期望估计(根据经验类比获得) 规模 工作量 文档页10天 数:42;增加、修改模块设计数目:10 最小估计 规模 工作量 文档页5天 数:30;增加、修改模块设计数目:5 PERT估计 规模 文档页数:41;增加、修改模块设计数目:10 工作量 9.5天 XX版本（增加XX特性〕话统模块概要设计 期望估计值是根据XX版本的话统模块设计的数据获得。
2-5：对某项工作产品和任务的软件，同时采用两种或以上的方法进行估计，以避免一种方法的偏差。 2-6：尽量采用历史经验数据进行软件估计。
仅供内部使用
14
2-7：参照“软件估计指导书”进行软件估计。 2-8：软件估计对应项目的任务分解结构进行。
说明：软件估计对于项目的任务分解结构对应得越清晰、越细致，相应的估计越准确。 2-9：在“软件项目计划”中必须包括项目管理活动的计划。
2-10：在“软件项目计划”中包括软件重用计划。包括重用软件部件的计划和开发可重用软件部件的计划。
2-11：在“软件项目计划”包括人员的培训计划。
说明：项目人员计划包括需要的人员类型、数量和技术等级的要求，相关人员的开始工作时间、工作周期、接受培训的计划等。 2-12：对软件项目进行风险分析与评估。
说明：可能存在的风险领域含：需求的不明确和变更、外部的限制与对外的依赖、人力资源的到位情况、人力资源的技术等级满足要求状况、技术问题等。 对风险的分析与评估实践包括： 从已知的情况推导出潜在风险；
对风险进行分析，得出：潜在风险可能引发的问题的影响、潜在风险发生的可能性大小、风险发
生的时间段等； 排列风险的重点次序；
对风险记录成文件（属于软件项目计划中的一部分）； 风险经受风险影响人审核，并取得他的同意； 根据需要，在开发过程中对风险文档进行维护和修订。 2-3：对应工作任务，制定项目的文档计划。
2-4：软件项目计划中应该包括正规检视活动计划、软件质量保证计划、软件配置管理计划。软件质量保证计划和软件配置管理计划可以和软件项目计划在同一份文档中，也可以分开为三份文档。
说明：参考建议2-13。
2-13:软件质量保证计划和软件配置管理计划作为独立的计划文档。 2-14：软件项目计划必须是整个项目开发过程的计划，包括测试。
仅供内部使用
15