查看“需求分析”的源代码

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


软件需求是针对待解决问题的特性的描述。所定义的需求必须可以被验证。在资源有限时，可以通过优先级对需求进行权衡。

通过需求分析，可以检测和解决需求之间的冲突；发现系统的边界；并详细描述出系统需求。


===需求的层次===
（1）业务需求。

业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作奠定了基础。

（2）用户需求。

用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。

（3）系统需求。

系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足；非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、可维护性、效率等）和其他非功能需求。设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明，例如，必须采用国有自主知识产权的数据库系统，必须运行在 UNIX 操作系统之下等。


===质量功能部署===
质量功能部署（Quality Function Deployment, QFD）是一种将用户要求转化成软件需求的技术。其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD 将软件需求分为三类，分别是常规需求、期望需求和意外需求。


===需求获取===
常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。


===需求分析===
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

在实际工作中，一般使用实体联系图（E-R 图）表示数据模型，用数据流图（Data Flow Diagram, DFD）表示功能模型，用状态转换图（State Transform Diagram, STD）表示行为模型。


===软件需求规格说明书===
软件需求规格说明书（Software Requirement Specification, SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS 是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

在国家标准 GB/T 8567-2006 中，提供了一个 SRS 的文档模板和骗写指南，其中规定 SRS 应该包括以下内容：（1）范围。（2）引用文件。（3）需求。（4）合格性规定。（5）需求可追踪性。（6）尚未解决的问题。（7）注解。（8）附录。


===需求验证===
需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS 正确地描述了预期的、满足项目干系人需求的系统行为和特征。

（2）SRS 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。

（3）需求是完整的和高质量的。

（4）需求的表示在所有地方都是一致的。

（5）需求为继续进行系统设计、实现和测试提供了足够的基础。


在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对 SRS 进行技术评审，SRS 的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅读 SRS, 通常很难想象在特定环境下的系统行为。

只有在业务需求基本明确，用户需求部分确定时，同步进行需求铡试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。