软件工程03：软件需求分析

1. 需求分析之前的活动

预研：主要探索软件项目的目标、市场预期、主要的技术指标等，用于帮助决策者做出是否进行软件项目立项的决定。
可行性分析：针对项目的目标和范围进行概要的分析和研究，探索问题域中的核心问题及其相应的解决方案，进一步为决策者提供经济、技术甚至是法律上可行性的分析报告。

2. 需求分析

2.1. 需求的定义

研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把需求严格地、形式地表达出来。

2.2. 必要性

在系统需求分析和软件设计之间起到桥梁的作用。
(1). 它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。
(2). 它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。
(3). 分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。
(4). 它能准确表达用户对系统的各项要求。

2.3. 对象、任务和目标

对象：用户要求。
任务：准确地定义新系统的目标，回答系统必须做什么的问题并编制需求规格说明书。
目标：借助于当前（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的做什么的问题。

2.4. 操作性原则

(1). 问题的信息域必须被表示和理解。
(2). 软件将完成的功能必须被定义。
(3). 软件的行为（作为外部事件的结果，或者理解为功能存在的理由）必须被表示。

2.5. 工程化原则

(1). 首先要正确地理解问题，再建立分析模型。
(2). 记录每个需求的起源及原因，保证需求的可回溯性。
(3). 开发一个人机交互过程的原型。
(4). 给需求赋予优先级：紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。
(5). 努力删除歧义性：因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。

2.6. 数据、功能和行为建模

数据模型：信息内容和关系、信息流、信息结构。
功能模型：对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：输入、处理和输出（IPO）。
行为模型：大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。

3. 需求工程

定义：所有与需求直接相关的活动通称为需求工程。

4. 需求获取

目的：清楚地理解所要解决的问题，完整地获得用户的需求，并提出这些需求实现条件，以及需求应达到的标准。
对象：用户（使用软件的人员）、客户（购买软件的人员）。
难点：用户无法清楚地表达需求、需求的理解问题、用户经常变更需求。

4.1. 需求获取的流程

4.2. 需求获取的准备

围绕三项：访谈主题、方式、访谈对象及时间。

4.3. 需求获取的记录

需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式。

4.4 撰写用户需求说明书

(1). 对收集到的所有需求信息进行分析，消除错误，归纳与总结共性的用户需求；
(2). 撰写《用户需求说明书》；
(3). 评审。

4.5. 用户需求说明书 与 软件需求规格说明书的区别

(1). 前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
(2). 后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据。
(3). 两者之间可能并不存在一一影射关系。

5. 需求类别

功能需求：最主要。
性能需求：技术性能指标（实时性、精确度、数据处理规模等）。
环境需求：硬件（机型、外部设备），软件（操作系统），使用（操作人员的技术水平）。

6. 需求的分析与综合

需求获取之后就需要对比较复杂的需求进行建模分析，进而逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。
依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
分析和综合工作需要反复地进行，其过程将一直持续到分析员与用户双方都感到有把握正确地制定该软件的需求规格说明为止。

7. 撰写软件需求规格说明书