课程长度: 标准版4天(28学时),精华版3天(21学时)
课程安排:
l 本课程采用案例情景式、互动型教学方式,为保证学习效果,限人数不超过25人。
l 这门课程的特点是,知识讲解、案例分析、分组角色模拟相结合,通过一系列实际案例将需求分析理论和学员的工作实践有机地串联起来,从而帮助学员解决工程项目实践的各种需求问题。
|
第一天
|
第1单元:
需求工程概述
|
1.1需求实践现状
1.1.1调查:学员在工作中遇到的需求问题
1.1.2需求实践常见问题研讨
l 用户不配合需求调研工作
l 用户说不清楚自己的需求
l 用户总能想出新的需求
l 不同用户的需求相互矛盾
l 用户的需求无法实现
l 用户看不懂需求规格说明书
l 开发团队猜测用户的需求
l 用户不肯为需求签字
l 第一版完成后用户需求大幅变更
l 系统上线时遇到很大阻力
l 系统上线后效果不佳
l 系统不可用甚至崩溃
1.1.3需求实践常见问题诊断
1.3 需求工程requirements
engineering
l 需求开发requirements development
n 需求获取requirements elicitation
n 需求分析requirements analysis
n 需求文档化requirements specification
1.4需求工程的深度话题
l 项目经理与需求分析师
l 从项目成败的角度去看待需求工作
l 项目成功的终极标志---客户满意
l 利用需求管理提升满意度
l 需求分析与软件生命周期的关系
讨论:需求分析时要不要考虑设计与实现;
|
第2单元:
项目启动
|
2.1产品愿景(product
vision)与项目范围(project scope)
2.2最佳实践:RUP范围定义五步法
1) 问题定义(Problem Definition)
2) 根源分析(Root Cause Analysis) —问题背后的问题
3) 干系人分析 (Stakeholder Analysis)与End User分析
4) 定义项目边界或系统边界(Boundary)
n 划分主题业务领域(Subject Domain)
n 明确各主题域的范围/边界
n 标识业务事件(Event)
n 标识管理控制点/报表(Report)
5) 明确限制与约束(Constraints)
2.3 阶段可交付物(Deliverable)
l 问题/机会列表
l 产品愿景 product vision
l 项目章程 Project Charter
l 项目需求文档 Project Requirement
Documentation
l Stakeholder列表
2.3工具与技术
l 关联图context
diagram
l 鱼骨图 Fishbone diagram
l 帕累托图Pareto
diagram
l 构件图 component diagram
l 部署图 deployment diagram
2.4 组建项目的需求分析团队
l 需求分析团队的职责
l 需求分析团队与甲方相关的角色
l 需求分析团队与乙方相关的角色
l 需求分析师应具备的能力
l 什么样的人适合做需求
l 如何培养优秀的需求分析师
l 需求分析师的职业前景
2.5课堂练习
l 高层/Sponsor:问题/机会à项目目标
l 人(涉及部门与人员)àStakeholder关注点
l 事(业务)à业务主题域à事件+ 管控点
|
第二天
|
第3单元:
需求获取
|
3.1 与真正的用户讨论需求 (Finding
the Voice of the Customer)
3.1.1 需求的层次 (Levels of Requirements)
3.1.2 用户的结构 (User Classes)
3.1.3 用户代表 (User Representatives)
3.1.4 决策机制 (Who Makes the Decisions)
3.1.5 用户代言人(The Product Champion)
讨论:信息中心与业务处室谁是用户?
讨论:新产品研发项目中的用户需求
讨论:冲突的用户需求——如何做好春晚导演
3.2 需求获取方式
l 用户访谈(面谈、电话、电子邮件)
l 现有系统的问题报告和改进要求
l 市场调查和用户问卷调查
l 观察用户如何工作(学徒实习)
l 需求专题研讨会(Elicitation Workshops)
l 文档研究
l 原型开发
l 研究竞争对手
l 软件考古学(Software Archaeology)
l 各种需求获取方法对比分析
|
第4单元:
需求分析
|
4.1 Model and UML
4.2 问题域、连接域和实现域
4.3基于UML的需求分析(Requirements Analysis with UML)
4.4以用例为中心的需求分析过程(Use-Case Modeling)
4.4.1开发一个可以理解的需求
n 识别参与者(actor)
n 识别用例(use case)
n 构建用例图(use case diagram)
4.4.2用例阐述(详细、完整地描述需求)
4.4.3重构用例模型
n 识别用例关系
n 用例组织和分包
|
第三天
|
第5单元:
编写需求规格说明
|
5.1将潜在需求变成书面需求
5.2编写需求规格说明书(SRS)的原则
5.3 非功能性需求Nonfunctional
Requirements
l 如何发现非功能性需求
l 用例与非功能性需求
l 观感需求 Look and
Feel Requirements
l 易用性需求Usability
and Humanity Requirements
l 性能需求Performance
Requirements
l 可操作性需求Operational
and Environmental Requirements
l 可维护性和可移植性需求Maintainability
and Support Requirements
l 安全性需求Security
Requirements
|
第6单元:
需求质量控制和质量验证
|
6.1需求质量控制
l 需求验证 Validation
l 需求审查 Inspection
l 同行评审 Peer Review
l 需求走查 Walkthrough
6.2需求质量关Quality Gateway
l 测试完整性
n 测试是否存在遗漏的部分
n 测试是否对所有风险承担者都有意义
l 测试可追踪性
l 统一使用术语
l 确定是否与目标相关
l 测试验收标准
|
第四天
|
第7单元:
需求管理
|
7.1需求基线
7.2需求状态跟踪
7.3需求变更控制
l 范围蔓延(Scope
Creep)与渐进明细(Progressive
Elaboration)
l 变更控制流程
l 变更控制委员会(CCB)
l 变更影响分析(Impact
Analysis)
7.4需求链维护
l 需求链
l 需求跟踪矩阵
l 需求跟踪工具
7.5需求管理工具
7.6需求工程最佳实践
7.6.1需求工程中的风险管理
n 软件需求工程中常见的风险
n 常见风险的分析和应对
n 信息化工程首先是一个管理工程
7.6.2产品经理与需求分析师
7.6.3关于需求签字确认问题的不同理解
7.6.4需求和设计工作的衔接
n 需求分析时要不要考虑设计与实现;
n 需求分析、系统分析和设计到底如何划分又如何衔接
7.6.5产品研发项目和客户定制软件开发项目需求管理工作的异同
|
第8单元:
案例分析与学员问答
|
两个铁球会同时落地,但铁球和羽毛会同时落地么,需求分析师不是生活在真空里,靠书上的理论能做出好的需求么能控制住需求膨胀和蔓延么?
这个单元的特点是,着重研究需求管理的各种问题在实战中而不是在理论中应该如何解决。
其目的是帮助学员提高解决实际问题的能力,所以要求每个学员都要带着自己的问题来参加研讨。为此,所有参加研讨的学员在报名时需提交至少一个案例(工作中遇到的问题),教师将会选择有代表性的案例在课堂上安排现场研讨。
|
|
|
|
|
|