4、 充分挖掘潜在需求
由于分析人员对软件技术非常熟悉，一些由于技术所带来的潜在需求对于客户来说，一般很难被发现。不实现这些需求，对整个系统也没什么实质性的影响；实现这些需求，则会锦上添花。
对这些潜在需求，会有两种处理方式：告诉客户，客户会得到启发，可能进一步提出新的需求，会有一些更大胆的想法，从而扩大了需求范围，增加了工作量，甚至会影响到工期；不告诉客户，等客户想到了再说。
这些需求如果对于产品软件，可能会是一个卖点，要尽可能的去挖掘。但对项目软件，考虑各种风险，有时候可能会回避，或对客户隐瞒。
我觉得，不管是否告诉客户，分析人员还是应该去挖掘，最起码可以作为自己的知识积累。
5、 采用科学的分析报告模板
分析完成后，需要形成《需求分析报告》，应采用规范科学的报告模板，通过ISO或CMM的企业，其模板大都非常详尽，不仅仅作为报告模板，还可以指导分析过程。
比如，我所在的企业除了有规范的需求分析报告编写指南、报告模板，还有"需求分析矩阵"和"需求变更报告"用于管理需求和控制变更。
6、 积累领域知识
领域知识对于分析人员很重要，这些知识的广度和深度影响分析结果的准确性和分析进度。分析人员应该通过各种途径去获取这些，不断积累，并进行比较和总结。
7、 抱着学习与指导并存的态度
面对一个新的客户时，分析人员首先必须抱着谦逊的学习的态度，把这看成是丰富领域知识的机会。但并非客户单位的任何层次的人都有值得学习的东西，随着分析人员接触的领域客户不断增多，分析人员对该领域的理解也会越来越深，逐渐会成长为领域专家，会有很多地方超过客户对领域的理解，此时，要以自己的深入理解去指导客户，说服客户，甚至纠正客户的一些错误的认识，得到客户的信任与尊敬，这对迅速顺利的完成需求分析会很有帮助。
8、 误区
在进行需求分析的时候，容易陷入一些误区，导致分析结果不理想。
分析结果越复杂越好
这是技术型分析人员经常碰到的情况，认为分析出错综复杂的关系，花哨的图表才能显示出分析水平高，其实，分析经常要经历"简单-复杂-简单"的过程，前一个简单表现为分析人员"认为简单"；随着分析的深入，原以为简单的问题会越来越复杂；最后，经过概括、消化、分解，使得需求简单明了。
必须一次到位
由于项目工期紧，或者客户单位地理位置偏远，不想反复去现场，希望通过一次需求分析就能得到完整的不再改变的结果。有这种情况时，表现为分析人员对客户方配合人员穷追猛问，或坚持要求配合人员做出保证，承诺需求范围不再扩大等等。结果往往是双方关系紧张，配合人员怕担责任，提出过多的灵活的、可配置的一些要求，无端增加了后续设计和编码的工作量。一次到位的想法是不现实的，随着开发工作的进行，用户经常会提出以前没想到的需求，或者更改已有的需求。需求必然有一个迭代的过程，变是不可避免的，关键是对于变化的控制，比如通过正规而繁复的流程提高需求变化时客户付出的代价：告知客户如此变化将会使工期延长，或需要追加资金等等，尽管对于"软件属于买方市场"的现状来说，开发方往往叫不起这个板，但这样的控制还是有一定的效果的。
客户的需求必须全部满足
陷入这一误区的分析人员，往往自己的领域知识欠缺，对客户的需求是否合理，缺乏分辨能力，只能由客户牵者走，这样会带来很大的风险：造成需求冗余，项目返工，更有对需求变化失去控制的危险，随着项目的开展，整个开发团队会越来越痛苦。所以必须加深自己的领域知识，变被动接受为主动引导，进而拒绝客户的不合理需求。
以上所述仅为个人体会，都是些做分析时的基本要求，要做好需求分析工作，还有赖于其他很多因素，如分析方法及辅助分析工具的掌握程度、个人交际能力的高低、语言沟通能力的高低等等，欢迎同行广泛交流，共同进步。
文章来源于领测软件测试网 https://www.ltesting.net/
