需求分析主要流程
1.1主要流程
需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计
划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。
1.1.1制定及修改需求开发计划
包括建立需求团队的组织并授权、对需求分析阶段的WBSS行分解、协商并
制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。
1.1.2需求调查以及分析的过程
主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对(软件)系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。
1.1.3需求验证环节
主要通过原型(Prototype )、POC( ProofofConcept )、用例(UseCase 或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。
(1)原型(Prototype )模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。
(2)POC( ProofOfConcept)原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性，评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。一般来说，进行POC K条件：1.论证业务中涉及到的模型或者算法的可行性。2.论证技术模型实现的可行性、成本等。
(3)用例(UseCase :对(软件)系统如何反应外界请求的描述，是一种
通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场
景说明了系统是如何同最终用户或其它系统交互（interact）的，也就是谁可以用
系统做什么，从而获得一个明确的业务目标。
1.1.4需求规则说明（SRS）制作
通过需求调查和初步的需求验证后，可以建立需求制作的准则，包括确认需求规则说明（SRS）的内容、制作方法、制作工具、质量标准等等。根据需求制作的准则制作需求规格说明（SRS ,好的需求规格说明（SRS应该遵循正确、无歧义、完备、一致、分级（重要性或稳定性）、可验证、可修改、可追踪的原则。
1.1.5需求确认
通过组织各级评审对需求分析阶段的产物，尤其最重要的结果产物需求规格说明（SRS进行确认，以确保相关人员理解一致。从评审方法来说，可以根据情况分为需求开发组组内评审、客户外部评审、关键关系人评审等等。
需求分析的流程往往因项目规模、作业人员、系统类型差异很大，因此必须根据实际的情况合理的裁减，以下举例几种不同情况下的具体流程：
案例一：简明的需求开发的流程
第1步：确定实现的目的、目标，基本业务需求、业务定义以及相关的评审。
从达到目的、目标的角度，重新评审业务定义，总结业务需求。（确认客户实施的业务要求）
第2步:使业务具体化，进行软件系统的定义（系统需求定义）。
从目的的角度，进行业务定义（功能，步骤），对系统结构进行讨论、对所要进行系统化或计算机化的功能、流程进行定义。
第3步:一边定义业务需求、系统需求、一边对运行上的相关要求（非功能需求）进行总结
运行时间，安全应对、访问权限等系统需求以及设计约束在业务需求的基础之上、考虑系统上的限制条件之后逐步形成。
业务厲求?业务定史f一切尊士从业舟开冶〉
■*以什么样的业务为对H f业务軍也）
-业务牡届閒步碌?业务功絶是忙么t业爵址龍卑住〉
?处毋卄应州的救躺
-主豐的网可以硏静什E样的改尊敦婆
^wu^^vm'v^jxr%jvi~r&jn?rtrujv^ju^^ri_rv^jxr%jvi~rw?j_ij^^"s>rur^^rtrv^jxr^ 系it需求?系嬪徑义业务具律化的手段) *杵么琳齟覲磅 圧比系逬巧眾： *和冀曲廉辭閒芸廉 ~i?ww^r"l^uraj"^rtmjvirxr^<^irww^j_-mjraj"^rtmj^^?rx^v^xr^jvu^j_-^un_rvujraj^^?rx^v^xr^jvuv^un~rvujraj^^?rx^v^xr^jvi- 參功JE婴朮，1LM吃宣戈5养?廉軽野的麵井*妙 隈M) ?竝ff时间抑何 ?預愴辻球就死■如儒 ?罢请胃疸时间.忙理町⑥苟坷 ;I n I ru%I n>nj a_nH>zs>n>l rwR-n l n_^u l uxrL?n>M>r%A>H I n>A l n_n>n I^?>A a FR I n I rv^>ww^^_a n I n^>njn>A I m 竜嫌开发他址社叫及舟憩 案例二：软件工程类的典型流程 主要特征：强调客户协同、提高运作效率、屏蔽技术风险、加强边界管控 1. 强调同客户协同，比如确定各种约定，包括截至时间、交流方式、成果物； 2. 强调计划管控，起目的确保进度和成本，人力资源合理使用； 3. 采用《问题回答管理票》的方式加强需求团队以及客户的协同作业，提高生产效率，确保质量； 4. 加强需求边界管理，控制项目整体成本； 5. 提前对技术关键环节（技术解决方案、技术构架）进行论证，控制技术风险，减少技术带来的成本损失； 6. 强调需求最终确认； 案例三：软件产品类的典型流程 主要特征：缩减开发周期、支撑跨部门运作、提高创造性、强调用户体验设计。 1. 强调计划性以加快研发进程，缩减产品开发周期。 2. 强调跨部门协调组织，建立统一的需求团队。 3. 强调行业学习、创新以及交流。 4. 分版本制作以适应产品的创造、快速变化、市场需求的适应性、进程以及 成本控制 5. 强调交互原型的重要性，加强用户体验性设计。 【下载本文档，可以自由复制内容或自由编辑修改内容，更多精彩文章，期待你的好评和关注，我将一如既往为您服务】 第一阶段：总体把握，了解概况 接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。 该阶段的主要工作方法：客户访谈 输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结） 第二阶段：详细了解业务，梳理业务流程 通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。 该阶段的主要工作方法：访谈、业务分析、原型设计演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：需求细化和确认 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档） 工作分析的程序（5个阶段） 工作分析是一项技术性很强的工作，需要做周密的准备。同时还需具有与组织人事管理活动相匹配的科学的、合理的操作程序。下图是工作分析的程序模型，工作分析通常依照该程序进行。 一、准备阶段 由于工作分析人员在进行分析时，要与各工作现场或员工接触。所以，分析人员应该现行在办公室内研究该工作的书面资料。同时，要协调好与工厂主管人员之间的合作关系，以免导致摩擦或误解。在这一阶段，主要解决以下几个问题：（一）建立工作分析小组 小组成员通常由分析专家构成。所谓分析专家，是指具有分析专长，并对组织结构机组织内各项工作有明确概念的人员。一旦小组成员确定之后，赋予他们进行分析活动的权限，以保证分析工作的协调和顺利进行。 （二）明确工作分析的总目标、总任务 根据总目标、总任务，对企业现状进行初步了解，掌握各种数据和资料。 （三）明确工作分析的目的 有了明确的目的，才能正确确定分析的范围、对象和内容，规定分析的方式、方法，并弄清应当收集什么资料，到哪儿去收集，用什么方法去收集。 （四）明确分析对象 为保证分析结果的正确性，应该选择有代表性、典型性的工作。 （五）建立良好的工作关系 为了搞好工作分析，还应做好员工的心理准备工作，建立起友好的合作关系。 二、计划阶段 分析人员为使研究工作迅速有效，应制定一执行计划。同时，要求管理部门提供有关的信息。无论这些信息来源与种类如额，分析人员应将其予以编排，也可用图表方式表示。这一阶段包括以下几项内容： （一）选择信息来源 信息来源的选择应主意：（1）不同层次的信息提供者提供的信息存在不同程度的差别。（2）工作分析人员应站在公正的角度听取不同的信息，不要事先存有 网络教育平台建议书 一、目的：加强教学质量，提高教学效率。 二、名称：网络教育平台 三、建议方案： 1.教育平台所有使用者必须要注册、申请，获得管理员批准后方可使用，且需要区分教师用户和学生用户。学生用户和教师用户应该有独立的管 理系统。（学生权限基本包括：个人资料的修改、提问权限、作业上传，下载网站内的学习资料、在线测试评估，视频学习等。教师权限基本包括：个人资料的修改，对于学生提问的解答，学习资料的上传，在线评估的试卷编辑和设置，视频教学课堂的设置，学生权限的调整等。） 2.在学习材料板块中，学生可以向自己的任课老师提交自己的作业，学生可以下载自己权限内的学习资料和相关文献。（学生用户可以给指定老师 上传自己的作业，学生可以删除和重传自己的作业。教师用户可以查看自己班级学生的作业，并将一些教学教案放在网站上。PS：个人认为学生将作业上传到网站上的这种方法很好，但方式不太好，建议将学生将作业发送到老师的邮箱。因为如果放在网站上的话，必须配备一台服务器，主要是用于文件的存放。按照一个学生每天发送一个1MB的文件计算，100个学生，10天就需要1G的空间。一个月不用，网站的流量就基本上用完，而且可用空间也基本没有了。所以个人建议网站主要用于存放教学资料下载。） 3.答疑系统可使用论坛模式，操作简单，成本较低。（答疑系统已经非常成熟，最好的方法是通过论坛，可根据学生的权限，问题的类型等，进入 相应的板块进行提问回答，学生也可以对某一个问题进行讨论。提高学习情趣，互相帮助，互相学习，老师也可以参与互动，随时查看学生的动向，关注和关爱学生。） 4.在线授课主要的问题是网络的速率问题。可采用视频聊天室的方法，或者其他的解决方法，比如软件客户端，但需要有自己的服务器和购买相 关的软件。（想说明一点的是：无论是采取网站在线授课还是客户端在线授课，费用都是较高的。如果采用录制视频，学生点击观看学习，成本较低。个人观点：即使是在线授课，也不能保证学生一直在在线状态。或许可以借住第三方视频网站，在线教学等，这种方法成本较低，既可以实现预约功能，而且能随时和学生交流，并且成本较低。） 5.在线评估板块可以能够由系统自动评判学生的英语水平、成绩、性格特征等相关的分值。可参考在线测试答题系统。（可采用调查问卷的形式， 类似于网上的驾校模拟考试。） 四、总结： 网络教育平台的这四个基本功能，在现有的技术下都可以实现，其中权限管理和学习材料、答疑系统可以通过论坛解决。在线授课的实现模式还需要具体商讨，评估系统也需要具体细化，看需要做到什么程度。在费用上，一个在线视频教学系统基本价格大概在1万以上，文件上传和下载功能加上答疑系统大概在3000-5000，评估板块需要看是简单测评还是人工智能分析。 需求管理过程 本文件属深圳天源迪科信息技术股份有限公司所有， 未经书面许可，不得以任何形式复印或传播。 2008-1-31发布 2008-2-18 实施 文件建立/修改记录 目录 1 简介 (4) 1.1 目的 (4) 1.2 适用范围 (4) 1.3 背景描述 (4) 1.4 术语表 (4) 1.5 参考资料 (5) 2 总体描述 (5) 2.1 概述 (5) 2.2 职责分工 (5) 2.3 结构描述 (6) 3 活动描述 (7) 3.1 需求培训 (7) 3.2 建立需求跟踪矩阵 (8) 3.3 维护需求跟踪矩阵 (9) 3.4 检查一致性 (10) 3.5 采取更正行动 (11) 3.6 需求变更管理 (12) 4 附录 (13) 4.1 附录A－相关过程 (13) 4.2 附录B－相关规范、指南 (13) 4.3 附录C－相关模板列表 (13) 1简介 1.1目的 制定需求管理过程的目的是管理产品和组件的需求，识别需求与项目计划及工作产品之间的不一致，有效地控制需求变更、以及跟踪需求的演进，指导项目组管理需求。 1.2适用范围 本过程适用于公司所有的软件项目，贯穿项目的整个生命周期。 1.3背景描述 无。 1.4术语表 ●软件需求：用户解决某一问题或者得到某一目标所需的软件功能。 ●基线：基线是经过评审和批准的配置项的集合，其作用是明确划分项目各阶段，确定各阶 段的结束点。在项目的开发过程中，最基本的基线有需求基线、开发基线、发布基线等。 ●配置控制委员会(Configuration Control Board)：简称CCB，是确定配置基线，评估、批准 变更，并保证已批准变更的实施的组织。 ●需求变更：需求变更主要来自三个方面－客户、高层和开发人员。因此，无论哪一方面提 出需求变更的要求，都应当对变更请求进行评估。需求变更通常包括三项内容：新增需求、修改需求、删除需求。每一种变更都可能影响到其他需求的变化，因此在进行变更时需要利用需求跟踪记录。 ●需求跟踪：需求跟踪主要是跟踪需求及其实现之间的一致性，需求跟踪通过管理需求跟踪 记录来进行。在需求的阶段已经建立了需求跟踪记录，在后续的开发过程中，通过不断填写需求跟踪记录，将设计、开发和测试等阶段产品与需求进行一一对应。同时，在任何一个阶段发生变更时，都要检查需求跟踪记录是否需要进行变更。需求跟踪是分布在各个开发阶段之中的。 ●涉众:专指所有会受到项目结果重大影响的人。要有效地解决任何复杂的问题，就会涉及 到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。了解涉众的组成及其特定需要是开发有效解决方案的关键。典型的涉众有客户（或客户代表）、用户（或用户代表）、投资者、股东、生产经理、买方、项目经理、设计人员、测试 需求分析方法论 原则上，需求分析阶段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.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、工作分析，又称职务分析，是对某一企事业组织内部各岗位工作的分析。即采取科学的手段与技术，对每个职务同类岗位工作的结构因素及其相互关系，进行分解、比较与综合，确定该职务岗工作的要素特点、性质与要求的过程。 理解这一概念要从以下几个方面入手： （1）工作分析的主体是：工作分析者； （2）工作分析的客体是：工作岗位； （3）工作分析的对象是：岗位中的工作内容、工作责任、工作技能、工作强度、工作环境、工作心理以及岗位在组织中的运作关系。 （4）工作分析的结果是：职务说明书。 （5）工作的具体形式或是职业、职务、职位（岗位）、任务与要素。 （6）分析的具体行为形式是调查、研究、分解、比较、综合、分类、排序、评价、记录、说明与描述。 （7）工作分析活动的实质：就是从不同个人职业生涯的调查入手, 顺次找出工作职务、职位、职责、任务与要素的过程，并由此确定工作的内容范围、属性关系、繁简难易与所需的资格条件。 2、要素：是指工作活动中不便再继续分解的最小单位。如从工具箱中取出工 具、将夹具与加工件安装在机床上，开启机床，加工工件等均是工作要素。 3、任务：即工作活动中达到某一工作目的的要素集合。可以由一个或多个工 作要素组成。如工人加工件、打字员打字都是一项任务。 4、职责：个体在工作岗位上需要完成的主要任务与大部分任务。它可以有一 个或多个组成。如打字员的职责包括打字、校对、机器维修等任务。 5、职位：也称岗位，指某一工作班制时间内某个人所担负的一项或数项相互联系的职责的集合，职位与个人是一一匹配的，也就是有多少个职位就有多少人，二者的数量相等，例如，为了达到组织的生产目标，必须搞好生产管理，包括：生产计划、生产统计、生产调度等，为此设置生产计划员、生产统计员、生产高度员和生产科长等职位。其中，生产计划员主要完成生产任务的编制和监督执行任务，对生产计划的质量负责；生产统计员完成生产信息的收集、分析、传递等任务，对生产信息的准确性、完整性和及时性负责；生产调度员完成为实现生产计划而所需的动态管理与控制任务，对高度的有效性和及时性负责；生产科长完成生产管理各方面的协调、指导、监督和指挥任务，对整个生产管理工作的质量负责。 系统需求分析（业务流程图的练习） 一、任务与目的 1.学习V isio软件的使用 2. 理解业务流程分析和画法 3. 利用业务流程来分析企业业务处理过程 二、原理（条件） 1.在进行信息系统开发之前，需要深刻的分析现有的业务流程，对原有的业务流程进行改造或者重新制定 2．通过业务流程分析，进而理解系统的整体功能需求 3. 一台可以上网的PC机即可进行实验 三、内容 1.Visio的使用； 2.企业业务流程分析； 3.汽车配件管理系统的业务流程图绘制； 四、步骤 1.了解Visio的工作环境： 1)工作窗口 2)视窗调整 3)任务窗口 4)小视窗 2.了解菜单项。 3.了解定位工具。 4.了解工具栏。 5.了解文件操作。 6.了解绘图页面操作。 7.针对第一个实验，绘制业务流程图 8.汽车配件管理系统的业务流程分析： 1）、销售管理： 对顾客的订货进行处理并回答顾客的咨询。包括订货处理、缺货通知、通知财务、制作销售报表等功能。这部分侧重的是对客户服务的，它是以客户为中心开展的。是整个系统数据的入口处。 2）、采购管理（P2）： 负责向供应商采购汽车配件并通知财务部门。包括采购配件、通知财务等功能。这部分侧重的是供应商的联系。它以采购配件为中心展开。 3）、财务管理（P3）： 主要负责向顾客收款与向供应商付款。包括付款给供应商、向顾客收款、制作报表等功能。这部分管理这公司的资金方面。 4）、库存管理（P4）： 主要负责对供应商收货与对顾客发货。包括验证发货给顾客、收取供应商发的货、通知采购部门到货、制作库存报表等功能。这部分管理这公司配件库存。 五、结论 第一个实验流程图 采购管理 工作分析的内容、程序和方法 工作分析是指系统全面的确认工作整体，以便为活动提供各种有关工作方面的信息所进行的一系列的工作信息收集、分析和综合的过程。工作分析是工作的基础，其分析质量对其他人力资源管理模块具有举足轻重的影响。工作分析在人力资源管理中的位置，如下图所示： 通过对工作输入、工作、工作输出、工作的关联特征、工作资源、工作环境背景等的分析，形成工作分析的结果——（也称作）。 包括工作识别信息、工作概要、和，以及的标准信息，为其他人力资源管理职能的使用提供方便。 工作分析的术语 在工作分析中，会涉及一些常用术语，但这些术语又常被人们混淆，因此掌握和了解这些术语对工作分析是十分必要的。 (1)。工作要素是指工作中不能继续再的最小动作单位。例如，的迎宾服务工作要素：开门、请客人进来。 (2)任务。任务是指工作中为了达到某种目的而进行的一系列活动。任务可以由一个或多个工作要素组成。例如工人给产品贴标签这一任务只有一个工作要素。上面提到的迎宾员，任务是迎接客人，他包括两个。 (3)工作。工作就是组织为达到目标必须完成的若干任务的组合。一项工作可能需要一个人完成，如的工作也可能需要若干人完成。 (4)职责。职责是指任职者为实现一定的或完成工作使命而进行的一个或一系列的工作。 (5)。职位也叫岗位，是指担负一项或多项责任的一个任职者所对应的位置。一般情况下，有多少个职位就有多少个任职者。例如，、秘书、等。应该注意的是职位是以事为中心而确定的，它强调的是人所担任的岗位，而不是担任这个岗位的人。职位是确定的，而职位的任职者是可以更换的。 (6)。职务是由一组主要责任相似的职位组成的，也称为工作。在不同的组织中根据不同的工作性质，一种职务可以有一个或多个职位。例如，处长这一，在不同的部门都设有这个职位。职务具有职务地位和职务位置的双重含义。即在同一职位，职务可以不同，如同是副厂级干部，却分为第一副厂长、第二副厂长等。虽然都是副厂级，但其职务地位却不同。一个职务也可以有 酒店管理系统需求分析 1. 引言 1.1 编写目的 本系统的开发目的在于更好的管理和经营酒店餐饮行业。本文档的预期读者是酒店管理系统软件开发有关的开发人员。 1.2 项目背景 本项目的名称：酒店管理系统。 随着国民经济的发展，酒店餐饮行业的队伍在全国范围（尤其是在经济发达地区）不断壮大，从事酒店餐饮行业的单位之间竞争愈加激烈。为了提升自身的竞争能力， 各酒店餐饮单位都在尽量定制或购买各项业务的应用软件，运用高科技手段进行经营 和管理。为了让酒店更好的经营，我们组织开发了本软件。 本项目的任务提出者及开发者是酒店管理系统软件开发小组，主要是面向酒店餐饮服务行业。 1.3 定义 酒店管理系统是帮助酒店自身管理和服务酒店客户的软件。 1.4 参考资料 ①《现代软件工程》北京希望电子出版社孙涌等编著 ②《Delphi住宿餐饮管理系统开发实例导航》人民邮电出版社 刘敬严东明马刚编著 ③《软件需求说明书（GB856T——88）.doc》 ④《iso标准之需求分析说明书.doc》 2.任务概述 2.1 目标 开发本软件是为了服务酒店，使得酒店更好的经营。适用于一些大中型酒店，主要用于就餐管理和住宿管理。本软件产品是一项独立的软件，不过功能还可以增加， 完成后可以升级以增加功能和完善系统。 2.2 用户的特点 使用本软件要求用户熟悉Windows 操作，并且有一定的软件操作基础。预计本软件将会在一些大中型酒店中得到广泛使用。 2.3 假定和约束 本软件由我们小组六个人共同开发，几乎不要经费，开发期限一个月左右。3.需求规定 3.1 对功能的规定 ①系统帐号管理 第一次用一个管理员账号（系统给定）登陆，登陆成功后，可以设置其他用户，包括密码、权限等。 ②就餐管理 为就餐客户查询并分配餐桌，纪录客户用餐情况并结帐。 ③住宿管理 为住宿客户查询并分配房间，纪录客户住宿情况并结帐。 3.2 对性能的规定 3.2.1精度 本软件主要用于管理，不是科学计算，要求计算的精度不是很苛刻。所以输入,输出数据精度的要求不是很高，用于计算的数用浮点数就可以了。 3.2.2时间特性要求 本软件运行的响应时间要求不超过1～2秒，基本能实现。 3.2.3灵活性 本软件具有升级功能，以满足用户的需求。 3.3输人输出要求 某集团船代项目需求分析和调研实践过程 此文档主要在于项目管理设置项目相关文档，有兴趣人员可以参考一下，对于项目管理和未来有此方向者有一定的参考价值。 流程再造方法论 -流程影射，系统评估，定义考核，再造建议 前言 本文档主要根据某集团船代项目需求分析和调研实践过程整理而得，描述从项目启动，调研到设计过程的大致过程叙述，重点在于咨询过程中涉及的需求分析和调研方法论，其他相关项目前期规划和调研可参考此方法论。如有不妥之处敬请指正，也希望能不断完善，谢谢！正文： 软件需求的定义： 根据IEEE软件工程标准词汇（1997年）中定义的需求为： 用户解决问题或达到目标所需的条件和能力； 系统或系统部件要求满足合同，标准，规范或其他正式规定文档所需具有的条件和能力； 一种反映上述条件和能力的文档说明。 本项目简介 因某某集团船代业务发展需要，加上目前的系统存在很大问题，也不能涵盖目前的所有业务需求，需进行调研和需求分析是否需要上一套 新的船代系统，新系统需要整合目前的业务结构和业务流程，同时满足业务的需求和未来发展。 适合读者 此文档适合信息系统项目咨询规划和分析的相关项目人员作为项目前期方法论参考之用。 目录 1.项目启动 2.项目调研 3.项目规划与考核指标 4.撰写SOR 项目启动 1.与成员企业与相关部门沟通 召开项目总启动会议，介绍项目组相关人员以及此项目的主要目的和要求，企业简单本项目涉及的业务流程和相关业务部门和目前主要组织结构。例如船代项目我们在这一个环节我们了解到了整个船代所涉及的主要业务可以分为： 集装箱进出口业务 散杂货进出口业务 箱管 订舱 根据业务的分工部门的分工也不同。以后的调研思路我们也可以按照这样两种业务流程主线去咨询调研相应的部门与人员。 2.安排项目相关人员 根据业务主线（集装箱进出口，散杂货进出口）整理调研思路，要求企业根据提供的业务主线流程，和部门结合分工安排，组织各部门主要相关人员积极配合项目未来的调研。 3.出初期调研时间和相关人员安排表 根据前期的准备工作，出具具体调研时间和人员安排表，时间项目组掌控制（需要和业务部门协调），人员安排需要业务部门提供详细人员名单资料。以便项目成员和企业相关部门人员提前做好调研准备（安排相关人员和准备一些相关资料）。 根据时间人员安排表，做好前期调研准备。 注：在调研具体调研前，我们因该知道所有物流在运作过程中碰到的四个主要问题为： 出错率 时效 成本 结算 在具体的调研过程中，我们始终要以此作为主导的思路问问题，才能找出目前的问题所在。也就是未来规划后的系统的价值所在。 IBM 软件产品需求管理流程 1. 简介 IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始，到研发以及后续的交付遵循IB M软件部集成产品设计(IPD)流程。IBM 软件产品需求管理流程是IPD的一个体现，也就是一个由市场/客户驱动的，跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。同时，此次内容我们将描述IPD和产品需求管理流程，及流程中的角色（市场、研发产品管理部门及研发工程部门），以及他们之间是如何通过协作来管理需求的。 2. 背景——IPD IPD指导如何对软件产品发布版本进行投资决策和如何协调部门间工作以实现这些决策所 定义目标，IBM软件产品需求管理基于IPD流程，要了解这个需求管理的流程，首先我们要了解IBM所有产品开发所遵循的IPD的流程，包括其决策点。 IPD流程分为六个步骤： 1.概念：即概念验证阶段，主要对需求包进行评审，以确定其是否有足够的商业价值； 2.计划：即资源投入计划阶段，主要对需求包进行评估，以确定是否有足够的资源且在 一定的时间范围内将需求包开发出来； 3.开发：即对需求包进行开发成产品阶段； 4.验证：即对产品进行验证阶段； 5.交付：即将产品交付市场阶段； 6.生命周期：即产品在市场上销售，使用，维护和退出市场的阶段。 其中包括了几个重要的决策检查点(DCP)： 1.概念决策检查点：即经过概念阶段各方面进行的一系列评审，在此检查点确定（1） 我们对需求包是否有足够的理解；（2）需求包是否有足够的商业价值。如果是，继续进入计划阶段； 2.计划决策检查点：即经过计划阶段的评估，在此检查点确定（1）我们是否有足够的 资源在既定的时间范围内完成需求包的开发（2）研发部门是否能在(1)的估计上承诺进行开发。如果是，继续进入开发阶段； 3.可交付决策检查点：即经过开发和验证阶段，在此检查点确定（1）产品是否质量合 格以交付给客户（2）我们产品的相应支持和销售是否已经准备好服务客户,如果是，产品交付市场； 4.生命周期结束决策检查点：即产品在市场使用一定时期后，在此检查点确定产品是否 退出市场。 一个产品从市场需求开始，经过概念验证，时间、资源等计划的支持，然后进行开发，验证，直至发布到市场供客户使用，最后在某个特定的时候结束产品在市场上的销售，在IBM都遵循着IPD流程。在其中过程中，这个产品的概念是否被接受，是否能得到资源上的投入的承诺，是否通过最终验证可以在市场上发布，以及什么时候在市场上停售，这些关键的决策都通过相应的委员会在不同的决策点上进行决策。 3. IPD 与产品需求管理流程 以上描述了IBM IPD的基本概念，我们接下来看IBM软件产品的需求管理是如何基于IPD 的。首先，请看下图一：产品需求管理流程。 电子政务的需求分析： 针对G to B做的需求分析： 面向企业的信息服务是建设服务性政府的一个主要方面。通过电子政务平台，为企业用户提供迅捷的信息和服务，提供"一站式"办公方式，减少分支环节，提高办事效率，为企业的经营和发展创造良好的政务环境。 1 技术可行性分析 基于当前的计算机技术、网络技术和管理技术已成熟。所以江丘市政府完全可以开发一个电子政务平台。针对于政府和企业的关系！ 2 经济可行性分析 对于一个在社会主义制度下、由共产党所领导的中国政府，完全有能力，有金钱来创办这套信息系统。所以，从经济上讲，就是九牛一毛的事！这是完全行得通的！ 3 操作可行性分析 现在的社会上每年有关于计算机方面的大学生找工作到一个关于自己本专业的工作是难之又难。人才方面可以说是供大于求。而且，所设计出来的系统，简单明了，一般的市民都是可以进行操作！所以，从技术上 讲，这完全是可以行的通的！ 业务流程分析： 信息服务： 企业可以通过电子政务平台，具体的了解江丘市政府的一些政策和各种信息，了解政府面向企业的信息服务包含哪些内容，以便于为自己的企业做出决策！就如时代所说：信息就是金钱啊！ （一）业务流程图 名称登记服务： 企业名称登记是网上工商的服务内容。尽管该业务由工商部门主管，但在办理过程中涉及到多个政府职能部门的业务范围。在传统政务的办理方式下，这需要申请人拿相关材料到各个政府职能部门自行办理，由于业务流程复杂、办公地点分散，从申请到办结需要很长的时间。而在电子政务的办理方式下，企业用户只要在电子政务网提出申 请，并提供相关材料后，即可在网上查询和跟踪办理过程。类似以下的过程，都可以轻松的在网上办理即可。如： 1、"网络信息服务"注册登记 2、2、工商管理部门的名称预核准 3、3、文化管理部门的筹建审批 4、4、公安机关的网络安全检查 5、5、消防安全部门的消防安全审批 6、6、文化管理部门的经营许可证的发放 怎样做需求分析之十三：分析之行动图和状态图 作者: fangang发布时间: 2012-04-11 10:23 前面，我们耗费了大量的篇幅来讨论用例分析及用例图。用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。 什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。它们就是行动图与状态图。 行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在行动图中，往往是从一个实心圆的起始节点开始的。最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。 在各种业务流程中，毫无疑问会有许多的分支。在行动图中，分支用一个菱形来表示。一个指向菱形的箭头，表示流程进入分支，另外两个或多个从菱形伸出的箭头，则表示不同条件下的分支流。而菱形本身，则表示为一个条件判断语句。 另外，业务中的各个流程还会分岔与汇合的情况。分岔，表示在某个时间点上，同时开始两个业务流程，这两个业务流程是同步进行的。分岔用一个入箭头，一根横杠，与两个出箭头表示。汇合，则表示，只有在两个流程都完成的情况下，才会进入下一流程，否则只能等待。汇合则用两个入箭头，一根横杠，与一个出箭头表示。 最后，用一个或多个带环的实心圆，表示的是活动图的终止节点，代表了业务流程的终结。以上这些元素，就组成了一个基本的活动图。然而，基本的活动图还不能完整的反映我们的业务流程，因此我们还需要在基本活动图的基础上增加元素。现在我们来看看泳道与业务对象流。 如图就是一个带泳道的活动图，图中每个泳道代表一个参与者的业务操作，而整个图形表述了多个参与者间的协作过程。起初我比较爱绘制这样的活动图，但后来常常感到绘制泳道是 工作分析 第一阶段：部门职责、任务清单与岗位职责的确认 1.填写工作日志：各部门连续填写10个正常工作日的工作日志，以便查清每个岗位目 前所从事的所有工作和工作任务构成，了解每个工作的不同职能的时间分配。具体填写格式参见附表一； 2.汇总个人工作日志：每个人汇总自己的工作日志，汇总要求和格式见附表二； 3.各部门汇总每个员工的工作日志，建立初步的部门工作任务清单，汇总要求和格式 见附表三； 4.在汇总的部门工作任务清单基础上，组织全部门的人进行逐项讨论，以便确认：A、 是否是本部门的工作，如果是，它与其他部门的哪些工作相关；如果不是，那么它应当属于哪个部门； B、在汇总的工作任务清单中，有没有重叠或遗漏的，如果有，进行补充和修改； C、考虑企业发展要求，讨论是否有目前尚未开展的工作，如果有，需进行补充； 5.整理清单结构：各部门对清单进行整理，按逻辑关系和工作任务的同类性归类，其 结构为： 第一级：部门的主体功能； 第二级：反映部门主体功能的职责； 第三级：把任务清单归并在相应的职责内。 6.各相关部门对工作任务清单进行集体讨论，目的是解决工作任务交叉、遗漏和界定 不清的问题，同时确认相关工作或任务的衔接点，以便确认和区分部门职责； 7.将工作任务清单交上级主管领导审核确认后，提交专家组进行评审，对于不合格的 部门，需返回修改。 8.部门职责的确认：将部门任务清单中的第一级和第二级提出，形成部门的基本职责； 9.各部门在确认的部门职责基础上，进行权限划分，具体做法为：对每一项工作职责 进行判断，凡有以下情况者，必须列入部门职责权限表（见附表四），并赋予相应的权限： A、需要做出决策（决定）的； B、具有关键责任判断点的； 需求分析 一.流程 ->1.需求分析（战略层，发现有效需求，排期）- ->2.功能设计（范围层，用哪些功能来实现这个需求） ->3.交互设计（结构层，将功能带入到产品里，将抽象的功能具象成按钮）->4.视觉设计（表现层） ->5.开发测试（走查） ->6.上线运营（循环） 二.需求 通俗来说即谁在什么情况下想干什么。这里就涉及到了“目标用户”“使用场景”“用户目标”。 目标用户： 是在人群细分的基础上得出的，需要考虑细分时的潜在用户量（市场份额）和用户质量（市场价值）。比如说做外卖市场，目标用户想当然的可能就是有定外卖需求的人，这当然没错，只是把用户群体定得太局限，也太浅显了。 020本质上是懒人经济，用户最大的特点就是懒和信息不对称。从潜在用户量的角度想，没有定外卖的习惯但是对新的菜品有强烈好奇心的吃货，是否也是我们的用户呢？从用户质量的角度想，主打高校市场是为了培养未来的主流消费用户的习惯，那主打白领市场就可能是想快速抢占用户并得到流量变现。使用场景： 是需要根据具体场景特点来分析如何满足需求。比如分析观看视频的用户在移动场景下的特点是移动频繁、注意力不易集中、流量有限等，那对应的视频类产品设计原则就会考虑让交互易单手操作、视频精简而亮点集中（如万万没想到等10分钟左右的搞笑视频） 用户目标： 即我们日常讨论的用户的需求。然而表层的目标和底层的需求还是有差别的，目标是不同用户在自己的认知范围内对自己的需求做出的一种反馈，由于大众认知偏差大，所以需求相似但目标相异，这就要求我们在众多的用户反馈中去剖析提取真实的需求。比如对于打折商品，用户的目标可能是需要查看商品折前折后价方便对比，但可知用户的需求是想知道商品的打折力度，其性价比的上升程度，从而确定购买决策，所以对此我们应该直接提供“省了多少，已有多少人下单、多少人好评”等这种辅助用户进行购买决策的信息。 三.产品 是指满足人们某种需求并能被使用和消费的东西，包括有形的物品和无形的服务。这里就涉及到了“使用人群”“主要功能”“产品特色”。 使用人群： 指经过需求分析和性价比考量后确定服务的对象，也就是说制造者会分析这个产品会被哪些人需要、这些人有没有盈利价值、产品做起来难不难。使用人群也涉及到了一个概念：用户自画像（即用户信息标签化，以后再详细讨论这点） 主要功能： 也就是用户使用产品的根本原因，解决用户的核心需求。 产品特色： 核心需求容易抓，用户为何选你不选他？这便是同行竞争的核心点，也是运营推销的切入点。 优秀的产品： 首先要能解决需求，这是产品的根本价值所在。其次是要有良好体验，这是产品出类拔萃的前提。最后还要有用户粘性，这是商业价值的源头。 职等职级体系干部序列 一、基本概念及相关术语： 1、工作分析，又称职务分析，是对某一企事业组织内部各岗位工作的分析。即采取科学的手段与技术，对每个职务同类岗位工作的结构因素及其相互关系，进行分解、比较与综合，确定该职务岗工作的要素特点、性质与要求的过程。 理解这一概念要从以下几个方面入手： （1）工作分析的主体是：工作分析者； （2）工作分析的客体是：工作岗位； （3）工作分析的对象是：岗位中的工作内容、工作责任、工作技能、工作强度、工作环境、工作心理以及岗位在组织中的运作关系。 （4）工作分析的结果是：职务说明书。 （5）工作的具体形式或是职业、职务、职位（岗位）、任务与要素。 （6）分析的具体行为形式是调查、研究、分解、比较、综合、分类、排序、评价、记录、说明与描述。 （7）工作分析活动的实质：就是从不同个人职业生涯的调查入手，顺次找出工作职务、职位、职责、任务与要素的过程，并由此确定工作的内容范围、属性关系、繁简难易与所需的资格条件。 2、要素：是指工作活动中不便再继续分解的最小单位。如从工具箱中取出工具、将夹具与加工件安装在机床上，开启机床，加工工件等均是工作要素。 3、任务：即工作活动中达到某一工作目的的要素集合。可以由一个或多个工作要素组成。如工人加工件、打字员打字都是一项任务。 4、职责：个体在工作岗位上需要完成的主要任务与大部分任务。它可以有一个或多个组成。如打字员的职责包括打字、校对、机器维修等任务。 5、职位：也称岗位，指某一工作班制时间内某个人所担负的一项或数项相互联系的职责的集合，职位与个人是一一匹配的，也就是有多少个职位就有多少人，二者的数量相等，例如，为了达到组织的生产目标，必须搞好生产管理，包括：生产计划、生产统计、生产调度等，为此设置生产计划员、生产统计员、生产高度员和生产科长等职位。其中，生产计划员主要完成生产任务的编制和监督执行任务，对生产计划的质量负责；生产统计员完成生产信息的收集、分析、传递等任务，对生产信息的准确性、完整性和及时性负责；生产调度员完成为实现生产计划而所需的动态管理与控制任务，对高度的有效性和及时性负责；生产科长完 软件需求分析（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）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需求； 2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准； 3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据； 职位分析的方法和步骤 在我国，现在的大多数企业都施行了岗位责任制。在许多企业中，你都可以查阅到厚厚的一本岗位责任手册，在手册中有企业每个部门的部门职能和每个职位的岗位职责，书写得非常细致和系统。 岗位责任制的实施对企业来说应该是管理上的一个提高，但就现实情况而言，在多数企业里，岗位责任手册只是一套形式上的文件，并没有得到认真的落实。没有人根据岗位职责的内容来规范自己的工作，更没有将它作为真正的依据进行绩效考评。 职务分析的方法 一、观察法 观察法是指职位分析人员通过对员工正常工作的状态进行观察，获取工作信息，并通过对信息进行比较、分析、汇总等方式，得出职位分析成果的方法。观察法适用于对体力工作者和事务性工作者，如搬运员、操作员、文秘等职位。 由于不同的观察对象的工作周期和工作突发性所有不同。所以观察法具体可分为直接观察法、阶段观察法和工作表演法。 1．直接观察法 职位分析人员直接对员工工作的全过程进行观察。直接观察适用于工作周期很短的职位。如保洁员，他的工作基本上是以一天为一个周期，职位分析人员可以一整天跟随着保洁员进行直接工作观察。 2．阶段观察法 有些员工的工作具有较长的周期性，为了能完整地观察到员工的所有工作，必须分阶段进行观察。比如行政文员，他需要在每年年终时筹备企业总结表彰大会。职位分析人员就必须在年终时再对该职位进行观察。有时由于间阶段跨度太长，职位分析工作无法拖延很长时间，这时采用"工作表演法"更为合适。 3．工作表演法 对于工作周期很长和突发性事件较多的工作比较适合。如保安工作，除了有正常的工作程序以外，还有很多突发事件需要处理，如盘问可疑人员等，职位分析人员可以让保安人员表演盘问的过程，来进行该项工作的观察。 在使用观察法时，职位分析人员应事先准备好观察表格，以便随时进行记录。条件好的企业，可以使用摄象机等设备，将员工的工作内容记录下来，以便进行分析。另外要注意的是，有些观察的工作行为要有代表性，并且尽量不要引起被观察者的注意，更不能干扰被观察者的工作。 二、问卷调查法 职位分析人员首先要拟订一套切实可行、内容丰富的问卷，然后由员工进行填写。问卷法适用于脑力工作者、管理工作者或工作不确定因素很大的员工，比如软件设计人员、行政经理等。问卷法比观察法更便于统计和分析。要注意的是，调查问卷的设计直接关系着问卷调查的成败，所以问卷一定要设计得完整、科学、合理。 国外的组织行为专家和人力资源管理专家研究出了多种科学的，也很庞大的问卷调查方法。其中比较著名的有： 1．职位分析调查问卷PAQ 职位分析调查问卷是美国普渡大学Purdue University的研究员麦考米克等人研究出一套数量化的工作说明法。虽然它的格式已定，但仍可用之分析许多不同类型的职位。PQA有194个问题，计分为六个部分：资料投入、用脑过程、工作产出、人际关系、工作范围、其他工作特征。 2．阀值特质分析方法TTA 劳普兹Lopez等人在1981年设计了"阈值特质分析"TTA问卷。特质取向的研究角度是试图确定那些能够预测个体工作成绩出色的个性特点。TTA方法的依据是：具有某种人格特性的个体，如果职位绩效优于不具有该种特制者，并且特质的差异能够通过标准化的心理测验反映出来，那么就可以确定该特质为完成这一工作所需的个体特质之一。软件需求分析的详细流程
工作分析的程序(5个阶段)
网络教育平台建议和简要需求分析及流程图
需求管理过程
需求分析方法论
需求分析主要流程
工作分析的流程、作用与意义
系统需求分析(业务流程图的练习)
工作分析的内容程序和方法
酒店管理系统需求分析及数据流程图
项目需求分析和调研实践过程
IBM软件产品需求管理流程
需求分析及其格式流程图
怎样做需求分析之十三：分析之行动图和状态图
工作分析流程
需求分析流程需求产品
工作分析的流程、作用与意义
软件需求分析方法
职位分析的方法和步骤