一种快速需求分析方法

摘 要：软件需求分析是软件工程的重要一环。现有软件需求分析方法还没有在避免由于使用自然语言可能产生的二义性和避免仅使用一般人不易理解的软件需求分析工具上令人满意。为此，利用自然语言和必要的图形实现了二者的兼顾。该方法适用于需求获取和早期需求分析，也能与其它建模工具一起使用。

关键词：软件需求分析；二义性；建模工具；快速需求分析方法；需求获取

0 引言

需求分析是软件工程的首要阶段，软件工程失败与需求分析在完整性、准确性、可验证性及一致性等方面的缺陷有较高相关性。需求分析不足可能表现在以下几个方面：①用户对自身需求比较模糊；②非核心需求过度膨胀；③需求完整度较难把握，用户需求经常变动；④需求分析不够详细，需求文档描述的多义性，使后续工程理解偏离；⑤忽视用户的行业特点与文化程度，没有挖掘用户的核心需求；⑥需求分析的时间不足，等等。

常见的需求分析方法有3种：问题分析法、界面原型法以及可运行原型系统法。按方法的特点来分，有形式化的、非形式化的和基于知识表示的需求分析和规格说明技术。形式化方法可以严格地描述所开发的软件功能，既减少二义性，又可以自动对需求分析进行推理验证，实现软件分析的自动化。但形式化方法往往难以掌握,且不易理解以及难以和用户沟通,目前应用还有局限性。非形式化方法采用了易于掌握的分割、抽象、投影等适合处理复杂问题的策略,尽管还存在某些不足或缺陷, 但在当前软件开发中仍然是广为使用的需求描述机制。基于知识表示的分析和规格说明方法是专家系统在软件需求工程中的一项应用，但是前期要由专家组进行知识的整理和合理表达，对一般软件工程准备期较长。每种方法都有其优缺点，很多情况下，软件开发项目组会根据项目的具体情况主要使用一种或同时几种分析方法。如赵占梁等在中采用尝试通过自然语言逻辑形式和语言形式加以一定的限制来减少其歧义性，增强其准确表达能力；罗慧慧结合自然语言处理技术,对需求分析辅助生成方法进行了研究,给出了一个能将受限汉语书写的需求分析报告自动转换成符合国家标准的软件需求规格说明书的系统；倪世道在中提出一个系统的基于知识支持和面向目标建模分析方法GONFR。

1 快速需求分析方法概述

针对上节提到的需求分析不足的几类表现，结合国内软件开发业的实际，本文从实践的角度提出了一种快速需求分析方法。这种方法旨在消除使用自然语言的需求分析说明书的二义性，又避免了一些工具软件偏向软件开发人员的缺点。其核心思想是使用包含专业术语的自然语言和原形界面设计相结合的模式，快速完成需求分析，缩短整个软件开发周期。该方法分为四个阶段，分别是需求预获取阶段、初次交流阶段、扩充交流阶段和需求验证阶段。需求预获取阶段先了解用户行业需求和单位特点，提出预想需求；然后与开发团队内部交流。初次交流阶段则是把预想需求与用户代表面对面交流，取得用户的修正意见；接着把用户意见反映到需求说明书和原型界面运行系统中，与开发团队内部交流，同时开展后续设计、开发。扩充交流阶段是把用户意见、团队的取舍加入需求分析中，再次与用户进行详细交流。需求验证阶段由用户、项目组、评审人员参加，确定用户最终需求，并对需求合理性进行验证。至此，在短时间内完成了2～3次需求分析的迭代，需求分析完成，部分模块已经进入设计或开发阶段。

2 具体实现

2.1 需求预获取阶段

（1）需求分析员以项目开发意向为基础，了解用户所属的行业、单位初步情况、用户单位的高层次及一些特定需求。根据用户所属行业查阅该行业的相关规范，了解该行业业务流程，查找该行业成功的软件开发案例及需求分析说明书。这样就从内外两个方面粗略地获取该单位的工作运行模式和企业部分特色。从系统完整性设计思路出发，将用户行业、单位的一般性需求作为骨架，根据用户特色需求合理地补充、预想用户可能的需求细节，把这两方面结合起来，形成一个与用户行业标准或规范匹配的《用户需求分析说明书》，并根据该说明书制作一个可演示的原型界面系统。

（2）与项目团队进行交流。目的有两个，一是让项目团队的经理、系统分析师（架构师）、程序员等对用户项目有前期的了解，二是根据《用户需求分析说明书》和原型界面运行系统，探讨项目难点、人员、工期、可利用模块等问题，还要涉及可能遗漏的功能性和非功能性需求。完善后进入第二阶段。

2.2 初次交流阶段

（1）需求分析员与用户代表（最好包含决策者），就原型界面运行系统和《用户需求分析说明书》初稿进行面对面交流。首先概述系统的整体功能、结构层次、特色，接着主要通过原型界面运行系统的图形化展示，分层次地讲解系统各项功能和性能指标，可边讲边讨论，重点记录用户对软件系统的理解、修改意见及补充要求。同时收集用户方的相关文档。交流结束前，整理出用户的修改意见和补充要求文档，并取得用户的认可。

（2）了解了用户需求的细节情况后，经整理和提炼，把形成的修改意见分别加入到原型界面运行系统和《用户需求分析说明书》，再次与项目团队交流。实现3个目的，一是让项目团队成员对用户项目有进一步的理解；二是在人员和工期确定的情况下，去除无法完成的功能和部分非重点需求，并给出合适的理由，以利于取得用户方理解；三是促使项目团队根据修正的《用户需求分析说明书》和原型界面运行系统，进行后续设计，开展技术攻关和部分模块开发。把内部会议的结果完善，反映到《用户需求分析说明书》和原型界面运行系统，然后进入第三阶段。

2.3 扩充交流阶段

（1）需求分析员及相关人员再次与用户代表（包含上次参加者），就补充了用户意见和项目团队理解的原型界面运行系统和《用户需求分析说明书》进行交流。着重阐述开发后系统的整体功能、结构层次等方面的修改情况和各项功能、性能指标的变化，然后诚恳地向用户解释去除的部分模块和功能，取得用户方理解，进一步挖掘用户的细节需求，记录用户对软件系统的补充修改意见，整理成文档，取得用户认可。

（2）经过此次交流，用户需求细节基本掌握，用户修改意见分别加入到原型界面运行系统和《用户需求分析说明书》，然后与项目团队进行交流，确定项目的大部分细节需求，进行详细设计、编程。

2.4 需求验证阶段

（1）整理好《用户需求分析说明书》，编写《需求分析规格说明书》，完善原型界面运行系统。与用户进行第三次交流，包括需求的验证与确认，除用户方、项目开发方之外，还需邀请评审人员。原型界面运行系统形象反映了软件系统部署后的功能和性能指标，《用户需求分析说明书》和《需求分析规格说明书》作为原型界面运行系统的辅助发挥作用。需求验证的关键是需求分析有没有真正反映用户的需求、完不完整，而不是某些学者强调的需求分析与详细设计是否一致，后者是项目团队内部的事。图文并茂的模式能够较好地验证用户的需求，也有助于双方就需求达成一致，从而在完成需求验证的同时，确定用户最终需求。

（2）按照需求验证的规范，完善验证文档需求。验证文档经三方签字认可，需求分析阶段就基本结束了。《用户需求分析说明书》、《需求分析规格说明书》和原型界面运行系统作为需求分析的最终材料伴随软件的设计、开发、测试与集成。

另外，如果在第二阶段交流中用户提出的补充需求较少，那么第三阶段和第四阶段可以合并。上半段进一步挖掘用户的细节需求，快速完善进原型界面运行系统和相关文档，下半段邀请评审人员进行需求验证。

3 举例

某单位做商务公开网站，项目组首先收集与该单位相关的文件和网站信息，利用UIDesigner设计如图1的第一版功能界面（由于篇幅所限只展示首页面），该界面可进行模拟操作，同时配以《用户需求分析说明书》。然后与单位用户代表结合，用户代表由单位分管领导、纪委、组织科、职工代表组成。项目组充分采纳了各方建议，比如党务公开等栏目在首页面取消tab页、主要显示更新及重要内容、详细分类移至二级页面等。项目组迅速做出第二版（如图2），经第二次讨论，当场修改首、二、三级页面和具体功能、性能指标，取得用户单位认可。接着就进入了实际开发。

4 特点及合理性分析

软件工程逐渐从顺序的过程向开发过程的流水线（如敏捷开发方法）过渡，快速需求分析方法实现了需求分析、设计与编程的部分并行。本方法还有以下三个特点：①既有效去除自然语言的二义性，又有利于双方交流；②原型界面运行系统一直作为软件开发的参考，减少转换环节中理解的走形；③兼容性强，可以与多种设计或开发方法结合。下面就方法的合理性进行分析。

4.1 去除自然语言的二义性

一般用户对软件工程比较生疏，这也造成用户方很难拿出项目的完整需求。一些软件工程行业的需求分析及设计工具对需求分析的挖掘和合理细化相当有效，但它们对一些程序员新手来说都有难度，让用户在短时间内掌握基本不可行。即使经过培训，用户也无法像软件工程设计人员那样熟练使用工具、完整地表述自己的需求。问题产生了：用户不愿使用特定工具，倾向于使用自然语言，项目组为了去除自然语言的二义性而推荐使用特定工具。这将引起交流不畅，导致需求分析的反复、拖延。能不能找出一种方法既能让用户积极参与，又能去除自然语言的二义性呢？［3］和［5］讨论的方法都需要进一步的规范，取得行业的认可，并取得用户和项目组的认可，这对于一般的软件开发项目前期准备工作难度较大。本文提出的方法从可运行的图形和文字及流程说明文档两方面出发，两方面相互限制、相互验证。可运行的图形有利于用户的参与，文字及流程说明文档便于后续的设计与开发。由于图文并茂，二义性产生的概率大大降低。经少数几次迭代后，就能快速、较完整地引导挖掘出用户实际需求。避免了用户学习特定工具产生的延期和表达的不准确，同时也降低了项目团队成员对项目理解和把握的难度。

4.2 预测用户需求的可行性

用户所在行业有成熟的行业规范，用户单位也有规定的业务流程，这些都是需求要抓的共性。用户的合理需求不会偏离共性太多。项目合作意向中提供的高层次及一些特定需求给预测用户的需求提供了更细节的信息。在工作、生活实际中我们处处面临决策，都是依据少量信息作出预判。因此需求分析员能根据共性、个性加上自己的经验与预想，做出第一版需求分析。项目团队对项目需求的理解和对软件系统的形象化描述，有利于引导和激发用户的需求。从认知角度看，一个人愿意与知音进行交流，没人乐意对牛弹琴；对一个成型的东西，特别是图形图像，让合作者去指出哪些地方要不要、应该如何改，比让他自己设计难度要低得多；用户看到了接近最终交付物的界面系统，心中有底。

4.3 促进软件工程的并行

需求分析员每一次与用户、与项目团队的交流，都是围绕着原型界面运行系统《用户需求分析说明书》和《需求分析规格说明书》进行，也就是围绕逐步接近用户实际需求的材料来进行。由于原型界面运行系统是用户和项目团队越来越认可的对最终交付物的描述，而前述论证中提到的行业共性使得部分功能模块可以提早进行设计，并便一些技术难点能够尽早懂到确定和攻克。在需求分析进程中，逐步地深入设计和编程基本不会造成时间的浪费，因为用户需求是在需求分析员和项目团队引导下形成的，框架和基本需求在项目团队的掌控中。如果以前开发过类似的项目，则可复用部分设计及代码。

4.4 原型界面运行系统避免软件走形

由于始终有原型界面运行系统作为参照，又有需求分析相应文档的指引，从系统设计、编程、测试到集成、交付，最终交付物必须完整地实现原型界面运行系统，并且要从功能、性能上有提升，也就是最终交付物“≥” 原型界面运行系统。相当于需求分析一直伴随软件开发的全过程，这正是软件工程最核心的要求，也是许多软件开发项目中容易忽略的地方。

4.5 与多种设计或开发方法结合

本方法没有限定详细设计、编程等具体方法，因此在软件开发实践中，只要遵循本方法的基本原理，通过《用户需求分析说明书》、《需求分析规格说明书》和原型界面运行系统使用大多数设计与开发工具均可。

5 结论

本文提出的方法既消除了需求分析中使用自然语言造成的二义性，又避免了一些工具软件偏向软件开发人员的缺点，促进了软件开发过程的部分并发，有效缩短了需求分析和软件开发周期，在规范性自然语言未取得编程行业及专业领域普遍认可的情况下，成为一种较为实用的快速需求分析方法。本方法在一定程度上吸收了敏捷开发的思想，又可以应用于传统开发模式和面向对象程序设计模式。但该方法把任务更多地压在了需求分析员身上，需要这个角色具有从用户角度思考问题的立场、积极获取并理解用户行业规范的能力、一定的预测能力、较高的沟通水平、奉献精神。该方法也有待于在实践中继续完善。

参考文献：

\[1\] 蒋海昌.降低软件需求分析风险之探索［Ｊ］.计算机时代，2010（10）.

［2］ 王晓宁.关于如何做好软件需求分析的探讨.科技资讯［Ｊ］.2010（34）.

［3］ 王迅冉，王春霞.基于Z语言的形式化需求分析［Ｊ］.商丘师范学院学报,2007(3).

［4］ 蔡文青,常浩娟,秦怀斌.软件需求分析作为过程实现［Ｊ］.福建电脑,2007（10）.

［5］ 罗慧慧.需求分析辅助生成系统的探讨与构建［Ｊ］.仲恺农业技术学院学报,2006(4).

［6］ 倪世道.基于知识和面向目标的非功能需求建模技术及工具的研究［D］.合肥:合肥工业大学,2002.

［7］ 赵占梁,刘铁林,龚传信.需求分析过程中规范性业务交流语言研究［Ｊ］.科学技术与工程,2007(11).