需求分析及评审步骤要求

需求分析及评审步骤要求
需求分析及评审步骤要求

需求分析及评审步骤要求

步骤要点:

1、需求调研:

1)与用户方的领导层、业务层人员、系统操作人员进行沟通,交流;

主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织

架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及

各委办局,最好能指定本次项目的接口人。

2)交流记录,采用表格的形式;

将收集到的需求进行分类,把不同模块的需求分别归类出来,按照主次

标出重点模块,并详细询问情况,这样可以初步划定需求的边界;

3)对于需要完成的功能模块,向客户索要相关文档说明;如果客户有相关的数据表格,尽量拷贝带回公司,以便后期参考;

4)每一需求模块都要写明提出需求或者交流的客户人员名字,方便后续核实;

5)跟客户一起画出功能模块的流程草图;

6)注意对客户进行诱导,讲已有的近似客户所需的功能演示给客户看,尽量让客户使用已有的,或者做一些改动,回避一些工作量大而又近似的

功能需求;

7)与客户交流,定制需求开发完成的大概时限;

2、需求总结:

1)将现场收集回来的需求整理成需求文档,并根据情况细化需求,将每个功能叙述的尽量详细;

2)将带回的数据文档进行整理,选择保留完整的、有针对性的数据;

3、需求分析:

1)和项目经理,主管一起讨论分析每个需求的可行性,整理出不确定可行的需求;

2)将需求进一步细化,最终划定需求的边界;

3)讲模糊需求挑出来进一步分析,仍有不明确的,待需求回访时进一步询问客户;

4、需求讨论:

1)召集开发主管开会讨论相关不确定可行性的需求,因为收集回来的需求不是都能够开发实现;

2)对于上述不能实现的需求,写明原因;

3)定制开发工作量及开发测试完成时间,开发、测试接口人;

4)

5、需求回访:

1)对开发提出无法实现的需求,及时和客户沟通,告知客户无法实现的原因,并寻找新的解决途径或者用近似的功能替代,做好详细记录,回公

司后提交开发;

2)提交详细需求分析的说明书,让客户确认并签字,并记录客户的意见;

3)针对开发给定的完成时间,和客户沟通,给定准确的完成时间(以保证开发充分时限为原则);

6、需求提交开发:

1)针对需求说明书一一提单,提交开发处理;

2)讲规格说明书中的相关事项提交项目经理的项目计划表中,特别是阶段性时间项;

3)指定相关事物单负责人员;

7、需求跟踪测试;

1)把控时间,保证需求在时限内开发测试完成;

2)遇到问题随时和客户沟通;

软件需求分析的详细流程

第一阶段:总体把握,了解概况 接手一个项目,不要着急去了解需求,这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通,主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门,最好能指定本次项目的接口人。 该阶段的主要工作方法:客户访谈 输出成果:业务流程报告/调查报告(对客户方的组织业务概况和企业现状的一些总结) 第二阶段:详细了解业务,梳理业务流程 通过第一阶段的调研,了解客户业务概况的前提下,经过充分的业务调研准备,开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构,尽可能多的与相关基层人员进行诱导式的访谈,与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作,发现问题,提出改进的意见和建议。 该阶段的主要工作方法:访谈、业务分析、原型设计演示 输出成果:调研分析报告、原型反馈报告、业务流程报告 第三阶段:需求细化和确认 这一阶段是在上述两个阶段成果的基础上,进行具体的流程细化、数据项的确认阶段,这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统,来提出反馈意见,并对已经可接受的报告、文档签字确认。 实现手段:拜访(回顾、确认),提交业务流程报告、数据项表;原型演示系统 输出成果:需求分析报告、数据项、业务流程报告、原型系统反馈意见(后三者可以统一归入需求分析报告中,提交用户方、监理方进行确认和存档)

软件需求分析文档

软件需求分析文档-编写概要与模式 一、软件需求前期采集部分 1、前期需求采集的方法 1.1 1.1市场调研:了解客户需求,竞争状况及市场力量,其最终目标是发现创新或改进产品的 潜在机会 1.2客户需求:通过市场信息反馈,得到一个总体的软件需求信息,进而对该项要求进行市 场调查与信息采集 1.3用户访谈:针对部分对需求功能点有意向的客户进行重点访谈,增加对功能需求的全面 了解,并且可将客户的一些基本需求及内容进行收集 1.4与直接面对客户的一线同时如销售,客服,技术支持等人员交流 1.5研究市场分析报告及文档 1.6试用竞争产品 1.7 2、前期需求采集存在的问题 2.1 区分用户需求与产品需求:用户需求是用户自以为的需求,并且经常是为了解决他们自身目前无法实现或较麻烦实现的解决方案,而产品需求,是为了适应更多的客户,找到真正的解决方案。所以,需求分析是从用户的需求出发,找到真正解决问题的方案,再转化为软件需求的过程 2.2 不完整的需求:想让用户代表能够更好的参与到完整性评价中来,就必须采用“业务导向”的组织结构,而不是让用户将一大堆技术动作翻译到自己的业务场景中去。除此之外,在实际的操作过程中还有一个要点,那就是利用树形层次结构将空管信息与微观信息进行有效的剥离 树形测试结构应该面向不同层面,决策者(高层),事物管理层(中层),操作层(基层),将需求分成不同的部分,让合适的人验证合适的部分,然后在汇总起来才是解决之道 需求规格说明书应该采用业务导向的树形层次结构来组织 2.3 缺乏用户参与 主动参与意思是与获得的利益成正比的,对于需求分析员而言,真正的专业主义是基于业务利益(解决问题,创造问题机会,提高管控力等)的沟通 2.4 不切实际的用户期望 软件的悟性和成本的不透明,简单的说,做不到是无效的,要说明为什么做不到才能解决问题 2.5 需求变更频繁 2.6 信息沟通失真 2.7 客户需求放大 需求分析人员是有必要对需求进行有效的控制的,问题出在控制的策略和方向上,如何才能缓解这一现象,应该以业务线索来组织需求,基于“Why”的层面对需求建立高层次的认识。业务场景是需求之魂 3、前期需求的分类 3.1 新增功能,功能改进,体验提升,软件bug,内部需求 3.2 需求层次:基础,扩展(期望需求),增值(兴奋需求) 4、分析需求的商业价值 4.1 重要性:重要程度,该软件功能在市场的需求量,实用性及功能卖点,是否涉及代理商

岗位分析方法与步骤

岗位分析方法与步骤 在我国,现在的大多数企业都施行了岗位责任制。在许多企业中,你都可以查阅到厚厚的一本岗位责任手册,在手册中有企业每个部门的部门职能和每个职位的岗位职责,书写得非常细致和系统。 岗位责任制的实施对企业来说应该是管理上的一个提高,但就现实情况而言,在多数企业里,岗位责任手册只是一套形式上的文件,并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作,更没有将它作为真正的依据进行绩效考评。 岗位分析的方法 一、 观察法 观察法是指职位分析人员通过对员工正常工作的状态进行观察,获取工作信息,并通过对信息进行比较、分析、汇总等方式,得出职位分析成果的方法。观察法适用于对体力工作者和事务性工作者,如搬运员、操作员、文秘等职位。 由于不同的观察对象的工作周期和工作突发性所有不同。所以观察法具体可分为直接观察法、阶段观察法和工作表演法。 1.直接观察法 职位分析人员直接对员工工作的全过程进行观察。直接观察适用于工作周期很短的职位。如保洁员,他的工作基本上是以一天为一个周期,职位分析人员可以一整天跟随着保洁员进行直接工作观察。 2.阶段观察法 有些员工的工作具有较长的周期性,为了能完整地观察到员工的所有工作,必须分阶段进行观察。比如行政文员,他需要在每年年终时筹备企业总结表彰大会。职位分析人员就必须在年终时再对该职位进行观察。有时由于间阶段跨度太长,职位分析工作无法拖延很长时间,这时采用"工作表演法"更为合适。 3.工作表演法 对于工作周期很长和突发性事件较多的工作比较适合。如保安工作,除了有正常的工作程序以外,还有很多突发事件需要处理,如盘问可疑人员等,职位分析人员可以让保安人员表演盘问的过程,来进行该项工作的观察。

需求分析方法论

需求分析方法论 原则上,需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力;在具体的任务开展上,以不干扰需求方的自主权为主,除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功,IT中心必须加强项目管理和项目分析工作,在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中,需求分析是一个项目的开端,也是项目建设的基石。在以往的信息化建设失败的案例中,80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一,就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理,用户不习惯或不愿意去用应用管理软件。作为IT中心,必须提醒需求方重视需求分析的重要性,采用必要的手段和方法来进行需求调研,同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向,才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手,而是应该先了解宏观的问题,再了解细节的问题。 一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。 S={D1,D2,D3,…Dn} 问题域Di由若干个问题(记为P)组成,每个问题对应于子系统中的一个软构件。 Di={P1,P2,P3,…Pm} 问题Pj有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3,…Fk} 需求说明书应该对于那些只想了解宏观需求的领导,和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题: 1、最好为每个需求注释“为什么”,这样可让双方(IT中心、需求方)了解需求的本质,以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性,更不能前后相矛盾。如果有二义性或前后相矛盾,则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉,当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时,需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时,用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性,为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验,随着用户对信息化建设的认识和自己业务水平的提高,他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上,历史上没有一个软件的需求改动少于三次的!所以必须接受“需求会变动”这个事实,在进行需求分析时要懂得防患于未然,尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求,以便在系统选型及实施时,将软件的核心建筑在稳定的需求上,同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色,所以也必须积极参与到需求分析的准备中来,以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才,更不可能是行业方面的专家。用户表达的需求,不同的分析人员可能

一、技术需求分析

公益性行业(农业)科研专项项目申报书 项目名称:功能性微生物制剂在农业副产物资源 化利用中的研究与示范 项目组织单位:农业部 项目申报单位:福建省农业科学院 项目首席专家:刘波博士、研究员 中华人民共和国农业部 二〇一二年四月

编写说明 1、本申报书由项目申报单位组织编写。 2、突出农业产业特点,切实围绕产业需求开展科研攻关与集成; 突出实用技术开发和示范应用,预期目标量化;突出联合协作,加强组织实施的管理创新。 3、字数控制在5000~7000字,A4纸双面打印。

一、技术需求分析 我国是农业大国,农业种植业、农业养殖业、食用菌产业和农产品加工业等生产过程大量的农业副产物,农作物副产物占整个生物产量的50-90%;如畜禽粪便排放量超过40亿吨,畜禽粪便中的N、P含量约相当于我国同期施用化肥量的80%和60%;农作物秸秆年产量达7.8亿吨(干物质量),比粮食总产量还要多;食用菌有机副产品的产量就达0.55亿吨,占食用菌总产量的60%?,甘薯淀粉加工过程则70%的生物产量成了副产物。大部分农作物副产物都被当作废料抛弃,一方面造成巨大资源浪费,另一方面造成严重环境污染。 农业副产物的资源化过程需要大量的功能性微生物,对动物排泄物、植物木质素、植物纤维、植物淀粉等农业副产物的物料进行微生物转化。适应不同性质物料的微生物筛选、物料分解能力、发酵转化机理、微生物制剂生产工艺成为技术需求的关键。围绕着农业副产物微生物转化,开发出适应农业种植业、农业养殖业、食用菌产业和农产品加工业等副产物资源化的功能性微生物制剂,将农业副产物发酵转化,形成资源生产出生物饲料、生物基质、生物肥料、生物原料,对于提升农业生产效率,资源循环利用率,农民增收具有重要意义。 我国农业发展已进入转型期,科学发展、持续发展已成为现代农业发展的要求。如何科学、高效地转化农业副产物对于促进资源可持续利用、发展循环农业,促进产业转型升级,有效保护生态环境具有重要意义,是实现国家可持续发展战略的技术需求。微生物处理法具有环保、高效、节能等特点,能从源头上控制农业副产物对环境的污染,采用微生物处理的循环利用途径是一种环境安全的有效方法,可以有效解决二次污染问题,还可产生巨大的经济效益,因此农业有机副产物微生物资源化利用,不但可以净化生活环境,还可以产生巨大的经济效益,增加农民的收入,促进新农村的建设。 二、国内外研究进展 在大田农作物(水稻、玉米、麦类、薯类、豆类等)生产过程产生的秸秆,茶叶和果树修剪后的枝叶;在植物产品加工过程产生的废渣(薯渣、蔗渣、玉米粉渣、豆渣、茶渣等)及果蔬加工后的残次品;在畜禽养殖业生产过程产生的畜禽粪便,食用菌生产过程产生的菌糠和菌棒以及大型生物制品(酿酒业、食用油、味精和生物制药)企业加工过程中产生的氨基酸、饼粕、酒糟和药渣等等。通过人工接种功能微生物制剂,促进有机农业副产品,提高终产品的质量,生产生物有机肥等产品国内外都开展了大量的相关研究。 利用农业副产物转化成生物有机肥已商品化的菌剂有日本EM菌剂、酵素菌等。我国目前得到农业部正式批准的有机物料腐熟剂有15个,临时登记产品9个。当前菌剂的研究正朝着高效、多功能、抗逆性强、方便使用方向发展。

需求分析、概要设计、详细设计的标准格式.doc

需求分析,概要设计,详细设计的标准格式 一、开发计划 (一)引言 1、目的 说明编制开发计划的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 (二)概述 1、工作内容 2、主要参加人员 3、成果 列出要提交给用户的程序文件、文档或服务的名称,及非移交 成果的名称。 4、完成的最迟期限 (三)实施计划 1、任务的分解及人员分工 列出各项任务及其负责人和主要参加人员。 2、进度 列出各任务的开始日期和完成日期。 3、关键问题 列出影响整个开发项目的关键问题,技术难度、风险及处理方 案。 (四)支持条件 1、计算机系统支持 2、需要由用户承担 二、需求分析说明书 (一)引言 1、目的 说明编制需求分析说明书的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 (二)概述 1、目标 说明本项软件开发意图、应用目标、作用范围等,以及所开发的软件与其它软件的关系。

2、用户特点 列出使用本软件的用户类型、特点、其教育程度和技术特长。 3、约束和假定 列出本软件开发工作的假定和约束。 (三)需求规定 1、对功能的规定 根据功能模型逐项说明本软件各项功能的详细需求。 列出完成各项功能所需输入,处理,输出及所需控制等。 2、对性能的规定 包括精度、时间特性要求、灵活性。 3、数据要求 数据分为静态数据和动态数据两类。 静态数据是指在程序运行过程中一般不改变的数据; 动态数据是指在运行中发生变化、需要输入输出的数据。 (1)数据描述 (2)数据采集 (3)输入输出要求 (4)其它要求 (四)运行环境规定 (1)硬件 包括处理机、网络、输入输出设备及其它设备。 (2)软件 列出支持软件。 (3)接口 包括必要的硬件接口、软件接口、通讯接口等。 (五)关于不可能实现的用户要求的说明 三、概要设计说明书 (一)引言 1、目的 说明编制概要设计说明书目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 (二)总体设计 1、需求规定 简述本系统的主要功能、性能等要求。 详见需求分析说明书。 2、运行环境 简述本系统的运行环境规定。 详见需求分析说明书。

职位分析的方法和步骤

职位分析的方法和步骤

在我国,现在的大多数企业都施行了岗位责任制。在许多企业中,你都可以查阅到厚厚的一本岗位责任手册,在手册中有企业每个部门的部门职能和每个职位的岗位职责,书写得非常细致和系统。岗位责任制的实施对企业来说应该是管理上的一个提高,但就现实情况而言,在多数企业里,岗位责任手册只是一套形式上的文件,并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作,更没有将它作为真正的依据进行绩效考评。一、问题的根源 每家企业出现这类问题的原因各不相同。归纳起来,可以总结出以下几个根源: 1.没有职位分析 一些企业从来没有进行过职位分析,岗位责任手册中的内容都是原模原样地照搬其他企业的职位职责内容,有些可能会进行一些修改,但这种修改大多是基于管理者的主观意愿进行的调整。这样草率的做法,肯定不会的作出符合企业实际情况的岗位职责。2.职位分析没有更新 有些企业也曾经做过职位分析,但"一稿定终身",企业并没有根据企业的变化来重新进行职位分析,修订岗位职责的内容,造成岗位职责的内容与实际工作不相符合。职位职责当然不会起到它的作用了。3.缺乏认真的工作态度 一些企业在进行职位分析时,起初可能充满了热情,但由于工作烦琐,职位量大,渐渐对职位分析失去了认真的态度。这样就使职位分析职位变得形式化了,并没有真实地反映出职位内容的信息,定出了不符合实际的职位描述和职位资格要求。4.缺乏一定的技术和经验 职位分析并不是一件简单的事务性职位,它要求职位分析人员有一定的专业素质和专业背景。这样工作并不是光靠工作热情就能做好。目前,我国企业现有的职位职责描述的质量都不是很高,比如有些岗位责任中只有工作内容,而没有工作责任。5.缺乏对职位资格要求的使用

需求分析主要流程

1.1主要流程 需求分析阶段的主要活动围绕需求开发进行,包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。1.1.1制定及修改需求开发计划 包括建立需求团队的组织并授权、对需求分析阶段的WBS进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容,其目的是保证各项活动有序、可控的进行。 1.1.2需求调查以及分析的过程 主要活动通过沟通、收集项目中的各级关系人的需求,形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对(软件)系统需求,分析并识别客户以及用户的需要、期望、业务要求,归纳整理后形成需求调查报告。1.1.3需求验证环节 主要通过原型(Prototype)、POC(ProofofConcept)、用例(UseCase)或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 (1)原型(Prototype)模拟最终软件的屏幕显示,这样用户可以看到最终软件将是什么样,有些原型可以模拟实际的操作,对关键的输入输出数据也可以一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 (2)POC(ProofOfConcept)原意是“为观点提供证据”。对于关键的技术或者业务模型,论证需求、设计的可实施性,评估和确认概念设计方案,POC的评价可能引起需求和设计的调整。一般来说,进行POC的条件:1.论证业务中涉及到的模型或者算法的可行性。2.论证技术模型实现的可行性、成本等。 (3)用例(UseCase):对(软件)系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场

软件需求分析重点-

软件需求分析重点 第1 章软件需求基础知识 返工的成本占了总开发成本的30%-50%,而对于返工的情况,70%-80%是国需求错误引起的。(11) 在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求,就会作出过于乐观的估计,最终不可避免地陷入超支的泥潭。(13-14)造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时,应该提供范围(最好的情况,最可能的情况和最糟的情况)或把握程度(“我有九成把握在三个月内完成”)。(14) 从产品的实际用户处收集需求这一过程是不可替代的。(18) 第2 章客户眼中的需求 某些需求问题源于混淆了不同层次的需求(业务需求、用户需求和功能需求)。(19) 要想开发出优秀的软件产品,必须以优质需求为基础精心制定计划。(20)不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。(22) 需求审阅是最有价值的保证软件质量的活动之一。(25) 需求批准过程的所有参与者都应该明白签字意味着什么,否则会出现很多问题。(25) 不可能在项目初期就能明确所有的需求,需求肯定要随时间的推移而发生变化。(26) 第3 章需求工程的推荐方法 熟练的需求分析员应具备以下特点:耐心,思维条理性强,有良好的交际和沟通能力,理解产品应用领域,并且掌握丰富的需求工作技术。(29)为每类用户选择代言人(31)

观察用户工作的过程(31) 跨项目重用需求(32) 过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。(37)38图表 不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。(38) 第4 章需求分析员 相比缺乏经验的需求分析员,使用经验丰富的需求分析员能使项目所需求的工作量减少三分之一。(42) 优秀的需求分析员应同时具备出色的交流、引导和人际交待能力,具备技术和业务领域的丰富知识,以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。(44) 需求分析员必须研究可能出错的情形。(44) 第5 章确定产品前景与项目范围 第6 章获取客户的需求 能否让开发人员更准确地了解用户需求,将决定软件需求工作能否取得成功,进而影响到软件开发的成功。(62) 项目伊始就应确定谁来担任问题的决策人。(72) 第7 章聆听客户的需求 需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。(75) 需求获取的参与者在理解问题之前要抵制住诱惑,不要急于设计系统。 要强调用户任务,而不是用户界面,要强调根本需要,而不是用户表达出来的期望,这样有助于项目团队避免过早是制定设计的细节。 在软件开发中,需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。(76)

职位分析的方法和步骤

职位分析的方法和步骤 在我国,现在的大多数企业都施行了岗位责任制。在许多企业中,你都可以查阅到厚厚的一本岗位责任手册,在手册中有企业每个部门的部门职能和每个职位的岗位职责,书写得非常细致和系统。 岗位责任制的实施对企业来说应该是管理上的一个提高,但就现实情况而言,在多数企业里,岗位责任手册只是一套形式上的文件,并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作,更没有将它作为真正的依据进行绩效考评。 职务分析的方法 一、观察法 观察法是指职位分析人员通过对员工正常工作的状态进行观察,获取工作信息,并通过对信息进行比较、分析、汇总等方式,得出职位分析成果的方法。观察法适用于对体力工作者和事务性工作者,如搬运员、操作员、文秘等职位。 由于不同的观察对象的工作周期和工作突发性所有不同。所以观察法具体可分为直接观察法、阶段观察法和工作表演法。 1.直接观察法 职位分析人员直接对员工工作的全过程进行观察。直接观察适用于工作周期很短的职位。如保洁员,他的工作基本上是以一天为一个周期,职位分析人员可以一整天跟随着保洁员进行直接工作观察。 2.阶段观察法 有些员工的工作具有较长的周期性,为了能完整地观察到员工的所有工作,必须分阶段进行观察。比如行政文员,他需要在每年年终时筹备企业总结表彰大会。职位分析人员就必须在年终时再对该职位进行观察。有时由于间阶段跨度太长,职位分析工作无法拖延很长时间,这时采用"工作表演法"更为合适。 3.工作表演法 对于工作周期很长和突发性事件较多的工作比较适合。如保安工作,除了有正常的工作程序以外,还有很多突发事件需要处理,如盘问可疑人员等,职位分析人员可以让保安人员表演盘问的过程,来进行该项工作的观察。 在使用观察法时,职位分析人员应事先准备好观察表格,以便随时进行记录。条件好的企业,可以使用摄象机等设备,将员工的工作内容记录下来,以便进行分析。另外要注意的是,有些观察的工作行为要有代表性,并且尽量不要引起被观察者的注意,更不能干扰被观察者的工作。 二、问卷调查法 职位分析人员首先要拟订一套切实可行、内容丰富的问卷,然后由员工进行填写。问卷法适用于脑力工作者、管理工作者或工作不确定因素很大的员工,比如软件设计人员、行政经理等。问卷法比观察法更便于统计和分析。要注意的是,调查问卷的设计直接关系着问卷调查的成败,所以问卷一定要设计得完整、科学、合理。 国外的组织行为专家和人力资源管理专家研究出了多种科学的,也很庞大的问卷调查方法。其中比较著名的有: 1.职位分析调查问卷PAQ 职位分析调查问卷是美国普渡大学Purdue University的研究员麦考米克等人研究出一套数量化的工作说明法。虽然它的格式已定,但仍可用之分析许多不同类型的职位。PQA有194个问题,计分为六个部分:资料投入、用脑过程、工作产出、人际关系、工作范围、其他工作特征。 2.阀值特质分析方法TTA 劳普兹Lopez等人在1981年设计了"阈值特质分析"TTA问卷。特质取向的研究角度是试图确定那些能够预测个体工作成绩出色的个性特点。TTA方法的依据是:具有某种人格特性的个体,如果职位绩效优于不具有该种特制者,并且特质的差异能够通过标准化的心理测验反映出来,那么就可以确定该特质为完成这一工作所需的个体特质之一。

软件需求分析方法

需求分析方法 一需求分析概括 需求分析应该先了解宏观的问题,再了解细节的问题。 一个应用软件系统(记为S)的涉及面可能很广,可以按不同的问题域(记为D)分类,每个问题域对应于一个软件子系统。 S={D1,D2,D,…Dn} 问题域Di由若干问题(记为P)组成,每个问题对应于子系统中的一个软构件。 Di={P1,P2,P3,…Pn} 问题Pi有若干个行为(或功能,记为F),每个行为对应于软构件中的实现接口。 Pj={F1,F2,F3,…Fk} 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时,应该注意两个问题: 1.最好为每个需求注释“为什么”,这样可以让程序员了解需求的本质,以便选用最合适 的技术来实现此需求 2.需求说明不能有”二义性”,更不能前后矛盾。如果有二义性或前后矛盾,即要重新分 析此需求。 二需求分析方法论 第一阶段:“访谈式”

第一阶段是和具体用户方的领导层、业务层人员的访谈沟通,主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局,最好能指定本次项目的接口人。 实现手段:访谈、调查表格 输出成果:调查报告、业务流程报告 第二阶段:“诱导式” 结合第一阶段的基本信息,做出简单的用户流程页面,同时结合以往的项目经验对用户采用诱导式,启发式的调研方法和手段,和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO,感受整个业务流程的设计合理性、准确性等等问题,以及提出改进意见和方法。 实现手段:诱导(拜访)、原型演示 输出成果:调研分析报告、原型反馈报告、业务流程报告 第三阶段:“确认式” 此阶段在上述两个阶段成果的基础上,进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。通过审查,提出反馈意见,并对已经可接受的报告、文档签字确认。 实现手段:拜访(回顾、确认),提交业务流程报告、数据项表;原型演示系统 输出成果:需求分析报告、数据项、业务流程报告、原型系统反馈意见(后三者可以统一归到需求分析报告中)

需求分析概述

需求分析概述 在具体的研究需求分析之前,我们先了解一下软件工程这个概念。软件工程分为三个层次,过程层、方法层、工具层。在最基础的过程层,最重要的就是一组被称为关键过程区域(KPAs)的框架(KPA的概念在讨论CMM的书中有详细的概念说明)。关键过程区域构成了软件项目的管理控制的基础,并且确立了上下文各区域的关系,其中规定了技术方法的采用、工程产品的,模型、文档、数据、报告、表格等,等的产生、里程碑的建立、质量的保证及变化的适当管理。方法层主要是过程在技术上的实现。它解决的问题是如何做。软件工程方法涵盖了一系列的任务:需求分析、设计、编程、测试、维护。同时他还包括了一组基本原则,控制了每一个的关键过程区域。工具层就很好理解了,他对过程层和方法层提供了自动和半自动的支持。这些辅助工具就称为CASE。 可以看到需求分析的位置,但是事实上需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层,同时也涉及到一些过程层的思想,至于工具层则不再我们的讨论之列,但是会提到一些很适合在需求分析时应用的工具,诸如Word、Excel、Visio等。 方法 需求分析都包括了哪些方法呢?这里列举出在《需求分析》一书中推荐的一些方法, 1. 绘制系统关联图,这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。 2. 创建用户接口原型,当开发人员或用户不能确定需求时,开发一个用户接口原型—一个可能的局部实现—这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。 3. 分析需求可行性,在允许的成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。 4. 确定需求的优先级别,应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。 5. 为需求建立模型,需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。 6. 创建数据字典,数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 7. 使用质量功能调配,(QFD)是一种高级系统技术,它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。QFD将需求分为三类:

岗位分析分类法的具体操作步骤

?分类法 ?排列法 ?点数法 ?配对比较法 ?点数加权法 ?工资市场调查 分类法 分类法是排列法的改革,又称归级法。它是在岗位分析基础上,采用一定的科学方法,按岗位的工作性质、特征、繁简难易程度、工作责任大小和人员必须具备的资格条件,对企业全部(或规范范围内)岗位所进行的多层次的划分,即先确定等级结构,然后再根据工作内容对工作岗位进行归类。 这种方法中,最关键的一项工作是确定等级标准。各等级标准应明确反映出实际上各种工作在技能、责任上存在的不同水平。在确定不同等级要求之前,要选择出构成工作基本内容的基础因素,但如何选择因素或选取多少则依据工作性质来决定。在实际测评时,应注意不能把岗位分解成各构成要素,而是要作为整体进行评定。岗位分类同企业单位以外的职业分类标准存在密切的联系。各类职业分类标准是以企业单位、国家机关岗位分类为基础制定的。一旦这类标准建立之后,企业单位在进行岗位分类时,便可依据、参照或执行这类标准。 (一)分类法的具体操作步骤 1、岗位分析。和其他方法一样,岗位分析是基础的准备工作。由企业内专门人员组成的评定小组,收集各种有关的资料、数据,写出调查报告。 2、岗位分类。按照生产经营过程中各类岗位的作用和特征,首先将全部岗位划分为若干个大类。然后在划分大类的基础上,再进一步按每一大类中各种岗位的性质和特征,划分为若干中类。最后,再根据每一种类中反映岗位性质的显著特征,将岗位划分为若干小类。 3、建立等级结构和等级标准。由于等级数量、结构与组织结构有明显的关系,因此这一步骤比较重要和复杂。它包括以下三个方面: (1)确定等级数量。等级的数量取决于工作性质、组织规模、功能的不同和有关人事政策。不同企业根据各自的实际情况,选择一定的等级数量,并没有同一的规定和要求。但无论是对单个的职务还是对组织整体都要确定等级数量。 (2)确定基本因素。通过这些基本因素测评每一职位或工作岗位的重要程度。当然,不同的机构选择的因素也不同,应根据实际情况灵活处理。 (3)确定等级标准。因为等级标准为恰当的区分工作重要性的不同水平以及确定工作评价的结果提供了依据,所以它是这一阶段的核心。在实际操作中,一般是从确定最低和最高的等级标准开始的。 4、岗位测平和列等。等级标准确定后,对岗位的测评和列等就根据这些标准,将工作说明书与等级标准逐个进行比较,并将工作岗位列入相应等级,从而也评定出不同系统、不同岗位之间的相对价值和关系。 对小企业来说分类法的实施相当简单,若应用到由大量工作人员的大企业,则会变

需求分析方法主要步骤

1.1主要步骤 遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。 需求涉及的方面有很多。 在功能方面,需求包括系统要做什么,相对于原系统目标系统需要进行哪些修改,目标用户有哪些,以及不同用户需要通过系统完成何种操作等。 在性能方面,需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。 在运行环境方面,需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求,以及对操作系统、数据库和浏览器等软件配置的要求。 在界面方面,需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求,识别问题 开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题,要满足哪些限制条件,这个过程就是对需求的获取。开发人员通过调查研究,要理解当前系统的工作模型和用户对新系统的设想与要求。 此外,在需求的获取时,还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如,多长时间需要对系统做一次备份,系统对运行的操作系统平台有何要求,发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求,开发人员应该采取科学的需求获取方法。在实践中,获取需求的方法有很多种,比如,问卷调查、访谈、实地操作、建立原型和研究资料等。 问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析,开发人员便可以得到一些有用的信息。采用这种方法时,调查问卷的设计很重要。一般在设计调查问卷时,要合理地控制开放式问题和封闭式问题的比例。 开放式问题的回答不受限制,自由灵活,能够激发用户的思维,使他们能尽可能地阐述自己的真实想法。但是,对开放式问题进行汇总和分析的工作会比较复杂。 封闭式问题的答案是预先设定的,用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理,但是会限制用户的思维。 访谈通过开发人员与特定的用户代表进行座谈,进而了解到用户的意见,是最直接的需求获取方法。为了使访谈有效,在进行访谈之前,开发人员要首先确定访谈的目的,进而准备一个问题列表,预先准备好希望通过访谈解决的问题。在访谈的过程中,开发人员要注意态度诚恳,并保持虚心求教的姿态,同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样,开发人员要根据用户的身份特点,进行提问,给予启发。当然,进行详细的记录也是访谈过程中必不可少的工作。访谈完成后,开发人员要对访谈的收获进行总结,澄清已解决的和有待进一步解决的问题。 关注用户的行为而不是他们的言语。

需求分析报告编写规范

需求分析报告编写规范 文件编号: NW503101 生效日期: 2000.3.20 受控编号: 密级:秘密版次:Ver2.1 修改状态:总页数16 正文 4 附录12 编制:杨利审核:袁淮批准:孟莉

沈阳东大阿尔派软件股份有限公司(版权所有,翻版必究)

文件修改控制

目录 1. 目的 2. 适用范围 3. 术语及缩略语 4. 编写规范 4.1排版规范 4.2模板使用 5. 引用文件 5.1NW503102《软件功能规格说明书编写规范》 6. 附录

1.目的 为使需求分析的结果能够完整、无遗漏地反映待开发系统的要求,本文件规定《需求分析报告》的编写格式和内容要求。 2.适用范围 适用于本公司软件产品或软件项目的需求分析报告的编制。 3.术语及缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 4.编写规范 4.1排版规范 1)整个规范由2节构成,模板单独一节。 2)正文样式采用“规范正文”。 3)标题编号采用每节独立编号。 4.2模板使用 需求分析报告的编写可依据具体情况选用摸板的格式或编写指南的格式。 1)拷贝规范。 2)删除第一节(需求分析报告封面前的所有页)。 3)在修改完内容后,更新目录域和相关的页数域。 5.引用文件 5.1NW503102《软件功能规格说明书编写规范》 6.附录 以下部分为需求分析报告的模板与编写指南。

密级:机密 文档编号:第版分册名称:第册/共册 项目名称(项目编号) 需求分析报告 (部门名称) 沈阳东大阿尔派软件股份有限公司 总页数正文附录生效日期:年月日编制:审核:批准:

软件需求分析(案例答案)

案例one:教学管理系统(用例驱动的交互式需求获取) 以一个教学管理系统JXGL的分析与设计作为示例,说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富,工作繁多。作为一个示例,规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况,选择自己要学习的课程,并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况,以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理,包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理,负责新学期的课程选课注册工作; (2)成绩管理,负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程,打印将开设的课程目录表,供师生参 考选择。若某课程的实际选课学生少于10人,则停开该课程,把该课程从课程目 录表中删除;若某课程的选课学生多于30人,则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间,在此期间学生可以选课注册,并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后,教学管理员打印学生选课注册名单和开课通知书,送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表,获得课程信息。查询的关键词以是:课 程名,授课教师名,学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名, 授课教师名,学分。学生只允许查询自己的选课信息,不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名,性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程,按学生,按班级),印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:

如何进行软件需求分析

软件需求分析(Software Reguirement Analysis)是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。 软件需求分析是一个项目的开端,也是项目实施最重要的关键点。据有关的机构分析结果表明,我们设计的软件产品存在不完整性、不正确性等问题80%以上是需求分析错误所导致的,而且由于需求分析错误造成根本性的功能问题尤为突出。因此,一个项目的成功软件需求分析是关键的一步。 一、软件需求分析理论 如果我们用数学方法来描述软件需求分析,可以将一个应用软件定义为S,可能应用软件涉及功能性问题非常广,我们用抽象化理论分析,可以划分为各个功能域,可以用D1、D2、… Dn表示,那么,我们可以用一个表达式描述为S={D1,D2,D3,…Dn} 但是,功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成,并且每个功能对应于子系统中的一个软构件,我们可以表示为 Di={P1,P2,P3,…Pm} 同样,功能Pj有若干个行为F1、F2、F3、… Fk,每个行为对应于软构件中的实现方法 Pj={F1,F2,F3,…Fk} 一个软件包含了所有功能的集合,同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求,经过需求问题识别,进行分析、消化与综合,制订规格说明,评审,分为四个阶段,形成用户需求与设计同步,设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段,用商业化行为解决需求与实现中存在的矛盾,解决用户需求与商业化产品融通,解决规范与个性化追求。 二、软件需求分析目标 软件需求分析的主要实现目标: 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需

需求分析习题及答案

第三章需求分析 一. 填空题 1.需求分析的步骤, , , 。 2.需求分析阶段需编写的文档有,,。 3.系统规格说明,数据要求,, ,这四份文档资料是在书写文档阶段必需完成的。 4.在书写文档阶段,数据要求主要包括通过需求分析建立起来的,以及描绘数据结构的层次方框图。 5.对于计算机程序处理的数据,其数据域应包括, , 和数据结构。 6.数据内容即是。 7.把一个功能分解成几个子功能,并确定, 就属于横向分解。 8.软件需求的逻辑视图给出, 而不是实现的细节。 9. 功能一般用, 来表示。 10.结构化分析方法是, 进行需求分析的方法. 11.描述结构化分析方法的工具有,,,判定表,判定树。 12. SA方法中自顶向下的分析策略主要是和。 13.数据流图的基本组成部分有,,,。 14.数据流图的特性,,,。 15.数据流图和数据字典共同构成了系统的模型,是需求规格说明书的主要组成部分。 16.分析员通过需求分析,逐步细化对软件的需求,描述软件主要处理的,并给软件开发提供一种可转化为,和的数据与功能表示。 17.需求分析阶段研究的对象是软件项目的。 18.数据流图的基本符号包括,,,。19.在需求分析阶段常用的图形工具有,,。20.需求分析应交付的主要文档是。 二. 选择题 1. 需求分析中开发人员要从用户那里了解() A.软件做什么B.用户使用界面C.输入的信息D.软件的规模 2. 需求分析阶段的任务是确定() A.软件开发方法 B.软件开发工具C.软件开发费 D.软件系统的功能 3. 需求分析阶段最重要的技术文档之一是非曲直()。 A.项目开发计划 B.设计说明书 C.需求规格说明书 D.可行性分析报告

软件需求分析习题大全

软件需求分析习题大全 Coca-cola standardization office【ZZ5AB-ZZSYT-ZZ2C-ZZ682T-ZZT18】

习题集 一、单项选择题 1、需求分析最终结果是产生()。 A.项目开发计划 B.可行性分析报告 C.需求规格说明书 D.设计说明书答案:C 2、需求分析中,开发人员要从用户那里解决的最重要的问题是()。 A.让软件做什么 B.要给软件提供哪些信息 C.要求软件工作效率怎样 D.让软件具有何种结构 答案:A 3、需求规格说明书的内容不应包括对()的描述。 A.主要功能 B.算法的详细过程 C.用户界面和运行环境 D.软件性能答案:B 4、需求规格说明书的作用不应包括()。 A.软件设计的依据 B.用户与开发人员对软件要做什么的共同理解 C.软件验收的依据 D.软件可行性研究的依据 答案:D 5、下面关于面向对象方法中消息的叙述,不正确的是()。 A.键盘、鼠标、通信端口、网络等设备一有变化,就会产生消息 B.操作系统不断向应用程序发送消息,但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息 D.发送与接收消息的通信机制与传统的子程序调用机制不同 答案:B 6、面向对象技术中,对象是类的实例。对象有三种成份:()、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息 答案:A 7、软件需求分析阶段的工作,可以分成以下四个方面:对问题的识别、分析与综合、 制定规格说明以及()。 A.总结 B.实践性报告 C.需求分析评审 D.以上答案都不正确 答案:C 8、软件需求规格说明书的内容不应包括对()的描述。 A.主要功能 B.算法的详细过程 C.用户界面及运行环境 D.软件的性能 答案:B 9、产品特性可以称为质量属性,在众多质量属性中,对于开发人员来说重要的属性有哪些(B ) A 有效性、效率、灵活性、互操作性 B 可维护性、可移植性、可重用性、可测试性 C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性

相关文档
最新文档