本文结合自己的经验，从实践的角度，对项目软件的分析工作从7个方面进行了阐述，并指出一些容易失误的做法。希望能对从事分析工作的同仁有所参考。
软件从使用范围的角度，可分为项目软件和产品软件。
项目软件：即针对特定某个客户的要求，并仅为其使用的软件。又称工程软件，特点是有明确的合同，严格的工期，约定的维护期等。如"xxx公司xxx系统"。
产品软件：即针对某一领域客户的共有需求而开发的软件。特点是通用、功能丰富而冗余，通过一次性的购买行为获得等。如操作系统软件、数据库软件、cad软件等。
本文就项目软件的需求分析，结合自身的体会，提出一些看法和建议。
1、 依据分析阶段确定合适的客户方配合人员
这一点对于获取真正的用户要求非常重要。通常，客户方会组织专工以上层次的人或在单位小有名气的计算机能手来和开发方分析人员配合，共同整理需求。
应该对客户方配合人员进行分类，层次化，使之和分析的各阶段相对应。
分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时，应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有完整的描绘，可以划分出子系统，及其之间的关系，这也是高级管理层对系统的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过程，避免需求范围漫无边际的扩大；
专业系统分析阶段，通常，客户单位都会有专业分工，彼此之间既相互独立，又会在某些点上发生联系。此阶段应与客户方专工层次的人员进行深入的讨论。这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务功能点。对他们应充分鼓励，尽量调动其积极性；
系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专工都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自然的希望能把这些信息融合到整个系统中来，为更多的人所共享。同时，也希望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。此阶段应把总工层和专工层召集到一起，共同理清系统间的接口。
经过这三个阶段，对需求的描述将比较准确和完整。
2、 多方位描述同一需求
有一些需求贯穿了从基层人员到高层领导，对此需求应该从各个角度、各个方位给以描述，总结之后才能得到完整的表达，否则可能会漏掉一些信息。这也为后续的设计工作打好了基础。
比如，在设备管理类软件中，有一个概念叫"缺陷"，指由于材料老化或外力作用，使得设备处于不正常的运行状态，但还没有到立刻就酿成"事故"的程度，但如不及时检修，就可能出事。对于设备缺陷业务，就涉及到从班组人员到领导，上上下下对此都非常关心，但各层次的人关心的侧重点却不尽相同：领导关心"消缺率"（即缺陷消除率）、"消缺及时率"；专工关心缺陷类型和处理方法；班组人员关心消缺工作的人员安排及时间地点。缺陷的业务处理流程依赖于"设备缺陷单"（用于记录缺陷及消除情况），如果仅仅局限于从由基层得到的设备缺陷单上的数据结构（设备名称、缺陷发现人、发现时间、二级单位确认时间、缺陷性质、安排消缺时间、消缺人员、消除日期、处理方法），无法满足专工层的分析要求：对设备的缺陷情况按类型、零部件、型号、生产厂家等分类统计，为设备采购时作为选型参考、调整设备及其零部件的检修周期以减少缺陷发生的频率等，因此需要在原来的设备缺陷单上增加一些相关信息。
3、 清晰化每一数据项
由于需求将作为设计的基础，弄清所有的数据项的来龙去脉对于设计是必不可少的。不能有模糊不清的地方，同时通过对数据项来源的分析，可以让分析人员更清楚的看到数据的流动情况，也会发现一些新的需求点。
4、 充分挖掘潜在需求
由于分析人员对软件技术非常熟悉，一些由于技术所带来的潜在需求对于客户来说，一般很难被发现。不实现这些需求，对整个系统也没什么实质性的影响；实现这些需求，则会锦上添花。
对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发，可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围，增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。
这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。
我觉得，不管是否告诉客户，分析人员还是应该去挖掘，最起码可以作为自己的知识积累。
5、 采用科学的分析报告模板
分析完成后，需要形成《需求分析报告》，应采用规范科学的报告模板，通过iso或cmm的企业，其模板大都非常详尽，不仅仅作为报告模板，还可以指导分析过程。
比如，我所在的企业除了有规范的需求分析报告编写指南、报告模板，还有"需求分析矩阵"和"需求变更报告"用于管理需求和控制变更。
6、 积累领域知识
领域知识对于分析人员很重要，这些知识的广度和深度影响分析结果的准确性和分析进度。分析人员应该通过各种途径去获取这些，不断积累，并进行比较和总结。
7、 抱着学习与指导并存的态度
面对一个新的客户时，分析人员首先必须抱着谦逊的学习的态度，把这看成是丰富领域知识的机会。但并非客户单位的任何层次的人都有值得学习的东西，随着分析人员接触的领域客户不断增多，分析人员对该领域的理解也会越来越深，逐渐会成长为领域专家，会有很多地方超过客户对领域的理解，此时，要以自己的深入理解去指导客户，说服客户，甚至纠正客户的一些错误的认识，得到客户的信任与尊敬，这对迅速顺利的完成需求分析会很有帮助。
8、 误区
在进行需求分析的时候，容易陷入一些误区，导致分析结果不理想。
分析结果越复杂越好
这是技术型分析人员经常碰到的情况，认为分析出错综复杂的关系，花哨的图表才能显示出分析水平高，其实，分析经常要经历"简单-复杂-简单"的过程，前一个简单表现为分析人员"认为简单"；随着分析的深入，原以为简单的问题会越来越复杂；最后，经过概括、消化、分解，使得需求简单明了。
必须一次到位
由于项目工期紧，或者客户单位地理位置偏远，不想反复去现场，希望通过一次需求分析就能得到完整的不再改变的结果。有这种情况时，表现为分析人员对客户方配合人员穷追猛问，或坚持要求配合人员做出保证，承诺需求范围不再扩大等等。结果往往是双方关系紧张，配合人员怕担责任，提出过多的灵活的、可配置的一些要求，无端增加了后续设计和编码的工作量。一次到位的想法是不现实的，随着开发工作的进行，用户经常会提出以前没想到的需求，或者更改已有的需求。需求必然有一个迭代的过程，变是不可避免的，关键是对于变化的控制，比如通过正规而繁复的流程提高需求变化时客户付出的代价：告知客户如此变化将会使工期延长，或需要追加资金等等，尽管对于"软件属于买方市场"的现状来说，开发方往往叫不起这个板，但这样的控制还是有一定的效果的。
客户的需求必须全部满足
陷入这一误区的分析人员，往往自己的领域知识欠缺，对客户的需求是否合理，缺乏分辨能力，只能由客户牵者走，这样会带来很大的风险：造成需求冗余，项目返工，更有对需求变化失去控制的危险，随着项目的开展，整个开发团队会越来越痛苦。所以必须加深自己的领域知识，变被动接受为主动引导，进而拒绝客户的不合理需求。
以上所述仅为个人体会，都是些做分析时的基本要求，要做好需求分析工作，还有赖于其他很多因素，如分析方法及辅助分析工具的掌握程度、个人交际能力的高低、语言沟通能力的高低等等，欢迎同行广泛交流，共同进步。
Java Asp PHP .Net XML C/C++ CGI VB Jsp J2ee J2se J2me EJB Servlet Tomcat Resin Struts Weblogic Eclipse ANT GUI JMS Web servise IDEA Webphere Hibernate Spring Jboss Applet Swing Socket Javamail Perl Ajax P2P 安全 模式 框架 测试 开源 游戏
Windows XP Windows 2000 Windows 2003 Windows Me Windows 9.x Linux UNIX 注册表 操作系统 服务器 应用服务器
