需求的分类：（四大类）
前三大类，需求的抽线程度
1、商务需求，整个企业和组织层面期望达成目标的所作的一个描述，不是某一个人或者某一类人所提的需求。
2、干系人需求，在了解整个组织的需求后，需要站在总体目标的前提下，进一步到具体组织和个人有哪些目的需要满足的，就是解决方案的用户。那不同的部门和干系人需要通力合作和协作。
关键按问题在于这类需求交付给开发团队，是否能够有成熟的方案直接实现，那么就存在以敏捷的方式还是瀑布的方式，瀑布的方式需要更详细的内容，包括用户业务流程
3.方案需求，解决方案的功能的能力和属性的总的集合，那么这样的方案交给实现团队，就能进一步实现需求的功能
前边的三个分类的界限在哪里，不好判断，视环境而变，最主要的是需求的收集、分析、定义不是一次性完成的，而是通过一种滚动、迭代逐步细化，最终完成一个详细的需求，刚开始可能是商业需求，例如刚开始收集需求的时候，如果过早的跳入到详细的解决方案的细节上面，就有可能之间树木不见森林，刚开始把关注点聚焦的整体的目标上，再进一步细化收集需求（干系人需求），再进一步分析方案需求
4、转换需求/过渡期需求：在解决方案的确认后，需要一些具体的方法，比如对人员进行一些培训，来适应设个方案，再例如一些数据的迁移的工作在解决方案的过渡过程中要实现的
4 的问题在于一般发生在转换和过渡后，后便再也不会用到，可以对一揽子过度需求进行打包，统一去实现
solution Requirement可分为：
功能性需求/非功能需求
----------------------------------------------
问题：需求/设计
Needs--Requirement<-->Designs--solution
Problem Owner--Business Analyst<-->Implementation SMEs--Solutions
例如：防盗系统接受密码输入，那么在设计过程中标表示成功，那么可以每输入一个数字是发出声音，这个声音有75赫兹，持续0.5秒钟
就是这样需求逐步过渡到设计，其中需求写到什么程度就算合适的标准，也要视情况而定
---------------------------------------------
需求作为设计的输入，但是在设计过程中也需要收集额外的信息，因此会产生一些迭代，实现团队也需要输出一些设计，再返回给BA进行确认，比如测试人员和开发人员在测试和开发设计的时候也会把输出成果反馈给BA进行确认，因此BA可能也需要一些技术背景，更好的理解开发设计和测试内容，不同的团队对于工作边界的定义不同
