软件需求分析

  文件类型：DOC/Microsoft Word  文件大小：11041字节

内容摘要：

第3章 软件需求分析
软件需求分析工作是软件生存期中重要的一步,也是决定性的一步.只有通过软件需求分析,才能把软件功能和性能的总体概念描述为具体的软件需求规格说明,从而奠定软件开发的基础.
软件开发人员在设计一个系统前,必须事先了解用户希望未来的系统能做什么,这项工作通常是由称为系统分析员(或税简称分析员)的人来承担的.分析员要认真了解用户的要求,细致地进行调查分析,把用户"做什么"的要求最终转换成一个完全的,精致的软件逻辑模型并写出软件的需求规格说明,准确地表示用户的要求.而用户则只是对软件功能和性能提出初步的要求,并澄清一些模糊概念.
3.1 需求分析概述
3.1.1 需求分析的任务
准确,完整和规范化的软件需求是软件开发的成功关键.染件项目中40%～60%的问题都是在需求阶段埋下的祸根.在产品需求分析过程中出现的方 法和步骤上的事物,包括信息收集不全,功能不明确,需求文档不完善等,都可能造成软件开发中的困难.那么,需求分析要完成什么任务,如何来进行需求分析呢
通常软件开发项目是要实现目标系统的物理模型,即确定待开发软件系统的系统元素,并将功能和数据结构分配到这些系统元素中.但是目标系统的具体物理模型是有它的逻辑模型经实例化,即具体到某个业务领域而得到的.作为目标系统的参考,需求分析的任务就是借助于当前系统的逻辑模型,解决目标系统的"做什么"的问题.其实现步骤如图3-1所示.
图3-1 参考当前系统建立目标系统模型

需求分析阶段研究的对象是软件项目的要求.一方面必须全面理解用户的各项要求,但又不能全盘接受,因为并非所有的用户要求都是合理的,对无法实现的要求应向用户作充分的解释;另一方面要准确地表达所接受的用户要求,只有经过确切描述的软件需求才能成为软件设计的基础.
3.1.2 需求分析的步骤
必须在分析中采取合理的步骤,才能准确的获取软件的需求,产生符合要求的SRS.整个需求分析一般分4个步骤进行:问题的认识,评价与综合,规格说明和复审.
1. 问题的认识
首先,软件分析员将研究系统规格说明(如果有的话)和软件计划.主要是要从系统的角度来理解软件并审查用来产生计划估算的软件范围是否恰当.确定对目标系统的综合要求,即软件的需求.并提出这些需求实现条件,以及需求应到达的标准.也就是解决要求所开发软件做什么,做到什么程度.
系统需求包括用户对软件功能的需求和界面的需求.为了收集到全面完整的信息,需将客户按使用频率,使用特性,优先级等方面进行分类,每类选择若干用户代表,从代表那里收集他们希望的软件系统功能,用户与系统间的交互和对话方式等需求.在确定功能需求之后,还需考虑对质量的要求,包括性能,有效性,可靠性和可用性等,提高用户对软件的满足程度.如果客户的要求和已有产品很相似,则需考虑可否复用一些已有的软件组件.表3-1简要列举了一些在软件需求分析时,应当考虑到的非功能性需求.很显然,任何一个软件的非功能性需求都要根据其类型和工作环境来确定.
表3-1 软件的非功能性需求
目
标
系
统
的
限
制
性能
实时性
其他的时间限制
资源利用,特别是硬件配制限制
精确度,质量要求
可靠性
有效性
完整性
安全/保密性
安全性
保密性
运行限制
使用频度,运行期限
控制方式(如本地或远程)
对操作员的要求
物理限制
系统的规模等限制
开
发
和
维
护
的
限
制
开发类型(实用型开发或试验型开发)
开发工作量估计
在采用具有试验型的累进开发法时,对资源,开发时间及交付的安排
开发方法
质量控制标准
量程碑和评审
验收标准
优先性和可修改性
可维护性
此外,要建立从事分析工作所需要的通信途径,以保证顺利地对问题进行分析.分析所需的途径如图3-2所示.分析员必须与用户,软件开发机构的管理部门,软件开发组的人员建立联系.项目负责人在此过程中起协调人的作用.分析员通过这种通信途径与各方商讨,以便能按照用户的要求去识别问题的基本内容.
图3-2 软件需求分析的通信途径
2. 评价与综合
问题评价和解的综合是分析工作的第二个重要方面.分析员必须求得信息的流程与信息结构,制定所有软件功能的细节,同时,还要确定系统的接口特性并找出设计的约束条件.上述每一个任务都是用来描述所给出的问题,这样就可以综合出该问题的总的解决办法.例如,一个主要的水管供应商需要配置一个库存量控制系统.分析员发现,就现行的人工系统而言,存在的问题有:
(1) 不能迅速地得到某一部件的当前情况;
(2) 更新卡片文件需要有二天或三天的工作周期;
(3) 由于没有办法把供应厂家与部件联系起来.
因而往往需要向同一厂家多次再订购.得出这些问题以后,分析员开始综合出一个或几个解决办法.一个联机终端系统将可以解决一些问题,不过它是否已经超出软件计划所规定的范围了呢 一个数据库管理系统也似乎是需要的,然而,用户-需求者要把厂家与部件相联系的要求是否适当呢 ……,对问题进行评价和综合的过程将一直持续到分析员与需求者双方都感到有把握恰当规定该软件的要求,以便进入开发阶段.
3. 规格说明
软件需求规格说明必须用统一格式的文档进行描述.为了使需求描述具有统一的风格,可以采用已有的且可满足项目需求的模版,例如在国际标准IEEE标准830-1998(IEEE-1998)中和中国国家推荐性标准GB 9385中描述的SRS模版,也可以根据项目特点和软件开发小组的特点对标准进行适当的改动,形成自己的SRS模版.
为了让所有的项目相关人员明白SRS中为何提出这些功能需求,应该指明需求的来源,例如来自客户要求,或是某项更高层系统需求,或业务规范,政府法规,标准或别的外部来源等.
最好为每项需求都注上标号,以便对需求进行跟踪,记录需求的变更,并为需求状态和变更活动建立度量.
4. 评审
由分析员提供的软件需求规格说明初稿往往看起来觉得是正确的,实现时却出现需求不清,不一致等问题.
为保证软件需求定义的质量,评审应以专门指定的人员负责,并按规程严格进行.评审结束应有评审负责人的结论意见及签字.除分析员之外,用户,开发部门的管理者,软件设计,实现,测试的人员都应当参加评审工作.通常,评审的结果都包括了一些修改意见,待修改完成后再经评审通过,才可进入设计阶段.图3-3给出了需求分析阶段工作的流程.
图中有效性准则,主要是指性能界限,测试种类,期望的软件响应及其他特殊考虑等.
图3-3 软件需求分析工作的流程图
3.1.3 需求获取的常用方法
需求获取是需求分析的第一步,目的是使开发人员全面准确地了解用户的需求.初学者可能认为,需求获取的手段无非是调查研究,只需多问多看即行.殊不知开发者和用户之间交流与理解,是一条曲折不平的道路.虽然双方都希望开发获得成功,但双方地都希望控制事情的进程,双方的意图和说话都可能被对方误解.为此,在过去的30多年中,软件工程研究者总结了一些较好的方法,这里主要介绍常规的需求获取技术和快速的原型技术在需求的应用.
1. 需求获取方法
负责需求分析的软件开发人员称为系统分析员.系统分析员为了获取正确的需求信息,可以使用一些基本的需求获取方法和技术,包括建立一个联合分析小组,用户访谈以及问题分析与确认等.
(1) 建立联合分析小组
系统开始开发时,系统分析员往往对用户业务过程术语不熟悉,用户也不熟悉计算机的过程.所以用户提供需求信息,在系统分析员看来往往是零散的和片面的,需要由一个领域专家来沟通.因而,建立一个由用户,系统分析员和领域专家的联合分析小组,对开发人员与用户之间的交流和需求的获取将非常有用.通过联合分析小组,可极大地方便系统开发人员和用户之间的沟通,所以有些学者也将这种面向联合开发小组的需求收集方法称为"便利的应用规约技术"(Facilitated Application Specification Techniques,FAST).
有人主张,在参加FAST小组人员中,用户方的业务人员也该是系统开发的主题,是"演员"和"主角";系统分析员作为高层技术人员,应成为开发工作的"导演";其他的与会开发人员是理所当然的"配角".切忌在需求获取阶段忽视用户业务人员的作用由系统开发人员越俎代庖.
(2) 客户访谈
为了获取全面的用户需求,光靠联合分析小组中的用户代表是不够的,系统分析员还必须深入现场,和用户方的业务人员进行多次交流.根据用户将来使用软件产品的功能,频率,优先登记或熟练程度等方面的差异,可将他们分成不同的类别;然后分别对每一类用户通过现场参观,个别座谈或小组会议等形式,了解他们对现有系统的问题和期望新系统功能等方面的看法.
客户访谈是一个直接与客户交流的过程,既可了解高层用户对软件的要求,也可以听取直接用户的呼声.由于是与用户面对面的交流,如果系统分析员没有充分的准备,也容易引起可客户的反感,从而产生隔阂;所以分析员必须在这个过程中尽快找到与用户的"共同语言",进行愉快的交谈.在与用户接触之前,先要进行充分的准备:首先,必须对问题的背景和问题所在系统的环境有全面的了解;其次,尽可能了解将要会谈用户的可行性特点及任务状况;第三,事先准备一些问题,在与用户交流时,应该遵循循序渐进,逐步逼近的原则,切不可急于求成,否则欲速则不达.
(3) 问题分析与确认
不要期望用户在一两次交谈中,就会对目标软件的要求阐述清楚,也不能限制用户在回答问题过程中的自由发挥.在每次访谈之后,要及时进行整理,分析用户提供的信息,去掉错误的,无关的部分,整理有用的内容,以便在下一次与用户见面时由用户确认;同时,准备下一次访谈时的进一步更细节的问题.如此循环,一般需要2~5个来回.
2. 快速原型法在需求分析中的应用
在实际的软件开发中,快速原形法常常被用作一种有效的需求定义方法.在分析阶段,开发人员根据对软件的理解,利用快速开发工具先快速地建立一个系统的原型.然后让用户对原型进行评估,并提出修改意见,从而达到全面,准确地确定软件系统的外部行为和特征.
作为开发人员和用户的交流手段,快速原型可以获取两个层次上的需求.第一层包括联机的屏幕.这一层的目的,是确定屏幕及报表的版式和内容,屏幕活动的顺序,以及屏幕排版的方法.第二层是第一层的扩展,用于模拟系统的外部特征,包括引用了数据库的交互作用及数据操作,执行系统关键区域的操作等.此时用户可以输入成组事务数据,执行这些数据处理的模拟过程,包括出错处理.
在需求分析阶段采用快速原型法,一般可按照以下的步骤进行:
(1) 用各种分析技术和方法,生成一个简化的需求规格说明;
(2) 对需求规格说明进行必要的检查和修改后,确定原型的软件结构,用户界面和数据结构等;
(3) 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试,修改;
(4) 将原型提交给用户评估并征求用户的修改意见;
(5) 重复上述过程,直到原型得到用户的认可.
由于开发一个原型需要花费一定的人力,物力,财力和时间,而且用于确定需求的原型在完成使命后一般就被丢弃.因此,是否使用快速原型法必须考虑软件系统的特点,可用的开发技术和工具等方面.Andriole提出的以下6个问题,可用来帮助判断是否要选择原型法.
·需求已经建立,并且可以遇见是相当稳定吗
·软件开发人员和用户已经理解了目标软件的应用领域吗
·问题是否可以被模型化
·用户能否清楚地确定基本的系统需求
·有任何需求是含糊的吗
·已知的需求中存在矛盾吗
如果第一个问题得到肯定回答,就不需要采用快速原型法;否则,如其他问题得到肯定回答,就适用于采用快速原型法.
先进的快速开发技术和工具是快速原型法的基础,如果为了演示一个系统功能,需要手工编写数千行甚至数万行代码,那么采用快速原型法的代价就太大,变得没有现实意义了.为了快速开发出系统原型,必须充分利用快速开发技术和复用软件构件技术.
第四代开发技术(4GT)是常用的快速原型工具,它利用第四代语言或开发工具,包括数据库查询和报表语言,程序和应用软件生成器,以及其他高级的非过程语言等,可以使用软件开发工程师快速地生成可执行代码.Borland公司的Delphi,Sybase公司的PowerBuilder,以及微软公司的Visual Basic,Visual C++等,都是很好的第四代开发工具.一些CASE工具也可以用于快速原型法.
使用软件构件组装的方法来装配原型系统,是近年来软件构件化和软件复用技术发展的结果.利用现有的数据结构或数据库构件,软件过程构件或其他可视化构件,可使开发人员无需了解构件的内部工作细节,即可快速地装配出一个原型系统.
3.2 结构化分析方法
3.2.1 结构化分析概述
结构化分析是面向数据流进行需求分析的方法.70年代末经Yourdon E., ConstantineL.,DeMarco T.等人提出和发展,至今已得到广泛应用,结构化分析方法的一些重要概念也渗透在其他开发方法中.例如,结构化分析与设计技术(Structured Analysis and Design Technique,SADT),面向对象技术(Object-Oreinted Technique,OOT),IDEF方法等.
结构化分析方法适合于数据处理类型软件的需求分析,由于利用图形来表达需求,显得清晰简明,易于学习和掌握,具体来说,结构化分析方法就是抽象模型的概念,按照软件内部数据传递,变换的关系,自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止,根据DeMarco的论述,结构化分析方法使用了以下几个工具:数据流图,数据词典,结构化英语,判定表和判定树.
3.2.2 数据流图
数据流图(Date Flow Diagram,简称DFM)是描绘软件系统逻辑模型的图形工具,是描绘信息在系统中流动和处理情况的.即使不是计算机专业技术人员也很容易理解,数据流图是软件设计人员和用户之间极好的通信工具.设计数据流图时,只需考虑软件系统必需完成的基本逻辑功能,完全不需考虑如何具体地实现这些功能.因而数据流图可以在软件生存周期的早期(可行性研究阶段)进行设计.在生存周期的以后几个阶段(需求分析,系统设等)不断改进,完善和细化.
图3-4是一个飞机机票预订系统的数据流图,它反映的功能是: 旅行社把预订机票的旅客信息(姓名,年龄,单位,身份证号码,旅行时间,目的地等)输入机票预订系统.系统为旅客安排航班,打印出取票通知单(附有应交的账款).旅客在飞机起飞的前一天凭取票通知单交款取票,系统检验无误,输出机票给旅客.
图3-4 飞机机票预定系统
1. 数据流图的基本符号
数据流图常用的符号有正方形,圆形,矩形,平行线,箭头等.如图3-5所示.
图3-5 数据流图基本符号
(1)数据流 数据流是数据在系统内传播的路径,因此由一组成分固定的数据组成.如订票单由旅客姓名,年龄,单位,身份证号,日期,目的地等数据项组成.由于数据流是流动中的数据,所以必须有流向,除了与数据存储之间的数据流不用命名外,数据流应该用名词或名词短语命名.
(2)加工(又称数据处理) 对数据流进行某些操作或变换.每个加工也要有名字,通常是动词短语,简明地描述完成什么加工.在分层的数据流图中,加工还应编号.
(3)数据存储(又称为文件) 指暂时保存的数据,它可以是数据库文件或任何形式的数据组织.
(4)数据源点或终点 是本软件系统外部环境中的实体(包括人员,组织或其他软件系统),统称外部实体.外部实体一般只出现在数据流图的顶层图.
2. 画数据流图的步骤
(1) 首先画系统的输入输出,即先画顶层数据流图.顶层流图只包含一个加工,用以表示被开发的系统,然后考虑该系统有哪些输入数据,输出数据流.顶层图的作用在于表明被开发系统的范围以及它和周围环境的数据交换关系.飞机机票预订系统的顶层图如图3-6所示.
图3-6 飞机机票预定系统顶层图
(2) 画系统内部,即画下层数据流图 不再分解的加工称为基本加工.一般将层号从0开始编号,采用自顶向下,由外向内的原则.画0层数据流图时,分解顶层流图的系统为若干子系统,决定每个子系统间的数据接口和活动关系.例如,在上面的机票预订系统按功能可分成两部分,一部分为旅行社预订机票,另一部分为旅客取票,两部分通过机票文件的数据存储联系起来,0层数据流图如图3-7所示.
图3-7 飞机机票预定系统0层图
(3) 注意事项.
1)命名 不论数据流,数据存储还是加工,合适的命名使人们易于理解其含义.
2) 画数据流而不是控制流 数据流反映系统"做什么",不反映"如何做",因此箭头上的数据流名称只能是名词或名词短语,整个图中不反映加工的执行顺序.
3) 一般不画物质流 数据流反映能用计算机处理的数据,并不是实物,因此对目标系统的数据流图一般不要画物质流.
4) 每个加工至少有一个输入数据流和一个输出数据流,反映出此加工数据的来源与加工的结果.
5) 编号 如果一张数据流图中的某个加工分解成另一张数据流图时,则上层图为父图,直接下层图为子图.子图及其所有的加工都应编号如图3-8所示.
图3-8 父图与子图
6) 父图与子图的平衡 子图的输入输出数据流同父图相应加工的输入输出数据流必须一致,此即父图与子图的平衡.
7) 局部数据存储 当某层数据流图中的数据存储不是父图中相应加工的外部接口,而只是本图中某些加工之间的数据接口,则称这些数据存储为局部数据存储.
8) 提高数据流图的易懂性 注意合理分解,要把一个加工分解成几个功能相对独立的子加工,这样可以减少加工之间输入,输出数据流的数目,增加数据流图的可理解性.
3. 流程图的实例--销售管理系统
某企业销售管理系统的功能为:
(1)接受顾客的订单,检验订单,若库存有货,进行供货处理,即修改库存,给仓库开备货单,并且将订单留底;若库存量不足,将缺货订单登入缺货记录.
(2)根据缺货记录进行缺货统计,将缺货通知单发给采购部门,以便采购.
(3)根据采购部门发来的进货通知单处理进货,即修改库存,并从缺货记录中取出缺货订单进行供货处理.
(4)根据留底的订单进行销售统计,打印统计表给经理.
根据上述的功能描述,画出如下的数据流程图如图3-10所示.
图3-9销售管理系统的分层数据流图
3.2.3 数据词典
数据词典(Data Dictionary)就是用来定义数据流图中的各个成分的具体含义的,它以一种准确的,无二义性的说明方式为系统的分析,设计及维护提供了有关元素的一致的定义和详细的描述.它和数据流图共同构成了系统的逻辑模型,是需求规格说明书的主要组成部分.
1. 数据词典的内容以及格式
数据词典的任务是对于数据流图中出现的所有被命名的图形元素在数据词典中作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释.数据词典中所有的定义应是严密的,精确的,不可有半点含混,不可有二义性.
数据词典有以下四类条目:数据流,数据项,数据存储,基本加工.
(1)数据流条目
数据流条目给出了DFD中数据流的定义,通常列出该数据流的各组成数据项.在定义数据流或数据存储组成时,使用的符号如3-2表所示.
举例:定义数据流组成及数据项.
机票=姓名+日期+航班号+起点+终点+费用

航班号="Y7100"..."Y8100"
终点=[上海|北京|西安]
数据流条目主要内容及举例如下:
数据流名称:订单
别名:无
简述:顾客订货时填写的项目
来源:顾客
去向:加工1"检验订单"
数据流量:1000份/每周
组成:编号+订货日期+顾客编号+地址+电话+银行账号+货物名称+规格+数量
2.数据存储条目
数据存储条目是对数据存储的定义,如:
数据存储名称:库存记录
别名:无
简述:存放库存所有可供货物的信息
组成:货物名称+编号+生产厂家+单价+库存量
组织方式:索引文件,以货物编号为关键字
查询要求:要求能立即查询
3.数据项条目
数据项条目是不可再分解的数据单位,,其定义格式如下:
数据项名称:货物编号
别名:G-No,G-num,Goods-No
简述:本公司的所有货物的编号
类型:字符串
长度:10
取值范围及含义:
第一位:进口/国产
第2-4位:类别
第5-7位:规格
第8-10位:品名编号
4.加工条目
加工条目是用来说明DFD中基本加工的处理逻辑的,由于上层的加工是由下层的基本加工分解而来,只要有了基本加工的说明,就可理解其他加工.举例如下:
加工名:查阅库存
编号:1.2
激发条件:接收到合格订单时
优先级:普通
输入:合格订单
输出:可供货订单,缺货订单
加工逻辑:根据库存记录
IF 订单项目的数量
THEN 可供货处理
ELSE 此订单缺货,登录,待进货后再处理
ENDIF
2. 数据词典的数据定义方法
在对数据进行定义时,可以使用数据各成分的组合来表示该数据,这些组成又由更底层的成分组合来定义.因此,对数据的定义可以理解为对数据进行自顶向下的分解,直到参与系统开发的人员都能理解所分解出来的成分或元素的意义,不再需安进行任何的解释.按照这样的方法,自顶向下,逐级给出定义式,直到最后出现无需定义的基本数据元素.数据词典就是这样建立起来的—组定义式.必要时,有些定义式可能需要增加一些解释行.同日常使用的词典一样,数据词典的定义式可以按一定顺序排列,如按字母顺序排列.当然不允许出现重复定义或是定义式互相矛后酌情况.
通常在数据词典的定义式中出现的符号可能有以下几个:
若x,a和b都是数据元素,给出以下各定义式的及其含义:
x=a+b x由a和b构成
x=[a,b] x由a或b构成
x=[a|b] x由a或b构成
x=(a) a可在x中出现,也可能不出现
x={a } x由零次或多次重复的a构成
x=m{a}n x由m至n个a组成,即至少有个a,至多有n个a
x=a..b x可取a至b的任一值
x="a" x为取值a的基本数据元素,即a无需进一步定义
例如,电话号码是一个3位至8位的十进制数,有的电话号码还需包括4位分机号.它可以这样来定义:
电话号码;3{十进数码} 8(+"-"分机号)
其中
十进数码="0".."9"
分机号=4{十进数码}4
这样,诸如119,4752,32152,282451-2373及25687602都是定义了的电话号码.
3.4 软件需求文档
需求分析规格说明书是需求分析阶段产生的一份最重要的文档,它以一种一致的,无二义的方式准确地表达用户的需求.需求规格说明书主要起以下三方面的作用:
(1)作为软件开发机构和用户之间一份事实上的技术合同书;
(2)作为软件开发机构下一步进行设计和编码的基础;
(3)作为测试和验收目标系统的依据.
在系统开发早期设计一个软件测试计划是十分必要的.大量的统计数字表明,在系统开发早期发现并修改一个错误的代价往往很低,越到系统开发的后期,改下同样错误所花费的代价越高.举个例子,假设在需求分析阶段检测并改正一个错误的代价为1个单位,那么到了软件测试阶段检测并改正同样的错误所花费的代价,据典型的保守数字为10个单位,而到软件发布后的代价就可能高达100个单位.所以,尽可能地在系统开发的早期进行软件测试,就可以较小的代价检测出需求规格说明书中不可避免的错误.这个初步的测试计划应包括对未来系统中的哪些功能和性能指标进行测试,以及达到何种要求.在后阶段的软件开发中,对这个测试计划要不断地修正和完善,并成为相应阶段的文档的部分.
用户系统描述从用户使用系统的角度描述系统,相当于一份初步的用户手册.内容包括:对系统功能和性能的简要描述,使用系统的主要步骤和方法,以及系统用户的责任等等.在软件开发过程的早期,准备一份初步的用户手册是非常必要的,它使得未来的系统用户能够从使用的角度检查,审核目标系统,因此比较容易判断这个系统是否符合他们的需要.为了书写这份文档,也迫使系统分析员从用户的角度考虑软件系统.有了这份文档,审查和复审时就更容易发现不一致和误解的地方,这对保证软件质量和项目的成功是很重要的.
下面给出需求规格说明书的一种结构.
××××××系统需求规格说明书
1.引言
1.1 编写目的
说明编写本需要分析规格说明书的目的.
1.2 背景说明
(1)给出待开发的软件产品的名称;
(2)说明本项目的提出者,开发者及用户;
(3)说明该软件产品将做什么,如有必要,说明不做什么.
1.3 术语定义
列出本文档中所用的专门术语的定义和外文首字母组词的原词组.
1.4 参考资料
列出本文档中所引用的全部资料,包括标题,文档编号,版本号,出版日期及出版单位等,必要时注明资料来源.
2.概述
2.1 功能概述
叙述待开发软件产品将完成的主要功能,并用方框图来表示各功能及其相互关系.
2.2 约束
叙述对系统设计产生影响的限制条件,并对下一节中所述的某些特殊需求提供的理由,如管理模式,硬件限制,与其他应用的接口,安全保密的考虑等.
·上一篇：采购评选委员会工作小组初审意见总表(范本)
·下一篇：运输组织学课程设计大纲