需求的三个层次：
1.业务需求-------------------组织或客户高层次的目标，一般来自项目的投资人，购买产品的客户，实际用户的管理者，市场营销部门或产品策划部门
输出文档------《产品前景和项目范围》
业务需求决定了应用的广度和深度，广度只应用能完成哪些工作（即用例）；而深度则说明将各项用例实现到何种程度。
当依据业务需求确定每项用例不在项目范围之内时，便是在进行广度的决策。业务需求将哪些用例要求稳定和全面的功能实现；哪些只需要
简单的实现，只是最初时是这样。当用户需求和功能需求存在不明确时已业务需求为主。业务需求明确的项目的边界。
2.用户需求------------------描述用户的目标 或用户要求系统必须能完成的任务。描述了用户能使用系统来做什么，是一种高度抽象的需求，不关注细节
使用用例、场景描述表达。
输出文档-----《用例文档》包括用例图和用例规约
3.功能需求 或 行为需求-----------------面向软件人员，规定开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
规定了开发人员需要实现什么。
输出文档-------------《软件需求规格》包括 功能需求+质量属性+约束
质量属性：
面向用户的质量属性（或运行期质量属性）：可用性，有效性，灵活性，完整性，互操作性，可靠性，健壮性，易用性
面向开发人员的质量属性（或开发时质量属性）：可维护性，可移植性，可重用性，可测试性
约束： 包括 技术专利，开发时间 和 成本 等
开发人员实现的不是业务需求 或用例，而是功能性需求。 功能性需求是让用户得以执行用例兵达成目标的系统行为，
用例是从角色的角度来描述系统行为，省略了很多细节。
用例描述的是用户的观点，以用户为中心。因此用例中不能包括开发人员编写软件所需的全部信息。
一个用例推导出多个功能需求，
广义的软件需求包括：业务需求+用户需求+功能需求
狭义的软件需求包括：功能需求+质量属性+约束
需求关注系统做什么，而设计关注怎么做 即解决方案，
但需求 如何 过度到设计 却存在一个灰色过渡区，所以有时在需求分析阶段 架构师可能会参与进来。
需求是一门工程 ：
需求工程=需求开发+需求管理
需求开发=需求获取+需求分析+编写需求规格+需求验证
需求获取：
1.与潜在用户沟通
2.描述现有产品或竞争产品的文档
3.现场客户访问
4.业务流程分析
5.工作流程分析和任务分析
6.事件列表
7.根据现有系统推导出需求
8.回顾以往项目
推荐书籍 《软件需求》第二版，经典之作。