医疗管理系统的需求分析报告怎么写?
展开全部 1.概念需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".百事通而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.2.需求分析的任务开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.事实上,需求文档在开发过程中一直起指导作用.3.需求分析过程可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,如图4-1所示:图4-1 需求工程域的层次分解示意图需求开发可进一步分为:问题获取、分析、编写规格说明和验证四个阶段.这些子项包括软件类产品中需求收集、评价、编写文档等所有活动.需求开发活动包括以下几个方面:确定产品所期望的用户类别.获取每个用户类的需求.了解实际用户任务和目标以及这些任务所支持的业务需求.分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息.将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件.了解相关质量属性的重要性.商讨实施优先级的划分.将所收集的用户需求编写成文档和模型.评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚.需求管理需要"建立并维护在软件工程中同客户达成的合同" .这种合同都包含在编写的需求文档与模型中.客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中.通常的需求管理活动包括:定义需求基线(迅速制定需求文档的主体).评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它.以一种可控制的方式将需求变更融入到项目中.使当前的项目计划与需求一致.估计变更需求所产生影响并在此基础上协商新的承诺,这种承诺具体体现在项目解决方案上.让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪.在整个项目过程中跟踪需求状态及其变更情况.以...
软件需求分析报告中的“需求规定
本系统是为了方便韶大学生春节订购火车票而开发的。
韶大有学生近一万五千人,春节时学生回家大都是乘坐火车, 而学生买票的途径不外是去火车站直接购买或者是通过在学校向一些专门为学生进行预定票服务的人进行订票买得车票。
对学生来说,这两种办法都很不方便,前者学生需要专程搭车去市区进行买票,而且要在火车站售票厅排队等待,因为春节人流较平时大很多,有时排队一排就是几个小时,费时费力,还不一定买的到票。
后者虽然不用出市区,但也存在排队买票难的问题,而且是进行手工登记,数据信息处理工作量大,容易出错,并且由于数据繁多,因此也容易丢失和不易于查找。
基于此,我们认为有必要建立一个韶大学生春节火车票订购管理信息系统,使学生订票买票电子化,程序化,能够及时、准确、有效的订购和查询,省去了学生订票买票难的困扰,方便韶大的学生。
在本系统中,需要建立三块功能模块来满足整个系统的需求: 针对学生:学生使用学号和密码进行登录,使用密码保护了学生的个人隐私,系统提供给学生有三个功能,有火车票预订,已订车票查询以及未付费车票退订。
针对工作人员:在工作台工作人员对学生所订的火车票进行收费操作,并根据管理人员汇总后的已付费车票信息与火车站联系进行统一购买。
针对管理人员:管理人员这个模块的功能最为复杂,管理人员的功能是对列车时刻信息、学生信息、车票订购情况信息进行管理和统计,管理人员功能的信息量大,数据安全性和保密性要求最高。
本系统需要的资源:计算机,网络(可利用校园网)。
本系统预算:建立系统大约需要人民币400元,使用期间大约需要人民币500元。
本系统效益分析:系统开发和投入使用的费用较低,既可以实现学生春节订票的电子化,方便学生,对维持学校秩序和保护学生的人身安全也有一定的保护作用。
本系统可行性分析结论:可以立即开发。
(自己根据实际情况进行修改)
软件需求分析的作用及如何进行需求分析?
软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通过对应问题及其环境的理解与分析,为问题涉及的信息、功能及系统行为建立模型,将用户需求精确化、完全化,最终形成需求规格说明,这一系列的活动即构成软件开发生命周期的需求分析阶段。
需求分析是介于系统分析和软件设计阶段之间的桥梁。
一方面,需求分析以系统规格说明和项目规划作为分析活动的基本出发点,并从软件角度对它们进行检查与调整;另一方面,需求规格说明又是软件设计、实现、测试直至维护的主要基础。
良好的分析活动有助于避免或尽早剔除早期错误,从而提高软件生产率,降低开发成本,改进软件质量。
需求工程是随着计算机的发展而发展的,在计算机发展的初期,软件规模不大,软件开发所关注的是代码编写,需求分析很少受到重视。
后来软件开发引入了生命周期的概念,需求分析成为其第一阶段。
随着软件系统规模的扩大,需求分析与定义在整个软件开发与维护过程中越来越重要,直接关系到软件的成功与否。
人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段,它贯穿于系统开发的整个生命周期。
80年代中期,形成了软件工程的子领域——需求工程(requirementengineering,RE)。
进入90年代以来,需求工程成为研究的热点之一。
从1993年起每两年举办一次需求工程国际研讨会(ISRE),自1994年起每两年举办一次需求工程国际会议(ICRE),在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。
一些关于需求工程的工作小组也相继成立,如欧洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups),并开始开展工作。
需求工程是指应用已证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。
RE可分为系统需求工程(如果是针对由软硬件共同组成的整个系统)和软件需求工程(如果仅是专门针对纯软件部分)。
软件需求工程是一门分析并记录软件需求的学科,它把系统需求分解成一些主要的子系统和任务,把这些子系统或任务分配给软件,并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。
需求工程是一个不断反复的需求定义、文档记录、需求演进的过程,并最终在验证的基础上冻结需求。
80年代,HerbKrasner定义了需求工程的五阶段生命周期:需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。
近来,MatthiasJarke和KlausPohl提出了三阶段周期的说法:获取、表示和验证。
综合了几种观点,可以把需求工程的活动划分为以下5个独立的阶段: (1)需求获取:通过与用户的交流,对现有系统的观察及对任务进行分析,从而开发、捕获和修订用户的需求; (2)需求建模:为最终用户所看到的系统建立一个概念模型,作为对需求的抽象描述,并尽可能多的捕获现实世界的语义; (3)形成需求规格:生成需求模型构件的精确的形式化的描述,作为用户和开发者之间的一个协约; (4)需求验证:以需求规格说明为输入,通过符号执行、模拟或快速原型等途径,分析需求规格的正确性和可行性; (5)需求管理:支持系统的需求演进,如需求变化和可跟踪性问题。
软件需求分析的需求类型有哪些呢?
呵呵,我前两天才用过···· 医疗管理信息系统可行性分析报告 系统建立了对医疗资源空间和属性信息的综合管理平台,有利于医疗资源布局和分配的科学决策,为卫生信息社会服务化增加了有益的内容,也为卫生电子政务的全面展开打下良好的基础。
系统具有如下特点: ? 先进性:系统充分利用现今国内外各种成熟的先进技术和设备,使系统站在一个较高的起点,具有较长的生命期。
? 实用性:系统具有良好的实用性是,确实能为医疗资源管理提供有效手段,方便其日常工作。
? 可靠性:系统的可靠性也是系统的生命力基础,因此有时宁愿舍弃一些不成熟或不实用的“先进”技术、设备,也必须保证系统的稳定性与可靠性。
? 资源共享性:网络上的所有资源,可以一体化管理,可以被各组成单元共享。
各医疗机构信息、用户信息等,不管是在卫生局局域网还是在互联网,都是统一的。
? 易用性:友好的人机交互界面,输入查询等操作直观方便,全面支持鼠标操作,尽量减少人工数据录入;提示信息简单明确,引导用户完成系统的各项功能。
联档帮助功能完整齐全,方便非计算机专业人员的学习和使用。
? 扩充性:系统基于模块化的设计,可以方便地进行扩充,当业务需要新的功能时,可以方便地进行扩充,保持系统的生命力。
基本医疗管理信息系统 1998年,国务院发布了《关于建立城镇职工基本医疗保险制度的决定》(国发[1998]44号文件),要求城镇所有用人单位包括企业、机关、事业单位、社会团体、民办非企业单位及其职工都要参加基本医疗保险,实行属地管理;基本医疗保险费用由用人单位和职工双方共同负担;用人单位缴费率应控制在职工工资总额6%左右,职工缴费率一般为本人工资收入的2%。
医疗保障制度改革是我国社会保障制度改革的重要组成部分,其目标是适应建立社会主义市场经济体制和提高职工健康水平的要求,建立社会统筹医疗基金与个人医疗帐户相结合的社会医疗改革制度。
建立符合中国国情的医疗改革新制度,是建立多层次社会保障体系的重要内容,是完善社会保障体系的重大举措,意义重大影响深远。
基本医疗保险是社会保险中的一个新兴险种。
基本医疗保险以其覆盖面广、涉及人员多、情况复杂、对社会贡献大等特点,使其在劳动保险中占据了重要的位置;是继基本养老保险之后的又一重要的基本社会保险险种。
基本医疗保险的业务量巨大,所需信息分布地域广,只靠增加业务人员不能从根本上解决问题,而运用现代化手段,建设庞大的计算机网络,加强科学管理,向现代化要效益,向自动化要人力,向网络化要信息,提高业务、办公效率和质量是根本出路。
基于基本医疗保险软件系统具体的需求分析,该系统 将在实施过程中进行修改或重新开发,其主要的功能模块如下: 一、基本医疗保险收缴系统 (一)单位管理 1、单位概况 2、单位缴费史 3、单位特殊政策 4、单位基数核定情况 5、催缴(交)通知单 6、记应收帐日志 7、单位概况日志 (二)个人管理 1、职工概况 2、职工缴费史 3、职工医疗个人帐户 4、职工医疗个人帐户结息 5、职工概况日志 6、职工转移日志 二、基本医疗保险结算系统 1、基本信息 2、医疗待遇审核 3、基本医疗统筹金支付 4、基本医疗统筹金支付审批 5、支付政策 6、支付单位特殊政策 7、定点医院管理 8、医院机构类别 9、支付历史 10、定点药店管理 11、支付历史 12、基本医疗统筹金支付医院汇总 13、银行数据接口 14、药品目录 15、诊疗费目录 16、服务设施费目录 17、手术项目目录 18、药品类型 19、药品剂型 20、病种管理 21、病种类型编码 22、病种类型与医疗费关系 三、票据子系统 1、托收单据 2、生成银行数据 四、定点医院管理系统 1、住院登记 2、医嘱管理 3、床位管理 4、押金管理 5、住院费用审核 6、住院费用结算 7、挂号管理 8、门诊费用审核 9、门诊费用结算 10、特殊病种统筹基金支付审核结算 11、药房管理 12、与医院系统接口管理 五、定点药店管理系统 1、医疗保险范围内售药 2、医疗保险范围外售药 3、当日售药记录 4、进药管理 5、药品库存管理 6、售药统计 7、进药统计 8、药品排行分析 9、药品销售趋势分析 六、 IC卡管理子系统 1、密钥管理 2、制、发卡管理 3、挂失、损坏补发管理 4、黑名单管理 5、单位用卡情况统计 七、统计报表子系统 1、专管员业务办理情况 2、应办未办统计表 3、单位欠费情况 4、统筹金使用情况 5、退休人员医疗费用情况 6、离休人员医疗费用情况 7、二等乙级医疗费用情况 8、单病种医疗费统计 9、同病种医疗机构医疗费统计 10、投保单位医疗费统计 11、大病病种医疗费统计 12、门诊住院医疗费统计 13、外地就诊医疗费统计 14、累计分段医疗费统计 15、医疗机构医疗费统计 . ........ . ........ . ........ 八、参量管理子系统 1、社会环境信息 2、医疗保险基金收费政策 3、医疗保险统筹支付政策 九、公众服务系统 1、基本医疗保险政策查询 2、基本医疗保险知识问答 3、社会保险机构介绍 4、本市基本医疗保险制度改革发展情况 5、单位缴费情况查询 6、医疗个人帐户查询 . ........ . ........ ......... 十、系统维护子系统 1、用户管...
怎样做软件的需求分析?
展开全部 软件需求的定义:(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
实通俗的讲,“需求”就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。
需求工程的定义:需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。
需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动,分为四个阶段:情况获取、分析、制订规格说明和评审。
这四个阶段不一定是遵循线性顺序的,他们的活动是相互独立和反复的。
需求管理是软件项目开发过程中控制和维持需求约定的活动,它包括:变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法:(1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
(2)可行性分析:在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
(4)系统原型:当用户自身对有的需求不十分清楚时,我们可以建立一个系统原型,用户通过评价原型更好地理解所要解决的问题。
。
(5)图形分析模型:绘制图形分析模型是编制软件需求规格说明重要手段。
它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。
这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
(6)数据字典:数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。
在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面:1)确定需求变更控制过程。
制定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此过程。
2)进行需求变更影响分析。
评估每项需求变更,以确定它对项目计划安排和其它需求的影响,明确与变更相关的任务并评估完成这些任务需要的工作量。
通过这些分析将有助于需求变更控制部门做出更好的决策。
3)建立需求基准版本和需求控制版本文档。
确定需求基准,这是项目各方对需求达成一致认识时刻的一个快照,之后的需求变更遵循变更控制过程即可。
每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。
4)维护需求变更的历史记录。
将需求变更情况写成文档,记录变更日期、原因、负责人、版本号等内容,及时通知到项目开发所涉及的人员。
为了尽量减少困惑、冲突、误传,应指定专人来负责更新需求。
5)跟踪每项需求的状态。
可以把每一项需求的状态属性(如已推荐的,已通过的,已实施的,或已验证的)保存在数据库中,这样可以在任何时候得到每个状态类的需求数量。
6)衡量需求稳定性。
可以定期把需求数量和需求变更(添加、修改、删除)数量进行比较。
过多的需求变更"是一个报警信号",意味着问题并未真正弄清楚。
4.需求分析评价标准(1)清晰:目前大多数的需求分析采用的仍然是自然语言,自然语言对需求分析最大的弊病就是它的二义性,所以开发人员需要对需求分析中采用的语言做某些限制。
例如尽量采用主语+动作的简单表达方式。
需求分析中的描述一定要简单,千万不要采用疑问句、修饰这些复杂的表达方式。
除了语言的二义性之外,注意不要使用行话,就是计算机术语。
需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。
(2)完整:需求的完整性是非常重要的,如果有遗漏需求,则不得不返工,在软件开发过程中,最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。
但实际情况是,需求的遗漏是常发生的事情,这不仅仅是开发人员的问题,更多发生在用户那里。
要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各个方面,贯穿整个过程,从最初的需求计划制定到最后的需求评审。
(3)一致:一致性是指用户需求必须和业务需求一致,功能需求必须和用户需求一致。
在需求过程中,开发人员需要把一致性关系进行细化,比如用户需求不能超出预前指定的范围。
严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
(4)可测试:一个项目的测试从什么时候开始呢?有人说是从编码完成后开始,有人说是编码的时候同时进行单元测试,编码完成后进行系统测试,这些结论都不完全正确。
实际上,测试是从需求分析过程就开始了,因为需求是测试计划的输入和参照。
这就要求需求分析是可测试的,只有系统的所有需求都是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。
转载请注明出处51数据库 » 医疗软件需求分析报告