需求部分笔记
目标模型2024夏 需求期末范围
需求获取 30%
需求获取上半段 20%
确定项目前景与范围 10% 目标模型
涉众分析 10%
涉众识别之 ADM 模型
涉众评估之 Power-Interest
Power-Attitude 模型
涉众共赢之 Stakeholder-Issue 模型
需求获取下半段 10%
面谈、原型、观察三大获取手段的联系与区别
面谈问题的设计
需求分析 10%
需求分析的根本任务与活动
基于UML软件建模的需求细化 – 概念类图、顺序图、状态图（大概率）
需求验证与管理 10% 四选一
需求验证基本活动
需求管理任务与活动
需求变更控制过程与组织
需求变更注意事项
基础知识
需求的层次性：问题->目标->用户需求->系统级需求
问题域：问题发生的地方，软件开发所谓的'需求'。
解系统：软件开发的设计、实现
软件系统中的某些部分对问题域中的某些部分的具有模拟特性
问题域和解系统之间的共享现象：通过映射建立的共同知识
需求工程基本活动：需求获取、需求分析、需求规约、需求验证、需求管理
目标模型
2020.06：结合微博存在的问题，进行目标分析（尽可能多地使用目标分析的元素）
2021.01：便利蜂想要在 2021 年⼤规模扩张，画出⽬标模型
2022.01：结合蔚来电动车的车友社区，进行目标分析（尽可能多地使用目标分析的元素）
2023.01：请为20年4月前后（阅文换血）的阅文集团写出目标模型，无需关注目标的实现，并指出哪些目标冲突、哪些目标之间是支持关系。
2024.01：给一段材料，画目标模型
2024.06：画出小天才在父母关心儿童安全和儿童社交两个方面的目标模型，并指出哪些目标冲突、哪些目标之间是支持关系
软目标：无法清晰判断是否可以满足的目标，可维护性，云朵表示
硬目标：通过技术确认是否满足的目标，性能指标，矩形表示
AND 精化：子目标完成保证父目标完成，合并画实心圆（子目标要一起连到父目标）
OR 精化：子目标之间是可以相互替代的，分开画空心圆（子目标要分开空心圈、分开连到父目标）
支持 Support：某一个目标达成会支持促进其他目标（可以被处理为 OR 关系）
冲突 Conflict：某一个目标对于其他目标的实现有阻碍作用
目标规格：实现 Achieve、终止 Cease、保持 Maintain、避免 Avoid、优化 Optimize
涉众分析
ADM模型 涉众识别
以前都没考，是不是因为卷子上不大好画彩色的图？🤔
更多内容参考PPT
目标依赖（goal dependency）：依赖者希望被依赖者满足一个条件，但不会规定怎样满足该条件。（椭圆）
软目标依赖（soft goal dependency）：一种特殊类型的目标依赖，其条件是无法量化描述的。（两个圈）
任务依赖（task dependency）：依赖者希望被依赖者执行特定任务。任务依赖比目标依赖更加具体，因为满足目标可以执行很多任务，被依赖者有自己的选择权。而任务依赖直接为被依赖者规定了任务。（六边形）
资源依赖（resource dependency）：依赖者希望被依赖者提供资源实体（抽象信息或者实物材料）为自己所用，但不关注提供资源需要被依赖者执行的行为和解决的问题。（正方形）
Power-Interest Power-Attitude 涉众评估
2020.06：使用power-interest和power-attitude模型，阐述如何化解微博的涉众风险
2024.01：画出给定材料的涉众评估和涉众共赢分析
2024.06：用power-interest和power-attitude模型，阐述小天才手表的涉众风险和化解方法，并指出目前小天才将在父母关心儿童安全和儿童社交两种需求并列的方式为何无法真正地化解风险
基于涉众特征与态度化解涉众风险策略
基于特征化解举例：亲子兴趣班
大人与小朋友一起参与：环境设定者（客户）→参与者（用户）
良好的产品体验打造亲子品牌：被影响者（潜在用户/客户）→参与者
基于态度化解举例：
电子竞技产业– 与地方政府文化产业发展相结合：强反对者→强支持者
成功的赛事运营与未成年人游戏时长限制：弱反对者→弱支持者
化解涉众风险
一方面提高环境设定者对系统的关注，转化为参与者
一方面消除强反对者的反对原因，变为强支持者
给予被影响者一些发表和实现自身意见的权利，缓解忧虑
Stakeholder-Issue 涉众共赢
2021.01：有店员因为数学不好⽽离职，⽼店⻓认为计算机不能代替⼈类决策；通过实验证明数据模型更有效；⽼店⻓培养新店⻓；减少店员数量，增加店员收⼊。结合材料，⽤ stakeholder-issue 模型进⾏涉众共赢分析
2022.01：使用 Stakeholder-Issue 模型进行共赢分析
2023.01：以网文IP改编剧的关键涉众和业务目标作为一个整体
用stakeholder-issue模型进行涉众共赢分析，stakeholder和issue数量不能过少
结合以上模型论述为什么阅文集团在“网文填坑节”等活动中会邀请演员代表参与
举例：阅文的免费模式能否与订阅模式共赢?
Issue：免费带来的更多流量与写手身份转换
Stakeholder对上述Issue的意见：
头部与底部写手、普通读者：可以接受
腰部写手：影响收入，进一步弱化保障
核心读者：担忧文章质量下降
如何共赢：免费与订阅在多大程度上共存
免费创作与订阅写作区分开，但共存
允许作者同时成为免费与订阅（特定连载小说）写手，或新手作者需先从免费写手做起
其它可能达成共赢的Issue：利用免费阅读模式为平台引流（并分享给腰部及以下写手）
其它较难达成共赢的Issue：平台对IP的强力掌控与作者本身的著作权主张
2024.01：画出给定材料的涉众评估和涉众共赢分析
列出系统的所有涉众类别，明确描述他们的兴趣和对系统的期望
从涉众们的兴趣和期望中发现背后涉及的共同问题(Issue)
建立涉众类别和问题的关联，如果某个涉众类别对一个 Issue 存在兴趣，那么该涉众类别和这个Issue 就存在关联关系
对每一个Stakeholder/Issue 关系，标明该关系上面所被寄予的期望
需求获取下半段
2020.06：假设你想要开发直播带货，结合三种需求获取方法，简述你将如何进行需求获取
2021.01：想搞社区团购，有个⼈懂，并且还会直播带货。需求获取有哪三个⽅法？结合材料谈如何进行需求获取
2022.01：面谈问题的两大类型，和一个传统燃油车用户面谈，探讨服务和？让这些客户选择电动车，构思一个问题列表
2023.01：写出面谈的两大类问题和适用范围。假如你在《需求与商业模式创新》中得了高分，并以此进入了阅文的产品设计和运营岗位。现在你将面谈一个资深的，较为自我的硬科幻读者，以让网文平台能够带来良好的硬科幻阅读体验，请设计一个前期面谈问题列表
2024.01：采访一个人，给出面谈问题列表，大意是想推广盒马的一个小程序游戏，采访一个不太使用线上购物的家庭主妇
2024.06：小天才为了防止不良内容，在聊天里面加入了极为严格的关键词屏蔽功能。你是小天才的产品设计人员，你要向一位33-43岁左右，对儿童手表不甚了解的孩子母亲，面谈关于关键词屏蔽功能的问题。请设计面谈问题。
面谈、原型、观察三大获取手段的联系与区别
联系：需求工程师获取用户需求的手段
面谈：与用户创造性地交流，充分发掘用户潜在想法
原型：帮助消除用户或需求工程师想法中的不确定性
观察：需求工程师亲自（涉身）观察并发掘情景性需求，无法确保用户将所有的信息都告知
面谈问题的设计
前期：开放式问题
目前的业务主要碰到了哪些问题？
希望新系统能够帮助达成哪些目标？
销售工作是怎样进行的？
哪些人会参与销售过程？
哪些人的哪些工作是最为瓶颈的？
后期：封闭式问题
xx事物是什么样的？
需要显示的xx有哪些？
有可能不xx吗？
程序性提问
总结和反馈
你能不能总结一下系统的功能？
你能不能总结一下一个成功系统的必备特征？
在使用的时候，你希望能够从系统当中得到什么类型的信息反馈？
重复和改述
能不能再说一次系统的哪些特征是重要的？
你能不能详细的重新叙述一下使用系统的步骤？
建立场景和细节描述
在使用系统的时候你会做出什么决定？
有什么是你现在能做，却在新系统中不能做的？
在什么情况下，功能是必需的？
设想现在是6个月之后，你需要评估系统的成功状况，你会使用哪些标准来做出评价？
你能不能想出什么不使用系统的理由？
抗辩
你为什么会不想使用系统呢？
你能不能想出将来可能导致系统失败或故障的原因？
其他
探究式问题
为什么？
你能举个例子吗？
你能详细描述一下吗？
诱导性问题：你和其他经理一样，都同意把财产管理计算机化，是吗
双筒问题： 每天你通常会做什么决策，你是怎样做的
元问题
我的问题看起来相关吗？
我还应该见什么人？
需求分析
需求分析的根本任务与活动
2024.01：需求分析四个活动，要写出细节
需求分析的根本任务：建立分析模型、创建解决方案
需求分析的活动：需求细化、需求建模、确定需求优先级、需求协商
概念类图
2023.01：阅文平台提供了月票和会员机制，请以会员获得月票作为完整的用例，构建领域模型（简化类图）
保底月票
无
上月订阅消费满1000起点币，次月获得1张
上月订阅消费满1000起点币，次月获得2张
上月订阅消费满1000起点币，次月获得3张
订阅月票
订阅消费满3000起点币获得1张
订阅消费满2000起点币获得1张
订阅消费满1500起点币获得1张
订阅消费满1000起点币获得1张
类似软工1的类图
类与类的连接要写动作
连接两边的0 1 * 代表多重性（对应0个 1个 多个）
顺序图
2021.01：买优惠券包、查看优惠券、优惠券包退款、优惠券包过期换积分。画出⽤例的系统顺序图
par：并行
alt：类比
switchopt：类比
if，方括号内为判断条件loop：循环，方括号内为循环条件
break：跳出，方括号内为跳出条件
状态图
2020.06：微博有一系列的封号规则，根据规则画出状态图
2022.01：蔚来电动车有一系列的升级（类似）规则，根据规则画出状态图
2024.06：小天才针对违规内容、违规应用，将违规级别分成3级，根据违规次数决定处罚方式，有不展示、下架应用一个月，永久下架应用，永久终止和开发者的合作等等（给了一张表），请画出对违规应用行为的状态图（注：每个触发方式是一个状态，“应用正常”也是一个状态）
需求验证与管理
需求验证基本活动
2023.01：免费网文较难进行影视化改编，但快手发现 IP +短视频的新模式模式。试写出需求验证除了自动化分析的其他五种手段，请对“IP+短视频”选择一种最佳的需求验证方式，并进行论述
2024.01：除了自动化分析之外的五项需求验证（方式）
评审
原型与模拟
开发测试用例
用户手册编制
利用跟踪关系
业务需求 -> 用户需求 -> 系统需求
系统需求 -> 用户需求 -> 业务需求
自动化分析
需求管理任务与活动
2020.06：简述需求管理的三种方法和流程
2021.01：让你做⼩程序和 APP ，需求管理包括哪些要点？结合着谈谈
2022.01：简述需求管理的三种方法和管理变更的五大原则
维护需求基线
交流涉众需要什么；
驱动设计和实现工作；
测试和验证最终产品；
辅助项目管理
实现需求跟踪
将需求分配到子系统；
将需求应用、实施到解决方案；
控制变更
控制变更
控制迭代式开发中的变化
需求变更控制过程与组织
提请需求变更 -> 接受变更需求 -> 评估者 -> 变更决策 -> 执行变更 -> 验证变更
变更控制委员会 CCB
项目或程序管理部门
产品管理或者需求分析部门
开发部门
测试或者质量保障部门
市场或客户代表
编写用户文档的部门
技术支持或帮助部门
配置管理部门
需求变更注意事项
2024.06：小天才注册了“老天才”商标，涉及科学仪器、珠宝首饰等产业。请写出需求变更的五大原则，分析“老天才”的产品可能的设计方向，并选取需求变更的一个原则，点评小天才注册“老天才”商标的行为。
认识到变更的必要性，并为之制定计划
维护需求基线，审计变更记录
管理范围蔓延
灵活应对变更请求
使用辅助工具
最后更新于
