测试需求与功能需求的关系功能需求：系统应该做什么。例如，某ATM机取款业务需求：每次取款额度在100～2000之间;取款的金额是100的倍数，每日取款总额不得超过20000，这是功能需求。测试需求：系统应该做什么、不应该做什么，发现系统设计中存在的问题。例如，取款金额可选：在100~2000之间且为100的倍数可取，小于100或大于2000不可取，在100~2000之间但不是100的倍数不可取，取款总额必须不超过账户余额，这是测试需求。
开发APP之前如何写一份好的需求文档？
1、先做好竞品分析，以及需求调研。2、梳理清楚需求故事线，方便做原型设计。3、设计好界面操作的交互序列和效果。4、明确app服务端的对应处理流程。5、明确各对口部门的管理流程，交易流程，资金流程。6、准备好给领导演示的demo，需要抛出疑问点和争议点，以便解决好需求冲突及复杂度过高的点。7、和技术负责部门沟通可行性和工期8、撰写需求分析和需求规格，列出风险点。
如何做一个软件需求分析师？优秀的需求分析师有什么样的品质？
这个问题很大，这篇不想再去重复一个软件需求分析员的知识体系结构，而是挑重点来谈下成为一个合格的软件需求分析人员的关键点。我原来对 软件需求的定义或描述更多是偏于对现实世界的定义，而对软件架构的描述为现实到实现之间的第一层抽象。在这里纠正一下即：用户需求是对现实世界的定义，而 软件系统需求是现实到实现的第一层抽象，即业务建模和软件系统用例建模。
在原来的软件工程里面我们更多谈到的一个词是系统分析员，我现在将其拆分为了软件 需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。从软件需求在整个软件生命周期中的定位来看，其上接业务，下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。对 于业务，首先要解决的是对业务的理解，然后才是在理解后业务的形式化表达和业务建模能力。
而对业务如何理解，最核心的仍然是顶层的流程建模和分析能力，底 层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力，业务单据和对象的抽取和定义能力，业务规则的清晰阐述能力，和流程配套的相关的 岗位角色，交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识，更多的是对业务的熟悉，对流程管理和分析方法的了解。
