需求分析概念及如何写好需求分析附需求分析报告例文.docx

《需求分析概念及如何写好需求分析附需求分析报告例文.docx》由会员分享，可在线阅读，更多相关《需求分析概念及如何写好需求分析附需求分析报告例文.docx（16页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、概念需求分析包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等。（1）.业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定 义与范围文档中予以说明；（2）用户需求描述了用户使用产品必须要完成的任务，应在使用实例或方案脚本中予以说明；（3）功能需求定义了开发人员必须实现的软件功能， 使用户利用系统能够完成他们的任务，从而满足业务需求；（4）非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约 束，操作界面的具体细节和构造上的限制等；（5）需求分析报告所说明的功能需求充分描述了软件系统所应具有的外部行为，在开发、测试、质量保证、

2、项目管理以及相关项目功能中起着重要作用。业务部门的主管通常阐明“业务需求”，即产品的高层次概念和主要业务内容，为后继工作建立指导性框架；但“业务需求”并不能为开发人员提供开发所需的许多细节说明。“用户需求”必须找系统的最终使用者，他们最清楚要使用该产品完成什么任务和一些非功能性的特性需求，如程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点的软件产品。业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。在实际需求分析过程中，

3、由于业务部门工作很忙，经常没有时间或者觉得没有必要与IT人员讨论需求分析，有时甚至希望IT人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则千万不能这样做。 优秀的软件产品建立在优秀的需求分析基础上，而优秀的需求分析又源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，通过对应用问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化、最终形成需求规格说明，这一系列的活动即构成软件开发生命周

4、期的需求分析阶段需求分析是介于系统分析和软件设计阶段之间的重要桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。需求分析阶段的基本任务是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件其它有效的需求。 需求确定为什么困难？ 最主要的原因是对于开发小组的使用成员(包括用户)来说，需求确定是极具认知性和创造性的活动。十项基本法则开发人员与业务部门的交流

5、需要好的方法。下面建议10条法则，开发人员和业务部门可以通过评审以下内容并达成共识；如果遇到分歧，可通过协商达成对各自义务的相互了解，以便减少日后的摩擦。先导入管理思想，再梳理业务流程。 “百闻不如一见，百见不如一尝。”没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上ERP（Enterprise Resource Planning（企业资源计划），是上个世纪90年代美国一家IT公司根据当时计算机信息、IT技术发展及企业对供应链管理的需求，预测在今后信息时代企业管理信息系统的发展趋势和即将发生变革，而提出了这个概念。 ERP是针对物资资源管理（物流）、人力资源管

6、理（人流）、财务资源管理（财流）、信息资源管理（信息流）集成一体化的企业管理软件。它将包含客户/服务架构，使用图形用户接口，应用开放系统制作。除了已有的标准功能，它还包括其它特性，如品质、过程运作管理、以及调整报告等。）系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等；CIO必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。表达要符合业务部门语言习惯需求讨论集中于业务需求和任务，必然使用各种业务术语。如果开发人员是IT厂商，CIO应将有关业务术语教给开发人员，同时还要把IT人员常用的一些术语“翻译”给业务人员

7、，做到交流畅通无阻。了解业务部门的业务及目标只有充分了解业务部门的具体业务，才能开发出满足其需求的软件。为充分了解业务人员的具体需求，CIO要和开发人员一起到业务部门去观察他们的实际工作流程，甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统，CIO还要亲自用一下目前的旧系统，明白目前系统是怎样工作的，了解其流程情况以及可供改进之处等。掌握各种沟通技巧需求分析的过程实际上是个沟通的过程，CIO要想方设法吸引业务人员说出其需求。有时候，尝试着问一些“愚蠢”的问题也有助于用户打开话匣子。如果CIO直接要求业务人员写出业务是如何实现的，十有八九无法完成；但如果尝试着问一些实际的问题，例如：“以

8、我的理解，你们收到订单后，会.”。业务人员立刻就会指出你的错误，并滔滔不绝的开始谈论业务，这一招就叫“抛砖引玉”。对业务需求进行逻辑分析业务人员对需求的表达通常是笼统、感性、琐碎的，CIO要尽量理解业务人员用于表述他们需求的思维过程，充分研究用户执行任务时决策的过程，并抽象出潜在逻辑关系，把一些“常识”性东西用逻辑来实现。例如，当IT人员与护士交流医嘱处理过程时，护士会告诉IT人 员，护理级别有特级护理、一级护理、二级护理、三级护理以等；饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来，就可能出现 同一个病人既是一级护理又是二级护理，既吃流食又吃半流食的可笑情况；这些

9、矛盾的避免原来是靠护士的大脑来判断的常识性问题，而用计算机来判断“常识”是最难的，也是最容易忽视的。经过反复探索，协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组，当护士选择特级护理的时候，自然排斥了一级、二级和三级护理。李包罗说：“在与医生、护士沟通的过程中，IT人员不是要成为临床专家或者护理专家，而是要用IT知识去梳理医生护士的要求，变成一种计算机可以实现的概念，超越了手工的功能才会受到业务部门的欢迎。”以通俗的语言编写软件需求报告IT人员应将从业务人员那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法等，然后编写软件

10、需求报告。“需求分析报告”是IT人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写；报告中可以大量使用图表，但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。描述产品的使用特性业务人员可以要求IT人员在实现功能需求的同时还注意软件的易用性，因为易用性或质量属性能使客户更准确、高效地完成任务。例如业务人员有时要求产品要“界面友好”或“健壮”、“高效率”，但对IT人员来讲，太主观了并无实用价值。IT人员可以通过询问和调查了解客户所要的“友好、健壮、高效“所包含的具体特性，具体分析哪些特性对

11、哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。业务人员和IT人员互相尊重如果业务人员与IT人员不能相互尊重，那关于需求的讨论将会遇到障碍。参与需求分析的业务人员有权要求IT人员尊重他们并珍惜他们为项目成功所付出的时间；但业务人员也要尊重IT人员的需求可行性及成本评估。所有软件功能都是有成本的，业务人员所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。IT人员会拒绝或实现不了业务人员的一些要求，业务人员也应该尊重IT人员的意见。有需求变更要立即联系 不断

12、的需求变更，会给在预定计划内完成的产品质量带来严重的不利影响，但需求变更又是不可避免的。在开发周期内变更越在晚期出现，其影响越大；变更不仅 会导致代价极高的返工，而且工期将可能被延误，特别是在主体架构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知IT人员。需求确认仅仅是以后讨论的“基线”。在“需求分析报告”上签字，通常被认为是业务部门同意需求分析报告的标志性行为，然而在实际操作中，业务人员往往把“签字”看作毫无意义的事情。有时这个领导同意了，那个领导却不同意；即使每个相关人员都签了字，也照样“翻供”，通常的理由是：“他们要我在需求文档的最后一行签名，于是我就签了，否则

13、他们不开始编码！”同样的问题也发生在仅把“签字确认”看作是完成任务的IT人员身上，一旦有需求变更出现，便指着“需求分析报告”说：“您已经在需求分析报告上签字了，所以这都是按照您的要求开发的。”-这两种态度都是不对的，因为业务人员不可能在项目早期就能说清楚所有业务需求，变更需求是必然现象。在“需求分析报告”上签字确认，仅仅是需求分析过程结束的标志，它意味着“需求分析报告”是以后讨论的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。拨开需求分析的迷雾，将给初步的需求开发工作画上双方都明确的句号，将有助于形成一个持续良好的客户与开发人员的关系，为项目成功奠定坚实的基础。需求分析的风险客户

14、有时会提一些看上去很“酷”，但缺乏实用价值的功能；若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。不重视需求分析的项目组将“自食其果”，但重视了并不一定能写出完美的需求分析报告，因为需求分析中还有很多陷阱，稍微不慎CIO就可能掉进业务需求的“陷阱”。需求分析中常见的陷阱有以下几种：首先是无足够用户参与。业务部门经常不明白为什么收集需求和确保需求质量需要费那么多功夫。由于业务部门工作很忙，有时IT人员很难与业务人员坐在一起交流业务需求；即使费了九牛二虎之力坐在一起，业务人员也讲不明白自己的真正需求。为确

15、保需求分析的质量，CIO一方面要让IT人员与尽量多的业务人员交流；另一方面，应让具有代表性的用户在项目早期就直接参与到开发队伍中来，一同经历整个开发过程。其次是业务需求无休无止。业务部门在开发中若不断补充需求，项目就可 能越变越大以致于超过计划及预算范围。计划并不总是与项目需求规模与复杂性、风险及需求变更实际情况相一致，使得问题更难解决。要想把需求变更范围控制到 最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。另一方面，CIO要确定一个提需求分析的最后时间，不能放任业务人员无休止的提需求分析。 再次是用户需求模棱两可。模棱

16、两可是需求规格说明中最可怕的问题。模棱两可的需求会使开发人员为错误问题而浪费时间，并使测试者无所适从。一位系统测试人员说，他所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。最后是不必要的“画蛇添足”。“画蛇添足”是指开发人员力图增加一些用户“欣赏”，但需求分析说明中并未涉及的新功能。有时IT人员花了非常大的力气，但用户并不认为这些功能很有用；IT人员应努力使功能简单易用，但不要未经业务人员同意，就自作主张。同样，客户有时也会提一些看上去很“酷”，但缺乏实用价值的功能；若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，

17、及时决定必须完成哪些需求，舍弃哪些需求。任何项目都不可能十全十美，也不可能满足用户的所有需求，毕竟项目的成本有限；CIO要弄清这些功能的“来龙去脉”，使得需求分析过程始终注重那些能使用户完成主要任务的核心功能。例:铁路售票系统应用软件需求分析报告目录前言：8（1）需求分析报告的编写目的8（2）产品背景明细8（3）缩写及缩略语8需求：8需求分析：8模块的独立性：10本工程描述：10（1）软件开发的目标：10（2）应用范围：10（3）硬件配置要求：10（4）子集说明：10（5）软件功能描述：10（6）软件操作人员的要求：11（7）在其他方面的要求：11软件结构化描述11（1）数据流图：11（2）数

18、据结构的描述：11设计要求：12（1）所调用的数据库的显示：12（2）关于编辑框的说明：12（3）指定记录说明：12（4）初始化说明：12（5）最大化说明：12（6）最小化说明 原理同上12（7） 查词编辑框说明（编辑框控制）12（8） 内容编辑框说明（编辑框控制）13（9）定义过滤说明13（10） 执行过滤说明13（11）同步说明：13（12）数据录入精度需求13（13）软件自身时间特性需求13（14）数据管理能力需求14接口要求：14（1）硬件接口：无特别要求14（2）网络硬件接口要求：14（3）软件接口要求：无14软件属性14（1）可用性14（2）安全性14（3）可维护性14（4）兼容性

19、15支持信息15（1）软件支持：15（2）设备支持：15前言：（1）需求分析报告的编写目的本需求分析报告的目的是规范化本软件的编写，旨在于提高软件开发过程中的能见度，便于对软件开发过程中的控制与管理，同时提出了本铁路售票系统的软件开发过程，便于程序员与客户之间的交流、协作，并作为工作成果的原始依据，同时也表明了本软件的共性，以期能够获得更大范围的应用。（2）产品背景明细软件名称：铁路售票系统软件开发者：（3）缩写及缩略语铁路售票应用系统软件：基本元素为构成铁路售票及相关行为所必须的各种部分。以下简称售票系统。需求：用户解决问题或达到目标所需的条件或功能；系统或系统部件要满足合同、标准，规范或其

20、它正式规定文档所需具有的条件或权能。（1）需求分析：包括提炼，分析和仔细审查已收集到的需求，以确保所有的风险承担者都明其含义并找出其中的错误，遗憾或其它不足的地方。（2）模块的独立性：是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。本工程描述：（1）软件开发的目标：完善目前铁路售票系统，使之能跟上时代的发展。同时通过实践来提高自己的动手能力。（2）应用范围：理论上能够实现于铁路部门的售票系统，其目的在于在原有的系统基础使得铁路售票实名化，以期实现完善日常生活中铁路售票的各种缺陷。（3）硬件配置要求：硬件外部设备需奔腾133以上的pc机，内存需16兆以

21、上。（4）子集说明：软件分别有五个模块组成，每个模块各有不同的功能。但都能完成查询和存储功能，各模块的数据都存放在数据库中。数据的调用和连接都有程序来完成。（5）软件功能描述：外部功能：实现可视化窗口，查找及存储内部功能：同步，过滤，定位，识别软件功能描述图：赔偿信息车次信息列车明细日志维护个人信息主界面同步过滤数据库定位（6）软件操作人员的要求：软件要求操作人员具有初步的相关知识（7）在其他方面的要求：由于本系统为即时软件，对数据的同步要求较高，建议配置网络时使用可靠性较高的相关网络硬件设施。软件结构化描述（1）数据流图：乘客数据库更新列车明细个人信息日志售票员（2）数据结构的描述：车票=日

22、期+价格+出发站+目的站+售票站+座号+车次+性质+编号日期=年+月+日+时+分价格=“1”.“9999”出发站=1汉字6目的站=1汉字6售票站=1汉字6座号=车厢号+座位号车次=“1”.“9999”编号=“000000001”.“999999999”性质=“1”.“6” 注：“1”表示空调硬座特快，“2”表示空调软座普快等设计要求：（1）所调用的数据库的显示：输入内容：指定的库文件名。加工内容：调用指定的数据库。输出内容：所指定的数据库的库结构。（2）关于编辑框的说明：输入内容：编辑框名称。加工内容：生成编辑框。输出内容：显示所生成的编辑框（3）指定记录说明：输入内容：指定的项名及库文件名。

23、加工内容：将指定的数据库里指定的记录置为当前记录。（4）初始化说明： 输入内容：所要求的尺寸要求处理内容：确定指定对象在窗体中的开始尺寸的大小输出内容：确定开始尺寸的四个参数。（5）最大化说明：输入内容：指定的参数值。加工内容：确定指定对象在窗体中的最大尺寸。输出内容：确定指定对象最大尺寸的四个参数。（6）最小化说明 原理同上（7）查词编辑框说明（编辑框控制）功能：主要是定义的一个编辑框，供用户输入一个词名，为程序生成查找条件做准备。输入内容：在查词编辑框中输入要查找的词名。加工内容：用输入的词名以供程序生成查找条。输出内容：地址、长度。（8）内容编辑框说明（编辑框控制）功能：主要是定义的一个

24、编辑框，将程序查找到的用户所输入词的相关内容显示出来，为用户提供帮助信息。输入内容：数据库中查找到的记录的项的内容的地址、长度。加工内容：置控制标题或值。输出内容：显示用户所输入词的相关内容（如该词的格式、用法）。（9）定义过滤说明作用：定义用户输入的词名与内容库中的词名字段中的词名进行串比较，即定义词名字段为过滤字段。输入内容：用户输入的词名。加工内容：把代码写入过滤条件指针之中。输出内容：查找条件。（10）执行过滤说明作用：将定义的过滤作为内容库的过滤条件。输入内容：查找条件。加工内容：与查找编辑框中的内容比较。输出内容：库过滤显 。（11）同步说明：I：令牌持有标记P：与数据库同步更新数

25、据O：更新数据库环境要求：（12）数据录入精度需求 在进行向数据库文件提取数据时，要求数据记录定位准确，在往数据库文件数组中添加数时，要求输入数准确。（13）软件自身时间特性需求程序响应时间：在人的感觉和视觉事件范围内；信息交换时间：要求在程序调用前调用后都与数据库保持同步更新，网络信息狡猾施加应该小于程序调用的时间（14）数据管理能力需求要求数据库具有很好的更新能力，由于本产品是实验性软件，故对磁盘和内存容量没有很高的要求，但是数据库应该能够对并发事件，脏数据具有较强的识别处理能力。接口要求：（1）硬件接口：无特别要求（2）网络硬件接口要求：现实中要求具有高速以太网组网一实现联网销售，但是在

26、理论实验验证软件本身的目的来看，无需网络通讯接口。（3）软件接口要求：无软件属性（1）可用性 本软件也可以通过单步跟踪的操作进行检查处理。（2）安全性 由于软件运行数据放在数据库中，所以参数不容易被错改、破坏，万一参数受到破坏也不会影响源程序。（3）可维护性 本软件利用数据库进行编程，系统结构由程序基本确定，大量的参数及文本内容全部放于数据库中。修改、更新数据只要在数据库进行修改添加，而不需要对系统结构进行修改，这样系统维护性、升级都十分方便。（4）兼容性 由于尚未测试，故无法对兼容性进行评析。支持信息（1）软件支持：本软件开发是使用Delphi编写。（2）设备支持：推荐配置：WindowsXP，256内存，VGA显示器