软件需求分析——需求工程导论

一：软件的需求问题

1.1：软件的发展

20世纪50年代，软件以机器为中心，主要内容为指令码、汇编语言、BIOS、批量事务处理、计算性任务等

20世纪60年代，软件以应用为中心，主要内容为3GL（第三代语言）、OOL、OS、Virtual Machine、基本业务处理、应用处理等

1968年北大洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”（software crisis）这个名词。软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题：

• 开发成本超出预期，实际进度比预定计划一再拖延
• 用户对“已完成”系统不满意的现象经常发生
• 软件产品的质量往往靠不住。Bug一大堆，Patch一个接一个
• 软件的可维护程度非常之低
• 软件通常没有适当的文档资料
• 软件的成本不断提高
• 软件开发生产率的提高赶不上硬件的发展和人们需求的增长

概括来说，软件危机包含两方面问题：

1. 如何开发软件，以满足不断增长，日趋复杂的需求
2. 如何维护数量不断膨胀的软件产品

解决方案：软件工程（以下来自于IEEE）

1. 应用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即将工程应用到软件
2. 对1中各种方法的研究

20世纪90年代，软件以企业为中心，主要内容为4GL、CBD（基于组件的开发）、Middleware、EAI（企业应用集成）、BPR、ERP等

从20世纪60年代到今天软件的发展之路可以被总结为如下几个关键点：

1. 个人为主的作坊式英雄主义时代
2. 面向复杂问题，实现大型软件可预测和提高软件可靠性的工程化开始阶段
3. 初步的基于组件要素工厂化生产阶段
4. 基于互联网和大数据技术新型开放软件开发平台

当前软件自主化面临的机遇与问题

• 机遇：
  • 开源已经变成一种普遍接受的观点
  • 网络的应用是一种无法阻挡的趋势，个别国家逆潮流的行为不会成功，只是会设置一点小的障碍
  • 经过多年的发展，我们已经在软件领域取得不少突出的成就，如tiktok的核心技术就是美国人希望购买的
  • 我们国家的制度优势让我们可以集中力量办大事，今天国家对软件行业的大力支持，举国上下的创新和创业的热情让美国这个世界信息技术最强国都感觉害怕
• 问题：
  • 自主软件生态的建立
  • 基础软件领域的薄弱
  • 专业人才培养的问题

当前主要的自主软件发展领域：

• 云计算
• 大数据
• 区块链
• 人工智能
• 工业互联网

我们最急需发展的领域：

• 工业软件
• 操作系统

1.2：软件生产状况调查

Standish Group 1995（1995年的一次软件生产状况调查）：调查了365家公司的8380个项目

• 成功项目（Success）：在预期的时间之内，在预算的成本之下完成预期的所有功能
• 问题项目（Challenged）：已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者时间的功能不全
• 失败项目（Impaired）：因无法进行而被中途撤销，或者最终产品无法提交使用

调查得出以下结论：

• 大公司开发项目的平均成本是232.2万美元，中等公司是133.1万美元，小型公司是43.4万美元
• 大约31%的项目在完成之前被取消，52.7%的项目成本是原来预算的189%
• 大公司9%按预算交付，小公司16%按预算交付

成功项目的影响要素	影响指数
用户参与	15.9%
高层管理支持	13.9%
清晰的需求说明	13.0%
正确的项目计划	9.6%
切合实际的期望	8.2%
细化的项目里程碑	7.7%
员工能力	7.2%
主人翁精神	5.3%
清晰的目标和前景	2.9%
努力工作	2.4%
其他	13.9%

问题项目的影响要素	影响指数
缺少用户输入	12.8%
不完整的需求说明	12.3%
需求变化	11.8%
缺乏高层管理支持	7.5%
技术能力不足	7.0%
缺乏资源	6.4%
不切实际的期望	5.9%
目标不清晰	5.3%
不现实的时间要求	4.3%
新技术的影响	3.7%
其他	23.0%

失败项目的影响要素	影响指数
不完整的需求说明	13.1%
缺少用户输入	12.4%
缺乏资源	10.6%
不切实际的期望	9.9%
缺乏高层管理支持	9.3%
需求变化	8.7%
缺乏计划	8.1%
额外的无用功能	7.5%
缺乏IT管理	6.2%
技术能力不足	4.3%
其他	9.9%

需求因素包括：

• 用户参与（用户输入）
• 高层管理支持
• 清晰的需求说明
• 切合实际的期望
• 清晰的目标和前景
• 需求变化
• 额外的无用功能

综合来看，需求因素：

• 对成功项目的影响指数为53.9%
• 对问题项目的影响指数为55.6%
• 对失败项目的影响指数为60.9%

ESPITI 1996(1996年的一次软件生产状况调查)：

• 欧洲软件协会ESI
• 欧洲软件过程改进培训计划项目ESPITI
• 17个国家的超过3800个组织
  

需求问题的典型案例（Bray2002）

• PROMS(演出权益协会），1992，未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周(与客户沟通的问题)
• RISP(西萨克斯地区信息系统计划）,1990，缺少清晰的项目范围定义（需求的边界问题)
• TAURUS(伦敦股票交易)，1993，未能协调不一致的需求（不一致需求的管理问题)
• LASDS(伦敦救护车服务派遣系统)，1992，社会服务领域糟糕的需求分析（需求不清晰)
• ATC(空中交通控制系统)，1998-2001，缺乏健壮的需求规格说明（需求没有搞清楚就匆忙开始工作)

近期的软件失效案例：

• 2004年4月，东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消一笔输错指令的交易，导致该公司蒙受了近2.5亿美元的损失；故障原因之一，对操作人员的错误行为的预期不充分
• 2008年6月30日，北京奥运门票系统在提交使用的当天即发生瘫痪;原因之一是对系统用户数的预测不足

二：需求问题的原因分析

2.1：应用软件的模拟特性

软件的三种类型：

• 应用型软件
  • 评判标准：功能的“模拟”性，使用的方便性、技术的可行性
  • 关注点：模拟性
  • 事例系统：MIS、EAI
• 纯工具型软件
  • 专业用户
    • 评判标准：功能的复杂性，使用的高效性，技术的先进性
    • 关注点：创新性
    • 示例系统：编程环境、DBMS
  • 普通用户
    • 评判标准：功能的有用性，使用的方便性，技术的可行性
    • 关注点：有效性
    • 示例系统：Office、语言翻译

软件的分析活动：

软件模拟性的实践调查

• Capers Jones[Capers1996]在调查了几百个公司之后发现超过75%的企业在需求处理环节存在不足。
• 2000年Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现[Nikula2000]：在以30分为标准线的情况下，75%的公司竟然在10分以下。
• Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程[Hofmann2001]。
• Juristo等人在对欧洲的150多名RE实践者进行调查后发现,在需求处理的诸多技术当中，需求获取和冲突协商的技术没有得到充分的应用[Juristo 2002]。
• 研究也发现当软件生产面临时间、市场等其他压力时，漠视“模拟”特性的情况就更为严重[Lubars1993，Francisco2003]

2.2：需求问题的技术原因分析

• 非技术性和社会性因素（组织机构文化、社会背景、商业目标、利益协商）
  • 关注软件系统和现实之间的互动效应。软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视
  • 解决方案和具体应用环境相关的。不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等
  • 单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的。面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商
• 结构化分析和面向对象分析具有一定的先天缺陷
  • 编程 => 设计 => 分析
  • 设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功
  • 需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标，即理解现实
• 以“企业”为中心的软件反应了软件规模日益扩大
  • 一方面提高了需求处理中非技术性和社会性因素的影响比重
  • 另一方面也进一步放大了传统技术在需求处理阶段的不适应性

需求错误的高代价性：

三：需求工程

需求工程是软件工程的一个分支

• 关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束
• 同时它也关注以上因素和准确的软件行为规格说明之间的联系
• 关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系

需求工程的基本活动：

需求工程与系统工程：

需求工程特性：

• 必要性
  • 软件开发是这样一个工程问题：利用通用的计算机结构，构建一个有用的软件系统来满足人们的某些目的
  • 计算机应用于现实世界的广泛性
    • 新的问题和新的解决方案
    • 定义问题就是需求工程的任务
• 重要性
  • 容易忽略需求工程重要性的地方
    • 问题广为人知：电梯调度、图书管理
    • 问题小而简单，出错也无所谓
  • Frederick Brooks[Brooks1987]：开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对他进行修改也极为困难
• 复杂性
  • 处理范围广泛：涉及世界和计算机世界
  • 涉及诸多参与方：客户、用户、领域专家、需求工程师、软件开发者、系统维护者等
  • 处理内容多样：功能需求、非功能需求、环境及其约束
  • 处理活动互相交织：需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的
  • 处理结果要求苛刻：正确性、完整性和一致性

四：需求工程师

4.1：知识要求

• 软件技术：尤其是软件建模与分析技术
• 认知学和社会学等方面的知识
  • 认知心理学
  • 人类学
  • 社会学
  • 语言学
• 哲学知识
  • 掌握涉众的信仰与理念（认识论）
  • 分析在现实中观察到的各种现象（现象学）

4.2：技能要求

• 专业技能：需求工程的相关知识
• 分析技能：抽象能力、整合能力、系统化思想
• 交流技能：交谈和提问的技巧、倾听的技巧
• 观察技能
• 建模技能
• 写作技能：文档组织能力、语言驾驭能力
• 创新技能：发现连用户都没有意识到的潜在需求
• 协调能力

五：小结

• 从20世纪60年代末期软件工程产生起，需求分析就一直是软件开发的重要主题
• 20世纪90年代的调查状况表明，单纯的需求分析已经不能很好的解决软件生产中的“需求”问题
• 应用型软件的模拟性和一系列的技术原因表明软件生产需要进行一个比需求分析更加复杂和完整的需求工程
• 需求工程是软件工程当中一项重要和复杂的活动，需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动

如果有兴趣了解更多相关内容，欢迎来我的个人网站看看：瞳孔的个人空间