要知道，当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这个问题很大，这篇不想再去重复一个软件需求分析员的知识体系结构，而是挑重点来谈下成为一个合格的软件需求分析人员的关键点。
1、软件测试的目的是什么？
一款软件的开发需要从需求分析、总体设计、代码开发、产品调试、软件测试、验收运行、后续升级几个大部分。在整个软件开发过程中，软件测试狭义上指软件初步发版后，对功能的完备度、对bug的情况进行整体测试；广义上来说，软件的测试应该围绕在软件的整个生命周期当中，对软件的操作和应用都属于软件测试，软件测试的目的首当其冲就是发现bug，修复bug，补充软件功能，完善客户使用友好度。
从产品本身来说，通过测试组操作使用，将不合理的地方找出，由开发人员逐一完善，在完善的过程中弥补软件的缺陷、程序的漏洞，让产品更加完备、成熟，让项目实施过程中，产品放心、靠谱，从客户层面来说，通过在项目中客户的使用，缩短软件从代码到业务的距离，让客户使用起来更友好、更贴近业务，让客户和友商能够通过该软件实实在在解决业务上或者技术上的难题。
其次，软件测试的过程，实际上能够加强开发人员和测试人员对软件整体功能的了解，在整个测试过程中，必然要由各类人员进行测试，开发组的人员往往只负责自己相关的功能，在整个测试的过程中对软件的其它功能也能加深印象，了解软件解决的业务难题。而测试人员或一些未参与软件研发的人员，则可以通过测试这一环节，从头到尾去了解软件，了解具体功能，尤其还能够从“陌生人”的角度提出整改意见和友好度体验，
最后，在整体的软件测试过程中，公司从上到下可以打造一套良好的最佳实践体系，这套体系包括测试体系和开发体系。通过测试的过程，总结出测试的经验，尤其是应该如何测试功能、如何测试业务、如何测试用户体验度等，让后续测试软件的过程有据可依，少走一些弯路，而通过在整个测试中发现的问题，可以向开发人员提出错误明细，让开发人员在开发过程中提前对类似的错误进行规避，提升开发人员的水平，构建开发最佳实践。
2、如何做一个软件需求分析师？优秀的需求分析师有什么样的品质？
这个问题很大，这篇不想再去重复一个软件需求分析员的知识体系结构，而是挑重点来谈下成为一个合格的软件需求分析人员的关键点，我原来对软件需求的定义或描述更多是偏于对现实世界的定义，而对软件架构的描述为现实到实现之间的第一层抽象。在这里纠正一下即：用户需求是对现实世界的定义，而软件系统需求是现实到实现的第一层抽象，即业务建模和软件系统用例建模，
在原来的软件工程里面我们更多谈到的一个词是系统分析员，我现在将其拆分为了软件需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力，从软件需求在整个软件生命周期中的定位来看，其上接业务，下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力，对于业务，首先要解决的是对业务的理解，然后才是在理解后业务的形式化表达和业务建模能力。
而对业务如何理解，最核心的仍然是顶层的流程建模和分析能力，底层的业务活动和规则清晰的描述能力，在这里里面涉及到流程梳理和定义能力，业务单据和对象的抽取和定义能力，业务规则的清晰阐述能力，和流程配套的相关的岗位角色，交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识，更多的是对业务的熟悉，对流程管理和分析方法的了解，
上面一步的业务更多的是属于顶层方面的内容，而第二个层面往往会过渡到系统软件需求层面的内容，在这里我们更加强调的是类似面向对象的用例分析和建模的方法，这包含了业务用例和系统用例分析和建模，是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例，单个具体的用例分析和建模，每个用例详细的基本流，扩展流，业务规则，参与角色，界面原型，业务对象和对象属性等各个方面内容的描述，要知道我们做用例建模的目的是能够按用例驱动的核心，平滑的转入到架构设计中去，因此用例分析建模已经不是简单的描述现实世界的问题，已经涉及到业务或用户需求到系统需求的第一层抽象转换。
