需求管理系列之需求分析与设计人员角色设计
软件开发团队中的角色
软件开发团队角色与职责概述软件开发过程中涉及许多团队角色，每个角色都有其特定的职责和任务，以确保项目的成功。
以下是一般的团队角色及其职责的概述：1.项目经理（Project Manager）项目经理是软件开发生命周期中的关键角色，负责规划、组织、指导和控制项目的整体进程。
他们制定项目计划，设置目标，并确保团队在预算和时间限制内完成任务。
项目经理还需要确保所有相关利益相关者（如客户、赞助商和团队成员）之间的沟通，并解决任何冲突或问题。
2.项目赞助商（Project Sponsor）项目赞助商是提供资金和政治支持的人或组织，通常来自高级管理层或决策者。
他们负责为项目设定目标和期望，并确保项目与企业的战略目标相符。
赞助商需要与项目经理紧密合作，以确保项目成功并满足所有利益相关者的期望。
3.需求分析师（Requirement Analyst）需求分析师负责与利益相关者进行沟通，了解和分析软件系统的需求。
他们需要理解用户的需求和业务需求，并能够将这些需求转化为技术需求。
需求分析师还需要编写和分析项目需求文档，以帮助开发团队了解项目的范围、目标和要求。
4.系统架构师（System Architect）系统架构师是负责设计和规划技术解决方案的人员。
他们需要了解系统的整体结构和功能需求，并能够制定技术架构和系统设计。
系统架构师还需要与开发团队密切合作，以确保设计和实现过程中的技术可行性和高效性。
5.系统设计师（System Designer）系统设计师负责设计软件系统的具体实现。
他们需要根据系统架构师的指导，设计系统的数据库、界面、功能和模块。
系统设计师还需要确保系统的性能、可扩展性、可维护性和可重用性。
6.开发人员（Developer）开发人员是负责编写和实现软件代码的工程师。
他们需要熟练掌握至少一种编程语言，并能够遵循最佳实践和标准来编写高质量的代码。
开发人员还需要进行单元测试和集成测试，以确保代码的正确性和可靠性。
系统分析之需求分析
3.5 系统需求审核列表
• 控制实例 系统必须在操作系统层次及应用系统层次提供登入安 全机制。 员工数据记录只能由人力资源部门的专人做新增、修 改及删除。 所有的交易必须留下可供稽查的纪录。 …
目录
未来增长、成本和效益
事实发现
面谈
其他事务发现技术
文档编制
3.6 未来增长、成本和效益
系统分析 之 需求分析
目录
系统分析阶段概述
联合应用程序开发
快速应用程序开发
建模工具和技术
系统需求审核列表
目录
未来增长、成本和效益
事实发现
面谈
其他事务发现技术
文档编制
系统开发的各个阶段
系统规划System planning –是项目的初始规划，定义初 始业务范围、目标、进度和预算. 系统分析System analysis –是研究业务问题领域，以推 荐改进措施并说明方案的业务需求和优先权. 系统设计System design –为系统分析阶段确定的业务需 求设计一个技术性的基于计算机的方案. 系统实现System implementation –是构造、安装、测试 和发布一个系统投入生产. 系统支持和持续改进（维护和提升项目）
目录
系统分析阶段概述
联合应用程序开发
快速应用程序开发
建模工具和技术
系统需求审核列表
3.1 系统分析阶段概述
系统分析阶段的总目标：了解将要建立系统，确保 它支持业务需求，为系统开发打下坚实基础。 四个主要活动：需求建模、数据和过程建模、对象 建模和对开发策略的考虑。
3.1 系统分析阶段概述
目录
系统分析阶段概述
联合应用程序开发
快速应用程序开发
第4讲 需求分析工具
（5）可与数据建模工具ERin集成使用 BPwin可与数据库工具ERwin双向同步。使用BPwin可进一步验证 ERwin数据模型的质量和一致性，抓取重要的细节，如数据在何处使 用，如何使用，并保证需要时有正确的信息存在。这一集成保证了新 的分布式数据库和数据仓库系统在实际中对业务需求的支持。 （6）符合美国政府FIPS标准和IEEE标准 支持美国军方系统的IDEFO和IDEF3方法，使得开发人员能够从静 态和动态角度对企业业务流程进行建模，支持传统的结构化分析方法 并能根据DFD模型自动生成数据字典。此外BPwin还支持模型和模型 中各类元素报告的自动生成，生成的文档能够被Microsoft Word和 Excel等编辑。 （7）易于使用，支持Unicode 可以在各种不同语言环境的Windows平台上使用。
1
2.开发人员 需求工程涉及的角色（不要与人相混淆，角色是指 一种职责，同一个人可以担当多种角色）包括客户方 （客户、系统使用者）、系统分析师、项目开发及管 理人员。其中系统分析师起到桥梁工程师的作用，负 责完成用户“业务世界（可系统化业务对象）”逻辑 向由软硬件组成的“电脑世界”逻辑的获取和转换过 程。 3. 需求工程3个阶段 需求工程包括需求获取、需求生成和需求验证3个阶 段。
◎商业驱动（产品线瞄准的是长期的商业战略，而不是仅仅走 单）； ◎架构驱动（产品线工程依赖一个通用的参考架构，特定项目 架构都基于参考架构进行开发）；
◎两阶段生命周期（每个产品基于平台开发，产品和平台有各 自的开发团队和开发生命周期）。
16
四、需求分析 CASE工具的具体使用
1．BPwin简介 BPwin 美国 Computer Association公司出品的用于业 务流程可视化、分析和提高业务处理能力的建模CASE环 境。采用BPwin不但能降低与适应业务变化相关的总成本 和风险，还使企业能识别支持其业务的数据并将这些信 息提供给技术人员，保证他们在信息技术方面的投资与 企业目标一致。因此，BPwin作为信息化的业务建模工具 被广泛地、成功地应用于许多位居《财富》500强的大企 业、国防部及美国政府等其他部门。
系统功能需求分析
对输入数据进行有效性验证，确保数据的准确性 和完整性。
数据处理逻辑
根据业务需求，定义数据的处理逻辑，如数据清 洗、转换、计算等。
数据输出与展示
输出格式
根据需求选择合适的输出格式，如表格、图表、报告等。
数据展示方式
确定数据的展示方式，如列表、表格、图表等，以便用户更好地 理解数据。
数据可视化
系统功能需求分析
目录
• 引言 • 系统功能需求概述 • 功能性需求分析 • 非功能性需求分析 • 需求变更管理 • 结论
01 引言
目的和背景
目的
系统功能需求分析的目的是明确系统的功能要求，确保系统 能够满足用户的需求，为后续的系统设计、开发、测试和部 署提供指导。
背景
随着信息技术的发展，系统功能需求分析在软件开发过程中 扮演着越来越重要的角色。通过对系统功能的深入分析，可 以避免开发过程中的功能缺失或冗余，提高系统的质量和用 户体验。
访问控制
系统应实施访问控制策略，限制用户对敏感数据的访问权限。
系统可用性需求
用户界面友好
系统应提供直观、易用的用户界面，方便用户进行操作和 交互。
操作便捷性
系统应提供简单、快捷的操作方式，降低用户的学习成本 和操作难度。
可定制性
系统应提供一定的定制选项，满足不同用户的个性化需求。
系统可维护性需求
响应时间
系统应能够在合理的时间内响应用户请求，避免用户长时间等待。
吞吐量
系统应能够处理大量用户请求，保证高吞吐量。
并发用户数
系统应能够支持一定数量的并发用户，保证系统的稳定性和可用性。
系统安全需求
数据安全性
系统应采取必要的安全措施，保护用户数据不被非法获取、篡改 或泄露。
产品需求分析与需求管理
评价 标准
参与 阶段
者者者者者者者
工程师
技术
2
采购
处长A
处长B
外面专 家
财务
价格
购买阶段 1、问题发现 2、解决方法 3、规格 4、来源确认 5、询问分析
6、建议评价 7、卖主选择 8、购买 9、安装实施 10、业绩评价
用 户 大 会
专 家 顾 问 团
高 层 拜 访
展 览
用 户 探 针
用客工 户户作 访反结 谈馈果
开发阶段
集成测试报告 系统测试计划 系统测试方案 系统测试用例 系统预测试项
系统测试 （执行）
验收测试 （执行）
执行系统预测试 转系统测试 执行系统测试
产品维护
测试任务 输 出 (测 试 )
系统测试用例
系统测试工具设计与实 现
商用测试工具报告
系统测试用例（更新） 系统测试计划（更新） 系统测试方案（更新）
部门: ………… 采集的活动
➢…
客户情况介绍
▪公司介绍 ▪部门介绍 ▪业务介绍 ▪需求产生的场景
姓名: ……….. 客户的描述
…
联系方式: …………… 产生的原因
…
客户的评判
➢验收标准 ➢满意度(提供与不提供) ➢竞争评判 ➢优先度
需求关联
➢系统关联 ➢业务关联 ➢人物关联 ➢支持材料关联
客户名称： 地址： 电话： 访谈问题/提示
客户产品陈述 客户陈述
访谈人： 日期： 后续跟踪： 需求描述（翻译）
客户需求（需求描述） 客户需求（需求描述）
需求群2 需求群1
ac
g xf
优化方向
需求1 需求2 需求3 需求4
需求1
软件工程 人员分工
软件工程人员分工
在软件工程中，人员可以根据其技能和专业知识来分工。
以下是一些常见的软件工程人员分工角色：
1. 项目经理（Project Manager）：负责项目的整体规划、组织、协调和控制。
2. 需求工程师（Requirement Engineer）：负责与用户和相关
利益相关者沟通，收集、分析和管理用户需求。
3. 软件设计师（Software Designer）：负责开发软件系统的整
体结构和模块设计。
4. 程序员（Programmer）：负责根据需求设计和编写软件代码。
5. 质量工程师（Quality Engineer）：负责软件质量管理和测试，确保软件的正确性和稳定性。
6. 配置管理工程师（Configuration Management Engineer）：负责管理软件开发和发布的版本控制、配置管理和变更控制。
7. 项目分析师（Business Analyst）：负责深入了解用户需求和业务流程，为软件开发团队提供需求分析和功能设计。
8. 数据库管理员（Database Administrator）：负责管理和维护
软件系统的数据库，保证数据的可靠性和安全性。
9. 网络工程师（Network Engineer）：负责设计和维护软件系统所需的网络基础设施。
10. 测试工程师（Tester）：负责设计和执行软件系统的测试计划，发现并修复软件中的缺陷。
这只是一些常见的软件工程人员分工角色，实际情况可能会因项目规模和需求而有所不同。
此外，人员分工的具体方式也可以根据团队的组织架构和工作流程进行灵活调整。
软件需求分析建模
小结
在需求获取和分析过程中，要对问题进行 评估，对方案进行综合。在整个过程中，分 析师关注的焦点是“做什么”，而不是“怎 么做”，系统必须完成什么功能，会产生什 么数据，将定义什么界面，会遇到什么约束 等。
总之，在这一阶段主要经历集中在获取和 分析系统的逻辑功能上。不要把“用计算机 如何实现”这样的物理因素牵扯进来，影响 逻辑功能的分析。
需求获取－需求人员
谁参加需求？
角色
职责
需求分析员
客户与最终 用户
项目组
调查、分析用户的需求、定义产品需求、 撰写《用户需求规格说明书》
提供必要的需求信息；确认最终需求
参与需求评审
需求获取－功能
功能性需求
软件必须实现的软件功能
非功能性需求
系统的易用性、反应速度、容错性、健壮性等等质量属性
需求获取－非功能
需求捕获技术－用户访谈
访谈开始和结束
陈述访谈的目的，谈谈被访谈者关心的事。 讨论他们所熟悉的日常工作的过程。 怎样的变化将使你的工作更简单或更有效？暗
示被访谈者提出改进意见。 当列表中的所有领域都讨论过后，提出下面问
题： “还有什么问题我们没有讨论吗？”或是 “ 我们还需要讨论些别的内容吗？” 结束会谈时，简短的总结讨论过的问题，重点 指出会谈的要点，并说出你的理解。 最后，你必须感谢被访谈者参加这次访谈。
本系统对于用户的需求，在功能上可以进行扩展，能满 足各级财政业务上的需求。
本系统在数据库上可以进行移植，支持Oracle,Sybase等 数据库。
需求获取-功能实例
需求获取—参与者
•谁使用了系统的主要功能？ •谁来维护和管理系统使系统正常工作？
角色及其职责描•哪述些人对系统产生的结果感兴趣？
软件开发中的se seg的工作职责
软件开发中的se seg的工作职责-概述说明以及解释1.引言1.1 概述在软件开发过程中，SE SEG（软件工程师和软件工程组）扮演着至关重要的角色。
SE SEG不仅需要与客户合作，识别他们的需求和期望，还需要与开发团队合作，确保软件项目按时完成，并具备高质量和良好的可靠性。
SE（软件工程师）负责软件开发生命周期的各个阶段，包括需求分析、软件设计、编码、测试和维护。
他们需要具备扎实的编程技能和对软件开发流程的深入了解。
而SEG（软件工程组）则是由一群SE组成的团队，他们共同合作，根据项目需求进行任务分配，确保整个开发过程的顺利进行。
在软件开发中，SE SEG的工作职责非常丰富。
首先，他们需要与客户进行密切的沟通，理解客户的需求和期望。
这包括与客户会面、收集需求、制定开发计划，并将这些信息传达给开发团队。
SE SEG还需要协调开发团队内部的工作，确保每个成员都明确自己的职责并按时完成任务。
此外，SE SEG还需要进行软件测试和调试，以确保软件的质量和可靠性。
他们需要进行各种测试，包括功能测试、性能测试和安全测试，以确保软件在各种条件下都能正常运行。
如果出现问题，SE SEG需要快速定位并解决错误，确保软件的稳定性。
除了以上职责，SE SEG还需要进行软件的文档编写和维护，包括用户手册、技术文档和培训材料等。
这些文档对于软件的正确使用和后续维护非常重要，因此SE SEG需要具备良好的文档写作能力。
总之，SE SEG在软件开发过程中承担着重要的工作职责。
他们需要与客户和开发团队进行密切合作，确保软件项目按时完成，并具备高质量和良好的可靠性。
通过他们的努力，软件开发能够顺利进行，并为客户提供优质的产品和服务。
1.2 文章结构本文将从以下几个方面探讨软件开发中的SE SEG的工作职责：1. 软件开发概述：介绍软件开发的基本概念，包括软件生命周期、开发过程和常用的开发方法。
2. SE (软件工程师) 的定义：阐述SE的角色和职责，包括需求分析、系统设计、编码实现、测试和维护等。
系统分析师的工作职责
系统分析师的工作职责系统分析师是一种专业人员，他们在组织中扮演着重要的角色，负责确保公司的信息技术系统得到有效地设计和实施。
系统分析师需要有广泛的技术知识和技能，以便能够分析、评估和改进组织的信息技术系统。
本文将详细介绍系统分析师的工作职责。
一、需求分析与评估系统分析师的首要职责之一是进行需求分析与评估。
他们与各个部门的管理人员合作，收集和分析业务需求，并根据这些需求评估现有系统的性能和功能是否能够满足需求。
通过了解各个部门的业务过程，系统分析师能够确定哪些系统功能需要改进或重建，并提出相应的解决方案。
二、系统规划与设计系统分析师负责制定系统规划和设计。
在制定规划和设计方案时，他们需要考虑各种技术和商业因素，如系统可行性、预算限制、业务需求等。
系统分析师需要具备深入的技术知识，以确保系统的安全性、可靠性和高效性。
在系统设计过程中，他们通常会与团队成员合作，确保系统能够满足所有的业务需求。
三、系统开发与实施系统分析师在系统开发和实施过程中也扮演着重要的角色。
他们与软件开发人员密切合作，确保系统按照规划和设计要求进行开发。
他们负责测试系统以及解决开发过程中出现的问题，并在系统发布前进行全面的验证。
系统分析师还需要进行培训，以便员工能够正确地使用新系统。
四、系统维护与支持系统分析师还负责系统的维护和支持。
他们与用户进行沟通，并解决用户遇到的问题。
系统分析师需要保持对最新技术的了解，以便及时更新和维护系统，并确保系统的稳定运行。
在系统维护的过程中，他们需要进行性能监测和故障排除，以便提供快速有效的解决方案。
五、项目管理对于一些大型的系统开发项目，系统分析师通常还担任项目管理角色。
他们负责制定项目计划、管理资源、监督进度，并确保项目按时完成。
系统分析师需要具备良好的组织和协调能力，能够领导和激励团队成员，以确保项目的成功实施。
六、持续改进系统分析师的工作并不仅仅是设计和实施系统，他们还需要不断地进行系统的改进和优化。
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：功能角色分析与用例图(转)在我们进行一系列需求调研工作的同时，我们的需求分析工作也开始启动了。
需求调研与需求分析工作应当是相辅相伴共同进行的。
每次参加完需求调研回到公司，我们就应当对需求调研的成果进行一次需求分析。
当下一次开始进行需求调研时，我们应当首先将上次需求分析的结果与客户进行确认，同时对需求分析中提出的疑问交给客户予以解答。
这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。
但是，当我们经过一番忙碌，将需求中的第一手资料从调研现场捕获回来以后，我们应当怎样进行分析呢？不少团队对此都比较迷茫，没有一个统一和有效的方法，往往采用想到哪里做到哪里的方式。
一些问题想到了就做了，没有想到则忽略掉了。
实际上，需求分析不应当是太公钓鱼，而应当是拉网排查。
任何一个疏忽都可能对项目研发带来风险。
因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。
不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。
在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。
按照这个思路，我们对需求的分析，首先应当从功能角色分析开始。
所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。
用例图是UML的4+1视图中的一种，准确地说就是那个“+1”。
用例图是贯穿整个面向对象分析/设计（OOA/D）的核心视图，它描述的是系统到底为用户提供了哪些功能，以及到底是哪些用户在使用这些功能，是沟通用户与技术人员的桥梁。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
设计类组织
需 组求 织工 程 师
体 验组 工织 程 师
三类组织统一合成设计类组织
边界·目标·制度·标准·建设
需求人员岗位设计
岗位职责
需求分析师岗位职责
• 负责调研、收集整理用户/客户的 需求，为产品规划和里程碑设计 提供输入； • 负责与客户沟通解决方案，确定 交付内容和范围
产品设计师岗位职责
• 协助产品经理完成产品规划和里 程碑设计； • 负责确定产品业务与技术架构 • 主责产品核心方案设计 • 主责产品价值设计 • 主责产品体验设计 • 主责产品技术管理
职业发展
机会
等待新产品机会，并 培养市场策划能力
行业专家 （职级延伸）
系统架构师 （能力转换）
缺少时间做深入的 专业学习与研究
现实
障碍
管理岗位 （路线变换）
挑战
学习与实践系统设 计能力
需求队伍规模小，少有 机会参与管理工作
需求工程师 （职级通道）
需求人员职业发展通道
结束语
已完结，没有后续内容
转向产品规划和方案设计，事实上承揽了需求和产品设计的责任； 一些对软件极度热爱的专业需求工程师，基于经验和自身的学习 对产品研发有了更深入的认知，也从单一的需求分析转向产品或 系统设计工作。因此成为产品或系统架构师是他们的终极所在。 – 目前需求工程师和一部分介于在开发和需求之间的系统分析人员
事实上承揽了产品的设计工作
• 尝试建立从专业需求到产品
经理的发展路径，提高岗位 吸引力； • 总部对应组织，要求各产品 线或产品必须有产品设计线 条专职负责，并定期开会， 从中获取产品研发设计状况， 从而统筹产品关系。
需求人员培养发展
高
培训培养
资深级分裂，逐渐专业
职业发展 工作绩效
中高级贴合，逐渐复合
针对训练
岗位匹配
初中级区分，逐渐综合
淘泥
西风送暖意，千万里花香意
需求管理系列文章 之
需求分析与设计人员角色设计
经验提供知识，知识创造价值 Tony’s father
目录
1 2 3
需求工作背景分析
需求人员角色认知
需求人员组织设计
需求工作现状分析
业务
问题总结
•产品管理提升能力弱。没有时间或机会接触前沿或趋势性的业务分享，路标设计更多依赖于销售的要求，而缺少对行业或 业务的满足以及业务发展的分析，从而难以将产品从业务替代变换为管理提升； •业务深度分析层次若。忙于产品的定期发版和问题修正，缺少专人对核心业务进行更深入的专项研究，来梳理模式和更合 理的解决方案等。
总部服务
有关培养 有关发展
• 改革需求线条为设计线条， 提升管理者对需求岗位的重 视，吸引优秀程序设计人员 加入
• 各个产品部门要承担业务课 题建设，此职责分配给需求 和产品设计组织，促进专业 技能培养
和产品设计能力培训来提升
职业能力；
• 建立需求分析、系统设计、
体验设计三类岗位人员交叉 培训体系和转换机制，促进 复合型人才培养 • 中初级需求工程师着力促进 其向系统设计转化，重点1） 软件设计技能培训 2）计算 机专业技能培训 3）产品设 计机会与职责落实
需求人员角色认知
工作场景
负责收集并分
设计软件的实 现方案，包括： 界面展现、功 能行为和规则 算法等
与编码/内外 部客户互动产 品的方案，选 择最佳实现路 劲 评估需求对产 品的进度和方 案影响 协调平台与产 品之间的开发 设计工作
析产品A类需
求，作为产品 路标规划输入
需求人员岗位设计
岗位构成
系统工程师 组织
• 负责编写需求规格
• 负责方案的研发交底 • 负责产品价值设计和价值传递
• 负责产品UI/UE设计
• 参与产品规划和里程碑设计
需求人员岗位设计
能力模型
必备能力
提升能力
需求人员职能结构
层级关系
研发(产品)服务(指导)组织
设计类 指导型组织
定方向 定方法 定框架
设计类 服务型组织
推制度 推规范 推实践
需求
•业务范围难以控制。销售、实施和客户掌握项目主动权，合同范围不清或超范围的业务需求不断涌现，难以控制，从而造 成产品超计划交付 •业务本质难以掌握。客户或市场人员掌握了业务的话语权，有时难以探索客户业务的真实意图，即便了解也可能被部分强 势人员主导，最终导致需求反馈和应用障碍。
产品
•规划能力缺失。多种原因造成产品缺少长期规划，短视，更多看到眼前利益而忽视了产品的长期发展 •设计能力缺失。设计人员匮乏能力不足，外来血液非常稀少，体现在一方面产品技术管理与方案设计混乱，没有长期性规 划，就点论点，散乱，另一方面缺少对新技术新思路的了解，因循守旧，跟不上时代发展，产品缺少竞争性。 •体验能力缺失。优秀的业务设计能力和糟糕的用户体验，是用户在深入了解我们的产品后的评价。
低 需求工程师 系统架构师 开发工程师 体验工程师
模块化
系统化
实践性
发展性
产品设计类人员 培养路径
职业晋升通道
产品设计列人员 培训体系
三类岗位组合，但不意味职业通道合并，可以存在多个相 岗位组合，也不意味岗位职责合并，可以存在多个
需求人员培养发展
产品经理 （角色转换）
不断收集分析客户反 馈，并定期迁移整理 到标准版产品，促使 产品不断发展，价值 不断增加，从而促进 产品销售
协助产品经理收集A 类需求，规划产品发 展路线，确定产品路 标，从而促进产品价 值不断提升。
违约
需求人员角色设计
• 定位
角色定位
– 产品（系统）设计师
• 理由
– 一部分技术架构师发展到一定阶段，主要工作会从技术架构设计
职业发展与 晋升通道（娘家）
产品分析设计方法与 最佳实践（诊断与指导）
产品分析设计流程与 标准推行（制度落实）
产品组织
设计类 业务型组织
产品组织
设计类 业务型组织
产品组织
设计类 业务型组织
上层强化服务与制度建设职能
下层加强实践与沟通改进职能
需求人员职能结构
有关培训
• 通过定期组织行业发展趋势 和信息化前沿技术的讲座来 促进职业发展 • 通过定期组织需求分析能力
需求人员的角色认知
角色画像
行业专
家
系统建
模专家
业务架
构专家
需求人员角色认知
价值存在
负责接受内外部客户 需求，并核实客户真 实想法，沟通方案， 减少变更，从而避免 方案走偏，减少变更 成本
与客户沟通研发计划
和交付节点，减少变
更，削减需求范围， 延长交付时间，从而 降低交付压力，减低 开发成本，避免合同
人员
•职业生涯受限。需求人员的成绩不易体现，经常处于背黑锅的状态；又大多出生于专业，发展和晋升路径非常狭窄。即便
是走出公司，由于缺少了工程实践，也不利于返回到原行业继续深造。 •能力成长受限 。在产品组织内，应用专业知识有限；学习软件知识，也没有太多机会。基本上机械式的忙于问题解答和方 案编写，缺少完整的体系性学习和成长的空间，即便有，有时也缺少应用机会。 •资源来源受限 。目前需求人员无论在薪酬还是发展机会都缺少吸引力，特别难以吸引有能力人员加入。招聘1个需求工程 师周期一般都在3~6个月以上，内部转岗目前也十分鲜见。