腾讯：从概念到产品需求分析过程

2020-03-01 207浏览

1.从概念到产品－需求分析过程 Something about grammar & literature
2.开始的话 2
3.引子：不仅仅纯技术 • 人文比科技重要！ • 方法比技能重要！领导者资深专家管理者高级专家监督者专家有经验者初做者 3
4.学习态度？ • 一天，三年甲班的杨过忘了交作业，导师郭靖问他：“为什么没交作业？” • 杨过答曰：“作业为什么要交？交了不一定是自己写的； – 写了又不一定会；（不小心破了珍珑的虚竹不好意思地看了逍遥子一眼） – 会了又不一定会考；（苦心准备当盟主的左冷禅背后响起闷响） – 考了又不一定会过；（白眉鹰王身边秋风吹过阵阵凄凉的落叶） – 过了又不一定能毕业；（被古墓派退学的李莫愁脸色一变） – 毕业又不一定会找到工作；乐天的令狐冲正在酒醉中没听见） – 找得到工作又不一定保得住工作；（萧峰夺门而出） – …… ？” • 只见现场沉默三秒之后，众人联手围殴杨过…… 4
5.先从语法课讲起 • 用户是一个或者多个名词； • 产品是名词，一般由很多个名词组成； • 产品设计过程 – 功能需求就是找出“动宾短语”的集合 – 性能需求就是找出“形容词”的集合 5
6.订书机为例（仅供参考）产品产品订书机订书机::n.n. 一种装订文件的文具一种装订文件的文具订书机包括：订书机包括：杠杆结构：杠杆结构：n.n. 进钉结构；进钉结构；n.n. 压钉结构；压钉结构；n.n. 钉书钉钉书钉((消耗品消耗品):n. ):n. 用户用户用户：用户：n.n. 使用订书机的人，应大于使用订书机的人，应大于33周岁周岁；且有手或者类似可以发出至少 1kg ；且有手或者类似可以发出至少 1kg力力量的人。最常用 (80% 以上 ) 为女性量的人。最常用 (80% 以上 ) 为女性 (21-40) (21-40)。。需求需求功能需求功能需求装订文件；装订文件； Load 书钉； Load钉钉钉钉； Unload Unload钉书钉；钉书钉； … … 性能需求性能需求外观、颜色、省力、材质外钉钉、钉钉色、省力、材钉钉钉钉……钉. . 钉 6
7.产品设计过程 • 定义好用户 • 定义好产品 • 先分析功能需求 80/20 的误区：产品日趋同质化，公司之间的差别，市场竞争的成败，往往是由性能决定 • 再分析性能需求 7
8.互联网本质论 • 计算机为什么叫计算机？ • 互联网其实是一个大数据库 • 大部分应用都是数据库应用 – – – – Search? B2B 、 B2C 、 C2C? Gaming? Avatar ？ Blog? • 小部分应用是即时的存储转发类 – IM – VoIP 知的库据数习复识! 8
9.课程概述 9
10.课程内容 • Use Case 分析方法 – 找寻用户 – 定义产品 – 发掘功能需求 • 性能需求的“套路” • 需求文档的撰写 • 钉品钉技理常用 “ 法” – 工作组织方法 – 常用图表和绘图方法 10
11.需求分析与人文 • 需求分析是一个工业化的写作过程 • 80 ％的套路＋ 20 ％的创意 • 好的钉钉文水平：钉钉钉 – – – – – 有利于抓住关键词汇有利于培养数字敏感有利于增强形容能力有利于组织文档结构有利于提高沟通能力！吧读书吧！客博写 11
12.Use Case 分析法 12
13.USE-CASE 的历史 • 1967 年 Jacobson 在爱立信工作的时候开始使用这种思想 • 这种想法最早应用于大型交换机系统的需求获取 • 1971 年完成了这种方法的最初原型 • 1985 年推出了改进版，并发布了面向对象的 OOSE 方法 • 大部分面向对象技术都采用这种需求方法， UML 建模语言也已将它包容进去 • 它还被广泛的应用于工业领域 13
14.需求获取的前提用户必须告诉你他想要什么你必须完整地了解用户的业务你必须知道与系统有关的任何人和任何东西如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现在是怎么工作的 • 从专家那里了解用户业务的原理和规则 • 你是去了解要做什么而不是怎么做 • • • • 14
15.首先，您需要把系统看成黑盒统统统统 • 一开始就深入细节的产品经理，忙乱而又没有绩效 – 往往陷入细节的泥坑，甚至是技术细节，甚至 UI 细节 – 被层出不穷的需求点和例外处理困扰 – 控制不住满脑袋乱冒的 ideas • 请相信！！！！！！！！！！！！！！！！！！！！ – 系统内部无论多么复杂 – 他总是可以被“使用说明书”说清楚 15
16.Actor 16
17.需求分析的第一个问题谁是这个产品的用户？或者，谁是这个产品系统中的角色？ 17
18.什么是角色 (Actor) • 与系统发生交互作用的、系统之外的任何东西都是角色 – 可以是人 – 也可以是机器 • • • • 角色不等同于使用者我是角色 Actor ！角色存在于系统外部角色不是活动的准确描述使用者是行驶某个角色职责的系统的使用人员 – 如小王是个采购员 18
19.角色（续） • 每个 Actor 都通过不同的方式使用系统，除非他们是相同的 Actor • Actor 使用系统的每一种方式就是一个 Use Case 群创建者群普通用户群股东群管理员群股东 19
20.角色分类 • 主钉角色：钉钉钉 Use Case 的动作序列是由他先发起的，通常系统返回最后结果 – 主叫方，采购人员，票据录入员等 • 被钉角色：系钉钉钉钉钉钉通钉钉钉用角色来完成钉钉钉钉钉 Use Case 的动作序列（或其中的某一个动作） – – – – 不是初始动作的发起者当系统需要它们帮助的时候最终是为了满足主动角色的需要通常是机器或其他系统 Use Case1 Actor Actor Use Case2 Actor 20
21.Script 21
22.脚本 Script • • • • • 脚本是一个角色与系统之间的一组交互作用通常具有详细的真实数据及实际的期望输出值一个应用系统可能具有成千上万个脚本即使同一件事，所得到的脚本可能也会有细微的区别脚本是描绘 Use Case 的重要的背景信息 22
23.脚本示例 1 ：小王输入他的账号 #413597 2 ：小王输入他的密码 #119823 3 ：小王查询 98.7.1 至 98.12.31 日之间的平均余额 4 ：系统显示余额 1 ：小张输入他的账号 #413343 2 ：小张输入他的密码 #646788 3 ：小张查询 98.3.1 至 98.5.31 日之间的平均余额 4 ：系统显示余额 1 ：小李输入她的账号 #346780 2 ：小李输入她的密码 #435645 3 ：小李查询 98.7.1 至 98.12.31 日之间的平均余额 4 ：系统显示余额 23
24.脚本与 Use Case • • • • • 一个 Use Case 代表一组潜在的脚本通过研究一组相似的脚本，可以得到它们内在的逻辑相似的脚本通常遵循相似的模式工作，并提供相似类型的结果一个 Use Case 通常关注某一个目标例如：钉钉钉存折余钉钉钉 ½Å ± ¾ Use ¹ ¦ÄCase ¼Ð Ü 24
25.Use Case 25
26.通过 Use Case 描述系统功能需求 • 一个系统具有无限个潜在的脚本 • 但一个系统可以被有限的Use Case 完整说明 • 系统的每一个 Use Case 都必须列举，否则系统将会遗漏功能转让群授权群管理群内发言解散群创建群邀请加入群加入群赞助群 26
27.Use Case • 描述系统提供的交互功能 – 一个 Use Case 可以被其他的 Use Case 调用 – Use Case 可以组合完成某一项更大的功能 • Use Case 说明系统需要提供什么而不是怎么提供 – 用户并不关心你如何给他们提供所需要的功能 • Use Case 一般是用“动宾”短语命名授权群管理群内发言解散群创建群邀请加入群加入群赞助群 27
28.Use Case • Use Case 不是分析设计文档 – 虽然它们支持后续的分析设计工作 • Use Case 不是操作脚本 – 它不是用户使用系统时实际操作的具体步骤的记录 – 虽然它可能是通过操作脚本得来的 28
29.Use Case 是很好的测试单元 • Use Case 清晰地描述了系统的功能界面 • 测试人员可以在开发初期制定测试计划 • 每一个 Use Case 都严格地说明了系统的某一项功能 – 它的输入 – 它的输出 – 期间的交互作用 • Use Case 是黑盒测试的基准 29
30.Use Case 的阐述 • 应该包含 Use Case 的所有重要细节 • 应该包括角色与系统交互的关键步骤，可以使用顺序图（ Sequence Diagram ） • 要表述有关角色的信息 • 要分清哪些是角色所具有的职能、哪些是系统所应提供的 • 要列清使用这些功能是所应满足的前提条件 • 如果某些功能具有质量上的要求（如性能），也要列出来创建群 Dddddddddddd Dddddxxafsdfads Dddddddddddd Ddddfcadsfasd ddddccdasdwe 30
31.Use Case ：标记方法简单 Use Case 名称 Actor 名称 31
32.Use Case ：主动角色经纪人投资人下单报价审查货币存取经纪管理系统 32
33.Use Case ：被动角色经纪人投资人下单报价审查货币存取银证转账系统经纪管理系统 33
34.画 Use Case 图规则 • • • • • • • • 主动角色画在图的左边被动角色画在图的右边每个 Use Case 必须为用户提供确切的功能 Use Case 名称必须写在椭圆里面保持图面整洁每一张图里不能有太多的 Use Case 为每一个 Use Case 编号便于检索为 Use Case 建立目录（编号和名称）便于管理 34
35.Use Case 高级概念 35
36.Use Case 高级概念 • 通过分析 Use Case 图，分析人员可以找出不同的业务过程之间的共性 – 钉展、包含、派生、使用等钉钉系 • 通过这些关系可以降低系统的复杂度 • 为重用提供了条件 • 将共性提出来，可以帮助我们发现重复的过程 – 二次开钉钉钉钉钉注的地方钉钉钉 36
37.Actor 的继承 • 类似于 Use Case 的扩展，角色之间可以继承 • 其他银行不仅具有储户的所有功能，还有其他的功能 Òø ÐÐ ² é Ñ Ó̄ à ¶ î ´ ¢ » § ´ æ Ç® È ¡Ç ® · Ñ ÓÃ ½á Ëã Æä Ëû Òø ÐÐ 37
38.Actor 继承的好处 • • • • 在不丢失信息的前提下，简化了 Use Case 图继承说明了角色间的层次关系派生者继承了父角色的所有能力父角色不知道派生者 38
39.扩展关系： extend ÊÓ ¹ Ã ¹ ñ Ô± » ú ¡ ¶ À© Õ ¹¡ · ÓÃ » § Ñ ¡Ô ñ ² é Ñ Ó̄ à ¶ î ² é Ñ Ó̄ à ¶ î • 扩展关系通常用来表示某一个 Use Case 的可选择部分 – 扩展关系允许分析人员在没有改变基 Use Case 的情况下增加或修改基 Use Case 的功能 – 钉钉的可替代途径钉钉钉钉钉使用钉钉钉展钉钉系把它钉钉钉钉分成多个钉 Use Case • 也可以这样看扩展关系： – 在基 Use Case 上插入功能，而基 Use Case 本身不知道钉个钉钉钉展 39
40.扩展关系 (extend ) 示图 ¹ ñ Ô± » ú ¡ ¶ À© Õ ¹¡ · Ó» Ã§ Ñ ¡Ô ñ ² é Ñ Ó̄ à ¶ î ² é Ñ Ó̄ à ¶ î ¹ ñ Ô± » ú ÓÃ » § ´ æ Ç® Ê ¹Ó Ã ¹ ñ Ô± » ú ¡ À ¶ © Õ ¹¡ · ÓÃ » § ÑÔ ¡ ñ́ æ Ç® ¡ ¶ À© Õ ¹¡ · ÓÃ » § Ñ ¡Ô ñ È ¡Ç ® È ¡Ç ® 40
41.使用关系 ´ æ Ç® ¡ ¶ ° ü º ¬ ¡ · ´ ò Ó ¡µ ¥ ¾Ý • 如果 Use Case A 包含 Use Case B ，表示在执行 Use Case 的动作序列过程中，在某一点上将开始执行 Use Case B 的动作序列，完成后将回到同一点上继续执行完 Use Case A 的动作序列 • 它与扩展关系的区别是： – 扩展是可的选 – 包含是必做的（更象一个子钉程）钉钉 • 和扩展关系一样，一个 Use Case 可以包含很多个子 Use Case ，也可以被很多个父 Use Case 所包含 41
42.包含关系 (include) 示例 ¸ ¹̧ ¦Ä Ü ¼Ð ¡ °Ô ö ¼Ó ÐÂ Ô± ¹ ¤ ¡ ± × Ó ¹ ¦Ä Ü ¼Ð ¡ °Ð Â ½ ¹̈ ¤ ¿ ¨¡ ± 1. Ê ä È 2. Ê ä È 3. Ê ä È 4. ± £́ 5. Ï µ Í 6. È ç¹ ÐÂ µ ë ± Ô ¹ ¤ ÐÅ Ï ¢ ¹ ¤ ë × Ê ¶ î Ö °Î » ë æ ³½ ø ÐÐ º Ï· ¨» ¯ ¼ ì² é Õ ý³ £ ¬ û Ï µ Í ³½ Á̈ ¢ Ô± Ä ¹ ¤ ¼Ç Â¼ ° ü º ¬ µ Ä ² å Èë µ ã 1. É ã Ï ñ 2. ² å Èë ¿ °Õ × ¿¨ 3. Ð Â ½ ¹̈ ¤ ¿¨ 42
43.包含关系 (include) 示图 ¹ ñ Ô± » ú ¡ ¶ À© Õ ¹¡ · Ó» Ã§ Ñ ¡Ô ñ ² é Ñ Ó̄ à ¶ î ² é Ñ Ó̄ à ¶ î ¹ ñ Ô± » ú ÓÃ » § ´ æ Ç® Ê ¹Ó Ã ¹ ñ Ô± » ú ¡ À ¶ © Õ ¹¡ · ÓÃ » § ÑÔ ¡ ñ́ æ Ç® ¡ ¶ À© Õ ¹¡ · ÓÃ » § Ñ ¡Ô ñ È ¡Ç ® ¡ ¶ ° ü º ¬ ¡ · È ¡Ç ® ¡ ¶ ° ü º ¬ ¡ · ´ ò Ó ¡µ ¥ ¾Ý 43
44.关于扩展和包含关系 44
45.Use Case 发掘实操 45
46.Use Case 发掘过程 • • • • • 定义 Actor 发掘 Actor 使用系统的脚本 Script 总结 Use Case 组合研究 Actor 之间的继承关系研究 Use Case 之间的 include 、 extend 关系 }CE • 贯穿始终：维护一套词汇表 46
47.词汇表！词汇表！ • 词汇表有多重要 ? – 可以建巴别塔 – 代码中的变量 – 需求文档的重要组成部分和线索 • 维护词汇表应该是产品团队最重要的工作之一 Buddy ？面板联系人？通讯录联系人？电话好友？手机好友？ QQ 联系人？邮件好友？ IM 联系人？过滤联系人？ 47
48.词汇表示例：被叫号码 •本节所述之被叫号码，其格式要求为： – 符合 E.164 电话号码编号计划规范。 – 对于 PBX 分机号码，应为 1 － 8 位数字； – 对于普通电话号码，合法格式为： • 以“ +” 、“ -” 分隔的 1-21 位数字字符串； • 可钉钉包含以钉钉“ +” 引钉钉的国家代钉钉钉钉钉； – 如 +86 代表中国， +1 代表美国； • 必钉钉包含地区代钉钉钉钉钉钉和钉钉钉号钉钉，其钉钉钉用“ -” 分隔； • 如果某外钉钉号钉钉包含分机号钉钉钉钉钉钉，其钉钉钉用“ -” 分隔； – – – – 如 0755-26441099 ； 010-38454233 ；如果包含国家代码，则地区代码的长途前缀（如“ 0” ）钉钉省略；钉钉如 +86-755-26441099 ； +86-10-38454233 如 0755-26551099-384 ； +86-755-26551099-384 – 对于中国移动电话号码，合法格式为： • 国家代码和移动电话号码 – 如 +86-13509345659 • 或移钉钉钉钉号钉 – 如 13509345659 ，在被叫号码中无需根据对外地手机加入 0 前钉。钉 – 不包含 Omni PCX 交换机的外线拨号前缀。 • 如某 Omni PCX 交钉钉机的外钉钉钉钉钉号前钉钉钉“ 具钉钉钉个外钉钉钉钉号前钉钉钉。 9” ，但在 RTX 系统中的电话号码资料中不需要－《 RTX Omni PCX 插件软件需求规格说明书 .doc 》 48
49.Use Case 的 Pattern • 大部分互联网服务本质上是 DB ： – 增删改查 – 导入导出 – 批量操作 • 计算机钉钉用的基钉钉钉钉支撑功能：钉钉钉钉 – 安装卸载 – 启动停止重启动 – OAM （运钉钉、管理、钉钉钉钉钉钉） 49
50.自定义头像的 Use Case 从本机设置《 extend 》设置自定义头像用户《 extend 》《 extend 》添加第三方 CP Server 组管理员从第三方系统设置第三方头像系统从网络硬盘设置网络硬盘系统查看头像运营数据 PMM 第三方头像 CP 50
51.Use Case 阐述 51
52.Use Case ：开始走向需求规格说明书 • Use Case 图并不是需求文档的必备部分 • Use Case 分析是过程，不是结果 • Use Case 钉述，等于： 52
53.Use Case 阐述的基本四要素 • 进入条件 – 描述 Use Case 在何种情况下进入 – 如用户必须具备什么条件？之前发生了什么？ • 基本流程 – 不考虑任何异常例外，没有 if then else – 从用钉钉角度钉钉钉述 Use Case 如何运作 • 结束条件 – Use Case 成功结束后，发生了什么变化 – 用户发生什么变化？系统发生什么变化？ • 例外流程 – 逐个阐述在基本流程中某个环节出现异常时的处理 53
54.Use Case 阐述的几个禁止 • 禁止假设系统由哪些技术实现模块组成 – “ 系统从服务器基础 DB 中删除好友关系” • 禁止假设用户可以使用哪些 UI 界面 – “ 系统弹出错误提示窗口” • 禁止使用没有主谓宾的语句 – “ 给出提示” • 禁止使用没有任何意义、意义不全的语句 – “ 系统给出状态提示信息” – “ 系统立即钉示”、“等”、“或者”、“其他”、“通常”… • 禁止给出没有值域的定义 – “ 系统显示天气温度信息” 54
55.Use Case 阐述的逐步细化－ 1 基本流程 a) 当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。 b) 邮件用户可以按照以下的一个或多个步骤执行： c) 按照发送这或主题整理邮件信息； d) 阅读邮件信息的内容； e) 把邮件信息保存为文件； f) 把邮件信息的附件保存为文件； g) 当邮件用户要求退出管理新来邮件信息时，功能夹终止。 55
56.Use Case 阐述的逐步细化－ 2 期望扩展 a) 当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。 [ 用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。 ] b) 邮件用户可以按照以下的一个或多个步骤执行： c) 按照发送这或主题整理邮件信息； d) 阅读邮件信息的内容； e) 把邮件信息保存为文件； f) 把邮件信息的附件保存为文件； [ 用户必须能够看见附件的文件类型 ] g) 当邮件用户要求退出管理新来邮件信息时，功能夹终止。 56
57.Use Case 阐述的逐步细化－ 3 补充值域 a) 当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。 [ 用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。 ] { 平均每 100 个同时显示的未读邮件消息中，其中 90% 的消息主钉钉行少于钉钉40 个字符。 } b) 邮件用户可以按照以下的一个或多个步骤执行： c) 按照发送这或主题整理邮件信息； d) 阅读邮件信息的内容； { 平均消息内容包括 100 字符。 } e) 把邮件信息保存为文件； f) 把邮件信息的附件保存为文件； [ 用户必须能够看见附件的文件类型 ] { 这种情况下， 95% 的邮件都少于 2 个附件。 } g) 当邮件用户要求退出管理新来邮件信息时，功能夹终止。 57
58.Use Case 阐述的逐步细化－ 4 补充发生概率 a) 当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。 [ 用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。 ] { 平均每 100 个同时显示的未读邮件消息中，其中 90% 的消息主题行少于 40 个字符。 } b) 邮件用户可以按照以下的一个或多个步骤执行： c) 按照发送这或主题整理邮件信息； ( 在钉钉种情况下，有超钉钉钉钉钉钉 60% 钉做了此项操作。 ) d) 阅读邮件信息的内容； { 平均消息内容包括 100 字符。 } e) 把邮件信息保存为文件； ( 在这种情况下，少于 5% 做了此项操作。 ) f) 把邮件信息的附件保存为文件； [ 用户必须能够看见附件的文件类型 ] { 这种情况下， 95% 的邮件都少于 2 个附件。 } ( 在这种情况下，有少于 30% 做了此项操作。 ) g) 当邮件用户要求退出管理新来邮件信息时，功能夹终止。 58
59.Use Case 阐述后 • 发现词汇，并给以定义 – 详细的解释，值域的描述 – 形成需求文档中的“定义” • 发现功能需求和性能需求 • 整理文字，形成功能需求规格说明和性能需求说明 59
60.性能需求 60
61.性能需求的 Pattern • • • • • • • • • • • 性能指标易用性安全性兼容性可扩展性可维护性可延展性可移植性可编程性可靠性可测试性产品关注技术关注 61
62.性能需求的专业化撰写态度 • 钉品钉钉理钉钉忘钉钉自己懂技钉钉钉钉钉、交互钉钉 • 从用钉钉、市钉钉钉角度把要求提出来钉钉钉钉钉钉钉 • 弄清楚自己的专业发展方向 – User-Oriented ， Market-Oriented • 其他的，不妨“扮猪吃老虎” 62
63.Good News ：天下文章一大抄 • 在一个产品系统中，性能需求是可以 Copy 的 • 第一份性能需求是重点，大家一起作 • 之后的需求文档往往只需改变： – – – – – – – – – – – 性能指标可扩展性易用性可延展性安全性兼容性可维护性可移植性可编程性可靠性可测试性这里简简单单几句话要求，让开钉钉同事、钉钉钉钉计钉钉作半年钉……钉 63
64.需求规格说明书 64
65.没有高质量的需求软件就象一个巧克力的盒子你不会知道你将要得到什么 65
66.高质量需求叙述的特性 • • • • • • 正确可行性必要性优先权明确可证实 66
67.高质量需求叙述的特性 1/6 • 正确： – 每个需求必须精确描述要交付的功能。 – 正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。 – 只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的： “这是没意义的 ”， “这可能是他们的意思 ”等众所周知的猜测。 67
68.高质量需求叙述的特性 2/6 • 可行性： – 在已知的能力、有限的系统及其环境中每个需求必须是可实现的。 – 为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，这个开发人员应能检查 • 在技术上什么能做什么不能做 • 哪些需要需要额外的付出或者和其他的权衡。 – 在抽象阶段应该有市场人员参与。 68
69.高质量需求叙述的特性 3/6 • 必要性： – 每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。 – 每个需求源于你认可或者具有授权的原始资料 – 跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户（特别是 Boss ）的意见。 – 如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。 69
70.高质量需求叙述的特性 4/6 • 优先权： – 为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。 – 客户或其代理都应有强烈的责任建立优先权。 • 如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时，项目经理将不能起到作用。 – 优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。 – Must Have, Nice To Have, Can Delay 70
71.高质量需求叙述的特性 5/6 • 明确： – 需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。 – 自然语言极易导致含糊。要避免使用一些对于 SRS 作者很清楚但对于读者不清楚的主观词汇，如： • 用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。 – 每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。 – 检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。 71
72.高质量需求叙述的特性 6/6 • 可证实： – 看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。 – 如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。 – 需求之间不一致，不可行，不明确也能导致不可证实。 – 任何需求如果说产品将要支持什么也是不可证实的。 72
73.高质量需求说明书的特征 • • • • 完整一致性可修改性可追踪 73
74.高质量需求说明书的特征 1/4 • 完整： – 不应该遗漏要求和必需的信息。 – 完整性也是一个需求应具备的。 • 发现缺少的信息很难，因为根本不存在。 • 在 SRS 中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。 – 在需求抽象上，应用 Use Case 方法会发挥很好的作用。 • 能够从不同角度察看需求的图形分析模型也可以检查出不完整性。 • 使用 TBD （ to be determined ）标准标志已知的缺失 – 当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。 – 如“ Vista 表现” 74
75.高质量需求说明书的特征 2/4 • 一致性： – 一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。 – 需求中的不一致必须在开发开始前得到解决。 – 只有经过调研才能确定哪些是正确的。 – 修改需求时一定要谨慎 • 如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。 75
76.高质量需求说明书的特征 3/4 • 可修改性： – 当每个需求的要求修改了或维护其历史更改时，你必须能够审定 SRS 。 – 每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。 – 通过良好的组织可以使需求易于修改，如： • 将相关的需求分组，建立目录表，索引，以及前后参考 • Feature List.xls 是很好的工具 76
77.高质量需求说明书的特征 4/4 • 可追踪： – 应能将一个软件与其原始材料相对应 • 如高级系统需求，用例，用户的提议等。 – 能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。 – 可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。 77
78.几个不好的需求 • “ 产品应在不少于每 60 秒（？）的正常周期（？）内提供状态信息” • “ 产品应瞬间在显示和隐藏不可打印字符间切换” • “HTML 分析器可以产生 HTML 标记错误报告，帮助 HTML 入门者快速解决错误”。 • “ 如果可能，主管号码应通钉钉钉机校钉钉钉，而不是通钉过主全体主管号码列表校验”。 78
79.编写高质量需求的方针 • 句子和段落要短 – 采用主动语气 – 使用正确的语法，拼写，标点 – 使用术语保持一致性，并在术语表或数据字典中定义它们 • 以开发人员的观点看需求是否被有效的定义 • 需求编写者还要努力正确地把握细化程度换位思考，不要太自信 • 密切关注多个需求合成了单个需求 Review 再 Review ，朗读自己的作品！ • 通篇文档钉钉钉上要保持一致钉钉钉钉钉 • 避免在 SRS 当成高考作文来认真对待！中过多的重复需求 – 要避免包含多个需求的长的叙述段落 – 把正常流程和异常流程分开 – 在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。 – 使用 Word 的“超链接”功能！ 79
80.一份需求规格说明书的内容 1/6 • 文档标题： – 准确、言钉钉意钉钉、遵守钉钉 SCM 规定 – 钉钉品取个好的英文钉钉称 • 《 RTX Omni PCX 插件软件需求规格说明书》 • 修订记录 – 认真对待，仔细填写 80
81.一份需求规格说明书的内容 2/6 • 关键词、摘要： – 就像写您的学位论文一样去写 – 摘要可以最后补充，先标红免得忘记 81
82.一份需求规格说明书的内容 3/6 • 缩略语清单： – 对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中文解释。 • 参考资料清单： – 请在表格中罗列本文档所引用的有关参考文献名称、作者、标题、编号、发布日期和出版单位等基本信息。 82
83.一份需求规格说明书的内容 4/6 • 引言 – 背景 • A. 用一个名字标识要生产的软件产品。 • B. 说明软件产品将干什么 , 如果需要的话 , 还要说明这个软件产品不干什么。 – 产品定义 • 本节必须给出易发生混淆的术语的定义 • 把词汇表都放这里 83
84.一份需求规格说明书的内容 5/6 • 概述 1 。系统描述一般整个系统作一份，所有需求文档都 Copy 2 。系统功能推荐用表格来说明本文档所列的功能需求 3 。开发环境一般整个系统作一份，所有需求文档都 Copy 4 。开发环境一般整个系统作一份，所有需求文档都 Copy 84
85.一份需求规格说明书的内容 6/6 • 产品需求 – 功能需求 • 到肉了，把功能需求一个个的写 – UI 需求 • 找设计师 – 性能需求 • 天下文章一大抄 • 把握产品重点的性能要求 85
86.常用方法和工具 86
87.思维导图 87
88.鱼骨图 88
89.Pareto 图 89
90.一张图胜过百句话 • UML 中的几种图表： – 动态的观察系统： • • • • • – Usecase 图序列图 (Sequence Diagram) 协作图 (Collaboration Diagram) 状态图 (Statechart Diagram) 活动图 (Activity Diagram) 静态的观察系统： • • • • 部署图 (Deployment Diagram) 组件图 (Compoment Diagram) 对象图 (Object Diagram) 类图 (Class Diagram) 90
91.更多的…… . • 请参考 RUP 2000 中文版本 – 学习各种图表工具 – 学习工作方法 – 不是去学 UML! • 记住： – – – – 产品经理的图，应该是用户可看懂的不是程序设计图可以不用 Visio ，用 Powerpoint 就可以画出来不会超过 One Page 的规模，最好是 Half a page 91
92.以马内利仁钉钉、喜钉钉钉、和平、忍耐、恩慈、良善、信钉钉钉钉钉钉钉钉钉钉钉钉钉钉钉、温柔、钉钉钉钉钉制 92

腾讯：从概念到产品 需求分析过程

腾讯：从概念到产品需求分析过程