为这可能是最困难、最关键、最需要交流的工作。因为软件不是硬件，不是主板，显示卡之类看得到摸得着的东西，软件是思想，是理念，是规则，是对真实世界的抽象。软件项目的交付物是有形的，可又不同于其他行业，比如汽车的构造是固定的，其组成部分是不变的。而一个软件系统的模块划分则可以有多种方法，多种结构。
这个特征导致对软件项目经理的抽象思维能力要求很高，要求要有较强的逻辑性。否则，就有可能表现为缺少全局概念，对项目整体的范围和业务系统把握不够，在项目过程中被客户牵着鼻子走，今天客户说要个什么功能，就添加个什么，明天要修改个什么，就跟着修改什么，被动至极。将客户信息结构化，编写成需求文档。这是需求定义的工作。公司的《产品需求规格说明书》的主要内容包括：“ 产品介绍;描述用户群体的特征;定义产品的范围; 阐述产品应当遵循的标准或规范;定义产品中的角色;定义产品的功能性需求;定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求;”仅有这份需求文档还不够，我上现场调研时带了个美工，将我们和客户沟通好的软件部分用图形界面UI画了出来。
需求定义是需求获取中最“痛苦”的一件事情，为了尽量避免日后的扯皮，我们力图使每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对需求定义的标准大致如下：需求存在二义性吗?2 需求文档的上下文有矛盾吗?2 需求完备吗?2 需求是必要的吗?2 需求可实现吗?2需求可验证吗?2 需求的优先级确定了吗?2
2、需求确认
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 在需求调研的过程中，我发现对项目范围的定义和当初了解的存在误差，这也是很正常的，因为未签订合同前，谁也不能做很深入的调研，只能了解个大概要求。但我们的原则是不轻易更改工作范围，只是在原来的框架内做一些小的调整。
而且每次和客户讨论之后，我们都写一份会议纪要，请客户签字确认。但即便如此，对需求的确认也是一件很让人头痛的事情。如何划定边界?做到什么程度就可以了?因为只有提供需求的人才能确定是否真正获取需求，我们都尽量请客户参与讨论并更正。需求评审会议非常重要，但是以前几个项目的评审会都开得不很理想，大家事先不认真阅读文档，会上乱哄哄的，你说一句，我问一句，往往花费了很多时间，却啥结论也没有。
这一次，我吸取了教训，组织了一个非常正规的需求评审会议，将部门领导、公司的业务专家、技术骨干都请来当评审人员。并自行设计了《评审准备表》和《评审记录表》。会前两天提前发了老挝项目的需求文档《老挝TAIS项目方案建议书》、《老挝TAIS项目调研报告》，发放了《评审准备表》，让大家提前将问题记录在评审准备表中，并反馈给我，我一直等到反馈意见收集的差不多了，才召开评审会。评审会开的很成功，效率很高。我让人整理了评审发现的问题，放在了评审记录表中，方便下去追踪。
3、需求变更控制
需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。
需求变更难以避免，重要的是不能没有章法得变，要遵循一个标准的变更控制程序，使得变化有序起来。如果不进行变更控制，那么，项目就不能得到及时的警告，常常会因为进度超期、预算超支而陷入泥潭，成为“烂尾”工程。但是变更