软件需求分析学习日记（一）需求工程概述

1.1需求工程的重要性

1.1.1几点说明和描述

• 在软件工程项目中，所有的利益相关者都感兴趣的就是需求分析阶段。
• 需求分析奠定了软件工程和项目管理的基础。
• 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向对象、面向机器和其他软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
• 需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。优秀的软件产品是建立在优秀的需求基础之上的，不重视需求过程的项目队伍将自食其果。
• 国内软件业痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。
• 容易忽略需求重要性的地方：问题广为人知（电梯调度）和问题小而简单（出错也无所谓）。
• 许多问题源于未能协调那些不一致的需求。
• 缺乏健壮性的需求规格说明可能导致无法继续进行系统的实现。
• 项目失败或严重超支的8个最重要原因中有5个都与需求相关：需求不完整，缺乏用户参与，客户期望不实际，需求和需求规格说明变更，提供许多不必要的功能。当项目失败时，需求问题通常正是核心问题。
• 需求分析可以帮助开发人员真正理解业务问题。
• 需求分析是估算成本和进度的基础。
• 需求分析可以避免建造错误的系统，从而减少不必要的浪费。
• 需求规格说明有助于开发人员与客户在“系统应该做什么”问题上达成正式契约。
• 需求分析形成了软件开发的基线，有助于管理软件的演化和变更。
• 需求分析是软件质量的基础，为系统验收测试提供标准。

1.1.2不适当的需求过程所引起的风险

• 无足够用户参与导致最终产品无法被用户接受。
• 用户需求的增加带来过度的耗费和降低产品质量。
• 模棱两可的需求说明可能导致时间的浪费和返工。
• 用户增加一些不必要的特性和开发人员画蛇添足。
• 过分简略的需求说明以致遗漏某些关键技术，并使得项目计划和跟踪无法准确进行。
• 忽略某些用户的需求将导致众多用户的不满。

1.2什么是软件需求

1.2.1软件需求的定义

1. 对于软件需求的定义，不同的研究人员有不同的看法:
   ①(A.Davis)软件需求是从软件外部可见的、软件所具有的、满足于用户的特点、功能及属性等的集合。
   ②(I. Sommerville)需求是问题信息和系统行为、特性、设计和实现约束的描述的集合。
   ③(M.Jackson)需求是客户希望在问题域内产生的效果。
2. 产生不同定义的原因:
   ①需求工程发展过程还不太长，人们的认识还在不断深入
   ②“需求”是人们的脑海中形成的，很难给予准确的定义。
3. IEEE软件工程标准词汇表中的定义：
   ①用户解决问题或达到目标所需的条件或能力。
   ②系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
   ③一种反映上面①或②所描述的条件或能力的文档说明。
   其中，①是从用户的角度定义的，②是从软件系统的角度定义的。

1.2.2关于需求的几种错误认识

①在需求上耗费多少时间就会导致产品开发推迟多少时间。
②客户不懂技术，说不出他们想要的新系统/产品是什么样的，所以只有我们开发人员自己来定义需求。
③我们开发组的人员都清楚需求是什么，不用写需求文档，而且写出来别人也看不懂，干脆我们直接设计或尽快编写出代码就行了。
④无需设定需求优先级，我们在交付产品时会完成全部的需求，这样才能使客户感到满意。

1.2.3存在向题的需求描述实例

①含糊的需求描述:
“工资总额由上一条记录获得”
“所有客户都具有同一控制域”
②错误的需求描述:
“所有系统将九月作为财政年度的起始时间”
③不完整的需求描述:
“出错信息显示在屏幕的第24行”
④矛盾或不一致的需求描述:
“C=A+B”;“C=A-B”
⑤无法测试的需求:
“系统应具有友好的界面”

可能的需求来源

①客户专有需求
对于有着明确问题的特定客户，最终客户享有决定权。 ②市场需求
对于在市场上广泛出售的产品，营销团队扮演着顾客和用户代表的角色，产品必须拥有顾客。
③社会需求
系统的目的是造福社会，而不需要客户(支付报酬)。
一些开源/自由软件，科学研究软件
④综合
为特定客户开发，但最终希望面向市场的软件。

1.3软件需求的分类

1.3.1目标需求

①反应组织机构或客户对系统和产品提出的高层次的目标需求，其限定了项目的范围和项目应达到的目标。
②文字处理系统
用户使用系统能够有效地纠正文档中的拼写错误，系统能满足用户的业务要求以及提高用户的工作效率。

1.3.2业务需求

①主要描述软件系统必须完成的任务、实际业务或工作流程等。软件开发人员通常可以从业务需求进一步细化出具体的功能需求和非功能需求。
②文字处理系统
当找到文档中拼写错误时，通过可供选择的单词表，选择单词表中的一个单词后，替换原来的单词。

1.3.3功能需求

①指开发人员必须实现的软件功能或软件系统应具有的外部行为。
②文字处理系统
查找文档中的单词，并高亮度的显示出错的单词。用对话框显示可供选择的单词表，实现整个文档范围内的替换。

1.3.4性能需求

①指实现的软件系统功能应达到的技术指标，如:计算效率和精度、可靠性、可维护性和可扩展性等。
②文字处理系统
检查单词的速度快，准确率要求达到99%，系统的有较高的有效性和可靠性等。

1.3.5约束局限性

①指软件开发人员在设计和实现软件系统时的限制，如:开发语言、使用的数据库等。
②文字处理系统
文件内部格式要与Word系统一致。 开发平台为Linux系统，使用C语言等。

1.4需求规格说明

1.4.1几点描述

①需求规格说明也称需求规约或功能规格说明，是需求工程的最终产物。
②需求规格说明是软件所应满足的全部需求，并可用文档化的方式完整和精确地陈述这些需求。
③需求规格说明是项目相关人员对将要开发的软件系统所达成的共识，是进行系统设计、实现、测试和验收的基本依据，也是整个软件开发过程中最重要的文档。
④需求规格说明应该精确的描述系统必须提供的功能和非功能，以及所要考虑的约束条件和限制。

1.4.2高质量的需求规格说明具有的特性

①完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。
每项需求都必须将所要实现的功能描述清楚。
开发人员可以从需求规格说明中获得设计和实现这些功能所需的所有必要信息。

②正确性
每一项需求都必须准确地陈述其要开发出的功能性。
只有用户代表才能确定用户需求的正确性，这就是为何一定要有用户的积极参与的原因。
没有用户参与的需求只是评审者凭空猜测。

③可行性
每一项需求都必需是在已知系统和环境的权能和限制范围内可以实施的。
最好在获取需求过程中，始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他来负责技术可行性上的检查。

④必要性
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。
“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”
要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

⑤划分优先级
给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。
不划分优先级，将导致项目管理者在开发或节省预算或调度中就丧失控制自由度。

⑥无二义性
对所有需求说明的读者都只能有一个明确统一的解释。
尽量把每项需求用简洁明了的用户性的语言表达出来。
避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

⑦可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。
如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。
一份前后矛盾，不可行或有二义性的需求也是不可验证的

1.5需求工程定义

1.5.1几点描述

• 需求工程是系统工程及软件工程的重要分支。
• 需求工程旨在了解软件系统设计的真实意图，具体功用及限制条件。并精确定义上述因素与系统行为的关系及系统随时间和产品线变化而发生的各种演化。
• 需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
• 需求工程是应用工程化的方法、技术和规格来开发和管理软件的需求。
• 目标:获取高质量的软件
• 与传统的需求分析概念相比，需求工程突出了工程化的原则，强调以系统化、条理化、可重复化的方法和技术进行与软件需求相关的活动，从而有利于提高所有与软件需求相关的活动及其过程的可管理性，降低需求开发和管理的难度和成本。
• Alan Davis:直到(但不包括)把软件分解为实际架构构件之前的所有活动
• BrayI. K:对问题域及需求做调查研究和描述，设计满足那些需求的解系统的特性，并用文档给予说明
• 需求工程的任务就是获取、分析和表达软件的需求。
• 软件需求工程应该是由一系列与软件需求相关的活动
  组成的，主要包括需求的开发活动和需求的管理活动。

1.5.2需求工程VS系统分析

• 需求工程由系统分析发展而来
• 需求工程超出系统分析的范围

1.5.3描述——需求工程的核心

• 用非形式化的语言指出感兴趣的主题现象，并命名(designation)。 例如:
  Parent (x, p): p是x的父母。
  Female(x): x是女性。

• 术语的形式化定义(definition)和使用。 例如:
  Mother(x,m) = Parent(x,m) and Female(m)
  Sister(x, y) = Female(y) and mother(x,m) and mother (y,m) and father(x,f) and father(y, f)

• 关于领域性质的无可驳的描述(refutabledescription)。无可驳性依赖于与主题现象的一致性。例如:
  对所有的m和x，Parent(x, m)蕴含not(parent(m,x))

• 开发过程中的带有假设性质的概略描述(rough sketch)。 例如:
  “人与人之间总是通过某种方式相互联系”
  “每个人实际上只能有一一个家”

• 补充：

1.5.3需求工程的任务

• 确定待开发的软件系统的用户类，并获取他们的需求信息
• 分析用户的需求信息，并按软件需求的类型对这些需求类型进行分类，同时，过滤掉不是需求的信息。
• 根据软件需求信息建立软件系统的逻辑模型或需求模型，并确定非功能需求和约束条件及限制。
• 根据收集的需求信息和逻辑模型编写需求规格说明及其文档。
• 评审需求规格说明。
• 当需求发生变更时，对需求规格说明及需求变更实施进行管理。

1.5.4需求工程指南

• 如何获取需求信息?
  ①识别:风险承担者，目标，分析角度，系统边界，应用实例，…
  ②核心技术:
  座谈，问卷，代表会议
  采用人种学方法(社交嵌入系统)
  采用原型法，或参与设计法(缺乏了解的系统)

• 如何分析需求信息?
  概念建模

• 如何就需求达成共识?
  ①进行经验主义的模型验证
  ②当出现矛盾和分歧时，提供磋商的方法和手段

• 如何表达需求?
  自然语言与形式化语言的合理搭配

• 如何保持需求的现时性?
  ①需求发生变化时，及时更新
  ②产品线的维护

1.5.4需求工程的理论基础

• 系统理论
  ①什么是系统
  ②系统的控制和演化

• 系统工程
  工程生命周期

• 数学与逻辑
  ①一阶逻辑
  ②模态逻辑，时序逻辑，及其他非经典逻辑
  ③代数和关系模型

• 计算机科学
  ①自动机理论
  ②抽象，分解，和面向对象
  ③软件体系结构和设计模式

• 杜会科学
  ①人类学与民族方法学
  ②组织行为学
  ③社会心理学
  ④政治学

• 认知科学
  ①认知心理学
  ②语言学.
  ③知识表示(人工智能)

• 哲学
  ①经验主义和科学哲学
  ②现象学，认识论和本体
  ③符号语言学
  …

1.6其他一些基本概念

• 用户
  ①利用计算机系统所提供的服务的人
  ②直接操作计算机系统的人，就是直接使用软件系统的人

• 客户
  ①掌握经费的人，通常有权决定软件需求。客户可以是用户，也可以不是用户。
  ②正式接受新开发或修改后的硬件和软件系统的某个人或组织.

• 软件开发人员
  为客户开发软件系统的人

• 项目相关人员(利益相关方)
  提出和定义软件需求相关的人，包括所有用户、客户和软件开发人员