需求分析：高质量军用软件开发的关键过程
需求分析：高质量军用软件开发的关键过程
黄锡滋 陈光宇
软件项目开发的需求分析和定义阶段处于软件寿命周期的早期，对项目实施具有关键性影响。需求定义的任何失误，必然严重影响项目的费用、进度和质量，后果具有全局性，远比在设计或编码阶段引入的技术错误严重得多，必须给与更多的关注。
一、 美国军用软件需求分析中常见的问题
从众多公开发表的文章上可以看出，美国军用软件项目开发中，需求分析和定义存在诸多令人困惑的问题，这些问题包括：
1. 大多数交付使用的软件，约有一半的功能，从未使用；
2. 大多数系统和软件项目的投入，有一半以上纯属浪费；
3. 用户提供给开发方的需求清单不能反映真实的需要；
4. 系统测试阶段发现的需求错误，80%是由不正确的需求或遗漏的需求造成；
5. 需求文档充满错误，没有及时发现和改正；
6. 项目主管对需求分析和定义的基本原理和重要性缺乏认识，忽视对需求的投入；
7. 在忽视需求投入的同时，项目主管将巨大的人力，资金投入测试，陷入认识误区。
8. 项目主管忽视需求管理和分析人员的培训，需求管理和分析人员技术水平不能满足项目要求。
9. 缺乏有效的需求分析工具支持需求分析和需求管理。
二、 改进需求分析提高开发质量的基本经验
针对存在的问题，众多软件工程专家，根据实践经验，提出下列各项应对处方。
1. 必须确保项目开发部拥有经过培训的，有经验的需求管理和分析人员，项目开发部的全体人员不论承担何种具体工作，都应对需求分析提供支持和帮助。
项目开发部不能仅仅要求技术主管熟悉需求工程，而且还需要拥有具有相当技术水平，数量足够的管理和分析人员，这些管理和分析人员应该由初级，中级和高级技术水平的人员构成（见表1），Robert Halligan 认为需求工程的头号问题是项目经理无法获得足够的经过培训的需求分析人员
2. 及早与用户建立合作伙伴关系，加强相互联系和沟通。项目主管应该将各个利益相关方对项目目标预期和使用范围，编写成文件，在相关方广泛传阅，征求意见，以利达成共识。在需求分析定义完成后，检查相关的需求文件，避免或减少需求错误。根据NASA的统计，在软件发布后发现的需求错误，49%来源于需求与实际情况不符，31%来源于实际需求遗漏。
表1. 需求分析人员技能矩阵表
3. 使用已经证明有效的需求导出技术，导出和确定需求，例如专题研讨会、程序原型和其他可以形象表达的方法，其中专题研讨会和程序原型最
为有效。如果不采取这些方法，仅按照用户提供的需求清单开发软件，据统计出现返工的概率高达到45%。
4. 关注需求过程资源投入。据统计美国军用软件产业，平均用3%的项目费用投资于需求过程。NASA指出如果需求过程投资能够增加到8-14%，则项目获得更低成本和更快进度的概率必将大增。
5. 采用增量或渐进方法，开发部署和执行软件需要的能力。在需求改变无法避免的情况下采用增量开发（即螺旋开发）可以降低开发费用损失，适应不断变化的外部需求，为用户快速提供急需的功能（见图1）。同时需要建立有效的机制，掌握和控制需求变化和新需求。
图1. 增量开发图
6. 使用有效的自动需求工具，跟踪，维护有关需求信息。Dr. Ralph R. Young 提出需要为项目需求建立专用信息库，记载和提供：
需求来源；
需求识别码；
需求优先度；
实现需求所需的费用或费用高低的等级；
各个需求满足'需求标准'的程度（见本文第3节）；
需求的基本根据；
需求变化历史；
需求的可跟踪性；
需求处置状况（草稿，正稿，报批，悬挂，已批准，未批准）；
实现该需求的系统部件。
7. 及早关注需求相关的风险，制订应对方案。常见的需求风险包括下列类型：
1）变化的需求；
2）不完备的或遗漏需求；
3）不清楚的需求；
4）无效需求；
5）不可行需求；
6）最新的，从未提出和实现的需求；
7）不适当的界面定义；
8）非验证需求；
9）不正确分配的需求；
10）不能跟踪的需求。
三、 合格需求的标准
合格需求的标准概括如下：
1. 必要性：如果没有这项需求，系统仍然能够满足经优化的实际需要，则该项需求是不必要的；
2. 可行性：在可用的费用和时间约束下，该项需求是可以实现和运行的；
3. 正确性：与需求有关的事实是准确的，需求在技术上和法律上是可能实现的；
4. 简明性：需求的描述应该简单明瞭；
5. 无歧义性：各项需求只有唯一的一种解释方法；
6. 完全性：需求应用的全部条件，都得到陈述；
7. 可验证性：需求在系统运行中可以得到验证；
8. 可跟踪性：需求的起源，设计，编码，测试和文档是可跟踪的；
9. 可分配性：需求可以分配到系统的部件，加以实现；
10.设计独立性：需求不应该仅有一种唯一的解决方案；
11.无冗余性：需求不应该重复；
12.使用标准结构陈述：使用命令式语气，采用词汇Shall陈述；
13.具有唯一的识别码：每个需求拥有唯一的标识数码。
14.无不确定词汇：不能使用含义不确定的词汇，例如if, when, but, except, unless, usually, generally, often, normally, and typically。
参考资料：
1. Young, Ralph R. Effective Requirements Practices. Boston: Addison-Wesley, 2001
2. Alexander, Ian F., and Richard Stevens.Writing Better Require
3. Young, Ralph R. The Requirements Engineering Handbook. Boston: Artech House, 2004.
4. Hooks, Ivy F., Customer-Centered Products: Creating Successful Products through Smart Requirements Management. New York:The American Management Association, 2001.
5. Young, Ralph R. "Recommended Requirements Gathering Practices." CrossTalk Apr. 2002
6. Young, Ralph R. "Project Requirements: A Guide to Best Practices." Vienna, VA: Management Concepts, 2006.
7. Ralph R. Young "Twelve Requirements Basics for Project Success" CrossTalk Dec. 2006