分析总结实用4篇

【导言】此例“分析总结实用4篇”的文档资料由阿拉题库网友为您分享整理，以供您学习参考之用，希望这篇资料对您有所帮助，喜欢就复制下载支持吧！

分析总结1

截止2006年6月30日，公司总人数为1254人，参加考评人数1220人（包括门点26人）。综合半年的绩效考核情况，我们从数据及填写情况进行分析：

一、生产质量中心：

一月二月三月四月五月六月

90分以上99342619

80—89分242242227317372

70—79分15015092171198

60—69分101063931

60分以下00040

优点：1、部分中心领导对分管部门责任人的考核比较有针对性，能体现部门阶段目标，考核有重点，如程总每月对质检部负责人的考核就对加强质量管理方面提出了要求和方向；

2、中心部门大部分员工对考核总结都比较重视，基本上反映了其上月工作情况，填写也较规范，如生产部大部分员工填写很规范，有自评和领导考评，有分析和改进方向及措施；

3、分管领导大部分都较重视绩效的填写质量，如每月中心主要领导张总对生产部、质检部所交绩效都进行查阅；

4、部门员工对照其具体工作，能有针对性地提出一些好的建议，如生产部部分员工经常对如何改进工作环境、提高工作效率、提升工作质量提出了一些不错的建议；

当然从整个中心的填写及交纳情况，也存在着不少问题：

1、虽然大多数中心领导比较重视，但还是有部门领导不重视，如维修部连续几个月无领导考评，部门员工考评有人的情况还时有发生；

2、交纳《绩效考核表》时间不及时，在六月份整个中心《绩效考核表》都未能及时上交，直至人力资源部多次催交才于7月7日左右陆续交齐；

3、员工自评还有计流水帐的现象，如质检部部分一检，特别是新员工对工作总结无分析无改进计划，月小结形同流水帐，对自己工作的分析和查找不深入，甚至有个别的根本没有开展，改进措施针对性不够强，不具有持续性，特别是质检部大部分一检和二检，绩效考核如同打草稿，随意性太强；

4、绩效考核没有进行有效的公示和反馈，不能形成一个很好的考核渠道，甚至有时出现“上传下不达，下请上无示”的局面，部门间的信息（特别是管理信息）不畅通，对员工的心声、思想动态不能有效及时地把握；部门没有及时做好沟通，如生产部、质检部有些员工对照其工作提出了一些好的建议，而部门领导或分管负责人没有重视或根本没有细看，致使这些建议和意见无反馈，问题还是存在，成了一个长期的问题；

5、考评流于形式，有的只提优点，不指出缺点，不能全面地反映各工岗的实际工作情况，或考评无依据，尺度不一，有打人情的现象，如质检部5月份各班班长对班组员工的绩效考评没有针对性，不能真实反映其工作中的优、劣处，更谈不上指导工作了，而且不同班组间考评分的数值相差较大，致使表现相近的人分值相差较大，不能很好的评价员工工作的好坏，如质检部5月份绩效考核表中，杜祖灯共考评27人，其中75分以下的有11人，占%；而同部门的张家平考评的21人中，低于75分的仅有2人，占%；

6、填写不规范，情况很多。如维修部4月份陈新文的绩效考核可以明显看出字迹是他人代填的，维修部部长考核表无人考评（其绩效考核是），且部长对员工的考核由统计人员。

二、供应中心：

一月二月三月四月五月六月

90分以上11141

80—89分2525241420

70—79分11111353

60—69分22500

60分以下00000

优点：1、由于年初供应部实施了绩效与奖金挂钩的绩效制度，在一定程度上促使供应部由上自下都比较重视绩效考核；

2、原料仓储部大部分员工都能认真填写《绩效考核表》，填写比较工整和规范，反映的工作比较实在和有针对性，对下一步的工作都提出了计划和目标。

但从供应中心上半年绩效总体情况看，我们也可以看到供应中心也存在着一些问题：

1、原料仓储部交绩效考核表一直很及时，但由于6月其部门人员分散，给绩效考核带来困难，因此未能及时交人力资源部；

2、供应部绩效考核表一直未能及时交人力资源部，在七月初才将其部门4、5、6月绩效一起交人力资源部，给绩效考核总结与分析带来了极大的麻烦。可以想象该部门的绩效一定缺乏反馈与沟通，更谈不上发现和解决绩效考核中存在的问题。

三、技术研发中心：

一月二月三月四月五月六月

90分以上223131

80—89分303025303016

70—79分77810139

60—69分001200

60分以下000000

优点：1、大部分员工都比较重视绩效考核，如应用技术、推广部员工很重视填写绩效考核表，从该部门5月份的绩效考核表中可以看出，员工在填写绩效考核表时很认真，充分总结、分析了自己的工作，且提出了很多建议

2、考核内容修改较为及时，有一定的针对性，对考评提供了一定的依据，起到了一定的以数据、指标考核人的作用。

缺点：1、交表不及时，技术研发中心各部门交绩效考核表都很滞后，研发部在六月中旬才将其部门1、2、3、4、5月的绩效考核表交人力资源部；

2、领导考评由上自下的表现得十分随意，考评评语没有很好地对照其工作实际，无太多依据、不严谨，甚至无考评，还有如售后服务部4、5、6月绩效考评部门领导对员工的考核评语比较雷同，无针对性；

3、部门领导不重视绩效考核，如应用技术部5月份绩效考核没有一张考核表有部门领导意见，更谈不上与员工沟通、反馈；

四、管理中心：

一月二月三月四月五月六月

90分以上1313710108

80—89分9393999512087

70—79分222221292120

60—69分115432

60分以下000000

优点：1、管理中心交绩效考核表相对比较及时，尤其是成品仓储部、保卫部、法规部等部门1—6月份的绩效考核表一直都比较及时的交人力资源部；

2、考核有一定的针对性，一定程度上反映出工作中存在的不足和问题；且考核比较重视员工的思想状态，特别是在管理中心有些部门在落后于市场要求时，部门对员工的思想引导特别重视，如厂办、人力资源部等；

3、绩效有一定沟通，在整个管理中心，领导考评后大都能与被考核者见面，进行一定的绩效沟通，一定程度上起到了指导下一步工作的作用。

但从管理中心上半年绩效考核情况看，主要存在着如下问题：

1、有些部门的绩效考核中，分级考核时太过于细化，考核未进行反馈，未形成畅通的绩效沟通渠道，致使一些员工思想或工作上的信息变化部门负责人未能及时掌握，如市场管理部对员工的考核，往往出现部门负责人考核主管，主管考核员工，但主管未将考核和考评意见向部门负责人反馈，致使绩效信息渠道不通畅，造成了部门负责人在管理工作中不能及时了解员工动态，管理不具针对性；

2、不同职位的员工，其职位要求是不同的，而考核的项目是相同的，没有侧重点，这样得出的结果对公司和员工本人都缺乏指导意义。如：市场管理部员工反映绩效考核表内容没有针对性，很难起到考核作用；

3、有些部门不能很好地利用绩效考核，对绩效考核重视但不落实，特别是有些部门的负责人对绩效考核的重要性没有一定的认识，往往借工作忙为理由而晚交绩效或未交，不能用绩效考核考核人、激励人、提高人；如劳资基建运行部3、4、5月的绩效考核表一直迟迟未交；

4、负责人考评有的只提优点，不指出缺点，不能全面地反映各工作岗位的实际工作情，如行政部、策划部、法规部不能用绩效指导工作，不能起到激励和导向作用。

五、营销中心：

一月二月三月四月五月六月

90分以上13132131510

80—89分40406364317

70—79分363610162316

60—69分2828913910

60分以下6635107

优点：综合今年上半年营销中心绩效考核情况，首先是上交比较及时，填写较去年规范，部门负责人比较重视绩效管理，也有一定的绩效沟通，而且因为实施电子绩效，绩效传递较去年快捷。

但是从其填写质量来看，也存在一些不足之处：

1、考评流程方面的问题。一些区域经理未对本区域业务人员进行考评，就直接将业务员给其发送的邮件转发给人力资源部，另有些区域经理也未将自己的绩效考评表传至其分管副总邮箱，而直接将自己的自评结果发送到了公司人力资源部，没有遵从公司绩效考评的程序；

2、填写不规范，有部分区域上的业务人员的《绩效考核表》都由区域经理一手代劳，往往只有领导考评，没有其工作小结、问题分析及下一步规划，这类现象比较集中在区域销售人员比较分散的区域，如山东、河北、湖南、西南等地；

3、技术方面的障碍。相当多区域经理因为电脑操作不够熟练，不能准确快捷地进行邮件收发，致使邮件出现格式错误以及漏发、重复等现象。同时公司的邮箱也经常出现问题，导致很多区域的绩效不能收到。

综上所述，我们可以看到，绩效考核流于形式，大多部门没有将之与部门的实际管理工作相结合，没有发挥绩效管理的作用，管理方法单一，管理思想浮于表面，没有切入工作实践和员工思想动态中。

绩效考核管理的最终目标就是配合公司战略，提高公司的核心竞争力，提升员工绩效，并通过绩效考核进行激励与淘汰，进一步优化人才机制。但是，在进行考核时，简单的加权打分，连面谈都不进行，更别说对员工进行职业生涯的规划、明确下一步的工作方向和发展目标了。

现在公司的绩效考核给我们员工的印象是绩效考核就是扣分，扣了分就是扣点工资，最重要的是为什么要扣就不得而知了，一切都是部门负责人的感觉。而主管们也不把绩效考核当作员工业绩管理的工具，感觉到十分麻烦。这样的绩效考核能产生什么样的效果可想而知了。

各自为阵、部门利益至上，同样导致了考核流于形式。公司各个部门按职能划分，员工只对自己的上级主管负责，对各自部门需要处理的事件都是优先处理。各个部门都尽可能地占有公司资源以及获得最大利益，很难达到整个协调、沟通过程的整体最优。也就是说公司的部门之间没有密切配合，直接影响了公司整体优势的发挥。不仅如此，部门间拖后腿的现象也时有发生。

目前公司大部分员工认为人力资源管理是人力资源部的工作，对人力资源管理工作仅仅是配合，而没有各自部门人力资源管理的宏观规划，就更没有各自部门的员工职业生涯规划了。

管理观念的落后是导致绩效考核工作流于形式的根源。公司有些部门的管理模式基本上还停留在企业一次创业阶段上，管理模式没有跟上公司规模的扩大而改变，管理人员与员工在工作中的随意性较大，没有意识到管理应该是一种有章可循的模式。致使部门的绩效考核投入与产出比失衡。绩效管理在其部门被片面地理解为绩效考核，导致了考核只是流于形式。

要使绩效考核真正落实到实处，不仅仅是方式方法的问题，关键是认识问题和执行问题。要以考核促进员工的发展，通过考核发现员工的不足，进行人力资源开发，纠正员工在目标的实施过程中的偏差，才能利用好绩效考核这一工具。

针对企业绩效管理的现状，我们制定下一步的改进方向和措施：

1、抓好员工关于绩效考核方面的培训工作，在新员工培训过程中加入绩效管理的培训，使新员工在进入公司时便了解绩效、重视绩效。同时加强中层管理者的培训，特别是一些绩效考核技能的培训，使管理者能充分的运用绩效考核这一工具，为企业服务。

2、加强部门间的沟通与协调。人力资源管理是以人力资源部组织、策划、管理、指导、监督，各部门管理者应积极主动参与、配合、执行，有效运用好这个管理工具。人力资源管理的工作并不仅仅是人力资源部的工作，而是全公司本身的工作。部门利益至上只会导致公司资源的浪费，当公司发展到一定的规模之后，整合公司的资源就显得尤为重要和必要，让公司的整体利益最大化，发挥公司整体优势。

他山之石，可以攻玉。山草香为大家整理的4篇分析总结到这里就结束了，希望可以帮助您更好的写作分析。

分析总结2

一、善于发现

班主任的工作很琐碎，仔细回想自己的班主任工作经历你会发现，其实班主任解决的只是班级里鸡毛蒜皮的小事。虽然只是解决小事，但良好的班集体就是在不断解决小事的过程中建立起来的。所以，班主任要具有一双慧眼，善于发现班级里细小的问题。细小的问题可能是学生的一个行为，也可能是班级里一种现象。

不论是正面的现象还是负面的现象，只要班主任善于引导，都能产生积极的影响。比如，我曾经发现有学生在洗好抹布后，直接将湿淋淋的抹布放在课桌里，我就引导全班学生讨论湿抹布放在桌肚里的坏处，进而引导交流如何解决这个问题。在讨论、交流中，学生明白了坏处，知道了解决的方法，就很自觉地将抹布晾在走廊的窗台上。后来，有学生发现这样做又出现了新的问题：当风大的时候，抹布很容易被吹走找不到。我就引导学生自己想办法解决，第二天等我再次看到窗台上的湿抹布时，它们已经被夹子夹住了。

我抓住“如何放置湿抹布”这个教育契机，使学生明白了一件事的不良影响，也使学生懂得要善于发现并动脑解决问题。如果这个问题我没有发现，那么将永远得不到解决，学生的自理能力也得不到提高。因此，只有善于发现问题，才有可能想办法将问题解决，使班级管理更加完善。

二、认真分析

在班级管理过程中发现问题后，我们需要认真分析问题，可以先从问题产生的根源出发，思考相应的解决问题的对策。班级里有问题很让人烦恼，但是如果因为烦恼而不去处理，问题不仅得不到解决，而且一直积压使得问题更可怕，烦恼会越来越多。所以不管遇到什么问题，班主任都要认真动脑筋，想出合适的办法，及时地解决这些问题，这样管理班级才会越来越顺心。

班主任在分析问题、思考对策时应考虑全面，要认真思考这样的解决方法是否有效，如果采取这种方法会不会带来新的问题，换一种方法是不是弊端更少……经过深思熟虑，才能付诸实践。我在刚担任一年级班主任时，遇到了学生用餐、食堂卫生的棘手问题。考虑到学生年龄小、能力差，共同打扫卫生会产生混乱等情况，我就每桌选了两名能力较强的小桌长，并采取了循序渐进的方式对小桌长进行训练，从低要求做起，一步一步地提高要求，使学生慢慢地适应，逐步完成任务。在发现桌长工作时动作太慢、任务过重的问题后，我思考是否要增加桌长人数，人数增加后会不会造成混乱，经过反复考虑，我决定不增加桌长人数，而是采用“敲表扬章”的方式奖励学生，激发每个学生维护食堂卫生的积极性。吃好饭的学生自己放好凳子、捡起垃圾，然后后由小桌长检查合格后方可离开食堂，这样既不会人多混乱，又减轻了桌长的负担。

三、敢于尝试

班主任在经过深思熟虑、认真分析后确定了解决问题的对策就要敢于尝试。一个好的方法如果不经过尝试、运用就永远不知道是否真正有效，只有在真正实践中才能不断探索总结出行之有效的方法和经验，才能使班级管理工作的水平不断跃上新台阶。

本学期开学一段时间后，我就发现班级里出现了“两极分化”的现象，一部分学生各方面都十分优秀，而有一部分学生表现不理想。进行思考分析后，我想出了“一帮一”的对策，即由一个优秀的学生去影响、带动一个“后进生”。于是，我先物色了一位优秀的学生去帮助一个“后进生”，不仅是学习上的帮助，还要负责监督他的纪律等。这样做确实有效果，体验到试验成功的喜悦后，我准备在全班范围内进行推广。于是，我在班级里隆重表扬这位“小老师”，学生十分钦佩并很积极地推荐更多的“小老师”，这样的方式产生的“小老师”是学生最信赖的，也会成为学生心目中的榜样。在“一帮一”过程中，我支持、鼓励小老师们创造性地完成任务，充分发挥其主观能动性，锻炼他们的工作能力，并推举这些学生当班干部。对“小老师”我还实行定期轮换的方法，不仅让班上更多的同学都有锻炼的机会，极大地调动每位学生参与班级管理的积极性，也使当上“小老师”的学生更加用心地为班级、为同学服务。

四、及时总结

在一种方法不断地尝试运用后，班主任就该及时进行总结，找到更加行之有效的方法，以面对不断遇到的新问题。不管是得是失，都应及时将其记录在案，以便在往后的班级管理工作中安排更周到、操作更自如，少走弯路、不走回头路。及时总结能更容易发现执行中被忽略的问题，因而对于以后的各项工作有着很强的指导性。

分析总结3

关键词 头位难产；识别；处理；预防

1 资料与方法

1．1 一般资料 本院2007年上半年共收治产妇900例，其中头位840例，占分娩总数的%，其中头位难产82例，占%。

1．2 方法 把82例头位难产所发生的类型、识别、原因、处理预防进行分析观察及总结。

2 结果

头位难产82例中，其中枕前位有20例，占头位难产%,枕后位44例，占%,枕横位18例，占%.82例头位难产中，剖宫产50例，占%.经阴道徒手旋转胎头为枕前位，从而能经阴道分娩24例，占%.胎头吸引术8例，占%。

3 讨论

3．1 头位难产的概念 头位难产是指在分娩过程中以胎头为先露却因分娩因素即产道、胎儿、产力异常而导致难产[1]。①产道性难产：又分为骨产道异常，包括a盆倾斜度过大b骨盆狭窄c骨盆畸形、此外还有软产道异常，如阴道纵隔或横隔。②胎儿性难产，胎儿以胎头位置异常最多见，本资料中胎方位异常共有62例，占%。其它胎儿性难产还包括胎儿畸形和胎儿巨大。③产力性难产，以宫缩乏力为主，其中包括原发性宫缩乏力和继发性宫缩乏力。以上这三个方面相与关联，相互影响，是个动态变化，要细心观察，确保最佳方式结束分娩。

3．2 头位难产的诊断方法

病史及体检 详细追问病史，了解产妇的年龄及孕产史、孕周及既往分娩史、难产史及产前检查情况，该次待产记录，详细查体，了解孕妇的身高、体质量、测量宫高、腹围，触诊腹壁，了解腹壁的厚度，并根据B超检查所提示胎儿大小并检查孕妇骨盆的大小，触摸腹壁了解宫缩情况，进行胎心监护，了解有无胎儿窘迫的情况存在[2]。

阴道检查 ①骨盆内测量：准确测量骨盆的骶耻内径，坐骨棘间径、坐骨切迹及出口前后径，并根据骨盆的外测量径线，即髂前上棘间径、坐骨结节间径、耻骨弓角度、髂嵴间径来评估骨盆是否有入口狭窄、坐骨棘突出造成中骨盆内聚或骨盆出口狭窄；②宫口扩张程度；③宫颈有无水肿及水肿程度；④胎膜是否早破；⑤胎头下降程度；⑥胎方位的确定，通过触及胎头的骨标志，颅缝及卤门的位置加以判定，但如果胎头位置较低，颅骨重叠时，则卤门常常查不清。这时常靠耳廓的方向来判断胎方位。

3．3 头位难产的处理 头位异常往往产程过长，所以要及时给予正确处理。如体贴、安慰、补液、必要时用镇静剂，改变，帮助排大小便[3]；①改善产妇及胎儿情况。由于目前产妇多为初产妇，对分娩有恐惧，精神极度紧张，所以应给予体贴入微的关怀、安慰、解说及鼓励。必要时给予镇静剂，产妇左侧卧位为宜，来改善胎儿一胎盘循环；②进入活跃期，宫口开大8 cm以上，检查为左横位，徒手入阴道，宫缩时逆时针旋转胎头60°左右，宫缩间歇时停止旋转胎头，通过旋转胎头，使其纠正胎头为左枕前位，右枕横位时，旋转胎头，则顺时针旋转胎头60°左右，使其纠正胎头为右枕前们，旋转胎头时要监测胎心，若胎心出现胎儿宫内窘迫，则要停止纠正胎方位的动作，枕横位通位徒手旋转胎头变为枕前位时多能经阴道分娩，必要时可会阴侧切，胎头吸引术助产分娩；③枕后位时，要评估胎儿大小，骨盆大小和产力情况，若胎儿较小，骨盆正常，产力较好，也可以经阴道徒手旋转胎头，使其变为枕前位，经阴道分娩，反之，则剖宫产术结束分娩。

3．4 头位难产的预防 孕期指导孕妇合理进食，适当运动，避免营养过剩，产生巨大儿，增加胎头难产率，孕妇临产后进行心理安慰，清除紧张感及恐惧感，宫口开大8 cm以上时，要阴道检查胎方位，发现胎方位异常要改换孕妇，徒手纠正胎方位，使其孕妇转危为安。

参 考 文 献

［1］ 凌萝达，顾美礼。头位难产。重庆出版社，1990:252-253.

分析总结4

引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。

编写目的

说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。

如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。

项目风险

具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：

任务提出者；

软件开发者；

产品使用者。

文档约定

描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括：

正文风格；

提示方式；

重要符号；

也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。

预期读者和阅读建议

列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括：

用户；

开发人员；

项目经理；

营销人员；

测试人员；

文档编写入员。

并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。

产品范围

说明该软件产品及其开发目的的简短描述，包括利益和目标。把软件产品开发与企业目标，或者业务策略相联系。

描述产品范围时需注意，可以参考项目视图和范围文档，但是不能将其内容复制到这里。

参考文献

列举编写软件产品需求分析报告时所用到的参考文献及资料，可能包括：

本项目的合同书；

上级机关有关本项目的批文；

本项目已经批准的计划任务书；

用户界面风格指导；

开发本项目时所要用到的标淮；

系统规格需求说明；

使用实例文档；

属于本项目的其它己发表文件；

本软件产品需求分析报告中所引用的文件、资料；

相关软件产品需求分析报告；

为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：

标题名称；

作者或者合同签约者；

文件编号或者版本号；

发表日期或者签约日期；

出版单位或者资料来源。

2. 综合描述

这一部分概述了正在定义的软件产品的作用范围以及该软件产品所运行的环境、使用该软件产品的用户、对该软件产品己知的限制、有关该软件产品的假设和依赖。

产品的状况

描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况：

是否是产品系列中的下一成员；

是否是成熟产品所改进的下一代产品；

是否是现有应用软件的替代品(升级产品);

是否是一个新型的、自主型的产品。

如果该软件产品需求分析报告定义的软件系统是：

大系统的一个组成部分；

与其它系统和其它机构之间存在基本的相互关系。

那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个大系统相关联的，或者(同时)说明相互关系的存在形式，并且要定义出两者之间的全部接口。

产品的功能

因为将在需求分析报告的第4部分中详细描述软件产品的功能，所以在此只需要概略地总结。仅从业务层面陈述本软件产品所应具有的主要功能，在描述功能时应该 针对每一项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作用领域时，也需要对应陈述本软件产品的非作用领域，以利 读者理解本软件产品。

为了很好地组织产品功能，使每个读者都容易理解，可以采用列表的方法给出。也可以采用图形方式，将主要的需求分组以及它们之间的联系使用数据流程图的顶层图或类图进行表示，这种表示方法是很有用的。

参考用户当前管理组织构架，了解各个机构的主要职能，将有助于陈述软件产品的主要功能。

用户类和特性

确定有可能使用该软件产品的不同用户类，并且描述它们相关的特征。往往有一些软件需求，只与特定的用户类有关。描述时，应该将该软件产品的重要用户类与非重要用户类区分开。

用户不一定是软件产品的直接使用者，通过报表、应用程序接口、系统硬件接口得到软件产品的数据和服务的人、或者机构也有他们的需求。所以，应该将这些外部需求视为通过报表、应用程序接口、系统硬件接口附加给软件产品的附加用户类。

运行环境

描述了本软件的运行环境，一般包括：

硬件平台；

操作系统和版本；

支撑环境(例如：数据库等)和版本；

其它与该软件有关的软件组件；

与该软件共存的应用程序。

设计和实现上的限制

确定影响开发人员自由选择的问题，并且说明这些问题为什么成为一种限制。可能的限制包括下列内容：

必须使用的特定技术、工具、编程语言和数据库；

避免使用的特定技术、工具、编程语言和数据库；

要求遵循的开发规范和标准

例如，如果由客户的公司或者第三方公司负责软件维护，就必须定义转包者所使用的设计符号表示和编码标准；

企业策略的限制；

政府法规的限制；

工业标准的限制；

硬件的限制

例如，定时需求或存储器限制；

数据转换格式标淮的限制。

假设和约束(依赖)

列举出对软件产品需求分析报告中，影响需求陈述的假设因素(与己知因素相对立)。如果这些假设因素不正确、不一致或者被修改，就会使软件产品开发项目受到影响。这些假设的因素可能包括：

计划使用的商业组件，或者其它软件中的某个部件；

假定产品中某个用户界面将符合一个特殊的设计约定；

有关本软件用户的若干假定(例如：假定用户会熟练使用SQL语言。);

有关本软件开发工作的若干假定(例如：用户承诺的优惠、方便、上级部门给予的特殊政策和支持等。);

有关本软件运行环境的一些问题；

此外，确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括：

工期约束；

经费约束；

人员约束；

设备约束；

地理位置约束；

其它有关项目约束；

3. 外部接口需求

通过本节描述可以确定，保证软件产品能和外部组件正确连接的需求。关联图仅能表示高层抽象的外部接口，必须对接口数据和外部组件进行详细描述，并且写入数 据定义中。如果产品的不同部分有不同的外部接口，那么应该把这些外部接口的全部详细需求并入到这一部分实例中。

注意：必须将附加用户类的特征与外部接口需求加以区分，附加用户类的特征描述的是通过接口取得软件产品的数据和服务的人的需求；而外部接口需求描述的是接口本身的需求。

用户界面

陈述需要使用在用户界面上的软件组件，描述每一个用户界面的逻辑特征。必须注意，这里需要描述的是用户界面的逻辑特征，而不是用户界面。以下是可能包括的一些特征：

将要采用的图形用户界面(GUl)标准或者产品系列的风格；

有关屏幕布局或者解决方案的限制；

将要使用在每一个屏幕(图形用户界面)上的软件组件，可能包括：

选单；

标准按钮；

导航链接；

各种功能组件；

消息栏；

快捷键；

各种显示格式的规定，可能包括：

不同情况下文字的对齐方式；

不同情况下数字的表现格式与对齐方式；

日期的表现方法与格式；

计时方法与时间格式；

等等。

错误信息显示标准；

对于用户界面的细节，例如：一个特定对话框的布局，应该写入具体的用户界面设计说明中，而不能写入软件需求规格说明中。

如果采用现成的、合适的用户界面设计规范(标准)，或者另文描述，可以在这里直接说明，并且将其加入参考文献。

硬件接口

描述待开发的软件产品与系统硬件接口的特征，若有多个硬件接口，则必须全都描述。接口特征的描述内容可能包括：

支持的硬件类型；

软、硬件之间交流的数据；

控制信息的性质；

使用的通讯协议；

软件接口

描述该软件产品与其它外部组件的连接，这些外部组件必须明确它们的名称和版本号以资识别，可能的外部组件包括：

操作系统；

数据库；

工具；

函数库；

集成的商业组件

说明：这里所说的“集成的商业组件”，是指与系统集成的商业组件，而不是与软件产品集成的商业组件。例如：中间件、消息服务，等等。

描述并且明确软件产品与软件组件之间交换数据或者消息的目的。描述所需要的服务，以及与内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必 须使用一种特殊的方法来实现数据共享机制，例如：在多用户系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。

通讯接口

描述与软件产品所使用的通讯功能相关的需求，包括：

电子邮件；

WEB浏览器；

网络通讯标准或者协议；

数据交互用电子表格；

必须定义相关的：

消息格式；

通讯安全或加密问题；

数据传输速率；

同步和异步通讯机制；

4. 系统功能需求

需要进行详细的需求记录，详细列出与该系统功能相关的详细功能需求，并且，唯一地标识每一项需求。这是必须提交给用户的软件功能，使得用户可以使用所提供 的功能执行服务或者使用所指定的使用实例执行任务。描述软件产品如何响应己知的出错条件、非法输入、非法动作。

如果每一项功能需求都能用一项，也只需要用一项测试用例就能进行验证，那么就可以认为功能需求已经适当地进行描述了。如果某项功能需求找不到合适的测试用例，或者必须使用多项测试用例才能验证，那么该项功能需求的描述必然存在某些问题。

功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使用实例、运行模式、用户类、对象类或者功能等级来组织这部分内容，也可以便用这些元素的组合。总而言之，必须选择一种是读者容易理解预期产品的组织方案。

用简短的语句说明功能的名称，例如：“系统参数管理”。按照服务组织的顺序，逐条阐述系统功能。无论说明的是何种功能，都应该针对该系统功能重复叙述~ 这三个部分。

可以通过各种方式来组织这一部分内容，例如采用：使用实例、运行模式、用户类、对象类、功能等级等，也可以采用它们的组合。其最终目的是，让读者容易理解 即将开发的软件产品。一般来说，每个使用实例都对应一个系统功能，因而按照使用实例来组织内容比较容易让用户理解。

对应一些被共享的独立使用实例，可以定义一些公用系统功能。

必须特别注意的是，在节“产品的功能”中描述的全部需求，以及它们的规格说明；必须在某个系统功能描述中有所反映，而且不应重复。

说明和优先级

对该系统功能进行简短的说明，并且指出该系统功能的优先级是：高、中、还是低。需要的话，还可以包括对特定优先级部分的评价，例如：利益、损失、费用和风险，其相对优先等级可以从1(低)到9(高)。

激励/响应序列

列出输入激励(用户动作、来自外部设备的信号或者其它触发)并且定义针对这——功能行为的系统响应序列，这些序列将与使用实例中相关的对话元素相对应。

描述激励/响应序列时，不仅需要描述基本过程，而且应该描述可选(扩充)过程，包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程，有可能影响软件产品的功能；如果遗漏例外过程，则有可能会引发系统崩溃。

如果采用流程图来描述激励/响应序列，比较容易让用户理解。

输入/输出数据

列出输入数据(用户输入、来自外部接口的输入或者其它输入)并且定义针对这些输入数据的处理(计算)方法，以及相应地输出数据，描述对应区别：输入数据和输出数据。

当有大量数据需要描述时，也可以分类描述数据，并且注明各项数据的输入、输出属性。

对于每一项数据，均需要描述：

数据名称；

实际含义；

数据类型；

数据格式；

数据约束；

对于复杂的处理方法，仅仅给出算法原理是不够的，必须描述详细的计算过程，并且列出每一步具体使用的实际算式；如果计算过程中涉及查表、判断、迭代等处理方法，应该给出处理依据和相关数据。如果计算方法很简单，也可以将其从略，不加描述。

5. 其它非功能需求

在这里列举出所有非功能需求，主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。

性能需求

阐述不同应用领域对软件产品性能的需求，并且说明提出需求的原理或者依据，以帮助开发人员做出合理的设计选择。尽可能详细地描述性能需求，如果需要，可以针对每个功能需求或者特征分别陈述其性能需求。在这里确定：

相互合作的用户数量；

系统支持的并发操作数量；

响应时间；

与实时系统的时间关系：

容量需求

存储器；

磁盘空间；

数据库中表的最大行数。

安全措施需求

详尽陈述与软件产品使用过程中可能发生的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作，以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。

安全性需求

详尽陈述与系统安全性、完整性问题相关的需求，或者与个人隐私问题相关的需求。这些问题将会影响到软件产品的使用，和软件产品所创建或者使用的数据的保 护。定义用户身份认证，或备授权需求。明确软件产品必须满足的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。一个典型的软件系统 安全需求范例如下：“每个用户在第一次登录后，必须更改他的系统预置登录密码，系统预置的登录密码不能重用。”

软件质量属性

详尽陈述对客户和开发人员至关重要的在软件产品其它方面表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。至少也应该指明不同属性的相对侧重点，例如：易用性优于易学性，或者可移植性优于有效性。

业务规则

列举出有关软件产品的所有操作规则，例如：那些人在特定环境下可以进行何种操作。这些本身不是功能需求，但是他们可以暗示某些功能需求执行这些规则。一个 业务规则的范例如下：“进行达到或者超过10，000，00元人民币的储蓄业务时，必须通过附加的管理员认证。”

列举业务规则时，可以根据规则的数量，选取合适的编目方式。

用户文档

列举出将与软件产品一同交付的用户文档，并且明确所有己知用户文档的交付格式或标准，例如：

安装指南

纸质文档，16开本；

用户手册

纸质文档，16开本；

在线帮助

电子文档，与软件产品一同分发、配置；

使用教程电子文档，与软件产品一同分发、配置。

6. 词汇表

列出本文件中用到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士阅读软件产品需求分析 报告，要求使用非软件专业或者非计算机专业的术语描述软件需求。所以这里所指的专业术语，是指业务层面上的专业术语，而不是软件专业或者计算机专业的术 语。但是，对于无法回避的软件专业或者计算机专业术语，也应该列入词汇表并且加以准确定义。

7. 数据定义

数据定义是一个定义了应用程序中使用的所有数据元素和结构的共享文档，其中对每个数据元素和结构都准确描述：含义、类型、数据大小、格式、计量单位、精度 以及取值范围。数据定义的维护独立于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向风险承担者开放。

如果为软件开发项目创建一个独立的数据定义，而不是为每一项特性描述有关的数据项，有利于避免冗余和不一致性。但是却不利于多人协同编写需求分析报告，容 易遗漏数据，也不方便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全一 致。必须注意的是，为了避免二义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，而不是根据数据项的名称汇总。

在数据定义中，每个数据项除了有一个中文名称外，还应该为它取一个简短的英文名称，该英文名称应该符合命名规范，因为在软件开发时将沿用该英文名称。可以使用等号表示数据项，名称写在左边，定义写在右边。常见数据项的描述方式如下：

原数据元素

一个原数据元素是不可分解的，可以将一个数量值赋给它。定义原数据元素必须确定其

含义、类型、数据大小、格式、计量单位、精度以及取值范围。采用以星号为界的一行

注释文本，描述原数据元素的定义。

选择项

选择项是一种只可以取有限离散值的特殊原数据元素，描述时一一枚举这些值，并用方

括号括起来写在原数据元素的定义前。在两项离散值之间，使用管道符分隔。

组合项

组合项是一个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元

素，也可以是组合数据项，各数据项之间用加号连接。其中每个数据项都必须是数据定

义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数据结构中有

可选项，使用圆括号把该项括起来。

重复项

重复项是组合项的一种特例，其中有一项将有多个实例出现在数据结构中，使用花括号

把该项括起来。如果知道该项可能允许的范围，就按“最小值：最大值”的形式写在花

括号前。

8. 分析模型

这是一个可选部分，包括或涉及到相关的分析模型，例如：

数据流程图；

类图；

状态转换图；

实体-关系图。