需求分析

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

需求的层次

1 、软件需求就是系统必须完成的事以及必须其备的品质。需求是多层次的， 包括业务需求、用户需求和系统需求， 这三个不同层次从目标到具体， 从整体到局部， 从概念到细节。
2 、质量功能部署（ QFD ）是一种将用户要求转化成软件需求的技术， 其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标， QFD 将软件需求分为三类， 分别是常规需求、期望需求和意外需求。
##需求过程
需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。
1 、需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是否科学、准备充分， 对获取出来的结果影响很大， 这是因为大部分用户无法完整地描述需求， 而且也不可能看到系统的全貌。因此，需求获取只有与用户的有效合作才能成功。
2 、常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
3 、一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性， 因此， 需要分析人员把杂乱无章的用户要求和期望转化为用户需求， 这就是需求分析的工作。
4 、需求分析的关键在于对问题域的研究与理解。
5 、结构化分析CSA ）和面向对象的分析（ OOA)
(1 ） 结构化分析（ SA)
有三个层次的模型， 分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中， 一般使用实体关系图（E-R 图） 表示数据模型， 用数据流图(DataFl ow Diagram, DFD）表示功能模型， 用状态转换图（S t at e TransformDi agram .STD） 表示行为模型。
E-R 图主要描述实体、属性， 以及实体之间的关系； DFD 从数据传递和加工的角度， 利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况， 来说明系统所完成的功能； STD 通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为， 指出作为特定事件的结果将执行哪些动作（例如， 处理数据等） 。
( 2 ）面向对象的分析（ Ob j ect Or i ented Analysis , OOA)
OOA 模型包括用例模型和分析模型
用例是一种描述系统需求的方法， 使用用例的方法来描述系统需求的过程就是用例建模； 分析模型描述系统的基本逻辑结构， 展示对象和类如何组成系统（静态模型） ， 以及它们如何保持通信， 实现系统行为（动态模型）。
6 、需求规格说明书编制
软件需求规格说明书（ SRS ）是需求开发活动的产物， 编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解， 使之成为整个开发工作的基础。
在国家标准GB/T 8567 《计算机软件文档编制规范》中， 提供了一个SRS 的文档模板和编写指南， 其中规定S RS 应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。
另外， 国家标准GB/T 9385 《计算机软件需求说明编制指南》也考虑作为SRS 写作的参考之用。
7 、需求验证与确认
在系统分析阶段， 检测SRS 中的错误所采取的任何措施都将节省相当多的时间和资金。因此， 有必要对于SRS 的正确性进行验证， 以确保需求符合良好特征。需求验证与确认活动内容包括：

1. SRS 正确地描述了预期的、满足项目干系人需求的系统行为和特征；
   2)SRS 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；
   3）需求是完整的和高质量的；
   4）需求的表示在所有地方都是一致的；
   5）需求为继续进行系统设计、实现和测试提供了足够的基础。
   8、在实际工作中， 一般通过需求评审和需求测试工作来对需求进行验证。
   需求评审就是对SRS 进行技术评审， SRS 的评审是一项精益求精的技术， 它可以发现那些二义性的或不确定性的需求， 为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性， 仅仅通过阅读SRS ， 通常很难想象在特定环境下系统的行为。
   只有在业务需求基本明确， 用户需求部分确定时， 同步进行需求测试， 才可能及早发现问题， 从而在需求开发阶段以较低的代价解决这些问题。