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