3.1 系统分析
1. 系统分析概述
系统分析是一组统称为计算机系统工程的活动。它着眼于所有的系统元素，而非仅仅局限于软件。系统分析主要探索软件项目的目标、市场预期、主要的技术指标等，其目的在于帮助决策者做出是否进行软件项目立项的决定。
2. 可行性分析（Feasibility - study）
可行性分析的目的并非解决问题，而是确定问题是否值得去解决。针对项目的目标和范围进行概要的分析和研究，探索问题域中的核心问题及其相应的解决方案，进一步为决策者提供经济、技术甚至是法律上可行性的分析报告。
4.2 需求定义
1. 需求的定义
宽泛地讲，需求来源于用户的一些 “需要”，这些 “需要” 被分析、确认后形成完整的文档，该文档详细地说明了产品 “必须或应当” 做什么。
通俗的软件需求定义为：针对待开发的软件产品，软件开发人员通过对软件产品的拥有者和使用者的交流和调研，获取相关的业务职能、业务知识和业务流程等信息，并对这些信息进行分析和整理后形成的有关该软件产品必须提供的功能和性能等指标的规格描述。
2. 需求的不确定性
需求的不确定性反映了需求的重要作用，需求分析的优劣对软件产品的质量影响最大。
4.3 软件需求分析的目标及任务
软件需求分析的任务是准确地定义新系统的目标，回答系统必须 “做什么” 的问题，并编制需求规格说明书。
需求分析的目标是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
4.4 软件需求分析建模的原则和方法
分析建模的操作性原则
- 问题的信息域必须被表示和理解（数据模型）：问题的信息域包含三个不同的数据和控制视图：
- 信息内容和关系：信息内容表示了个体数据和控制对象，它们可和其他的数据和控制对象关联。
- 信息流：信息流表示了数据和控制在系统中流动时变化的方式。
- 信息结构：信息结构表示了各种数据和控制项的内部组织。
- 软件将完成的功能必须被定义（功能模型）：对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：输入、处理和输出。功能模型从顶层的语境层模型开始，经过一系列的细化迭代，越来越多的功能细节被发现，直至得到所有系统功能。
- 软件的行为（作为外部事件的结果）必须被表示（行为模型）：大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。
需求分析的工程化原则
- 首先要正确地理解问题，再建立分析模型。
- 记录每个需求的起源及原因，保证需求的可回溯性。
- 开发一个人机交互过程的原型。
- 给需求赋予优先级：紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。
- 努力删除歧义性：因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法。
4.5 软件需求工程
软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，人们把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。
4.5.1 软件需求分析过程
需求分析阶段的工作可以分成以下几个主要方面：
需求开发
需求获取 — 《用户需求说明书》（User Requirements Statements）
- 需求获取的对象：用户和客户。用户是使用软件的人员，客户是购买软件的人员，客户与最终用户可能是同一个人也可能不是同一个人。
- 需求获取流程：
- 需求获取的准备工作：
- 起草需求调查问题表，将调查重点锁定在该问题表内（明确调查内容）。
- 确定需求调查的方式（如与用户交谈，向用户提问题；参观用户的工作流程，观察用户的操作；向用户群体发调查问卷；与同行、专家交谈，听取他们的意见；分析已经存在的同类软件产品，提取需求；从行业标准、规则中提取需求；从 Internet 上搜查相关资料）。
- 确定调查的时间、地点、人员等，撰写需求调查计划（明确 “何人” 在 “何时” 调查）。
- 需求获取与记录：在调查过程中随时记录（或存储）需求信息，建议采用表格的形式。
- 撰写用户需求说明书：需求分析员对收集到的所有需求信息进行分析，消除错误，归纳与总结共性的用户需求。然后按照指定的文档模板撰写《用户需求说明书》。《用户需求说明书》不同于最终的《软件需求规格说明书》，前者主要采用自然语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细；后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求是软件系统设计的直接依据，两者之间可能并不存在一一影射关系。
- 软件需求类别：功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。除了上述需求之外，还需要考虑一些其他的非功能性的需求并进行相应的分析。
软件需求定义
- 目的：定义准确无误的软件产品需求，产生《软件需求规格说明书》。
- 角色与职责：需求分析员定义软件需求。客户与最终用户确认软件需求。
- 启动准则：《用户需求说明书》已经撰写完成。
- 输入：《用户需求说明书》
- 主要步骤：
- 第一步：细化并分析用户需求；
- 第二步：撰写软件需求规格说明书；
- 第三步：软件需求确认。
- 输出：《软件需求规格说明书》
- 结束准则：《软件需求规格说明书》已经撰写完成。开发方和客户方已经对产品需求进行了确认。
- 度量：需求分析员统计工作量和上述文档的规模，汇报给项目经理。
- 需求分析与综合：需求获取之后，对比较复杂的用户需求进行建模分析，帮助软件开发人员更好地理解需求。在模型基础上，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。
- 需求建模：建模可以帮助软件开发人员更好地理解需求。它着重于描述系统必须做什么、而不是如何去做系统。该过程需要给出系统的逻辑视图（逻辑模型）以及系统的物理视图（物理模型）。逻辑模型给出软件要达到的功能和处理数据之间的关系，而不是实现的细节。软件需求的物理模型给出处理功能和数据结构的实际表示形式，这往往是由设备决定的。常用的建模分析方法包括面向对象的分析方法（OOA）、面向数据流的结构化分析方法（SA）、面向数据结构的 Jackson 方法、建立动态模型的状态转换图、PetriNet 等。
- 编制需求分析文档：包括软件需求规格说明书、数据要求说明书、初步的用户手册、修改、完善与确定软件开发实施计划。好的《软件需求规格说明书》应具备如下属性：正确、清楚、无二义性、一致、必要、完备、可实现、可验证、确定优先级、阐述 “做什么” 而不是 “怎么做”。
需求管理
需求确认 — 《需求评审报告》和书面承诺
- 目的：开发方和客户对需求文档进行评审，并作书面承诺。
- 角色与职责：开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之具有商业合同效果。
- 启动准则：需求文档如《用户需求说明书》和《软件需求规格说明书》已经完成。
- 输入：需求文档如《用户需求说明书》和《软件需求规格说明书》
- 主要步骤：
- 第一步：非正式需求评审；
- 第二步：正式需求评审；
- 第三步：获取需求承诺。
- 输出：《需求评审报告》和书面的需求承诺
- 结束准则：需求文档通过了正式评审，并且获得开发方和客户的书面承诺。
- 度量：项目经理统计工作量和上述文档的规模。
- 需求分析评审的主要内容：
- 系统定义的目标是否与用户的要求一致；
- 系统需求分析阶段提供的文档资料是否齐全；
- 文档中的所有描述是否完整、清晰、准确反映用户要求，有没有遗漏、重复或不一致的地方；
- 与所有其他系统成分的重要接口是否都已经描述；
- 所开发项目的数据流与数据结构是否足够，确定；
- 所有图表是否清楚，在不补充说明时能否理解；
- 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
- 系统的约束条件或限制条件是否符合实际；
- 开发的技术风险是什么；
- 是否考虑过软件需求的其他方案；
- 是否考虑过将来可能会提出的软件需求；
- 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；
- 软件开发计划中的估算是否受到了影响。
评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完备性、可实现性、可验证性。
