1、创建子程序 

·  是否检查过先决条件已经满足了？ 
·  定义子程序将要解决的问题了吗？ 
·  结构设计是否足够清楚，使得你可以给子程序起个好名字？ 
·  考虑过如何测试子程序了吗？ 
·  是否从模块化水平或者满足时间和内存要求角度考虑过效率问题？ 
·  是否查阅过参考书；以寻找有帮助的算法？ 
·  是否用详尽的PDL设计子程序？ 
·  在必要时，是否在逻辑设计步骤前考虑了数据？ 
·  是否检查过PDL，它很容易理解吗？ 
·  是否注意到了足以使你返回到结构设计阶段的警告（使用了全局数据，更适合其它子程序的操作，等等）。 
·  是否使用了PDL到代码流程，是否把PDL 作为编码基础并把原有的PDL 转为注释？ 
·  是否精确地把PDL翻译成了代码？ 
·  在作出假设时，验证它们了吗？ 
·  是从几个设计方案中选择了最好的，还是随意选择了一个方案？ 

· 程序的名字让人困惑。Handlestuff（）能告诉我们程序是干什么的吗？
· 程序没有被说明（关于说明的问题已经超出了个别子程序的范围，详见第19章“自我说明的子程序”）。
· 子程序的布局不好。代码的物理组织形式几乎没有给出其逻辑组织形式的任何信息。
布局的使用过于随心所欲，程序每一部分的布局都是不一样的。关于这一点。只要比较一下ExpenseType=2 和ExpenseType=3 两个地方的风格就清楚了（关于布局问题，详见第十八章“布局与风格”）。
· 子程序的输入变量值InPutRec 被改变过。如果它作为输入变量，那它的值就不该变化。如果要变化它的值，就不该称之为输入变量InputRec。
· 子程序进行了全局变量的读写操作。它从CorpExpense 中读入变量并写给Profit。它应该与存取子程序通信，而不应直接读写全局变量。
· 这个子程序的功用不是单一的。它初始化了某些变量。对一个数据库进行写操作，又进行了某些计算工作，而它们又看不出任何联系。一个子程序的功用应该是单一，明了的。
· 子程序中没有采取预防非法数据的措施。如果CrntQtr的值为“0”，那么，表达式YTDRevenue*4.0／real(CrntQtr)就会出现被零除的错误。
· 程序中使用了几个常数：100, 4.0, 12, 2和3。关于“神秘”（magic）数的问题见11.1节“常数”
第五章高质量子程序的特点47
· 在程序中仅使用了域的CORP_DATA 型参数的两个域。如果仅仅使用两个域，那就该仅仅传入特定的域而不是整个结构化变量。
· 子程序中的一些参数没有使用过。ScreenX 和ScreenY 在程序中没有涉及。
· 程序中的一个参数被错误标定了。PrevColor被标定为变量型参数，然而在程序中又没有对其赋值。
· 程序中的参数太多。程序中参数个数的合理上限应该是七个左右。而这个程序中则多达11个。程序中的参数多得怕人，恐怕没谁会仔细检查它们，而且连数一下都不愿意。


2、结构分析

· 软件的总体组织形式是否清晰明了？包括对于结构设计的总体评论与描述。
· 模块定义是否清楚？包括它们的功能及其与其它模块的接口。
· 要求定义中所提出的所有功能，是否有恰当数量的模块覆盖？
· 结构设计是否考虑了可能的更改？
· 是否包括了必要的购买？
· 是否阐明了如何改进重新启用的代码来满足现在的结构设计要求？
· 是否描述并验证了所有主要的数据结构？
· 主要数据结构是否隐含在存取子程序中？
· 规定数据库组织形式和其它内容了吗？
· 是否说明并验证所有关键算法？
· 是否说明验证所有主要目标？
· 说明处理用户输入的策略了吗？
· 说明并验证处理输入／输出的策略了吗？
· 是否定义了用户界面的关键方面？
· 用户界面是否进行了模块化，以使对它所作的改动不会影响程序其它部分
· 是否描述并验证了内存使用估算和内存管理？
· 是否对每一模块给出了存储空间和速度限制？
· 是否说明了字符串处理策略？是否提供了对字符串占用空间的估计？
· 所提供的错误处理策略是不是一致的？
· 是否对错误信息进行了成套化管理以提供一个整洁的用户界面？
· 是否指定了坚固性级别？
· 有没有哪一部分结构设计被过分定义或缺少定义了？它是否明确说明了；
· 是否明确提出了系统目标？
· 整个结构在概念上是否是一致的？
· 机器和使用实现的语言是否顶层设计依赖？
· 给出做出每个重要决定的动机了吗？
· 你作为系统实现者的程序员，对结构设计满意吗？


3、需求分析

需求内容
· 系统的所有输入都定义了吗？包括它们的来源、精度、取值范围和频率？
· 系统所有的输出都定义了吗？包括它们的目标、精度、取值范围、频率和格式？
· 所有的报告格式都定义了吗？
· 所有的硬件与软件接口都定义了吗？
· 所有的通信交界面都定义了吗？包括握手、错误检查以及通信约定？
· 是否从用户的观点出发，定义了所有必要操作的反应时间？
· 是否定义了时间问题，如处理时间、数据传输率以及系统吞吐能力？
· 是否对用户所要求完成的任务部作出了规定？
· 每项任务所需用到和产生的数据都规定了吗？
· 规定保密级别了吗？
· 规定可靠性了吗？包括软件出错的后果、在出错时要保护的至关重要的信息、以及错误测试和恢复策略。
· 规定所需最大内存了吗？
· 所需最大存储容量规定了吗？
· 对系统的维护性是否作出了规定？包括系统对运行环境、精度、性能以其与其它软件的接口等方面变化的适应能力规定了吗？
· 是否规定了相互冲突的设计之间的折衷原则，例如，在坚固性与准确性之间如何进行折衷？
· 是否制定了系统成败的标准？

关于需求的完善性
· 在开发开始前暂时得不到的信息是什么？是否规定了不够完善的区域？
· 需求定义是否已经完善到了可以成为软件标准的地步？
· 需求中是否有哪一部分令你感到不安？有没有根本不可能实现，而仅仅为了取悦老板和用户才加进来的内容？

关于需求的质量
· 需求是否是用用户的语言制定的？用户也这样认为吗？
· 需求中是否每一条之间都尽量避免冲突？
· 需求中是否注意了避免规定设计工作？
· 需求在详细程度方面是否保持了一致性；有没有应该更详细些的要求？有没有应该更简略些的？
· 需求是否明确得可以分为一些独立的可执行部分，而每一部分又都很明了？
· 是否每一条都与问题和答案相关？是否每一条都可以追溯到产生它的环境中？
· 是否每一条需求都可以作为测试依据？是否可以针对每一条进行独立测试以确定是否满足需求？
· 是否对可能的改动作出了规定？包括每一改动的可能性？


4、总结

· 如果想开发一个高质量的软件，必须自始至终重视质量问题。在开始阶段强调质量往往比在最后强调质量更为有效。
· 程序员的份内工作之一便是向老板和同事宣传软件的开发过程，包括在编程开始前从事先决条件准备工作的重要性。
· 如果问题定义工作做得不好，那么在创建阶段，所解决的问题可能并不是用户真正要解决的问题。
· 如果需求分析工作做得不好，很可能因此而漏掉要解决问题中的重要细节。在创建工作后更改要求，要比在需求分析阶段进行更改的成本高20 到100倍。所以，在开始编程前一定要确认要求定义工作一切正常。
· 在编程前规定好约定，在创建工作结束后再改变代码来满足约定几乎是不可能的。
· 在创建活动开始之前如果无法完成准备工作，可以尝试在不太稳固的基础上进行创建活动。