本文结合自己的经验，从实践的角度，对项目软件的分析工作从7个方面进行了阐述，并指出一些容易失误的做法。希望能对从事分析工作的同仁有所参考。
软件从使用范围的角度，可分为项目软件和产品软件。
项目软件：即针对特定某个客户的要求，并仅为其使用的软件。又称工程软件，特点是有明确的合同，严格的工期，约定的维护期等。如"XXX公司XXX系统"。
产品软件：即针对某一领域客户的共有需求而开发的软件。特点是通用、功能丰富而冗余，通过一次性的购买行为获得等。如操作系统软件、数据库软件、CAD软件等。
本文就项目软件的需求分析，结合自身的体会，提出一些看法和建议。
1、 依据分析阶段确定合适的客户方配合人员
这一点对于获取真正的用户要求非常重要。通常，客户方会组织专工以上层次的人或在单位小有名气的计算机能手来和开发方分析人员配合，共同整理需求。
应该对客户方配合人员进行分类，层次化，使之和分析的各阶段相对应。
分析的初期，即总体分析阶段，需要得到整体意义上的轮廓需求，此时，应与客户方总工以上层次的人员进行交流，这一层次的人，对未来的系统会有完整的描绘，可以划分出子系统，及其之间的关系，这也是高级管理层对系统的期望。可以以此作为纲领性的文档指导进一步的分析，并约束后续的分析过程，避免需求范围漫无边际的扩大；
专业系统分析阶段，通常，客户单位都会有专业分工，彼此之间既相互独立，又会在某些点上发生联系。此阶段应与客户方专工层次的人员进行深入的讨论。这一层次的人，对自己的专业相当熟悉，对专业内的需求会非常到位，大都年富力强，有相当的阅历和理解能力，甚至自己都可以绘制业务流图，总结业务功能点。对他们应充分鼓励，尽量调动其积极性；
系统关联分析阶段，在各专业系统得到充分分析的基础上，紧接着就要理清它们之间的关系，这是提升需求档次的关键阶段，也是高级领导层和专工都关心的阶段。通常，客户单位都会有一些零散的软件，如财务软件，部颁软件等，这些专业软件都发挥着重要的作用，但都是些信息孤岛，客户会很自然的希望能把这些信息融合到整个系统中来，为更多的人所共享。同时，也希望数据能够在各专业系统间顺畅的流动，从而减少重复劳动，提高工作效率。此阶段应把总工层和专工层召集到一起，共同理清系统间的接口。
经过这三个阶段，对需求的描述将比较准确和完整。
2、 多方位描述同一需求
有一些需求贯穿了从基层人员到高层领导，对此需求应该从各个角度、各个方位给以描述，总结之后才能得到完整的表达，否则可能会漏掉一些信息。这也为后续的设计工作打好了基础。
比如，在设备管理类软件中，有一个概念叫"缺陷"，指由于材料老化或外力作用，使得设备处于不正常的运行状态，但还没有到立刻就酿成"事故"的程度，但如不及时检修，就可能出事。对于设备缺陷业务，就涉及到从班组人员到领导，上上下下对此都非常关心，但各层次的人关心的侧重点却不尽相同：领导关心"消缺率"（即缺陷消除率）、"消缺及时率"；专工关心缺陷类型和处理方法；班组人员关心消缺工作的人员安排及时间地点。缺陷的业务处理流程依赖于"设备缺陷单"（用于记录缺陷及消除情况），如果仅仅局限于从由基层得到的设备缺陷单上的数据结构（设备名称、缺陷发现人、发现时间、二级单位确认时间、缺陷性质、安排消缺时间、消缺人员、消除日期、处理方法），无法满足专工层的分析要求：对设备的缺陷情况按类型、零部件、型号、生产厂家等分类统计，为设备采购时作为选型参考、调整设备及其零部件的检修周期以减少缺陷发生的频率等，因此需要在原来的设备缺陷单上增加一些相关信息。
3、 清晰化每一数据项
由于需求将作为设计的基础，弄清所有的数据项的来龙去脉对于设计是必不可少的。不能有模糊不清的地方，同时通过对数据项来源的分析，可以让分析人员更清楚的看到数据的流动情况，也会发现一些新的需求点。
文章来源于领测软件测试网 https://www.ltesting.net/
