重拾软件工程—（3）需求分析

需求分析在我看来无疑是整个软件工程活动中最为重要的一步，因为这决定了整个软件系统的功能、性能，为整个软件的完成打下了最重要的基础。最最最重要的是，你面对的用户可能啥都不懂，所以，这就需要需求分析工作加以引导。

需求分析的基本概念

需求分析确定系统必须具有的功能和性能（非功能性需求），系统要求的运行环境，并且预测系统发展的前景。

• 功能性需求：描述系统应该实现的功能和提供的服务。
• 非功能性需求：遵循的标准，实现的约束条件，质量属性等。限定了选择解决问题方案的范围，如运行平台、实现技术、编程语言和工具等。

这儿有一个简单的例子说明了什么功能性需求和非功能性需求

将飞机订票系统中的以下方面做如下的划分，F代表“功能性”，NF代表“非功能性”，X代表“不应当是需求”。简要的说明功能性或非功能性需求的种类。对于不应当是需求的方面，说明其原因。

• 如何输入有关航班、乘客及订票信息。 F：输入
• 什么信息要出现在机票和报告中。 F：输出
• 如何计算乘机费用。 F：计算
• 什么信息必须存储在旅行社和其他人访问的数据库中。 F：存储
• 这个系统应该设计成可以处理常旅客计划。 NF：可扩展性
• 这个系统在任何时候都必须是可用的。一周中只允许有2分钟宕机时间。 NF：有效性
• 必须使用某排序算法根据离开时间对航班排序。 X：这是一个设计要求

需求分析的作用

• 因为需求分析的错误和变更是导致软件失败的重要原因
• 希望对开发进行指导
• 希望开发人员对用户的要求进行理解
• 希望用户理解开发人员
• 测试部门有理可依

下面开始具体的了解需求分析

需求分析的任务和步骤

需求分析的任务

• 建立分析模型
  准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。
• 编写需求说明
  用《需求规格说明书》规范的形式准确地表达用户的需求。

需求分析的步骤

需求获取
需求提炼
需求描述（撰写需求规格说明书）
需求验证

需求获取

主要包含：

• 需求的来源
• 收集这些需求的方法

需求来源 需求来源 用户目标
领域知识
投资者
运行环境
组织环境 采访
设定情景（用例）
原型
会议
观察商业过程和工作流

需求获取面临的挑战

• 用户说不清需求。
• 需求易变性。
• 问题的复杂性和对问题空间理解的不完备性和不一致性。

需求提炼（需求分析）

对应用问题和环境的理解和分析
将问题涉及的信息、功能及系统行为建立模型
将用户需求精确化、完全化
最终形成《需求规格说明书》

• 需求分析的核心在于建立分析模型。
• 需求分析采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题。
• 需求分析还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

需求建模的图形工具

类型 面向过程的需求分析 面向对象的需求分析 数据模型 实体-联系图（ERD）
数据字典（DD） 类图、类关系图 功能模型 数据流图（DFD） 用例图 行为模型 状态变迁图（STD） 活动图、时序图、状态图

目前需求分析建模，我一般使用微软的visio，可以自行网上搜索下载，然后可以下载“KMSpico”这个工具进行破解。

在这些建模图形工具中数据流图和用例图是最为重要的两个需求分析建模工具。

需求规格说明书

软件系统的需求规格说明，是对待开发系统的行为的完整描述。它包含了功能性需求和非功能性需求。

• 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
• 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

软件需求规格说明的原则

• 从现实中分离功能，即描述要“做什么”而不是“怎样实现”
• 要求使用面向处理的规格说明语言（或称系统定义语言）
• 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
• 规格说明必须包括系统运行环境
• 规格说明必须是一个认识模型
• 规格说明必须是可操作的
• 规格说明必须容许不完备性并允许扩充
• 说明必须局部化和松散耦合

需求验证

需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。

对需求文档需执行以下类型的检查：

• 有效性检查：检查不同用户使用不同功能的有效性。
• 一致性检查：在文档中，需求之间不应该冲突。
• 完备性检查：需求文档应该包括所有用户想要的功能和约束。
• 现实性检查：检查保证能利用现有技术实现需求。