软件需求分析

需求的三个层次：

1.业务需求-------------------组织或客户高层次的目标，一般来自项目的投资人，购买产品的客户，实际用户的管理者，市场营销部门或产品策划部门

  输出文档------《产品前景和项目范围》

  业务需求决定了应用的广度和深度，广度只应用能完成哪些工作（即用例）；而深度则说明将各项用例实现到何种程度。

  当依据业务需求确定每项用例不在项目范围之内时，便是在进行广度的决策。业务需求将哪些用例要求稳定和全面的功能实现；哪些只需要

  简单的实现，只是最初时是这样。当用户需求和功能需求存在不明确时已业务需求为主。业务需求明确的项目的边界。

2.用户需求------------------描述用户的目标 或用户要求系统必须能完成的任务。描述了用户能使用系统来做什么，是一种高度抽象的需求，不关注细节

                                       使用用例、场景描述表达。

输出文档-----《用例文档》包括用例图和用例规约

3.功能需求 或 行为需求-----------------面向软件人员，规定开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

                                                          规定了开发人员需要实现什么。

输出文档-------------《软件需求规格》包括 功能需求+质量属性+约束

质量属性：

面向用户的质量属性（或运行期质量属性）：可用性，有效性，灵活性，完整性，互操作性，可靠性，健壮性，易用性

面向开发人员的质量属性（或开发时质量属性）：可维护性，可移植性，可重用性，可测试性

约束： 包括 技术专利，开发时间 和 成本 等

开发人员实现的不是业务需求 或用例，而是功能性需求。 功能性需求是让用户得以执行用例兵达成目标的系统行为，

用例是从角色的角度来描述系统行为，省略了很多细节。

用例描述的是用户的观点，以用户为中心。因此用例中不能包括开发人员编写软件所需的全部信息。

一个用例推导出多个功能需求，

广义的软件需求包括：业务需求+用户需求+功能需求

狭义的软件需求包括：功能需求+质量属性+约束

需求关注系统做什么，而设计关注怎么做 即解决方案，

但需求 如何 过度到设计 却存在一个灰色过渡区，所以有时在需求分析阶段 架构师可能会参与进来。

需求是一门工程 ：

需求工程=需求开发+需求管理

需求开发=需求获取+需求分析+编写需求规格+需求验证

需求获取：

1.与潜在用户沟通

2.描述现有产品或竞争产品的文档

3.现场客户访问

4.业务流程分析

5.工作流程分析和任务分析

6.事件列表

7.根据现有系统推导出需求

8.回顾以往项目

推荐书籍 《软件需求》第二版，经典之作。