软件工程-第3章 软件需求分析基础

例3. 在例1与例2的基础上，一些可以进一步 思考内容是，一旦已经建立这些信息，就该考 虑针对实现的基本体系结构，那么客户/服务 器方法似乎是合适的，但是它确实属于软件计 划的范围吗？似乎需要一个数据库管理系统， 但是，该数据库系统真的是用户需要的吗？继 续这种评估和综合的过程，直至分析员和客户 均确信针对后面的开发步骤软件确实已被适当 地刻划了。
比较通俗的需求定义如下：需求是指明系统必 须实现什么的规格说明，它描述了系统的行为、 特性或属性，是在开发过程中对系统的约束。
需求的类别
功能需求：指定系统必须提供的服务，通过需 求分析应该划分出系统必须完成的所有功能；
性能需求：指定系统必须满足的定时约束或容 量约束；
可靠性和可用性需求：定量地指定系统的可靠 性与可用性；
l 用户解决问题或达到目标所需要的条件。 l 系统或系统部件要满足合同、标准、规范
或其他正式规定的文档所要具有的条件。 l 反映上面两条的文档说明。
IEEE公布的需求定义分别从用户和软件工程 师的角度阐述了什么是需求，需求一方面反映 了系统的外部行为，另一方面反映了系统的内 部特性，反映的方式是需求文档。
问题定义阶段
在需求分析之前，需要描述和定义问题。问题 定义阶段必须回答的关键问题是“要解决的问 题是什么” 。
通过对系统的实际用户和使用部门负责人的访 问调查，最后得出一份双方都满意的文档。
问题定义阶段是软件生存周期中最简短的阶段， 一般只需要一天甚至更少的时间。
可行性研究阶段
这个阶段要回答的关键问题是“对于上一个阶 段所确定的问题有行得通的解决办法吗？”
需求分析的任务
获得当前系统的物理模型：首先，分析、理解 当前系统是如何运行的，并用一个具体的模型来 反映自己对当前系统的理解。 抽象出当前系统的逻辑模型：在理解当前系统 “怎样做”的基础上，取出非本质因素，抽取出 “做什么”的本质。
建立目标系统的逻辑模型：分析目标系统与当 前系统逻辑上的差别，明确目标系统要“做什 么”，从而从当前系统的逻辑模型中，导出目标 系统的逻辑模型。
系统分析员需要进行一次大大压缩和简化了的 系统分析和设计的过程。
如果系统分析员通过可行性研究之后，得出该 工程项目不值得做的结论时，应该及时中止投 资该工程项目，可以避免更大的浪费。
3.1.1 需求分析
需求分析是一种软件工程活动，使得系统分析 员能够刻划出软件的功能和性能、指明软件和 其他系统元素的接口、并建立软件必须满足的 约束。
需求必须描述的基本问题
功能——所设计的软件要做什么； 性能——软件功能在执行过程中的速度、可使
用性、响应时间、各种软件功能的恢复时间、 吞吐能力、精度、频率等等；
强加给实现的设计限制——在效果、实现的语 言、数据库完整性、资源限制、操作环境等等 方面所要求的标准；
属性——可移植性、正确性、可维护性及安全 性等方面的考虑因素；
例2. 客户希望得到指明什么零件从库存中取出、 以及还剩余多少相似零件的日报表。客户指明 一旦当该零件离开仓库时库存管理员就该记载 每个零件的标号。通过对当前问题和希望的信 息（输入和输出）进行的评估，系统分析员开 始综合一个或多个解决方案。为了便于开始， 必须详细地定义系统的数据、处理功能和行为。
出错处理需求：说明系统对环境错误应该怎样 响应；
接口需求：描述应用系统与其环境通信的格式； 约束：描述了应用系统应遵守的限制条件；
逆向需求：说明软件系统不应该做什么。理论 上有无限多个逆向需求，我们应该仅选取能澄 清真实需求且可消除发生误解的那些逆向需求；
将来可能提出的要求：应该明确地列出那些虽 然不属于当前系统开发范畴，但是据分析将来 很可能会提出来的要求。
第三章 软件需求分析基础
主要内容
需求分析的概念和原则 传统的软件需求分析基础
3.1 需求分析的概念和原则
需求分析的基本任务是准确地回答“系统必须做什 么？”这一核心问题。
需求分析是发现、求精、建模和规约的过程。这一过 程包括：详细精化最初由系统分析员建立在软件项目 计划中确定的软件范围，创建所需数据流、控制流以 及操作行为的模型，在此基础上选择解决方案。
能掌握抽象概念，能对其进行分类，能从中综合 出解的能力；
能从冲突或者混淆中吸取恰当事实的能力； 能弄清用户环境的能力； 能为用户系统恰当配置软硬件的能力 能较好地用书面和口头形式进行沟通的能力 有“从树木见森林”的能力。
3.1.2 需求获取
软件需求分析中需要很好的的相互沟通，沟通 总是要在两方或多方间进行。
客户和系统分析员之间最常用的交流方式，是 通过预备会议或访谈进行的。
获取用户需求的主要方法是调查研究。
做好准备 制定调研计划 准备调研资料 访谈用户 写调研报告 评审
系统分析员所问的第一组问题可以关注客户、 整体目标和收益。
接下来的下一组问题使得系统分析员能够对问 题做更好的理解，使得客户能够表达其关于解 决方案的感觉。
对目标系统逻辑模型进行补充：具体内容如 用户界面、启动和结束、出错处理、系统输入输 出、系统性能、其他限制等等。
3．需求分析的主要工作
软件需求分析可被划分成5个工作阶段：问题分 析；问题评估和方案综合；建模；规约；复审。
例1. 汽车零件的主要供应商需要一个库存控制 系统，系统分析员发现与当前的手工系统相关 的问题包括：（1）不能快速地获得部件的状况； （2）更新卡片文件需要2至或3天的工作量； （3）由于没有办法查找相关厂商的部件信息， 而使得对同一厂商同一货品多次再订货，等等。 一旦问题被标识出来，系统分析员将确定新系 统该产生什么信息，以及将提供什么信息。
需求分析是软件设计师进行软件分解的基础， 需求分析建造了软件处理的数据模型、功能模 型和行为模型。需求分析为软件设计师提供了 可被翻译成数据、体系结构、界面和过程设计 的模型，最后，需求规约为软件设计师和客户 提供了软件建造完后，进行质量评估的依据。
1.软件需求的概念和分类
比较权威的需求的定义来自于IEEE软件工程 标准词汇表中的定义：
FAST方法的基本原则
在中立的地点举行会议，由系统分析员和客户 出席。
建立准备和参与会议的规则。
建议一个足够正式的议程，以便可以对所有重 要的、而又是足够非正式的问题进行自由交流。
有一个“协调者”控制会议过程。
使用一种“定义机制” 记录有关信息。
会议的目标是标识问题、提出解决方案的要素、 商议不同的方法以及在有利于完成目标的氛围 中，刻画出初步的解决方案需求。
3.1.5 评审
需求审查是需求分析阶段工作的最后一步，是由 软件工程师和客户一起进行并完成的。
目的是发现软件需求规格说明中的错误、二义性 和遗漏的需求。
复审首先在宏观的级别上进行，复审者试图保 证软件需求规格说明是完整的、一致的、精确的。 然后复审会更详细，关注软件需求规格说明中的 措词。
3.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.划分
实际的问题经常太大而且复杂难于进行整体理 解，我们往往将这样的问题划分为易于理解的 子问题，并建立各子问题间的接口，以便完成 整个功能。
除了上面提到的操作性分析原则，Davis提出 了一组针对需求工程的指导性原则：
在开始建立分析模型前，先充分理解问题。 开发原型，使得用户能够了解如何进行人机交互。 记录每个需求的起源及原因。 使用多个需求视图。建立数据、功能和行为模型，
为软件工程师提供三种不同的视图。 给需求赋予优先级。 努力删除歧义性。
在整个评估和综合过程中，分析员的主要焦点 是“做什么”，而不是“怎么做” 。
在问题评估和综合解决方案的活动中，系统分 析员创建系统模型，以便可以更好地理解数据 流和控制流、处理功能和操作行为以及信息内 容。
4. 系统分析员的主要能力
在整个系统分析活动中，系统分析员起着关键 的作用，其本人应该具备突出的能力，如：
1.信息域
所有的应用软件均可称为数据处理系统。
信息流表示了数据和控制在系统中流动时的变 化方式，输入对象被变换为中间信息，这些信 息被进一步变换为输出。沿着这个变换路径， 可能从现存的数据存储中引入附加的信息。
数据的变换是程序必须完成的功能或子功能， 在两个变换（功能）间流动的数据和控制定义 了每个功能的接口。
3.1.3分析原则
在过去20年，研究者已经开发出一些实用分析 方法及相应的建模符号，每种分析方法有独特的 观点，然而，所有分析方法都遵循以下操作原则：
必须表示可理解的问题信息域。 必须定义软件将完成的功能。 必须表示软件的行为。 必须划分描述信息、功能和行为的模型，从而能以
层次的方式揭示细节。 分析过程应该从要素信息移向细节实现。
第四条操作性分析原则建议划分软件的信息、 功能和行为域。
3.1.4 需求规格说明
软件需求规格说明是分析任务的最终产物，美 国国家标准局、IEEE以及美国防部门均已提 出了软件需求规约（以及其他软件工程文档） 的候选格式。
软件需求规格说明必须正确地定义所有的软件 需求；除了设计上的特殊限制之外，软件需求 规格说明中一般不描述任何设计、验证或项目 管理的细节。
最后一组问题关注于会议的效果。
FAST方法
也可以采用一种面向团队的需求收集方法，该 方法被应用在分析和规约的早期阶段，被称为 便利的应用规约技术，即FAST技术。
该方法鼓励建立客户和系统分析员之间的合作， 由他们共同工作来标识问题、提出解决方案的 要素、商议不同的方法以及刻画出初步的解决 方案需求。
2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型 导出目标系统的逻辑模型，解决目标系统“做 什么”的问题。
所要做的工作是深入描述软件的功能和性能， 确定软件设计的限制和软件同其他系统元素的 接口细节，定义软件的其他有效性需求。
必须全面理解用户的各项要求，但只能接受合 理的要求。
要将软件的需求准确地表达出来，形成软件需 求说明书。
外部接口——与人、硬件、其他软件和其他硬 件的相互关系。
Leabharlann Baidu件需求规格说明的大纲
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 ……
功能模型：记录软件的变换信息，为了达到此 目标必须至少完成三个常见功能：输入、处理 和输出。
行为模型：一个计算机程序总是存在于某个状 态，仅当某事件发生时才被改变。行为模型创 建了软件状态的表示，以及导致软件状态变化 的事件表示。
需求分析阶段创建模型的作用
模型帮助分析员理解系统的信息、功能和行为， 因此，使得需求分析任务更容易实现。
结构化的分析方法是最经典的需求分析方法。 适用于数据处理类型软件的需求分析。 它提供的工具包括：数据流图、数据字典、结 构化英语、判定表和判定树。 系统的分析模型必须达到三个主要目标： （1）描述客户的需要； （2）建立创建软件设计的基础； （3）定义在软件完成后可以被确认的一组需求。