搜索
信息系统的需求管理信息技术部2015年9月软件工程的流程123需求管理什么是需求管理什么是软件需求需求管理的流程软件需求的完全严格解释1、用户解决问题或达到目标所需条件或权能(Capability)。2、系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。3、一种反映上面(1)或(2)所述条件或权能的文档说明。软件需求的完全严格解释简单来说，软件需求就是一个软件要实现的功能，当然这里所谓的“功能”可能分为两种情况，一种是有形的，一种是无形的：“有形”的很好理解，比如要求Word文档具备把字题加粗的功能。“无形”的其实也好理解，比如说软件的运行速度，稳定性，还有比如这个软件要达到什么目的（比如系统能够根据录入的具体信息，按照费率表计算出正确的保险费）。123需求管理什么是需求管理什么是软件需求需求管理的流程1、软件需求的诞生软件需求是随着计算机的发展而发展的，在计算机发展早期，软件规模很小，所以当时大家关注的是编码，而对于需求并不怎么关注，后来随着“软件危机”的出现，诞生了软件工程，而需求阶段就是软件工程的第一阶段（也称之为需求分析）。软件危机：伴随计算机系统的广泛使用，软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。2、软件需求的重要性软件需求：是软件工程的第一阶段，是软件系统最初的框架，决定了软件的可靠性、易用性、可扩展性和可维护性，对一个软件工程能否成功起决定性作用。完成了需求分析和设计，相当于完成了一项工程的图纸，而之后的编程实现只是施工阶段，掌握需求分析与设计才是掌握了一项工程的核心。2、软件需求的重要性“苹果”就是这样的公司，把最后的生产交给富士康，最终得到完美的产品。需求是将管理思想融入系统的过程，将管理思想抽象成系统需求是一个艰难的过程，需要业务管理部门与信息技术部做到密切配合，只有融入了管理思想的系统才是优秀的系统，在实际的应用过程中才具备生命力。3、如何进行软件需求管理既然软件需求如此重要，那么需求管理就自然特别重要了。需求阶段主要由这么几个阶段组成：获取用户需求（要做些什么）--策划工作（怎么去做）--评审（能不能做、做得好不好）--开发（开始做/让谁去做），需求管理对这些阶段的过程管理。第一阶段：需求获取（要做些什么）关于要做些什么，其实对于产品的需求阶段而言，是极其重要的一个环节，但我想提醒大家几点。一、角色意识，我们都是需求设计者不是用户。二、抽象需求是一个融合的过程。三、风险意识与价值成本意识。第一阶段：需求获取（要做些什么）还是拿“苹果”为例，那对于用户而言，他们关注的是实现了什么功能，是不是做得更漂亮，更薄，更强大，但是他们不关心怎么去把它做薄，做强大，用了什么材料，用了什么技术，用的是那种设计思想。我们的末级分支机构也许是用户，但总公司和二级机构的业务管理部门和信息技术部我们都是需求设计人员。第一阶段：需求获取（要做些什么）伴随公司规模和机构的不断发展，采集需求是一个非常容易的过程，发个通知很容易就能采集来很多需求，但不成体系。分离出有价值的需求，形成体系需要一个不断融合的过程，需要业务管理部门人员去了解一些系统建设的知识，同时也需要信息技术部门的人员去了解公司的业务知识。如何获取有价值的需求，就很难讲解了，从量变到质变需要的是灵感。诸葛亮借东风项目背景：赤壁大战在即，周瑜突然发现隆冬应该不会有东南风，既定的火攻策略恐难奏效，顿时气急攻心，口吐鲜血，孔明闻讯前来……项目经理：诸葛亮项目团队组长：周瑜项目时间：一周项目交付物：东风项目风险：不可预知性资源，风险极大项目运作模式：项目经理提前向当地渔民咨询了气候规律。诸葛亮借东风孔明：都督莫非有心事？周瑜：先生怎知？孔明：我有一良策，可医都督之病。（说完写了16个大字给周瑜：欲破曹公，宜用火攻，万事俱备，只欠东风）周瑜心想：Oh,MyGod！孔明真神人也。孔明摇着羽扇心道：你怎知我早就咨询了当地老渔民，否则如何借你三日大风。项目结论：借助东风火烧赤壁，蜀吴联军十万战胜曹军百万。亮曰：“为将而不通天文，不识地利，不知奇门，不晓阴阳，不看阵图，不明兵势，是庸才也”。诸葛亮的风险管理能力项目管理中对于未来趋势的判断是极为重要的，做决策时需要提前判断未来有什么风险，怎么去处理这种风险，这样项目才有可能成功。信息技术工作都是硬指标，系统的平稳运、项目按照既定的日期上线等都是风险极高的管理目标，往往业务部门提出一些会大量消耗系统资源，影响系统平稳运行的需求、邻近上线日期无法按期完成或改动程序影响版本稳定的需求，信息技术部往往会因风险太高不予实施，能够予以实施的一定是掌握了完整的可行性方案，能够做到风险可控。第二阶段：需求分析与设计（怎么去做）需求获取后就说明系统功能已确定，接下来就是如何进行需求分析和进行需求管理了，所谓的需求分析，简单点来说就是把获取的需求做出尽量准确的描述，准确反映用户的真实意图，以保障最终的产品符合要求，避免造成重复的返工和资源浪费。关于需求管理的相关规定，就不在这做详述了。需求出错的图例第二阶段：需求分析与设计（怎么去做）完整系统的需求分析与设计是较为庞大的项目工程，而我们作为新成立的保险主体，各方面的条件都不允许我们完成完整的系统需求分析与设计，时间也是不允许的，系统一般采用外包的建设方式，系统基本是拿来主义，因此我们需要做的是需求变更，优化系统。但需求变更同样需要对提出的需求做准确性的描述。第二阶段：需求分析与设计（怎么去做）保险公司的系统多数为数据处理系统，通常输入、输出、处理逻辑等三项是需求的重要组成部分，因此输入要有完整的具体项目，甚至需要有具体的附件；输出要有清晰完整的描述和具体的项目（打印输出要出具格式）；处理逻辑无非是计算公式，控制逻辑等等。一但这些要素不够齐全，会导致系统建设的项目遗漏，因此在一个项目需求形成的过程需要信息技术部与业务部门进行反复的探讨和沟通，最终形成确定的文档。第三阶段：需求评审（能不能做、做得好不好）需求评审是需求管理必须进行的处理阶段，主要是可行性、完成时间、需要的成本等方面的因素，是对需求做科学筛选的过程，是需求管理的保障。因此公司的项目需求管理办法中部门审批、相关部门审批、信息技术审批和公司领导审批等过程。信息技术部是项目需求的末端管理部门，自然也就成了需求管理部门，要求大家严格遵守需求管理办法也就成了自然的职责。123需求管理什么是需求管理什么是软件需求需求管理的流程1、需求管理必须流程化需求的管理涉及了从需求获取、需求分析、需求设计、编程实现这样一连串的过程，每个过程都是缺一不可的，而且过程之间有着必然的联系，我们不可能获取了需求就去设计开发，这样会经常发现做出来的东西不是当初的目标，主要原因是我们绕过了需求分析的阶段。所以需求的管理必须对过程的流程化非常重视，需求需要严格按照流程来处理，每个过程最好由不同的人的来处理，并且过程之间转换时，需要有审核程序。需求管理流程图2、需求管理必须有审核需求审核这个程序非常重要，需求处理的流程长环节多，每个环节都必须经过严格的审核，每个环节的失误都会导致最终结果的错误和项目的失败，因此要求每个环节对于不能审核通过的需求文档必须退回重新来过，重要环节要建立多重审核机制。3、需求管理必须欢迎变更“没有不变的需求，世上的软件都改动过3次以上，唯一的只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”需求变更是不可缺少的一个因素，即使你初期软件设计的很好，总是或多或少在后期会有些需要变更的地方，增加或者减少或者改变功能点都是有可能的，所以我们必须欢迎变更，不然的话，机构用户经常会提出这方面和那方面的问题。虽然我们必须欢迎变更，但是我们还是需要对变更做严肃的处理，对已经在开发功能做变更，会增加很多难度，成本、时间、质量都会受到影响；对已经开发完的功能做变更，潜在问题可能更多。所以我们需要一套严格的机制来确保质量。4、需求管理必须有版本控制版本控制的好处是可以随时知道以前的情况，对于需求管理而言，这个是极其重要的，因为开发设计是不断变更的工作，一但出错没有版本控制改回去都会很难，因此信息部会要求业务部门提供纸质需求，便于形成档案。5、需求管理必须有可跟踪性所谓的可跟踪性，说得简单点就是这个需求自始至终所有的过程我都能跟踪到和记录下来，这样的目的，第一、是为了能管理到整个需求变化的过程，知道这个需求谁在做，在做什么，什么时候能完成，已经修改了多少次，谁负责审核的。第二、很多时候，我们需要查找需求变更的历史，比如，这个需求完成代码后发现严重与最初的要求不符，这样就需要知道当初谁提出的需求，谁负责分析，谁负责审核。第三、形成需求变更的记录可以用来分析过去和预测未来。5、需求管理必须有可跟踪性需求管理是大家共同的工作以上是需求管理要点和过程，但我想说的是需求管理不是信息技术部一个部门能够独立管好的一项工作，系统建设工作也不单单是信息技术部的工作，信息技术部单方面搞系统建设，仅仅能做到系统流程通畅、计算准确，但这样的系统只能算及格，将业务部门的管理思想融入系统功能，系统才有灵魂和生命力，而大家共同的一项工作“需求管理”才是实现优秀系统建设的唯一手段。结束语临结束给大家讲一个小故事，有人问上帝天堂和地狱有啥差别，上帝说跟我来看，先到了地狱，看到人们坐在高台上，中间的餐桌上摆着美味佳肴，但是每个人都愁眉苦脸，仔细一看餐具比胳膊长，只能看无法享用；上帝又把这个人领到天堂，同样的环境，每个人都红光满面，边吃边聊，差别在于每个人都用长长的餐具把美味佳肴送给对面的其他人，我们的需求管理也是如此，天堂是通过合作创造出来的。谢谢