需求分析

先说结论：

业务需求 + 用户需求===（进行需求分析）====>系统需求（软件需求规格说明书）。

1.2.3 需求分析

软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。根据IEEE软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他规定文档所需具有的条件或能力，以及反应这些条件或能力的文档说明。

需求分析：就是把杂乱无章的用户要求和期望转化为无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性的用户需求（业务需求+用户需求=系统需求）。其作用是可以检测和解决需求之间的冲突，发现系统的边界，并详细描述出系统需求

（1）需求层次

①业务需求，反应企业各客户对系统高层次的目标要求，据之可以确定项目的视图和范围；

②用户需求，从用户的角度描述用户的具体目标，或用户要求系统必须能完成的任务；

③系统需求[1]，即从系统的角度说明软件的需求，包括功能需求（也称行为需求，从系统角度说明系统应当实现的功能，用户通过这些功能来完成任务，满足业务需求。）、非功能需求（系统应具备的属性和品质，比如软件可维护性、效率等质量属性）和设计约束（也称限制条件或补充规约，比如必须使用国产数据库系统等）。

可以说：业务需求从企业角度出发、用户需求从具体使用者角度出发、系统需求中的功能需求则是从具体系统出发；业务需求相当于战略、用户需求相当于战术、系统需求中的功能需求则是系统对具体战术、战略的具体实现。

（2）质量功能部署（QFD）是一种将用户要求转化为软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。包括：

①常规需求，用户认为系统应当做到的功能或性能，实现越多用户会越满意；

②期望需求，用户想当然认为系统应具备的功能或性能，但并不能正确描述自己相要的这些功能或性能需求。期望需求未实现，用户会感到不满意；

③意外需求[2]，也称兴奋需求，是用户要求之外的功能或性能，实现这些功能用户会更高兴，但不实现也不影响用户购买的决策

（3）需求分析方法

①结构化分析方法（SA），该方法建立的模型核心是数据字典，围绕核心有三个层次模型，分别是数据模型（用E-R图描述）、功能模型（用DFD图描述）和行为模型（也称状态模型，用STD图描述）。

u实体联系图（E-R图）：描述实体、属性，以及实体之间的关系（如右图）。

u                                               数据流图（Data Flow Diagram, DFD）从数据传递和加工的角度，描述系统内各个部件的功能和数据在它们之间传递情况；

u状态转换图（State Transform Diagram, STD）指出特定事件的结果将执行哪些动作（如处理数据等），从而描述系统的状态和引起系统状态转换的事件。

②面向对象分析方法（OOA）。OOA的基本任务是运用OO的方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系，最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。其核心工作是建设系统的用例模型与分析模型。OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA与OOD的区别所在。可以说OOA的任务是“做什么”，OOD的任务是“怎么做”。该模型包括用例模型和分析模型。

u构建“用例模型”步骤：识别参与者、合并需求获得用例、细化用例描述、调整用例模型

u建立“分析模型”步骤：定义概念类、确定类之间的关系（UML的4种关系）、为类添加职责、建立交互图等。其中前三个步骤可统称为CRC[3]建模。

（4）需求文档：软件需求规格说明书（Software Requirement Specification，SRS）,一般包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解、附录。

（5）需求验证：验证方法是需求评审、需求测试。

[1] 注《计算机软件文档编制规范》(GB/T8567-2006)中将系统需求分为三大类：功能需求、业务需求（包括：接口、资源、性能、可靠性、安全性、保密性等）、数据需求。

[2] 意外需求，控制在开发人员手中，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以基于成本等考虑选择不实现任何意外需求。

[3] CRC：Class-Responsibility-Collaborator，类-责任-协作者