敏捷过程在我的理解之内是更“圆滑”一些，为了成为敏捷的团队，则需要作出改变：自主管理（从领导布置任务到自己挑选任务，并总结不足，提出改进并且自己要实施这些改进）、自我组织（从做好自己的事足够到联合起来对项目负责）和多功能型（每个人要全面负责，自己搞定规格说明书，同时自己搞定测试）。这样又和团队的定义有相悖之处？这是我所不理解的地方。敏捷——通俗的说，木有计划、木有文档、马上写代码、随时发牢骚。其实敏捷是一股思潮，或者说是一种价值观，它涵盖了好几种软件开发的方法论。敏捷的原则和前人总结的软件工程原则有着千丝万缕的联系，即把原来单个的实践方法结合起来并运用到极致这样。但是敏捷也有它的适用范围，且也会随着发展继续前进。
软件需求分析十分重要，过去人们一直认为需求分析是整个软件工程中的一个简单的步骤，“软件危机” 爆发之后，人们才逐渐认识到需求分析是软件开发过程中最关键的一个工程。由此可见需求分析的重要性。很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。听说过一句话，如果你不了解事物本身，你一定做不好（软件）。我很赞同作者的这个说法，让大学生暂时放下自己所学的许多高端技术，走到真实的世界中去，也许会看到并理解来自普通用户的真实需求。我们首先要知道并且很了解用户所说的是什么，才能懂得需求。
软件开发人员往往会将自己使用产品的习惯和对软件行业的熟悉程度出发进行设计，忘记了我们的软件是给千千万万个不会使用电脑的人使用的。所以我们要搞一个“典型用户”，强迫我们在考虑问题时从用户的角度出发。
软件功能说明书从用户的角度来描述产品的功能、输入、输出、界面、功能的边界问题等，不涉及软件内部的细节；技术说明书又叫设计文档，用于描述开发者如何去实现某一功能，或相互联系的一组功能。