需求分析导引

ISSN 1009 3044E- -mail: xil@cce.net.cnComputer Knowledge And Technology电脯知识与技术htp/://ww.w.net.cnnVolL4.No.8.December 2008. pp.2156 -2158.2173Tel:+86- 551-56909635690964需求分析导引付红雷',张勇凤2(1.深圳市南凌科技发展有限公司软件研发中心干细胞业务部,北京100062:2.山西师范大学.山西临汾041004)摘要:各种需求分析方法各具特点,如果仅使用某种方法在项目实践中往往会困难重重,怎样结合各种需求分析方法之长为项目实践建立一种需求分析参考标准成为一个迫切需要解决的问题。通过对面向问题域、面向对象、模型驱动等分析方法的研究,并结合在项目实践中应用,以面向问题域分析为核心规定需求分析的根本目的与基本活动,结合面向对象的分析与模型驱动分析说明有效建模的技术要点,初步形成一个适合于实际项目活动的需求分析标准的框架。关键词:需求分析;西向问题域的需求分析;面向对象分析;领域模型驱动;需求分析标准中图分类号:TP302文献标识码:A 文章编 号:1009 -0442008353 -2156-03An Introduction to Requirements AnalysisFU Hong-lei', ZHANG Yong feng(1.CMDP Service Department of Nova Network Software Development Center, Bejing 10002,0 Chin; 2.Shanxi Normal Univecity,Linfen 041004, China)Abstract: Each kind of denand analysis method each characteristic, but if will only use some method to be ofen beset with dificulies inthe project practice, how to unify each demand analysis method long to establish one kind of demand analysis reference standard for theproject practice to become the question which urgent needs to solve. Through the opposite to the question teritory's analysis method, theobject- oriented analysis method, the model actuation analysis method's tresearch, and unifies in the project practice applies, ake fces thequestion trritory analysis as the core stipulation demand analysis primary purpose and the basic activity, unifies the object-oriented analysisand the model actuation analysis explanation efective modeling importance and the technical point, forms one to suit initally in the actualproject activity demand analysis standard fame.Key words: requirements anlysis; problem domain oriented analysis; analysis strategy; domain model driven; requirements analysis standard1引膏开发软件就是通过描述来构建-部软件机器去实现某一目的,因此在动手之前.我们需要详细地弄清这个特定目的是什么,这就是需求分析需要完成的任务。需求分析过程处于软件工程的开始阶段,它提供了软件项其余部分得以构建的根基,如果错误出现在需求分析阶段,而且并未立即予以纠正,那么所有后续阶段的工作将都在错误的基础上进行,修正错误的代价将飞速增加。对于一个大型的软件项目,一旦忽略或低估需求分析过程必将承担风险。2需求分析的目的与活动软件项目的目的一般是解决一个信息化的问题.而需求分析的目的就是要定义所需解决的问题。-般情况下,对于项目组来说，总是要面对向题定义不足，需求不清的闲境。因此.可以这样初步理解需求分析的目的一需求 分析过程就是要把-一个定义不足的问题转换为一个定义良好认并且清晰的问题并且找出解决方案。要确定软件项目的目的,那么首先要做的是识别问题,然后再去研究解决方案。要识别问题.那么首先要去了解向题域。问题域.应用领域或客户领域,就是需要解决问题的现实世界的一个领域,面项目的最终成果,即解系统或新系统,将运行其上,产生某种效果而最终解决问题。问题域并不等同新系统运作的环境,因为新的解系统将不可避免地对问题域进行改变,否则它就不可能解决问题,因此问题域与新系统运作环境事实上存在差别。向题域也不等同于旧的应用系统,这个旧的应用系统可能是原有的计算机软件系统或是非软件的解决方案，因为旧的应用系统本身只是问题城的解决方案.即问题域的一-个不成功的解系统，新的解系统也许会继承其运作方式或者产生全新的运作方式，因此对旧的应用系统的研究不能替代对向题域的研究,虽然它可以提供一些知识.但它始终是问题域的一种包装。口解累统旧的应用系统不仅仅指原有的计算机信息系统，也涉及客户当前的工作流程和工作方式。整个需求分析过程需要关注两个系统一问题域与解 系统，它们的相互关系如图1。中国煤化工解系统的关系MYHCNMHG收稿日期:2008-09-16作者简介:付紅雷(1973-),男,山西太原人,主要研究方向:软件工程;张勇凤,讲师,文学博士。2156”软件设计开发.......本栏目责任编辑:谢媛媛付红需等:需求分析导引这个相互关系也定义了三个主要开发活动的区域,如图2所示。对于这三个主要开发活动可以区别如下:分析:关注问题城本身,清晰定义需要解决的问题。(口规格说明:关注解系统与问题城的交互，规定解系统的运行方式以解决问题设计:不属于需求分析范畴.关注于解系统的内部实现。因此，需求分析阶段包含两个主要活动.需求分析与规格说明。这两个主要活↑动可简述为:从向题域的研究人手.对问题域进行描述,获取问题域的定义和客户分析规格说明 埂计对新的解系统能够产生的效果(需求)的陈述,以此确定新的解系统所应具有的功圈2软件工程的三个主要开发活动能,以便达到客户所需要的效果。显而易见.需求分析阶段必然包括两个主要文档,一个应当包含问题域特性的细致描述与需求的陈述,称之为《用户需求说明书);另一个包含经过精心设计的解系统的功能的描述,这个精心设计的行为可以满足客户的需求,称之为《钦件需求规格说明书》。3需求获取3.1“获取”与“采集”“需求采集”隐含表示已有了“成熟”的需求,只需要去“采集" ,而实际上很少会有这种情况,客户“原始”的需求往往是以很零散.很不完整的形式呈现出来。“获取"隐含着一个知识传递的过程,"需求获取”是要将隐藏在问题城之中的信息明确化具体化、系统化,并与客户形成共识。3.2需求获取的信息对于大型的软件系统,由需求分析阶段的整体要求决定,应当包括:l)问题域的描述;2)要求解决的问题列表,即需求列表;3)用户对解系统想要施加的任何约束;3.3信息来源问题域中信息的主要来源.即需求获取人员应当关注的对象,包括:1)实际的客户和潜在的客户;2)客户的“要求说明";3)任何原有解系统及其文档;4)原有系统的用户和新的解系统的可能用户;5)开发者相似产品;6)竞争对手产品;7)行业专家;8)定义任何.操作规范或数据规范的文档;9)相关的技术标准与法规。3.4需求获取的技术获取需求的技术与信息的可能来源密切相关,大致包括:阅读背景材料;面谈;调查表;检查文档;任务观察;人种论;用例与场景;讨论分析;联合应用设计;需求剥离等方法,这里不再详述。3.5需求获取策略3.5.1-般策略1)从一般到具体,通过概述帮助确定每次需求获取的目标,适当时候再详细调查;2)要敢于陈述好像是显而易见的事实;3)从信息的源头探究.而不是道听途说;4)信息来源多多益善;5)主管与高层应适时介入;6)注意消除分歧。3.5.2.管理者与一般用户1)管理者:一般对原始数据不感兴趣,只对增加新的业务知识的信息感兴趣;关注的是整体,通常对细节不感兴趣;对业务功能的整体视图感兴趣;从系统支持的功能和改进的预期方面理解系统;可以帮助确定需要收集和存储数据的相关业务实体;可以帮助理解描述业务实体是如何交互的简单业务关系和规则;需要持续跟踪这些业务实体和规则,以产生有用的信息;会谈时可使用业务事件列表及对那些事件的响应方式记录业务功能(包括时间);可能会了解新系统需要为哪些企业部门、员工、客户和外部企业提供接口;这些接口位于么地方;是否需要同其他的信息系统或自动化系统接口。2)-.般用户:以目前数据如何存储或他们认为数据应如何存储的方式来看待数据;说明被存储的确切数据属性以及用于维护这些数据的精确业务规则;应当正确地确定和验证用户的业务数据需求;业务过程一为了提供对业务事件的恰当响应必须执行的“工作";以过程需求的方式说明新系统的业务过程.过程需求通常以策略和规程的形式定义;关心输入与输出;输人输出的构成细节,图型用户界面的原型形式,形似于PC工具(WORD,EXCEL)。3.5.3需求演化问题域本身远不及需求更易于变化,用户可能要求产生新的报表或采用不同的方式对某一部分产生控制,但底层的问题域数据或相关元素的内在行为的变化却很少。首先应当将问题城特性描述与需求分离;可维护文档是另一个关键因素;时间越长,变化的可能越大,鼓励尽快完成系统开发。.4需求分析4.1目的需求分析的根本目的:通过对问题领城的研究,获得对该领城特性及存在于其中需要解决的问题特性的透彻理解并用文档说明。需求分析的输出结果是《用户需求说明书>,该文档应当能够提供关于问题域各个相关方面的全面描述和有关客户需求的完整的列表。4.2需求分析策略4.2.1关注问题域中国煤化工需求分析强调的揭示问题域的结构与属性，而不是将来解系统将要实现MYHCNMHG4.2.2 建模与描述分析的总目标可以被认为是以某种易于理解的形式提供所有必需的信息。这就需要对收集得来的信息应当精心加以提炼,获取精华从而保证所有相关的细节能以一种清晰符合逻辑且简洁的方式得以呈现一--建立合适的问题领域的模型。本栏目责任编辑;谢媛媛.......软件设计开发.2157Computer Knowedge And Technoloy电脑知识与技术2008年第4卷第8期(总第35期)许多系统真正复杂之处不在于技术，而在于问题领域本身。如果在需求分析时没有获得对问题领域的深刻理解,没有通过模型将复杂的领域逻辑以模型概念和模型元素的形式清晰地表达出来,那么无论我们使用多么先进的平台或架构,都难以保证项目的真正成功。成功项目的特征是:在迭代中不断地完善领域模型.通过领域模型越过问题域的表象揭示其底层的结构;将这个领域模型作为项目骨干结构的一部分;模型是知识的一种有选掙的简化和有意识的组织形式,一个合适的模型能够表达信息的含义并聚焦于问题本身;模型并不是某种特殊的图.而是图所要表达的思想,可能是图也可以是认真编写的代码或形式化语言,模型松散地表现具有特定目的的现实不要试用用UML表示出整个模型或设计。很多对象模型过于完整.又遗漏了很多东西:总是想要把的有将要编码的对象都放进去,所有的东西过于细化;属性与关系只占到一个对象模型的一半内容.那些对象的行为及约束则不容易用阁例表达出来。因此，应当采用图与描述相结合的方式:约束与断育可用括号包含的文本在对象关系图中表达;对象与模型所代表的概念意义(定义)和对象所要完成的工作应当以文本加以描述。与其使用一个带有文本注释的图.不如编写一个文本文档,里面用经过挑选的简化图做示例。4.2.3有效模型因素1)模型与编码实现相互绑定;2)基于模型产生-种通用语言,既可以用来与领城专家进行沟通,又可以做为需求设计、编码的沟通语盲;3)开发-一个包含丰富知识的模型;4)精炼模型;5)采用头脑风暴与实验来验证模型。4.2.4模型分析过程1)从需求获取中得到领域模型的元素.建立初步的领域模型;2)在讨论中细化.在询问中解释.随着对领域的理解和领城专家对模型如何在问题解决中发挥作用的理解,模型一步步地发展;3)编写--个简单的原型.该原型是能够精确地反映领域模型的部分软件系统,开发人员结合领域专家通过各种场景一步-步地使用模型对象来非正式地走查模型,当原型不能完成-个重要的场景时,对模型进行修改;4)原型并不仅仅是界面,重要的是清晰地表达业务逻辑和行为。4.2.5面向对象的分析1)需求分析的基本技术手段是面向对象的分析。2)类模型作用的延续性:需求分析阶段一问题域概念化,建立问题域类模型;规格说明阶段--规格说明, 建立接口类;编码实现阶段一业务模型实现.建内部设计的业务类。3)用例的作用应该是有限的,使用用例避开了对问题域及相关问题做全面考虑.并直接对解系统的行为进行定义。4)面向对象分析的补充:在面向对象分析的过程中可建立DD(数据字典)来定义和解释术语与数据项;分析初期可采用传统意义的流程图帮助理解问题域.但最终要避免让业务流程成为模型中的突出方面,对象意味着将业务流程封装起来,对于复杂的处理流程可以用服务来进行封装,对于多种分支流程,可以将算法本身作为一个独立的对象,选择不同的流程也就选择不同的对象，每个对象代表一个不同的策略。可以单独列出问题域事件与输人列表及这些事件可能的发生序列;应当对需求(需在问题域中求解的问题)单独列表,包括必须支持的查询与需要提供的报表。4.2.6用户需求文档1)文档核心内容:结合模型对每个问题子域的全面描述;需求列表,需求应避免指导该如何解决向题;如果出现了被初始载入系统的数据是那些原有的、以电子方式存储的数据的情况.那么存取这类数据的方式就应该详细阐述;数据字典。2)特性与需求:语态的区别清楚地区分问题域的内在特性及需求;特性是对问题域的真实的反映.它们完全超出了所要构建的新的解系统所能控制与影响的苑围,其声明采用指示语态;需求是新系统能够控制的东西.即要求新系统产生的结果。其声明使用祈使语态,它反映了有客户选定的选项;只要给出问题域的内在特征,新系统应当完全有能力满足需求。5规格说明5.1规格说明的任务创建并定义新系统的-种行为,使之在问题域中产生所需要的效果。创建新系统可能的行为并选择某-种行为,然后进行规格说明文档编制,并经由客户同意。5.2规格说明策略5.2.1外部接口1)规格说明关注问题域与新系统之间的接口,即关注的是新系统的外部视图;2)新系统的行为将通过其与问题城交互的接口来定义。软件系统通过传递数据与外部世界发生交互,每一个接口将有一个从新系统接收或发送数据的端子,这个端子可能是操作员其他软件系统、电子硬件等,定义接口的首要任务是识别端子;3)在规格说明阶段-般要添加新的端子,如系统管理员接口。5.2.2功能抽象1)通过确定新系统输人和输出的语法与语义,以及这些输入和输出之间所需的关系(时间关系、因果关系),就可以表达新系统.所需的行为;2)规格说明需要添加大量的输人和输出:如用户提示及消息操纵接口所需的用户命令.无效的或异常输入的处理等;3)可以分别在详细与抽象级别上确定新系统的行为;中国煤化工4)可采用逻辑层次分解的方式进行规格说明。5.23文档编制.MH.CNMH G1)规格说明文档应首先以一种很大的粒度来讨论和理解新系统，可以用一组局层次的概念或规则采整个新系统建立- -个模式,使人们能够基本理解每个部分在整体中所处的位置.即使他们并不了解这个部分职责的细节内容，其次可以对一些核心元素 进行专门的说明;(下转第2173页)2158“软件设计开发.......本栏目责任编辑:谢媛媛鲁顺等:DDR SDRAM控制器中全数字延时锁定环的设计实现将设计好的Verilog代码进行基于Foundry的标准单元库的逻辑综合、自动布局布线、物理验证最终生成版图及网表。用HSIM仿真器对版图反抽出的网表进行动态仿真。图5仿真结果在初始化完毕之后系统便进行连续的延时调整.直至TESTCODEC和TESTCODE_F不变化.表征系统锁定延时。观察图6的锁定态时波形,CLK _FB与CLK IN同相.DQS移相90生成DQS _D。仿真结果表明DLL在400MHz工作频率时,最好工艺角环境下和最差T.艺角环境下tSD延时分别为606ps和655ps;在200MHz T.作频率时分别为1240ps 和1318ps.满足tSD要求。图5 DLL 在400MHz工作频率时延时锁定过程仿真波形围6 DLL 在400MHz工作频率时锁定态仿真波形5结束语.该文设计的基于标准单元的全数字DLL可以用布局布线工具自动生成版图.在缩短设计周期可集成性和工艺兼容性方面有很大优势。其工作频率范围较宽,功能上实现自动跟踪参考时钟频率.无谐波锁定出错、可跟踪PVT变化和正确产生tSD延时非常适合DDR SDRAM控制器应用,有一定的实用价值。参考文献:[1]陈昊.DDR存储控制器的设计与应用[D].国防科学技术大学,2006:6 -8.[2] Ching-Che Chung,Pao-lung Chen,Chen-Yi Lee.An All-Digital Delay-Locked Loop for DDR SDRAM Controller Applications [小In-temational Symposium on VLSI Design,Automation and Test2006(4);:1-4.[3] Rong -Jyi YangShen-luan Liu.A 40-550 MHz Harmonic -Free All-Digital Delay-Locked Loop Using a Variable SAR Algorithm[J.IEEE Joumal of Solid-State Gircuits,2007.,42(2):361-373.[4] Pao-Lung Chen,Ching- -Che Chung,Chen-Yi Lee.A Portable Digially Cortolled Oscillator Using Novel Varactors [JIEEE Transactionson Circuits and Systems I:Express Bris2005.52()233- 237.[5] Guang-Kaai DehngJune -Ming Hsu.Ching -Yuan Yang.Shen-luan Liu.Clock -Deskew Buffer Using a SAR -Contolled Delay -LockedLopIJ]IEEE Joumal of Solid- State Crcuit.,200.358)128-1136.[6]罗翔鲵.全数字延时锁定环及其应用小电子工程师204.3010);224.[7] Ching-Che Chung,Chen-Yi Lee.A New DLL- -Based Approach for All-Digital Muliphase Clock Generation [J]IEEE Journal of Solid-State Circuits.2004,39(3):469 -475.(上接第2158页)2)文档与原型相结合,文档不应该去做原型已经做得很好的工作,如所有的细节问题,精确的程序行为说明,文档要对原型的概念进行解释，并帮助定位到代码中的细节;3)在定义输人与输人关系时,应采用功能性的说明方式,而不要去描述过程;4)加入性能需求,关注系统可用性。6需求验证1)正因为需求阶段所犯的错误代价昂贵,因此,尤为重要的是设法把错误减到最少,并且一有可能就检测与更正任何已出现的错误;2)需求验证机制,可采用确保--致性的简单检查、问题域专家评审、逻辑分析.系统Demo测试用例设计.编制用户手册等方法。7结束语笔者在长期的需求分析工作中.感觉到各种的系统分析理论各具特点.仅仅依靠某种分析方法的指导，很难保证项目的圆满完成,项目组虽然有CMM规范指导按步骤完成一个个项自过程.但怎样去完成工作产品才能提高项目的质量仍然缺乏有效的指导与规范。总绪多年的学习与实践经验,完成此文档,希望能对项目的需求分析过程具有参考和指导意义,能够对提高需求分析工作产品的质量有所帮助。[1] Bray L K.REQUIREMENTS ENGINEERING:需求工程导引M].舒忠梅.罗文村.译.北京:人民邮电出版社,2003.[2] Evans E:Domain-Driven Design:领域驱动设计(M]陈大峰张泽鑫,译北京:清华大学出版杜2006.[3] Jlfrey L, Whitten L D, Bentley K C.Sytems Analysis and Design Methods:肖剧孙,译.北京:机械工业出版社, 2005.中国煤化工TYHCNMHG本栏目责任编辑:谢媛媛.......软件设计开发“2173