林锐《软件工程思想》中，自己深有感触的一些言语摘录。有些可能是反面，有些是正面。
可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么，不做什么”。
即使可行性分析是客观的、科学的，但决策仍有可能是错误的。
如果在项目做了一大半时需求发生了变化，那将使项目陷入困境。
当你没碰到一个挑刺的人而感觉这产品好得会让你发大财时，就要做好会破产的心理准备。
在统计软件总的开发时间时，不能漏掉用于维护的时间。
软件维护是非常拖后腿的事，它能把前期拿到的利润慢慢地消耗光。
如果软件的质量不好，将会导致维护的代价很高，企图通过偷工减料而提高生产率，是得不偿失的事。
技术可行性分析可以简单地表述为：做得了吗？做得好吗？做得快吗？
社会环境的可行性至少包括两种因素：市场与政策。
“人分四类——人物，人才，人手，人渣。”
打破水缸的小孩子很多，但并不见得就会有司马光的业绩。
如果不允许一个男人在工作时仰天大笑，这样的地方不去也罢。
我曾得到很多炫目的荣誉，但学生时代的荣誉只是一种鼓励，并不是对我才能和事业的确认。
只有在具备极大的市场需求、极优秀的知识产品、业界杰出人物的条件下，才可能使一个公司的股值远远高于其“原始投资 + 经营利润”。
有几种原因使需求分析变得困难：
（1）客户说不清楚需求；
（2）需求自身经常变动；
（3）分析人员或客户理解有误。
分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。
最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。
据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]
尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。
在合同中一定要说清楚“做什么”和“不做什么”。
分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。
需求分析应该先了解宏观的问题，再了解细节的问题。
在写需求说明书时还应该注意两个问题：
（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。
（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。
前人既然付了学费，后人就不要拒绝坐享其成。