软件工程实验报告

实验题目：实验一 软件工程标准文档

专    业：    计算机科学与技术   

班    级：      BU计算机091     

学    号：       0911503107      

姓    名：         谭 正         

实验日期：    2012年3月6日     

实验地点：        1J2D204         

盐城工学院 优集学院

一、软件生存周期阶段

实验内容：从GB-T8567-2006《计算机软件文档编制规范》中搜集整理出典型的软件生存周期的六个阶段，并说明各阶段主要的活动、任务及参与者。

实验要求：能够识别软件生成周期的六个阶段，能够列举出各阶段主要的活动、任务及参与者。

解：软件生存周期的六个阶段为：

a)可行性与计划研究阶段；

b)需求分析阶段；

c)设计阶段；

d)实现阶段；

e)测试阶段；

f)运行与维护阶段。

各阶段主要的活动、任务：

在可行性分析(研究)与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资——收益分析、制订开发计划，并完成可行性分析报告、开发计划等文档。

在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明(也称为：软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来。

在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块(或CSCI)的划分、功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：结构设计说明、详细设计说明和测试计划初稿。

在实现阶段内，要完成源程序的编码、编译(或汇编)和排错调试得到无语法错的程序清单，要开始编写进度日报、周报和月报(是否要有日报或周报，取决于项目的重要性和规模)，并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。

在测试阶段：该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。

在整个开发过程中(即前五个阶段中)，开发集体要按月编写开发进度月报。

在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。

各活动的基本参与者：

a)可行性与计划研究阶段的参与者有用户、项目负责人和系统分析师。

b)需求分析阶段的参与者有用户、项目负责人和系统分析师。

c)设计阶段的参与者有系统分析师、软件设计师和程序员。

d)实现阶段的参与者有系统分析师、软件设计师和用户。

e)测试阶段的参与者有系统分析师和软件设计师。

f)运行与维护阶段的参与者有维护人员和用户。

二、用于软件生存周期各阶段的文档

实验内容：从GB-T8567-2006《计算机软件文档编制规范》中搜集整理出软件生存周期各阶段的标准文档，并说明各标准文档的用途。

实验要求：能够识别软件生成周期各阶段的文档，能够说明各文档的用途。

软件生存周期各阶段的标准文档为：

a)可行性与计划研究阶段；可行性分析(研究)报告、软件(或项目)开发计划；开发进度月报；软件配置管理计划；软件质量保证计划；

b)需求分析阶段；软件(或项目)开发计划；软件需求规格说明；接口需求规格说明；(软件)用户手册；开发进度月报；软件)用户手册；

c)设计阶段；系统/子系统设计(结构设计)说明；软件(结构)设计说明；接口设计说明；数据库(顶层)设计说明；测试计划；开发进度月报；软件)用户手册；

d)实现阶段；(软件)用户手册；操作手册；测试计划；开发进度月报；

e)测试阶段；测试报告；开发进度月报；项目开发总结报告；

f)运行与维护阶段。软件产品规格说明；软件版本说明等。项目开发总结报告；

各标准文档的用途：

a)可行性分析(研究)报告；

l.《可行性分析(研究)报告》(FAR)是项目初期策划的结果，它分析了项目的要求、目标和环境；提出了几种可供选择的方案；并从技术、经济和法律各方面进行了可行性分析。可作为项目决策的依据。

2.FAR也可以作为项目建议书、投标书等文件的基础。

b)软件(或项目)开发计划；

1.《软件开发计划》(SDP)描述开发者实施软件开发工作的计划，本文档中“软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其他所有的活动。

2. SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。

3.本计划的某些部分可视实际需要单独编制成册，例如，软件配置管理计划、软件质量保证计划和文档编制计划等。

c)软件需求规格说明；

1.《软件需求规格说明》(SRS)描述对计算机软件配置项CSCI的需求，及确保每个要求得以满足的所使用的方法。涉及该CSCI外部接口的需求可在本SRS中给出：或在本SRS引用的一个或多个《接口需求规格说明》(IRS)中给出。

2.这个SRS，可能还要用IRS加以补充，是CSCI设计与合格性测试的基础。

d)接口需求规格说明；

1.《接口需求规格说明》(IRS)描述为实现一个或多个系统、子系统、硬件配置项HWCI,计算机软件配置项CSCI、手工操作、其他系统部件之间的一个或多个接口，而强加在这些实体上的需求。

2.这个IRS,还可以被用来补充《系统/子系统需求规格说明》(SSS)及《软件需求规格说明》(SRS)，作为系统和CSCI设计与合格性测试的基础。

e)系统/子系统设计(结构设计)说明；

1.《系统/子系统设计(结构设计)说明》(SSDD)描述了系统或子系统的系统级或子系统级设计与体系结构设计。SSDD可能还要用《接口设计说明》(IDD)和《数据库(顶层)设计说明》(DBDD)加以补充。

2.SSDD连同相关的IDD和DBDD是构成进一步系统实现的基础。贯穿本文的术语“系统，如果适用的话，也可解释为“子系统”。所形成的文档应冠名为“系统设计说明”或“子系统设计说明”。

f)软件(结构)设计说明；

1.《软件(结构)设计说明》(SDD)描述了计算机软件配置项(CSCI的设计。它描述了CSCI级设计决策、CSCI体系结构设计(概要设计)和实现该软件所需的详细设计。SDD可用接口设计说明IDD和数据库(顶层)设计说明DBDD加以补充。

2.SDD连同相关的IDD和DBDD是实现该软件的基础。向需方提供了设计的可视性，为软件支持提供了所需要的信息。

3.IDD和DBDD是否单独成册抑或与SDD合为一份资料视情况繁简而定。

g)接口设计说明；

1.《接口设计说明》(IDD)描述了一个或多个系统或子系统、硬件配置项HWCI、计算机软件配置项CSCI、手工操作或其他系统部件的接口特性。一个IDD可以说明任何数量的接口。

2.IDD可用于补充《系统/子系统设计(结构设计)说明》(SSDD)、《软件(结构)设计说明》(SDD)和《数据库(顶层)设计说明》(DBDD)。IDD及其相伴的《接口需求规格说明》(IRS)用于沟通和控制接口的设计决策。

h)数据库(顶层)设计说明；

1.《数据库(顶层)设计说明)(DBDD)描述了数据库的设计。所谓数据库指存储在一个或多个计算机文件中的相关数据的集合，它们可由用户或计算机程序通过数据库管理系统(DBMS)加以访问。DBDD还描述了存取或操纵数据所使用的软件配置项。

2.DBDD是实现数据库及相关软件配置项的基础。它向需方提供了设计的可视性，为软件支持提供了所需要的信息。

3.DBDD是否单独成册或与SDD合为一份资料视情况繁简而定。

i)(软件)用户手册；

1.《软件用户手册》(SUM)描述手工操作该软件的用户应如何安装和使用一个计算机软件配置项(CSCI) ,一组CSCI,一个软件系统或子系统。它还包括软件操作的一些特别的方面，诸如，关于特定岗位或任务的指令等。

2.SUM是为由用户操作的软件而开发的，具有要求联机用户输入或解释输出显示的用户界面。如果该软件是被嵌人在一个硬件一软件系统中，由于已经有了系统的用户手册或操作规程，所以可能不需要单独的SUM.

j)操作手册；

1.《计算机操作手册}(COM)提供操作指定的计算机及其外部设备所需的信息。本手册侧重计算机自身，而不是运行在其上的特定的软件

2.COM主要针对一些新开发的计算机、专用计算机、无现成的商用操作手册或其他操作手册可用的其他的计算机。

k)测试计划；

1.《软件测试计划》（STP)描述对计算机软件配置项CSCI,系统或子系统进行合格性测试的计划安排。内容包括进行测试的环境、测试工作的标识及测试工作的时间安排等。

2.通常每个项目只有一个STP,使得需方能够对合格性测试计划的充分性作出评估。

l)测试报告；

1.《软件测试报告》(STR)是对计算机软件配置项CSCl,软件系统或子系统，或与软件相关项目执行合格性测试的记录。

2.通过STR，需方能够评估所执行的合格性测试及其测试结果。

m)软件配置管理计划；

《软件配置管理计划》(SCMP)说明在项目中如何实现配置管理。

n)软件质量保证计划；

《软件质量保证计划》(SQAP)规定在项目中采用的软件质量保证的措施、方法和步骤。

o)开发进度月报；

开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进展和情况，以便及时发现和处理开发过程中出现的问题。一般地，开发进度月报是以项目组为单位每月编写的，如果被开发的软件系统规模比较大，整个工程项目被划分给若干个分项目组承担，开发进度月报将以分项目组为单位按月编写。

p)项目开发总结报告；

项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。

q)软件产品规格说明；

1.《软件产品规格说明》(SPS)包含有或引用了可执行软件、源文件以及软件支持的信息。包括一个计算机软件配置项(CSCI)“已建成”的设计信息和编辑、构造及修改的过程等。

2.SPS可被用于订购可执行软件和/或对应于该CSCI的源文件。它是针对该CSCI的基本的软件支持文档。注意，不同的组织对软件的订购和移交有着不同的策略。这种策略应在使用这个文档之前决定。

r)软件版本说明等。

1.《软件版本说明》(SVD)标识并描述了由一个或多个计算机软件配置项(CSCI)组成的一个软件的版本。它被用于发行、追踪以及控制软件的版本。

2.术语”版本”可用于软件的最初发行，用于其后续的发行，或用于在几乎同时发行的软件的多种形式之一(例如，用于不同的场所等)。

三、用于软件需求工程阶段与软件设计工程阶段的分析工具

实验内容：搜集资料并整理出用于软件生存周期各阶段的分析设计工具，并说明各个工具的主要用途。

实验要求：能够区分用于软件生存周期各阶段的分析设计工具，能够说明各个工具的主要用途。

解：a）软件环境开发：

1）软件工程CASE工具，软件开发环境是面向软件整个生存周期，为支持各个阶段的需要，在基本硬件和宿主软件的基础上使用的一组软件系统。

b) 软件需求工程阶段的分析设计工具

数据流图（DFD）：软件系统逻辑模型的一种图形表示，描述总体要求

数据词典：描述数据细节

加工说明：描述详细数据处理要求

c)软件分析和建模工具：

1）PowerDesigner是面向数据分析、对象分析、对象设计和实现，集成UML和数据建模的CASE工具。

　　2）Microsoft  Visio是软件开发绘图工具，软件分析与设计过程是要建立各种各样的模型，这些模型用来深入理解系统，使用图形的形式来表达对象系统的分析是一种行之有效的方法，且便于在软件人员和用户之间进行交流。

3）Rational Rose是IBM公司的面向对象建模工具，利用这个工具，我们可以建立用UML描述的软件系统的模型，而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码。

d)软件测试工具：

1）WinRunner界面测试工具可以学习应用程序的界面交互过程，并生成脚本，对界面进行自动化测试。

2）LoadRunner负载测试工具是一个功能非常强大的系统性能模拟工具，可以模拟不同层次和水平的负载量来测试系统的整体性能。

3）PurityPlus代码测试工具是一个百合测试工具，可以对源代码进行自动化测试，指出代码可能存在的缺陷。

e)软件项目管理工具：

1)Visual Safe Source用于软件项目的配置管理和变更控制，保证多人协同开发。

2)Microsoft Project是软件项目管理工具，Microsoft Project通过Microsoft Project Server为工作组协作提供有效的解决方案。二者结合可以为与项目成员、其他项目经理和风险承担者进行有效地通信提供巨大的灵活性和许多优点。

四、软件生存周期各阶段文档的评审标准

实验内容：搜集资料并整理出用于软件生存周期各阶段文档的评审标准。

实验要求：能够掌握软件生成周期各阶段文档的编制规范与评审要求。

系统分析与结构设计阶段应交付的文档有：

1）系统可行性研究报告

2）系统／子系统需求规格说明

3）系统／子系统设计说明

4）接口需求规格说明（可选项）

5）接口设计说明（可选项）

在系统分析与结构设计阶段，有关软件的主要评审内容包括：

1)软件功能描述的正确性

2)软硬件功能划分的合理性和可行性

3)接口要求及接口设备要求的合理性

4)质量要求的合理性

5)开发环境要求的合理性和可行性

6)开发进度要求的合理性和可行性

7)软件开发技术的合理性和可行性。

8)软件开发成本的合理性和可行性。

软件需求评审的主要内容：

1）用例

用例规格说明中是否包含了所有备选事件流和异常事件流？    

用例规格说明是否清楚地、无歧义性和完整地记录了每个场景的交互？

用例规格说明中的每个动作和步骤是否都与执行的任务有关？

用例规格说明中定义的每个场景是否都可行并且都可验证？

2）功能

是否清楚、明确地描述了所有的功能？

所有已描述的功能是否是必须的？

是否能满足用户需要或系统目标的要求？

功能需求是否覆盖了所有非正常情况的处理？

3）性能

是否精确地描述了所有的性能需求？

是否指定了期望处理时间、数据传输速率、系统吞吐量？

在不同负载情况下系统的效率如何？

在不同的情况下系统的响应时间如何？

4）接口

是否清楚地定义了所有的外部接口？

是否清楚地定义了所有的内部接口？

所有接口是否必须？

各接口之间的关系是否一致、正确？

5）数据

是否定义了系统的所有输入∕输出并清楚地标明了输入的来源？

是否说明了系统输入∕输出的类型以及系统输入∕输出的值域、单位、格式和精度？

是否说明了如何进行系统输入的合法性检查？

对异常数据产生的结果是否作了精确的描述？

6）硬件

是否指定了最小内存和最小存储空间需求？

是否指定了最大内存和最大存储空间需求？

7）软件

是否指定了需要的软件环境／操作系统？

是否指定了需要的所有软件设施？

8）通信

是否指定了目标网络和必须的网络协议？

是否指定了网络能力和网络吞吐量？

是否指定了网络连接数量和最小∕最大网络性能需求？

9）正确性

需求规格是否满足标准的要求？

算法和规则是否做过测试？

是否定义了针对各种故障模式和错误类型所必需的反应？

对设计和实现的是否都做了论证？

10）完整性

需求规格说明是否包含了有关功能、性能、、目标、质量等方面的所有需求？

是否识别和定义了将来可能会变化的需求？

是否充分定义了关于人机界面的需求？

是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序？

是否包括了每个需求的实现优先级？

11）可行性

需求规格是否使软件的设计、实现、操作和维护都可行？

所有模式、算法是否适用于要解决的问题？

是否能够在相应的条件下实现？

是否对需求规格进行了可行性分析及相关资料是否已归档？

是否对影响需求实现的因素进行了调查，调查结果是否已归档？

是否评估了本项目对用户、其他系统、环境的影响特性？

12）一致性

各个需求间是否一致？是否有冲突和矛盾？

规定的模型、算法和数值方法是否相容？

是否使用了标准术语和定义形式？

需求是否与其软硬件操作环境相容？

是否说明了软件对其系统和环境的影响？

是否说明了环境对软件的影响？

所有对其他需求的内部交叉引用是否正确？

所有需求在细节上是否都一致或者合适？

13）兼容性

接口需求是否使软硬件系统具有兼容性？

需求规格说明是否满足项目文档编写标准？

在矛盾时是否有适当的标准？

14）清晰性／无歧义性

所有定义、实现方法是否清楚、准确地表达了用户的需求？

在功能实现过程、方法和技术要求的描述上是否背离了功能的实际要求？

是否有不能理解或造成误解的描述？

15）安全性

是否所有与需求相关的安全特性都包含了？

是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性？

16）健壮性

是否有容错的需求？

是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件（硬件、软件、数据库、通信）都作了规定？

17）可理解性

产品的每个特性是否始终用同一术语描述？

是否每一个需求都只有一种解释？

是否使用了形式化或半形式化的语言？

语言是否有歧义性？

需求规格说明是否只包含了必要的实现规则而不包含不必要的实现细节？

需求规格说明是否足够清楚和明确使其已能够作为设计规格说明和功能测试数据设计的基础？

是否有术语定义一览表？

18）可修改性

需求规格说明的描述是否容易修改？例如是否采用良好的结构和交叉引用表等？

是否有冗余的信息？

是否一个需求被定义多次？

19）可测试性和可验证性

需求是否可以验证（即是否可以检验软件是否满足了需求）？

是否对每一个需求都指定了验证过程？

数学函数的定义是否精确？

20）可维护性

是否包含了所有与需求相关的维护特性？

需求规格说明中各个部分是否是松耦合的，即能否保证在对某部分修改后产生最小的连锁效应？

是否包含了所有与需求相关的外部接口？

是否包含了所有与需求相关的安装特性？

21）可跟踪性

是否每个需求都具有唯一性并且可以正确地识别它？

是否可以从上一阶段的文档查找到需求规格说明中的相应内容？

需求规格说明是否明确地表明上一阶段提出的有关需求的设计都已被覆盖？

需求规格说明是否便于向后续开发阶段查找信息？

22）可靠性

是否为每个需求指定了软件失效的结果？

是否指定了特定失效的保护信息？

是否指定了特定的错误检测策略？

是否指定了错误纠正策略？

系统对软件、硬件或电源故障必须作什么样的反应？

23）其他

是否所有的需求都是名副其实的需求而不是设计或实现方案？

是否明确标识出了对时间要求很高的功能并且定义了它们的时间标准？

概要设计评审的检查内容 ：

需求规格概述是否与需求规格说明保持一致？是否每一部分的设计都可以追溯到需求规格、接口需求规格或其他产品文档？

是否对需求分析中不完整、易变动、潜在的需求进行了相应的设计分析？

模块的规格是否和软件需求文档中的功能需求和软件接口规格要求保持一致？

设计和算法是否能满足模块的所有需求？

是否阐述了设计中的风险和对风险的评估？

1）总体设计

设计目标是否明确清晰地进行了定义？

是否阐述了设计所依赖的运行环境？与需求中运行环境是否一致性？

是否全面准确地解释了设计中使用到的一些基本概念？

设计中的逻辑是否正确和完备？

是否全面考虑了各种设计约束？

是否有不同的设计方案的比较？是否有选择方案的结论？是否清楚阐述了方案选择的理由

是否合理划分了模块并阐述了模块间的关系？

系统结构和处理流程能否正确地实现全部的功能需求？

2）接口设计

用户界面设计是否正确且全面？

是否有硬件接口设计？硬件接口设计是否正确且全面？

是否有软件接口设计？接口设计是否正确且全面？

是否有通信接口设计？通信接口设计是否正确且全面？

内部接口设计是否正确且全面？

是否描述了接口的功能特征？

接口是否便于查错？

接口相互之间、接口和其他模块、接口和需求规格说明及接口需求规格说明是否保持一致？

是否所有的接口都需要类型、数量、质量的信息？

3）质量属性设计

是否有可靠性的设计，设计是否具体、合理、有效？

是否有安全性的设计，设计是否具体、合理、有效？

是否有可维护性的设计，设计是否具体、合理、有效？

是否有可移植性的设计，设计是否具体、合理、有效？

是否有可测试性的设计，设计是否具体、合理、有效？是否明确规定了测试信息的输出格式？

4）数据结构

是否准确定义了主要的常量？

全局变量的定义是否准确？定义的全局变量的必要性是否充分？

主要的数据结构是否都有定义？

是否说明了数据结构存储要求及一致性约束条件？

是否对所有的数据成员、参数、对象进行了描述？

是否所有需要的数据结构都进行了定义，或者定义了不需要的数据结构？

是否所有的数据成员都进行了足够详细的描述？数据成员的有效值区间是否定义？共享和存储数据的使用是否描述清楚？

5）运行设计

对系统运行时的顺序、控制、过程及时间的说明是否全面、准确？

6）出错处理设计

是否列出了主要的错误类别？

每一错误类别是否都有对应的出错处理？

设计是否考虑了检错和恢复措施？

出错处理是否正确、合理？

7）运行环境

硬件平台、工具的选择是否合理？    

软件平台、工具的选择是否合理？

8）清晰性

程序结构，包括数据流、控制流和接口的描述是否清楚？

9）一致性

程序、模块、函数、数据成员的名称是否保持一致？

设计是否反映了真正的操作环境、硬件环境、软件环境？

对系统设计的多种可能的描述之间是否保持一致？（例如：静态结构的描述和动态描述）

10）可行性

设计在计划、预算、技术上是否可行？

11）详细程度

是否估计了每个子模块的规模（代码行数）？是否可信？

程序执行过程中的关键路径是否都被标名和经过分析？

是否考虑了足够数量及代表性的系统状态？

详细程度是否足够进行下一步的详细设计？

12）可维护性

是否模块化设计？模块是否为高内聚、低耦合？

是否进行了性能分析？

是否描述了所有的性能参数?（如实时性能约束、存储空间、速度要求、磁盘I／O空间）

详细设计评审的检查内容：

1）清晰性

是否所有的程序单元和处理的设计目的都已文档化？

单元设计，包括数据流、控制流、接口描述是否清楚？

单元的整体功能是否描述清楚？

2）完整性

是否提供了所有程序单元的规格？

是否描述了所采用的设计标准？

是否确定了单元应用的算法？

是否列出了程序单元的所有调用？

是否记录了设计的历史和已知的风险？

3）规范性

文档是否遵从了公司的标准？

单元设计是否使用了要求的方法和工具？

4）一致性

在单元和单元的接口中数据成员的名称是否保持一致？

所有接口之间，接口和接口设计说明之间是否保持一致？

详细设计和概要设计文档是否能够完全描述“正在构建”的系统？

5）正确性

是否有逻辑错误？

需要使用常量名的地方是否有错误？

是否所有的条件都被处理？

分支所处的状态是否正确？

6）数据

是否所有声明的数据块都已经使用？

定位于单元的数据结构是否已经描述？

如果有对共享数据、文件的修改，对数据的访问，则访问是否按照正确的共享协议进行？

是否所有的逻辑单元、事件标记、同步标记都已经定义和初始化？

是否所有的变量、指针、常量都已经定义并初始化？

7）功能性

设计是否使用了指定的算法？

设计是否能够满足需求和目标？

8）接口

参数表是否在数量、类型和顺序上保持一致？

是否所有的输入∕输出都已经正确定义并检查过？

所传递参数的顺序是否描述清楚？

参数传递的机制是否确定？

通过接口传递的常量和变量是否与单元设计的相同？

传入、传出函数的参数，控制标记是否都已经描述清楚？

是否以度量单位描述了参数的值区间、准确性和精度？

过程对共享数据的理解是否一致？

9）详细程度

代码和文档间的展开率是否小于10:1？

对模块的所有需求都已经定义？

详细程度是否足够开发和维护代码？

10）可维护性

单元是否是高内聚和低耦合？

是否这种设计是复杂度最小的设计？

开始部分的描述是否符合组织的要求？

11）性能

处理是否有时间窗？

是否所有的时间和空间的都已明确？

12）可靠性

初始化时是否使用了默认值，是否正确？

访问内存时是否进行了边界检查，以保证地址正确？

对输入、输出、接口和结果是否进行了错误检查？

对所有错误情况都安排了准确的消息反馈？

特殊情况下的返回码是否和文档中定义的全局返回码一致？

是否考虑了异常情况？

13）可测试性

是否每个单元都可以被测试、演示、分析或检查，以确认满足需求？

设计中是否包括辅助测试的检查点（如条件编译代码、断言等）？

是否所有的逻辑都是可测试的？

是否描述了本单元的测试驱动模块、测试用例集、测试结果？

14）可跟踪性

是否每一部分的设计都可以追溯到需求？

是否每一个设计决策都可以追溯到成本／效益分析？

是否所有的设计决策都可以追溯到成本／效益分析？

是否描述了每个单元的详细需求？

单元需求是否能够追溯到软件设计说明？

软件设计说明能够跟踪到单元需求？下载本文