一、需求分析的概念和原则

需求分析的概念和原则
需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分析员建立并在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择的解决方案。
在可行性研究之后，我们对值得开发的软件进行需求分析。
3.1.1 需求分析
需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。需求分析为软件设计师提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。
1.软件需求的概念和分类
在我们分析需求之前，先要了解需求的类别，在获取需求时，按类别来处理就不容易遗漏。对需求有很多种不同的分类方法，其中的一种分类方法告诉我们需求应该包括：
第一是功能需求，这方面的需求指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能； 第二是性能需求，性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求； 第三是可靠性和可用性需求，可靠性和可用性需求即需求定量地指定系统的可靠性与可用性； 第四是出错处理需求，这类需求说明系统对环境错误应该怎样响应，例如，如果一个系统接收到从另一个系统发来的违反协议格式的消息，该系统应该做什么？ 第五是接口需求，接口需求描述应用系统与其环境通信的格式，常见的接口需求有用户接口需求、硬件接口需求、软件接口需求和通信接口需求； 第六是约束，约束描述了应用系统应遵守的限制条件，在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，这只是反映了用户或环境强加给项目的限制条件，常见的约束有：精度约束、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台等； 第七是逆向需求，逆向需求说明了软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求； 第八是将来可能提出的要求，应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求，这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。
2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的问题，所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求，描述软件要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用户的各项要求，但这些要求不能全盘接受，只能接受合理的要求；对其中模糊的要求要做进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户作充分的解释。最后，将软件的需求准确地表达出来，形成软件需求说明书。其实现步骤如图3.1所示。

图3.1 参考当前系统建立目标系统模型
（1）获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入/输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估，理解他们的需要及未来系统要解决的问题，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。当然，如果系统相对简单，也没必要大动干戈地进行业务建模，只要做一些简单的业务分析即可。
（2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。
（3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。
（4）对目标系统逻辑模型进行补充，具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。
3．需求分析的主要工作
软件需求分析可被划分成5个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。
例1. 汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工系统相关的问题包括：（1）不能快速地获得部件的状况；（2）更新卡片文件需要2至或3天的工作量；（3）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以及将提供什么信息。
例2. 客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题和希望的信息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。
例3. 在例1与例2的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户/服务器方法似乎是合适的，但是它确实属于在软件计划中概括的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户/客户需要的吗？继续评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当地刻划了。
例3. 说明了在贯穿整个评估和综合过程，分析员的主要焦点是“做什么”，而不是“怎么做”，即应该思考的是：系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会应用什么约束？。在问题评估和综合解决方案的活动中，系统分析员创建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内容。
4. 系统分析员的主要能力
毫无疑问，在整个系统分析活动中，系统分析员起着关键的作用，这意味着我们对系统分析员有着较高的期望，其本人也应该具备各项突出的能力。这些能力的主要表现如下：
能掌握抽象概念，能对其进行分类，能从中综合出解的能力； 能从冲突或者混淆中吸取恰当事实的能力； 能弄清用户环境的能力； 能伪用户系统恰当配置软硬件的能力 能较好地用书面和口头形式进行沟通的能力； 有“从树木见森林“的能力。
3.1.2 需求获取
软件需求分析中的相互沟通，总是要在两方或多方间进行。系统分析员所问的第一组问题可以关注客户、整体目标和收益。接下来的下一组问题使得系统分析员能够对问题做更好的理解，使得客户能够表达其关于解决方案的感觉，例如：如何刻画由某成功解决方案所产生的“好的”输出？该解决方案强调了什么问题？能向我显示或描述解决方案所应用的环境吗？系统分析员所问的最后一组问题关注于会议的效果。例如：你是回答这些问题的合适人员吗？你的回答是“正式的”吗？我的提问和你想解决的问题相关吗？其他人员可以提供附加信息吗？其他我应该问你的问题吗？
除了上述做法之外，也可以采用一种面向团队的需求收集方法，该方法被应用在分析和规约的早期阶段，被称为便利的应用规约技术，即FAST技术，该方法鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求。
FAST方法的基本原则是：
在中立的地点举行会议，由系统分析员和客户出席。 建立准备和参与会议的规则。 建议一个足够正式的议程，以便可以对所有重要点的、而又是足够非正式的问题进行自由交流。 有一个“协调者”控制会议过程。 使用一种“定义机制”（它可以是工作表、图表、墙上胶黏纸或墙板）记录有关信息。 会议的目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中，刻画出初步的解决方案需求。
3.1.3分析原则
在过去20年，研究者已经开发出一些实用分析方法及相应的建模符号，每种分析方法有独特的观点，然而，所有分析方法都遵循以下操作原则：
必须表示可理解的问题信息域。 必须定义软件将完成的功能。 必须表示软件的行为（作为外部事件的结果）。 必须划分描述信息、功能和行为的模型，从而能以层次的方式揭示细节。 分析过程应该从要素信息移向细节实现。
3.1.4 需求规格说明
软件需求规格说明是分析任务的最终产物，美国国家标准局、IEEE（标准号830－1984）以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。
编写需求的人必须描述的基本问题是：
功能——所设计的软件要做什么； 性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等； 强加给实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准； 属性——可移植性、正确性、可维护性及安全性等方面的考虑因素； 外部接口——与人、硬件、其他软件和其他硬件的相互关系。
下面给出一种软件需求规格说明的撰写大纲。
表3.1 软件需求规格说明的大纲
目录
1 前言
1.1 目的
1.2 范围
1.3 定义、缩写词、略语
1.4 参考资料
2 项目概述
2.1 产品描述
2.2 产品功能
2.3 用户特点
2.4 一般约束
2.5 假设和依据
3 具体需求
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 引言
3.1.1.2 输入
3.1.1.3 加工
3.1.1.4 输出
3.1.2 功能需求2
……
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用户接口
3.2.2 硬件接口
3.2.3 软件接口
3.2.4 通信接口
3.3 性能需求
3.4 设计约束
3.4.1 其他标准的约束
3.4.2 硬件的限制
…………
3.5 属性
3.5.1 安全性
3.5.2 可维护性
…………
3.6 其他需求
3.6.1 数据库
3.6.2 操作
3.6.3 场合适应性
…………
附录
索引
3.1.5 评审
下面的问题会被提出并确认：
叙述的软件目标与系统的目标是否保持一致？ 已经描述了所有系统元素的重要接口吗？ 已经定义了合适的问题域的信息流和结构吗？ 图是否清楚？每个图可以没有文字补充而单独存在吗？ 是否主要的功能保留在规定范围中，并且均已合适地描述？ 软件的行为和它所必须处理的信息及必须完成的功能是否一致？ 设计约束是可现实的吗？ 是否考虑过开发的技术风险？ 是否考虑过其他可选的软件需求？ 校验标准是否被详细地陈述？它们对成功描述的系统是合适的吗？ 是否存在不一致性、是否信息被忽略或存在冗余？ 和客户全面接触过吗？ 是否用户复审过初步的用户手册或原型？ 计划的估算受到什么样的影响？
下面的指南是针对详细的规约复审而提出的：
着重于说服性的连接词（例如，当然、因此、明确地、显然地、紧随的），并问“为什么”。 观察含糊的术语（例如，一些、有时、经常、通常、一般地、大多数、大多数的），并进行澄清。 当给出了不完整的列表时，确定已理解了所有的项。关键是查找“等等、如此这样”。 确定陈述的范围没有包含未陈述的假设（例如，从10到100的校验代码范围究竟是整数？实数？还是复数？） 小心含糊的动词如“处理、拒绝、处制、跳过、限制”等，它们可以以很多方式来解释。 小心含糊的代词（例如，I/O模块与数据校验模块通信，且设置它的控制标志，那么标志是谁的？） 查找蕴含了确定性的语句（例如，总是、每次、所有、无、永不），然后要求证明它们。 当某术语被明确地定义在某地方，力图用该定义去替换其他的出现术语。 当用语句描述某结构，画出图以帮助理解。 当刻画计算时，至少试验两个例子。
一旦复审完成，软件需求规格说明就变成了客户与软件工程师之间的软件开发“合约”。但在软件需求规格说明完成后也可能被修改，但是，客户应该注意，每个事后的修改是对软件范围的扩展，因此可能存在着增加成本或延长项目进度等情况。