2、需求分析

　　问题一：主次不分

　　需求分析人员常站在自身的角度去理解用户的需求造成主次不分。而实际上不同的系统对系统的功能与非功能性需求要求很不一样。比如，金融系统一般对系统的安全质量要求比较高。企业ERP系统一般对信息传递速度要求高一些。针对这种情况，首先需求分析人员可以借用当前的需求分析工具和图形的方式，明确用户的功能需求和非功能需求，特别注意产品性能、使用性、完整性、可靠性等非功能性需求。其次就要充分考虑到哪些需求是相对固定的需求，哪些可能会产生变动的需求，哪些需求会牵一发而动全身，区分这些需求，设定用户的每项需求、特性或使用实例的优生级并安排在特定的产品版本或实现步骤中，以应付客户后期的需求变更。

　　问题二：需求分析时间不够

　　这个问题非常普通，用户认为“我出钱你出力，当然以我的要求为准”，但实际上不合理的要求会导致项目失败，拿一个简单的例子来说明：假如1个人需要干100天时间才能把某件事情完成，为了赶进度，现在增加人数，选100个人干一天把这件事情做完。绝大多数人都会认为是不可能实现的。软件项目也是如此，它有一个最短周期，也就是说无论你如何增加资源追赶进度，都无法再缩短时间，在关键路径上增加人力、物力资源，或许还会添乱。一般需求开发工作应占全部工作量的15%。所以用户方与开发方必须达成共识留足够的时候给需求分析。

　　3、需求规格说明编写

　　问题一：文档混乱，文字表述过多

　　需求文档是需求人员对前期工作的总结。需求人员写出的文档混乱，图形连线错综复杂。首先是需要理清思路：需求的描述可以从2个方面来进行描述，一方面是对用户现行系统的描述，一方面是对系统未来的设想。构成企业信息系统主要包括基本要素：企业的组织结构、流程、数据、商务规则与功能，其中从用户的角度主要关注流程，是以流程为中心，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。企业组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务和系统范围有帮助；业务流程图把企业的业务流程与部门职责结合起来了，且形象直观；企业的数据（各种单据、帐本、报表等）可采用描述分类、格式化；企业商务规则与功能可以采用分类方法进行。其次尽量采用SRS(需求规格说明书)，较好的模板为IEEE标准830-1998描述的SRS模板，下面是一个常见的需求说明书的模板：

　　1. 前言(目的、范围、定义、缩写词、略语)www.mypm.net
　　2. 项目概述 （产品描述、产品功能、用户特点、一般约束、假设和依据）
　　3. 功能性需求 （功能需求1、功能需求2….）
　　4. 外部接口 （用户接口、硬件接口、软件接口、通信接口）

　　5. 性能需求
　　6. 设计约束 （其他标准的约束、硬件的限制）
　　7. 属性
　　8. 其他需求（数据库….）
　　9. 附录
　　10. 索引

　　4、需求论证

　　问题六：需求文档口头达到共识，缺乏文字依据

　　有时候因为时间紧凑或其他原因，即使达到了一致的共识，多数的用户单位都不愿意在需求文档上签字。这种情况有可能导致后期需求不断变更，需求变更影响软件开发的进度、成本，甚至有可能使得软件开发中止。对策：需求分析人员与用户建立良好的沟通渠道，强调需求文档书面认可的重要性，期望得到用户的理解。

　　总结：

　　综上所述，多数软件项目都是在时间紧、人员少、项目预算有限的条件下完成的。在这些“先天不足”的条件下，如何做到项目进度不延迟、工作量不超期、费用不超支？首先就是关注需求分析。 “良好的开端就成功了一半”，需求分析做好了，对下一步的设计阶段工作真正起到指导性作用，规避需求开发过程存在的问题，成功的软件项目指日可待。