新一代应用分析与应用开发承接的研究与实践代理保险车险流程的设计开发实践以及个人客户综合积分应用分析的研究

开发中心导师责任制结业论文题目：新一代应用分析与应用开发承接的研究与实践代理保险车险流程的设计开发实践以及个人客户综合积分应用分析的研究学员姓名： 导 师： 部 门： 开发三处 2014年 7 月 16日目 录第一章 绪论31.1课题背景31.2工作内容41.3 论文结构5第二章 快速上线模板的设计内容62.1 概述62.2 逻辑架构72.3 投保界面域控制信息文件72.3.1 文件命名72.3.2模板数据文件格式及说明8第三章 代理保险使用的快速上线模板的配置、生成及展示123.1 对快速上线模板的配置123.2 对快速上线模板的生成123.3 对快速上线模板的展示13第四章 快速上线模板的优化174.1 模板和实例的关系174.2 新增的触发事件174.3 界面加载时间过长17第五章 总结与展望19工作总结19心得与展望19致谢21第一章 绪论1.1 课题背景随着金融信息化建设的不断发展，围绕“以客户为中心”的经营理念，实现银行管理的不断创新与变革越来越重要。客户关系管理（CRM：customer relationship management），其核心是客户价值管理，银行要能够满足不同价值客户的个性化需求，提高客户忠诚度和保有率，实现客户价值持续贡献，从而全面提升银行的盈利能力。对于零售银行来说，客户是一项重要资产，银行应与目标客户建立长期并有效的业务关系，在与客户的每一个“接触点”上，更加接近客户、了解客户，最大限度的增强客户忠诚度，提高市场占有率。伴随着信息技术的革命性发展，尤其是互联网的高速发展，国际金融业涌现出声势浩大的金融创新浪潮，信息技术投资与应用水平已经逐渐影响到银行业务运营的基础能力，在信息化的基础上发展银行业为我国的银行业带来新的生机，解决和缓和了目前国有商业银行所面临的矛盾和危机，提高了银行的市场竞争力，银行日常的业务运营已无法离开信息技术投资系统的使用。我们必须逐渐提高银行在信息技术投资以及服务等方面的能力，进而促进银行业务高效、稳定的发展。因此，利用先进的技术手段，可以使银行金融产品的开发与推广更加迅速，可以更快地应对市场的变化以及开拓新的市场，抢占市场先机。同时，通过信息资源共享，促进银行的集约化经营管理，可以使资金流动更快，业务效率更高，风险监控更完善。随着建行新一代如火如荼的开展，这种需要也就更加强烈。零售银行自1980年恢复办理国内保险业务以来，银行保险业务是一种由银行代理销售保单的新兴的保险销售方式，与传统的保险销售方式相比，它最大的特点是能够实现客户、银行和保险公司的“三赢”，可以通过代理销售多样化的产品，提高客户满意度和客户忠诚度，并通过代理的手段收取部分中间收入。对银行来说，可以通过代理销售多样化的产品，提高客户满意度和客户忠诚度。并通过代理的手段收取部分中间收入。对保险公司来说，利用银行密集的网点可以提高销售并且降低成本，从而可以以更低的价格为客户提供更好的产品；利用银行的客户资源和信誉，再配合以保险公司的优质服务，可以树立良好的品牌形象，开拓更多的客户源。对客户来说，在银行买保险，价格更便宜，回报更高；银行网点多，在家门口就可以买到保险，减少了交通费用和时间、精力等的支出；可以同时在银行办理银行业务和买保险，满足了“一次购足”的心理；银行值得信赖，也就可以放心买保险；产品简单易懂，可以当场决定是否购买；投保手续更加简捷，不用体检，十分方便。目前，国内多家寿险公司通过银行柜台销售保险产品取得了成效。今后，随着保险公司和银行合作的深入，人们还将享受到更加方便、快捷和满意的银行保险服务。代理保险作为银行主要的中收业务新一代代理保险系统是连接建行客户和保险公司的重要系统，因此，系统的便捷性、易用性对于客户和保险公司来讲都是不可或缺的。积分是商家为了维系客户关系而设置的与核心业务合作程度有关的表现形式。客户积分可以直接反映客户与商家之间的合作紧密程度，积分越高商家与客户的联系越紧密从而商家的回馈力度就越大。这种表现形式已经广泛的应用于通讯、银行、航空、商超、会员制服务机构等行业，我行也采用此形式来管理客户关系。我行个人客户均可享有个人客户综合积分服务，本项服务具有受理渠道广泛、业务种类丰富、积分累计便捷、服务品质升级等优势，从而促进客户与我行之间的联系。积分累积到一定程度提供相应级别的增值服务，或者增加更多的服务内容以达到持续维护客户关系的目的，从而提高客户满意度和忠诚度。在此业务大背景下，参与了新一代代理保险-车险项目的开发实践工作以及个人客户综合积分项目的应用分析工作，阐述工作的大致过程及业务价值，归纳了解决问题克服难点的工作方法，并重点总结和思考了从技术开发到应用分析工作角色转换的过程中的的感悟以及对个人成长后续工作的展望。1.2 工作内容自2014年8月以来，我正式加入新一代代理保险项目组，参与项目组车险的需求分析讨论、应用服务代码编写、组件组装测试相关工作。2014年1月，加入个人客户综合积分项目组，进行应用分析工作。一年以来，本着让新人尽快融入项目组和开发中心工作环境的目的，我在此期间经历了从学习讨论到编码实际开发、与各部门、各分行同事需求讨论及与外项目组件需求对接等不同内容和性质的工作锻炼，了解到了项目组运转细节的方方面面，对需求从应用分析到实际落地的流程等有了具体的认识和整体把握。首先，本论文回顾了在入职一年来学员所承担的新一代代理保险项目车险的设计开发及相关测试工作，此外还包括在导师责任制要求下，对我行规章制度、信息系统开发、数据库开发理论和实施、新一代实施工艺等多方面的学习情况，并简要介绍代理保险车险项目中快速上线模板的设计与实现。工作一年以来，我负责的主要工作内容如下：1) 负责新一代代理保险中车险的多支交易的业务分析、各相关渠道系统用例以及P8后端应用组件设计、细化设计的文档编写以及对应交易的开发及测试工作：2) 负责对新一代个人使用的车险投保界面标准数据模板；3) 负责新一代个人客户综合积分的应用分析工作，其中承接建模的三级活动两个（定义积分规则、管理客户积分活动），从需求流程、用户工作流、业务功能、界面、输入输出完成需求“端到端”的分析通过以上工作，本人完成新一代代理保险系统中申请车险投保、查询车型信息、查询车险详情的业务分析、设计及实现，并在开发过程中熟悉了P8平台的逻辑架构，以及在代理保险应用系统中的运行机制；在个人客户综合积分项目组应用分析的工作，通过需求讨论、建模分析与回补、外组件需求对接等学习到了分析需求的方法。结合之前做过的开发工作经验，在需求分析时尽可能的把需求想的细且全面，考虑正流程和异常流程，能在开发时尽量避免问题，提高开发质量与效率。1.3 论文结构本论文共分为五章。第一章，绪论（即本章）。介绪论。主要介绍论文的研究背景和选题意义，说明论文的主要内容及整体结构。第二章，车险设计、开发的过程以及期间遇到的问题难点，工作总结与思考。第三章，个人客户综合积分项目的意义以及在应用分析工作中需求分析方法的学习，工作总结与思考；第四章，从开发到应用分析转换的感悟以及对后续工作的展望。第五章，总结论文的内容，并对本人导师制实施近一年期间的学习和工作情况进行简单回顾，总结自己在专业技术和职业技能方面的成长，并对自己得到的关怀和帮助表达致谢。第二章 代理保险车险设计内容2.1 概述随着国家金融市场的不断开放，越来越多的银行加入到市场中来参加竞争，银行常规业务的预期利润逐步下降，迫使银行不得不设法寻求新的利润增长点，并通过新的服务来稳定或增加自己的客户群。代理保险作为主要的中收业务新一代代理保险系统是连接建行客户和保险公司的重要系统，因此，系统的便捷性、易用性对于客户和保险公司来讲都是不可或缺的。在银行代理车险，不仅能给客户信任感提升，办理快捷方便，还能够给银行带来中收，可达到共赢的效果。在实际的银行保险业务交易中，银保系统除了要与各个渠道进行交易数据交互外，还需要将一些基本的，确定的标准数据发送到渠道，以帮助渠道构建各自的交易流程，否则渠道无法知晓某些具体的参数细节，从而导致这一渠道的交易无法顺利开展。这些标准数据包括：界面域控制信息、产品介绍信息、下拉菜单数据信息。代理保险的参数维护、界面展示以及数据同步机制如下：1. 全部标准数据参数均由P2界面在P8代理保险后台维护，所有数据均保存在P8代理保险后台数据库中。日间由业务人员在代理保险组件的营运管理端修改维护参数文件中的内容。2. 每天P8代理保险日终之后，如果有对标准数据的更新，则在P8生成对应的全量数据文件，使用文件传输组件推送给P1/P2。3. P1/P2渠道发起交易时，根据最新版本的标准数据文件内容确定各险种的输入要素（即界面的栏位）、必输项/非必输、缺省值等信息，确定P1险种录入界面，完成处理后发送P8代理保险组件处理以上方式的优点如下：1. 减少新增险种带来的开发维护工作量。该参数文件主要定义新单申请环节的险种要素，如果不采用类似的参数方式定义险种要素，可能面临每次新增险种，就需要新增对应险种的新单申请交易，今后带来比较大的开发维护工作量。2. 通过日终1次传输将参数缓存到P1，日间P1从本地读取，避免重复取参数带来的效率问题。2.2 车险投保界面域逻辑架构2.3 车险投保的流程设计2.3.1 车险投保申请界面2.3.2 查看套餐内容界面2.3.3 查询保单详情界面2.3.4车险保单信息录入界面2.3.5车型平台查询信息界面2.3.6车险非实时投保信息录入界面2.3.7车险投保信息/保费确认界面以上是参与车险需求分析、应用设计，确定车险投保流程的相关主要界面。2.4 车险投保界面域控制信息文件2.4.1 文件命名投保界面域控制信息文件生成数据规则：一个投保界面对应一个xml文件；对于套餐，拆分成2两种配置文件，套餐信息文件和套餐界面域控制配置文件，具体说明如下：1、险种配置文件命名方式为：“TBJM”+“_”+“保险公司编号”+“_”+“险种编号” +“.xml”。命名方式为：“TBJM”+“_”+“保险公司编号”+“_”+“附加险种编号” +“.xml”。内容说明：a、险种或附加险种的基本信息和投保界面域控制信息；b、险种与附加险种的对应关系在“下拉菜单数据文件”中标识。2、套餐信息文件命名方式为：“TBJM”+“_”+“保险公司编号”+“_”+“套餐编号” +“.xml”。内容说明：包含套餐的基本信息和套餐层级信息。3、套餐界面域配置文件分两种情况：1. 套餐为单一投保界面，既投保界面域定义在套餐本身上，对应的界面域配置文件也只有一个。命名方式为：“TBJM”+“_”+“保险公司编号”+“_”+“套餐编号” +“_” + “0000” + “.xml”。包含内容：本套餐单一的投保界面域配置信息。2. 套餐投保界面不是单一的，按照其包含的险种分不同的投保界面进行投保操作,按照界面个数生成多个配置文件。命名方式为：“TBJM”+“_”+“保险公司编号”+“_”+“上级套餐编号” +“_” + “险种编号” + “.xml”。包含内容：套餐下某险种的投保界面域配置信息。2.4.2模板数据文件格式及说明以层级维度可以对标准数据模板中所有节点进行一下划分：包括报文及产品信息，组信息以及界面元素信息。1. 报文及产品信息层级节点名称说明1entity该节点用来标示模板文件根节点，节点为必填节点，且只在文件中出现一次1.1CDDATA该节点用于包裹具体模板数据以处理数据中可能出现的特殊字符，节点为必填节点，且只在文件中出现一次1.1.1msgData该节点是被CDDATA包裹的保险数据根节点，节点为必填节点，且只在文件中出现一次1.1.1.1agInsPDId该节点为代理保险产品编号，标示当前模板数据文件对应的产品编号1.1.1.2insTp该节点为保险类型，用来标示当前模板数据文件对应产品的类别，对于不同类别的产品（财险、寿险）需要调用P8的不同交易。可选取值：0 - 寿险1 - 财险2. 组信息层级节点名称说明1grp组节点。用于表示分组。页面上各元素必须在分组中传回，分组下包含分组属性数据grpProp和分组内包含的元素的数据grpData。该节点为文件中的必输节点，在同一文件中可以同时存在多个组。1.1grpProp组属性节点。用来标示组信息的内容1.1.1id组编号，规则：由系统自动生成（如：006每个msgData节点下组id必须唯一）。组编号为必填节点，且在每个组中只能出现一次。1.1.2title组标题，用于在界面中展示该组时显示的名称。1.1.3prntGrpId父组编号，有父组时填写。1.1.4dfaltStatus组默认状态。在P2中，组默认以PJF组件panel方式展示，该节点值标识该组对应panel默认是否展开显示。可选取值:0 - 默认不展开显示1 - 默认展开显示2 - 隐藏1.1.5isDynmcGrp表示该组是否可以动态添加、删除0 - 不可以1 - 可以1.1.6grpInd组序号，用来标示在界面中的显示顺序1.1.7isPubGrp表示该组是否是公共组，如果该组为公共组的话在界面上只会展现一次。可选取值：1 是0 否1.1.8trgrEvNm组触发事件标志，对于一些动态组，会在触发事件中写明校验内容。1.1.9actChnlSet组的使用渠道，该节点以逗号分隔每个可用渠道的渠道类型代码。例如：0001,0002,00031.2grpData组数据节点。用来标示组内界面元素的信息。具体内容在下一章节展示3. 界面元素信息层级节点名称说明1element元素节点。页面中每一个输入元素（每个输入元素前的描述文字label不作为输入元素对待，而是以输入元素的一个属性对待）在模板数据中表示为一个element 节点数据。在一个grpData节点中可以存在多个element节点，且element节点不是必输项。1.1id元素节点对应的编号。取值通常从1，在每个grpData中必须唯一。在每个元素节点中，编号必须存在且唯一。1.2key元素对应的key(域名称),将作为页面中输入元素的name属性，并作为回送服务端的请求报文中的key。用来在组报文时对应使用。域名称节点必须存在且唯一。1.3label元素对应的文字描述。为操作者展示在界面中使用。该节点在文件中必须存在且唯一。1.4elmtType元素类型节点。用于标识元素在页面中应该渲染成何种pjf组件。可选取值：00 - textField(单行文本框)01 - textArea(多行文本框)02 - dateInput(日期输入框)03 - select(下拉框 - 单选)04 - identityCard(刷证件)05 - cardReader(刷卡折)06 - password(密码录入)07 - checkbox(复选框)08 - hidden(隐藏域 - 用于传递不在页面显示的数据)1.5categoryId元素对应数据编码（企业级标准数据/应用级数据）。当元素为下拉框或者预留的复选框时，下拉框或者复选框的可选值选项数据将通过该节点值查询数据取值。当元素类型节点为03或07时必填。1.6stdDataInd是否为企业级标准数据标识。当元素为下拉框或者预留的复选框时，下拉框或者复选框的可选值选项数据将通过categoryId节点值查询数据取值。stdDataInd节点值标识categoryId对应数据是否为企业级标准数据。企业级标准数据和应用级数据的来源不同。可选值：1 - 是0 - 不是1.7dfaltVal元素默认值。1.8inputProp输入属性。用于标识元素是否可以输入以及是否必须。该节点在元素类型不为08时必填。可选值：0 - 必须输入1 - 非必输2 - 不能输入1.9tips界面提示信息，由保险公司配置在界面中的提示内容。1.10trgrEvNm当该字段在前端页面会触发事件时填写事件名。1.11dmnId元素对应域编号（企业级标准数据/应用级数据）。当元素为下拉框或者预留的复选框，是否为企业级标准数据标识为是时，下拉框或者复选框的可选值选项数据将通过该节点值在数据字典代码表中获得1.1.9actChnlSet字段的使用渠道，该节点以逗号分隔每个可用渠道的渠道类型代码。例如：0001,0002,00031.1.10rule元素的校验规则，每个元素可以同时存在多个校验规则。1.1.10.1name元素的校验规则的名字校验规则可选值如下：dataType - 元素数据类型可选取值：0 - text普通文本1 - money提供金额三位分割显示2 - card提供账号4位分割显示3 - number数字类型precision - 元素数据如果允许小数，该域标识小数的精度可选取值：minLen - 元素数据如果为文本，该域标识允许的最小长度maxLen - 元素数据如果为文本，该域标识允许的最大长度minVal - 元素数据如果为数字，日期，该域标识允许的的最小值maxVal - 元素数据如果为数字，日期，该域标识允许的的最大值校验规则约束:dataType - 当elmtType为0时可以出现precision - 当elmtType为0且dataType为3时可以出现minLen -（- 当elmtType为0且dataType 为0或者2时可以出现- 当elmtType为1、4、5、6时可以出现）maxLen - （- 当elmtType为0且dataType 为0或者2时可以出现- 当elmtType为1、4、5、6时可以出现）minVal - (- 当elmtType为0且dataType为1或3时可以出现- 当elmtType为2时可以出现)maxVal - (- 当elmtType为0且dataType为1或3时可以出现- 当elmtType为2时可以出现)1.1.10.2value元素的校验规则的值第三章 新一代应用分析方法所谓”需求分析”，是指对要解决的问题进行详细的分析，弄清楚问题的要求，比如需要输入什么数据，要得到什么结果，最后应输出什么。需求分析顾名思义，要有东西给到手上，才能做分析的，一种是分析数据，一种是分析问题。应用分析工作从需求调查，需求收集等阶段的工作开始，到建立项目目标、需求细化、CPC（客户、场景、渠道）流程场景的还原，业务功能梳理，界面流程等，最后能够由系统来实现。初始的需求调查和需求收集虽然是有目的性，有针对性的去收集，也会反馈回来大量的需求数据，更别说无目的性的收集需求了。不过有数据总比没有数据强，需求分析人员要做的就是从这些林林总总的需求当中找出可实现的，有价值的需求，排除那些无意义，不可实现的需求，或者是当前暂时先不实现，或者是这个产品不实现但可以利用在别的产品身上的，反正与当前产品无关的需求，都需要排除掉，这个过程就是在做减法。需求分析人员要根据产品的愿景，设计理念等等去捕捉到有价值的需求，这个筛选的过程是围绕着最终实现的功能区的，并不是胡乱筛选。比如说，我们收集到10个功能需求，觉得其中有两个是没必要做的，或者是可以以后再做的，就把这2个需求功能先排除掉，先做剩下的8个功能需求。应该来说，做减法是需求分析人员最基本的素养了，一般都是有东西去给你做减法的。当收集到的需求数据无法满足现有产品的设计时，一种方式是重新做一轮需求调查，一种方式是靠需求分析人员的能力去找出新的需求来完善产品的设计，后一种方式就是做加法的过程。需求分析人员依靠自身的工作经验，和对产品设计理念的理解，可以提出新的需求，这些新的需求不一定就是最终的需求，但需求分析人员要有能力去总结发现。因为往往人们在考虑问题的时候都是不全面的，所以才古语有云，三个臭皮匠顶个诸葛亮，把所有的意见综合在一起，很有可能就是个非常棒的点。这里做加法主要还是要依靠自身的经验来取决，比如要做5个功能需求，需求分析人员觉得应该再加上报表统计的功能，这就是在做加法。一般的话要掌握一定的分析能力，会一些分析工具才行，比如UML，思维导图等等。做加法更多要看需求分析人员自身的知识储备。当我们面对一件全新的产品设计任务时，没有任何现成的数据去提供给我们做分析，或者说数据很少，这个时候需求分析人员要去挖掘需求，也可以说是发现新需求，这个新需求是全新的，没有任何经验可借鉴的。比如说轻博客需求，在此之前没有一种产品形式可以以微博的形式分享音频，视频等等富媒体。这个挖掘的能力需要锻炼才行，经常关注一些事物的本质，经常问为什么，经常去分解现有产品所提供的服务。网上卖车，网上卖房，以前从没有人做过，但随着时代的发展，这样的需求也被发掘出来了。思维导图是很好的一种挖掘需求的办法，发散思维。需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求） 1业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 2用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本说明中予以说明。3功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。在软件需求规格说明书（SRS）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个大型系统来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于子系统（或软件部件）。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时地在功能、质量上完全满足用户的期望。不适当的需求过程所引起的一些风险1. 无足够用户参与 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为开发人员感觉与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。 系统人员在实践过程中，也有些感觉，在实施一家公司的项目时，若无足够的用户参与，系统人员获得的需求是片面的，不完整的，这样系统在需求之初就埋下风险。2. 用户需求的不断增加在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。3. 模棱两可的需求 模棱两可是需求规格说明中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现，那时再发现的话会使得更正代价很大。4. 要求得到需求工作结果的解释说明 分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面。所以需求说明中 的各种图表有着极高的价值。虽然它们不太难于理解，但是你很可能对此并不熟悉。因此可以要求分析人员解释说明每张图表的作用或其它的需求开发工作结果和符号的意义，及怎样检查图表有无错误及不一致等。5. 要求开发人员对需求及产品实施提供建议，拿出主意 通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。在彻底弄清业务领域内的事情后，分析人员有时就能提出相当好的改进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性。尊重开发人员的需求可行性及成本评估所有的软件功能都有其成本价格，开发人员最适合预算这些成本（尽管许多开发人员并不擅长评估预测）。你所希望的某些产品特性可能在技术上行不通，或者实现它要付出极为高昂的代价。而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据，开发人员会对此作出负面的评价意见，你应该尊重他们的意见。有时，你可以重新给出一个在技术上可行、实现上便宜的需求，例如，要求某个行为在“瞬间”发生是不可行的，但换种更具体的时间需求说（“在50ms以内”,但若没有准确的技术分析不能轻易下结论），这就可以实现了。6. 评审需求文档和原型 对需求文档进行评审都会对软件质量提高有所帮助。让客户参与评审才能正鉴别需求文档是否的确完整、正确说明了期望的必要特性。评审也给客户代表供一个机会，给需求分析人员带来反馈信息以改进他们的工作。如果你认为编写需求文档不够准确，就有义务尽早告诉分析人员并为改进提供建议。通过阅读需规格说明，很难想象实际的软件是什么样子的。更好的方法是先为产品开发一个原型。这样你就能提供更有价值的反馈信息给开发人员，帮助他们更好地理解你的需求。必须认识到：原型并非是一个实际产品，但开发人员能将其转变、扩充成功能齐全的系统。 : 第四章 应用分析与应用开发承接的研究与实践4.1 应用分析与应用开发的承接根据应用分析对需求进行用户工作流的分析，对客户、产品、渠道进行的场景还原，业务功能的分析，界面流程的确定，进行应用设计、应用组件设计、细化设计以及应用开发工作，完成需求的实施落地工作。4.2 应用分析与应用开发承接的研究与实践需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。需求的另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。有些需求分析专家拓展了这个概念：“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。需求开发可进一步分为：问题获取、分析、编写规格说明和验证四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：确定产品所期望的用户类别。获取每个用户类的需求。了解实际用户任务和目标以及这些任务所支持的业务需求。分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。了解相关质量属性的重要性。商讨实施优先级的划分。将所收集的用户需求编写成文档和模型。评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。需求管理需要“建立并维护在软件工程中同客户达成的合同”。这种合同都包含在编写的需求文档与模型中。客户的接受仅是需求成功的一半，开发人员也必须能够接受他们，并真正把需求应用到产品中。通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）。评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。使当前的项目计划与需求一致。估计变更需求所产生影响并在此基础上协商新的承诺，这种承诺具体体现在项目解决方案上。让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。在整个项目过程中跟踪需求状态及其变更情况。让每项需求都能与其对应的设计源代码和测试用例联系起来以实现跟踪。在整个项目过程中跟踪需求状态及其变更情况。需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系。然后，你可以使客户信息结构化，并编写成文档和示意图。下一步，就可以让客户代表评审文档并纠正存在的错误。这四个过程贯穿着需求开发的整个阶段。在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为使用实例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是我们必须细化用户界面设计。已开发系统的视角细化需求应用分析过程，考虑整体流程细而全面，能够对应用分析工作的开展起到很好的促进工作，是系统开发更方便快捷。第五章 总结与展望5.1 工作总结回顾导师责任制实施一年以来的理论知识学习和参与的实践项目，我的工作可以分为四部分，一是对利用需求分析文档对系统用例、应用组件说明书、细化说明书进行编写，包括申请车险投保，查询车险保单详情，查询车型信息相关交易，二是对领导分配的交易进行后端服务代码的编写；三是协助测试人员对自己负责的交易进行测试，四是应用分析工作，编写应用分析说明书。1.对技术相关说明书进行编写：在编写各个渠道以及P8