某科技从概念到产品需求过程

从概念到产品－需求分析过程Somethingaboutgrammar&literature2开始的话3引子：不仅仅纯技术人文比科技重要！方法比技能重要！初做者有经验者监督者专家管理者高级专家领导者资深专家4学习态度？一天，三年甲班的杨过忘了交作业，导师郭靖问他：“为什么没交作业？”杨过答曰：“作业为什么要交？交了不一定是自己写的；写了又不一定会；（不小心破了珍珑的虚竹不好意思地看了逍遥子一眼）会了又不一定会考；（苦心准备当盟主的左冷禅背后响起闷响）考了又不一定会过；（白眉鹰王身边秋风吹过阵阵凄凉的落叶）过了又不一定能毕业；（被古墓派退学的李莫愁脸色一变）毕业又不一定会找到工作；乐天的令狐冲正在酒醉中没听见）找得到工作又不一定保得住工作；（萧峰夺门而出）……？”只见现场沉默三秒之后，众人联手围殴杨过……5先从语法课讲起用户是一个或者多个名词；产品是名词，一般由很多个名词组成；产品设计过程功能需求就是找出“动宾短语”的集合性能需求就是找出“形容词”的集合6订书机为例（仅供参考）产品订书机:n.一种装订文件的文具订书机包括： 杠杆结构：n.

进钉结构；n.

压钉结构；n.

钉书钉(消耗品):n.用户用户：n.使用订书机的人，应大于3周岁；且有手或者类似可以发出至少1kg力量的人。最常用(80%以上)为女性(21-40)。需求功能需求装订文件；Load钉书钉；Unload钉书钉；…性能需求外观、颜色、省力、材质….7产品设计过程定义好用户定义好产品先分析功能需求再分析性能需求80/20的误区：产品日趋同质化，公司之间的差别，市场竞争的成败，往往是由性能决定8互联网本质论计算机为什么叫计算机？互联网其实是一个大数据库大部分应用都是数据库应用Search?B2B、B2C、C2C?Gaming?Avatar？Blog?小部分应用是即时的存储转发类IMVoIP复习数据库的知识!9课程概述10课程内容UseCase分析方法找寻用户定义产品发掘功能需求性能需求的“套路”需求文档的撰写产品经理常用“技法”工作组织方法常用图表和绘图方法11需求分析与人人文需求分析是一一个工业化的的写作过程80％的套路＋20％的创意好的语文水平平：有利于抓住关关键词汇有利于培养数数字敏感有利于增强形形容能力有利于组织文文档结构有利于提高沟沟通能力读书吧！写博客吧！12UseCase分析法13USE-CASE的历史1967年Jacobson在爱立信信工作的的时候开开始使用用这种思思想这种想法法最早应应用于大大型交换换机系统统的需求求获取1971年完成了了这种方方法的最最初原型型1985年推出了了改进版版，并发发布了面面向对象象的OOSE方法大部分面面向对象象技术都都采用这这种需求求方法，，UML建模语言言也已将将它包容容进去它还被广广泛的应应用于工工业领域域14需求获取取的前提提用户必须告诉诉你他想想要什么么你必须完完整地了了解用户的业务你必须知知道与系系统有关关的任何人和和任何东东西如果用户不能告诉诉你他们们想要什什么，你你必须花花费时间间去观察察和记录录他们现现在是怎怎么工作作的从专家那那里了解解用户业业务的原原理和规规则你是去了了解要做做什么而而不是怎怎么做15首先，您您需要把把系统看看成黑盒盒一开始就就深入细细节的产产品经理理，忙乱乱而又没没有绩效效往往陷入入细节的的泥坑，，甚至是是技术细细节，甚甚至UI细节被层出不不穷的需需求点和和例外处处理困扰扰控制不住住满脑袋袋乱冒的的ideas请相信！！！！！！！！！！！！！！！！！！！！！！！！！！！系统内部部无论多多么复杂杂他总是可可以被““使用说说明书””说清楚楚16Actor17需求分析析的第一一个问题题谁是这个个产品的的用户？？或者，谁谁是这这个产品品系统中中的角色？18什么是角角色(Actor)与系统发发生交互互作用的的、系统统之外的的任何东东西都是是角色可以是人人也可以是是机器角色不等等同于使使用者角色存在在于系统外部部角色不是是活动的的准确描描述使用者是是行驶某某个角色色职责的的系统的的使用人人员如小王是是个采购购员我是角色Actor！19角色（续续）每个Actor都通过不不同的方方式使用用系统，，除非他他们是相相同的ActorActor使用系统统的每一一种方式式就是一一个UseCase群普通用户群管理员群股东群创建者群股东20角色分类类主动角色色：UseCase的动作序序列是由由他先发发起的，，通常系系统返回回最后结结果主叫方，，采购人人员，票票据录入入员等被动角色色：系统统通过调调用角色色来完成成UseCase的动作序序列（或或其中的的某一个个动作））不是初始始动作的的发起者者当系统需需要它们们帮助的的时候最终是为为了满足足主动角角色的需需要通常是机机器或其其他系统统ActorUseCase1UseCase2ActorActor21Script22脚本Script脚本是一一个角色色与系统统之间的的一组交交互作用用通常具有有详细的的真实数数据及实实际的期期望输出出值一个应用用系统可可能具有有成千上上万个脚脚本即使同一一件事，，所得到到的脚本本可能也也会有细细微的区区别脚本是描描绘UseCase的重要的的背景信信息23脚本示例例1：小王输输入他的的账号#4135972：小王输输入他的的密码#1198233：小王查查询98.7.1至98.12.31日之间的的平均余余额4：系统显显示余额额1：小张输输入他的的账号#4133432：小张输输入他的的密码#6467883：小张查查询98.3.1至98.5.31日之间的的平均余余额4：系统显显示余额额1：小李输输入她的的账号#3467802：小李输输入她的的密码#4356453：小李查查询98.7.1至98.12.31日之间的的平均余余额4：系统显显示余额额24脚本与UseCase一个UseCase代表一组组潜在的的脚本通过研究究一组相相似的脚脚本，可可以得到到它们内内在的逻逻辑相似的脚脚本通常常遵循相相似的模模式工作作，并提提供相似似类型的的结果一个UseCase通常关注注某一个个目标例如：查查询存折折余额UseCase25UseCase26转让群通过UseCase描述系统统功能需需求一个系统统具有无无限个潜潜在的脚脚本但一个系系统可以以被有限限的UseCase完整说明明系统的每每一个UseCase都必须列列举，否否则系统统将会遗遗漏功能能创建群解散群加入群赞助群邀请加入入群群内发言言授权群管管理27UseCase描述系统统提供的的交互功功能一个UseCase可以被其其他的UseCase调用UseCase可以组合合完成某某一项更更大的功功能UseCase说明系统统需要提提供什么么而不是是怎么提提供用户并不不关心你你如何给给他们提提供所需需要的功功能UseCase一般是用用“动宾宾”短语语命名创建群解散群加入群赞助群邀请加入入群群内发言言授权群管管理28UseCaseUseCase不是分析析设计文文档虽然它们们支持后后续的分分析设计计工作UseCase不是操作作脚本它不是用用户使用用系统时时实际操操作的具具体步骤骤的记录录虽然它可可能是通通过操作作脚本得得来的29UseCase是很好的的测试单单元UseCase清晰地描描述了系系统的功功能界面面测试人员员可以在在开发初初期制定定测试计计划每一个UseCase都严格地地说明了了系统的的某一项项功能它的输入入它的输出出期间的交交互作用用UseCase是黑盒测测试的基基准30UseCase的阐述应该包含含UseCase的所有重重要细节节应该包括括角色与与系统交交互的关关键步骤骤，可以以使用顺顺序图（（SequenceDiagram）要表述有有关角色色的信息息要分清哪哪些是角角色所具具有的职职能、哪哪些是系系统所应应提供的的要列清使使用这些些功能是是所应满满足的前前提条件件如果某些些功能具具有质量量上的要要求（如如性能）），也要要列出来来创建群DdddddddddddDddddxxafsdfadsDdddddddddddDdddfcadsfasdddddccdasdwe31UseCase：标记方方法简单单Actor名称UseCase名称32UseCase：主动角角色经纪人下单投资人报价审查货币存取经纪管理理系统33UseCase：被动角角色经纪人下单投资人报价审查货币存取经纪管理理系统银证转账系统34画UseCase图规则主动角色色画在图图的左边边被动角色色画在图图的右边边每个UseCase必须为用用户提供供确切的的功能UseCase名称必须须写在椭椭圆里面面保持图面面整洁每一张图图里不能能有太多多的UseCase为每一个个UseCase编号便于于检索为UseCase建立目录录（编号号和名称称）便于于管理35UseCase高级概念念36UseCase高级概念念通过分析析UseCase图，分析析人员可可以找出出不同的的业务过过程之间间的共性性扩展、包包含、派派生、使使用等关关系通过这些些关系可可以降低低系统的的复杂度度为重用提提供了条条件将共性性提出出来，，可以以帮助助我们们发现现重复复的过过程二次开开发应应该关关注的的地方方37Actor的继承承类似于于UseCase的扩展展，角角色之之间可可以继继承其他银银行不不仅具具有储储户的的所有有功能能，还还有其其他的的功能能38Actor继承的的好处处在不丢丢失信信息的的前提提下，，简化化了UseCase图继承说说明了了角色色间的的层次次关系系派生者者继承承了父父角色色的所所有能能力父角色色不知知道派派生者者39扩展关关系：：extend扩展关关系通通常用用来表表示某某一个个UseCase的可选选择部部分扩展关关系允允许分分析人人员在在没有有改变变基UseCase的情况况下增增加或或修改改基UseCase的功能能复杂的的可替替代途途径应应该使使用扩扩展关关系把把它们们分成成多个个UseCase也可以以这样样看扩扩展关关系：：在基UseCase上插入入功能能，而而基UseCase本身不不知道道这个个扩展展40扩展关关系(extend)示图41使用关关系如果UseCaseA包含UseCaseB，表示示在执执行UseCase的动作作序列列过程程中，，在某某一点点上将将开始始执行行UseCaseB的动作作序列列，完完成后后将回回到同同一点点上继继续执执行完完UseCaseA的动作作序列列它与扩扩展关关系的的区别别是：：扩展是是可选选的包含是是必做做的（（更象象一个个子过过程））和扩展展关系系一样样，一一个UseCase可以包包含很很多个个子UseCase，也可可以被被很多多个父父UseCase所包含含42包含关关系(include)示例43包含关关系(include)示图44关于扩扩展和和包含含关系系45UseCase发掘实实操46UseCase发掘过过程定义Actor发掘Actor使用系系统的的脚本本Script总结UseCase组合研究Actor之间的的继承承关系系研究UseCase之间的的include、extend关系贯穿始始终：：维护护一套套词汇汇表}CE47词汇表表！词词汇表表！词汇表表有多多重要要?可以建建巴别别塔代码中中的变变量需求文文档的的重要要组成成部分分和线线索维护词词汇表表应该该是产产品团团队最最重要要的工工作之之一Buddy？面板板联系系人？？通讯讯录联联系人人？电话好好友？？手机机好友友？QQ联系人人？邮邮件好好友？？IM联系人人？过过滤联联系人人？48词汇表表示例例：被被叫号号码本节所所述之之被叫叫号码码，其其格式式要求求为：：符合E.164电话号号码编编号计计划规规范。。对于PBX分机号号码，，应为为1－8位数字字；对于普普通电电话号号码，，合法法格式式为：：以“+”、“-”分隔的的1-21位数字字字符符串；；可选包包含以以“+”引导的的国家家代码码；如+86代表中中国，，+1代表美美国；；必须包包含地地区代代码和和电话话号码码，其其间用用“-”分隔；；010-38454233；如果包包含国国家代代码，，则地地区代代码的的长途途前缀缀（如如“0”）应省省略；；如+86-755-26441099；+86-10-38454233如果某某外线线号码码包含含分机机号码码，其其间用用“-”分隔；；384；+86-755-26551099-384对于中中国移移动电电话号号码，，合法法格式式为：：国家代代码和和移动动电话话号码码移动动电话话号码码在被被叫号号码中中无需需根据据对外外地手手机加加入0前缀。。不包含含OmniPCX交换机机的外外线拨拨号前前缀。。如某OmniPCX交换机机的外外线拨拨号前前缀为为“9”，但在在RTX系统中中的电电话号号码资资料中中不需需要具具备这这个外外线拨拨号前前缀。。－《RTXOmniPCX插件软软件需需求规规格说说明书书.doc》》49UseCase的Pattern大部分分互联联网服服务本本质上上是DB：增删改改查导入导导出批量操操作计算机机应用用的基基础支支撑功功能：：安装卸卸载启动停停止重重启动动OAM（运营营、管管理、、监视视）50自定义义头像像的UseCase用户Server组管理理员PMM第三方方头像像CP设置自自定义义头像像从本机机设置置从网络络硬盘盘设置置从第三三方系系统设设置第三方方头像系系统网络硬硬盘系统《extend》《extend》《extend》添加第第三方方CP查看头头像运运营数数据51UseCase阐述52UseCase：开始始走向向需求求规格格说明明书UseCase图并不不是需需求文文档的的必备备部分分UseCase分析是是过程程，不不是结结果UseCase阐述，，等于于：53UseCase阐述的的基本本四要要素进入条条件描述UseCase在何种种情况况下进进入如用户户必须须具备备什么么条件件？之之前发发生了了什么么？基本流流程不考虑虑任何何异常常例外外，没没有ifthenelse从用户户角度度阐述述UseCase如何运运作结束条条件UseCase成功结结束后后，发发生了了什么么变化化用户发发生什什么变变化？？系统统发生生什么么变化化？例外流流程逐个阐阐述在在基本本流程程中某某个环环节出出现异异常时时的处处理54UseCase阐述的的几个个禁止止禁止假假设系系统由由哪些些技术术实现现模块块组成成“系统统从服务器器基础础DB中删除除好友友关系系”禁止假假设用用户可可以使使用哪哪些UI界面“系统统弹出出错误提提示窗窗口”禁止使使用没没有主主谓宾宾的语语句“给出出提示示”禁止使使用没没有任任何意意义、、意义义不全全的语语句“系统统给出出状态提提示信信息”“系统立即显示”、““等”、“或者”、“其他”、“通常”…禁止给出没没有值域的的定义“系统显示示天气温度信息”55UseCase阐述的逐步步细化－－1基本流程a)当邮件用户户要求管理理邮件信息息时功能夹夹启动，系系统显示信信息。b)邮件用户可可以按照以以下的一个个或多个步步骤执行：：c)按照发送这这或主题整整理邮件信信息；d)阅读邮件信信息的内容容；e)把邮件信息息保存为文文件；f)把邮件信息息的附件保保存为文件件；g)当邮件用户户要求退出出管理新来来邮件信息息时，功能能夹终止。。56UseCase阐述的逐步步细化－－2期望扩展a)当邮件用户户要求管理理邮件信息息时功能夹夹启动，系系统显示信信息。[用户必须能能够区分新新的、已读读过的、未未读过的消消息。用户户还必须能能够看见每每个消息的的发送者、、主题和优优先级。]b)邮件用户可可以按照以以下的一个个或多个步步骤执行：：c)按照发送这这或主题整整理邮件信信息；d)阅读邮件信信息的内容容；e)把邮件信息息保存为文文件；f)把邮件信息息的附件保保存为文件件；[用户必须能能够看见附附件的文件件类型]g)当邮件用户户要求退出出管理新来来邮件信息息时，功能能夹终止。。57UseCase阐述的逐步步细化－－3补充值域a)当邮件用户户要求管理理邮件信息息时功能夹夹启动，系系统显示信信息。[用户必须能能够区分新新的、已读读过的、未未读过的消消息。用户户还必须能能够看见每每个消息的的发送者、、主题和优优先级。]{平均每100个同时显示示的未读邮邮件消息中中，其中90%的消息主题题行少于40个字符。}b)邮件用户可可以按照以以下的一个个或多个步步骤执行：：c)按照发送这这或主题整整理邮件信信息；d)阅读邮件信信息的内容容；{平均消息内内容包括100字符。}e)把邮件信息息保存为文文件；f)把邮件信息息的附件保保存为文件件；[用户必须能能够看见附附件的文件件类型]{这种情况下下，95%的邮件都少少于2个附件。}g)当邮件用户户要求退出出管理新来来邮件信息息时，功能能夹终止。。58UseCase阐述的逐步步细化－－4补充发生概概率a)当邮件用户户要求管理理邮件信息息时功能夹夹启动，系系统显示信信息。[用户必须能能够区分新新的、已读读过的、未未读过的消消息。用户户还必须能能够看见每每个消息的的发送者、、主题和优优先级。]{平均每100个同时显示示的未读邮邮件消息中中，其中90%的消息主题题行少于40个字符。}b)邮件用户可可以按照以以下的一个个或多个步步骤执行：：c)按照发送这这或主题整整理邮件信信息；(在这种情况况下，有超超过60%做了此项操操作。)d)阅读邮件信信息的内容容；{平均消息内内容包括100字符。}e)把邮件信息息保存为文文件；(在这种情况况下，少于于5%做了此项操操作。)f)把邮件信息息的附件保保存为文件件；[用户必须能能够看见附附件的文件件类型]{这种情况下下，95%的邮件都少少于2个附件。}(在这种情况况下，有少少于30%做了此项操操作。)g)当邮件用户户要求退出出管理新来来邮件信息息时，功能能夹终止。。59UseCase阐述后发现词汇，，并给以定定义详细的解释释，值域的的描述形成需求文文档中的““定义”发现功能需需求和性能能需求整理文字，，形成功能能需求规格格说明和性性能需求说说明60性能需求61性能需求的的Pattern性能指标易用性安全性兼容性可扩展性可维护性可延展性可移植性可编程性可靠性可测试性产品关注技术关注62性能需求的的专业化撰撰写态度产品经理应应忘记自己己懂技术、、交互从用户、市市场角度把把要求提出出来弄清楚自己己的专业发发展方向User-Oriented，Market-Oriented其他的，不不妨“扮猪猪吃老虎””63GoodNews：天下文章章一大抄在一个产品品系统中，，性能需求求是可以Copy的第一份性能能需求是重重点，大家家一起作之后的需求求文档往往往只需改变变：性能指标可扩展性易用性可延展性安全性兼容性可维护性可移植性可编程性可靠性可测试性这里简简单单单几句话话要求，让开发同事事、设计师师作半年……64需求规格说说明书65没有高质量量的需求软件就象一一个巧克力力的盒子你不会知道道你将要得得到什么66高质量需求求叙述的特特性正确可行性必要性优先权明确可证实67高质量需求求叙述的特特性1/6正确：每个需求必必须精确描描述要交付付的功能。。正确性依据据于需求的的来源，如如真实的客客户或高级级别的系统统需求说明明书。只有用户的的代表能够够决定用户户需求的正正确性，这这就是为什什么在检查查需求时，，要包括他他们或他们们的代理的的关键所在在。不包括括用户的需需求检查就就会导致开开发人员的的：“这是是没意义的的”，“这这可能是他他们的意思思”等众所所周知的猜猜测。68高质量需求求叙述的特特性2/6可行性：在已知的能能力、有限限的系统及及其环境中中每个需求求必须是可可实现的。。为了避免需需求的不可可行性，在在需求分析析阶段应该该有一个开开发人员参参与，这个个开发人员员应能检查查在技术上什什么能做什什么不能做做哪些需要需需要额外的的付出或者者和其他的的权衡。在抽象阶段段应该有市市场人员参参与。69高质量需求求叙述的特特性3/6必要性：每个需求应应载明什么么是客户确确实需要的的，什么要要顺应于外外部的需求求，接口或或标准。每个需求源源于你认可可或者具有有授权的原原始资料跟踪每个需需求回溯到到出处，如如用例，系系统需求，，规章，或或来自其他他用户（特特别是Boss）的意见。。如果你不能能标识出处处，可能需需求只是个个镀金的例例子，没有有真正的必必须。70高质量需求求叙述的特特性4/6优先权：为了表明在在一个详细细的产品版版本中应包包含哪些要要点，需要要为每个需需求，特征征，或用例例分配实现现的优先权权。客户或其代代理都应有有强烈的责责任建立优优先权。如果所有的的需求都被被视为同等等重要，那那么由于在在开发中，，预算削减减，计划超超时或组员员的离开导导致新的需需求时，项项目经理理将不能起起到作用。。优先权的作作用是提供供给客户的的价值，实实现的相关关费用，实实现相关联联的有关技技术风险。。MustHave,NiceToHave,CanDelay71高质量需求求叙述的特特性5/6明确：需求叙述的的读者应只只能从其得得到唯一的的解释说明明，同样，，一个需求求的多个读读者也应达达成共识。。自然语言极极易导致含含糊。要避避免使用一一些对于SRS作者很清楚楚但对于读读者不清楚楚的主观词词汇，如：：用户友好性性，容易，，简单，快快速，有效效，几个，，艺术级，，改善的，，最大，最最小等等。。每写一个需需要都应简简洁，简单单，直观的的采用用户户熟知的语语言，不要要采用计算算机术语。。检查需求模模糊的有效效方式包括括需求说明明书的正规规检查，根根据需求写写测试，建建立用户的的假想来说说明产品某某个特定部部分预期的的特性。72高质量需求求叙述的特特性6/6可证实：看你是否能能够做出测测试计划或或其他验证证方式，如如检查和实实证，来决决定在产品品中每个需需求是否正正确的实现现。如果需求是是不可验证证的，决定定需求是不不是正确的的实现就成成了判断的的事。需求之间不不一致，不不可行，不不明确也能能导致不可可证实。任何需求如如果说产品将要支支持什么也是不可证证实的。73高质量需求求说明书的的特征完整一致性可修改性可追踪74高质量需求求说明书的的特征1/4完整：不应该遗漏漏要求和必必需的信息息。完整性也是是一个需求求应具备的的。发现缺少的的信息很难难，因为根根本不存在在。在SRS中将需求以以分层目录录方式组织织，将帮助助评审人员员理解功能能性描述的的结构，使使他们很容容易指出遗遗失的东西西。在需求抽象象上，应用用UseCase方法会发挥挥很好的作作用。能够从不同同角度察看看需求的图图形分析模模型也可以以检查出不不完整性。。使用TBD（tobedetermined）标准标志已已知的缺失失当你在构建建产品的相相关部分时时，就可以以从一个给给定的需求求集中解决决所有的缺缺陷。如“Vista表现”75高质量需求求说明书的的特征2/4一致性：一致性需求求就是不要要于其他的的软件需求求或高级别别的系统（（商业）需需求发生冲冲突。需求中的不不一致必须须在开发开开始前得到到解决。只有经过调调研才能确确定哪些是是正确的。。修改需求时时一定要谨谨慎如果只审定修修改的部分，，没有审定于于修改相关的的部分，就可可能导致不一一致性。76高质量需求说说明书的特征征3/4可修改性：当每个需求的的要求修改了了或维护其历历史更改时，，你必须能够够审定SRS。每个需求必须须相对于其他他需求有其单单独的标示和和分开的说明明，便于清晰晰的查阅。通过良好的组组织可以使需需求易于修改改，如：将相关的需求求分组，建立立目录表，索索引，以及前前后参考FeatureList.xls是很好的工具具77高质量需求说说明书的特征征4/4可追踪：应能将一个软软件与其原始始材料相对应应如高级系统需需求，用例，，用户的提议议等。能够将软件需需求与设计元元素，源代码码，用于构造造实现和验证证需求的测试试相对应。可追踪的需求求应该具有独独立标示，细细密和结构化化的编写，不不应过大，不不应是叙述性性的文字和公公告式的列表表。78几个不好的需需求“产品应在不少于每60秒（？）的正常周期（？？）内提供状态信息”“产品应瞬间在显示和隐藏藏不可打印字符符间切换”“HTML分析器可以产产生HTML标记错误报告，帮助HTML入门者快速解决错误”。。“如果可能，主管号码应通过联机校验验，而不是通过主全体主管号号码列表校验”。79编写高质量需需求的方针句子和段落要要短采用主动语气气使用正确的语语法，拼写，，标点使用术语保持持一致性，并并在术语表或或数据字典中中定义它们以开发人员的的观点看需求求是否被有效效的定义需求编写者还还要努力正确确地把握细化化程度要避免包含多多个需求的长长的叙述段落落把正常流程和和异常流程分分开密切关注多个个需求合成了了单个需求通篇文档细节节上要保持一一致避免在SRS中过多的重复复需求在多处包含相相同的需求可可以使文档更更易于阅读，，但也会给文文档的维护增增加困难。文文档的多份文文本要在同一一时间内全部部更新，避免免不一致性。。使用Word的“超链接””功能！换位思考，不不要太自信Review再Review，朗读自己的的作品！当成高考作文文来认真对待待！80一份需求规格格说明书的内内容1/6文档标题：准确、言简意意赅、遵守SCM规定给产品取个好好的英文简称称《RTXOmniPCX插件软件需求求规格说明书书》修订记录认真对待，仔仔细填写81一份需求规格格说明书的内内容2/6关键词、摘要要：就像写您的学学位论文一样样去写摘要可以最后后补充，先标标红免得忘记记82一份需求规格格说明书的内内容3/6缩略语清单：对本文所用缩缩略语进行说说明，要求提提供每个缩略略语的英文全全名和中文解解释。参考资料清单单：请在表格中罗罗列本文档所所引用的有关关参考文献名名称、作者、、标题、编号号、发布日期期和出版单位位等基本信息息。83一份需求规格格说明书的内内容4/6引言背景A.用一个名字标标识要生产的的软件产品。。B.说明软件产品品将干什么,如果需要的话话,还要说明这个个软件产品不不干什么。产品定义本节必须给出出易发生混淆淆的术语的定定义把词汇表都放放这里84一份需求规格格说明书的内内容5/6概述1。系统描述一般整个系统统作一份，所所有需求文档档都Copy2。系统功能能推荐用表格来来说明本文档档所列的功能能需求3。开发环境境一般整个系统统作一份，所所有需求文档档都Copy4。开发环境境一般整个系统统作一份，所所有需求文档档都Copy85一份需求规格格说明书的内内容6/6产品需求功能需求到肉了，把功功能需求一个个个的写UI需求找设计师性能需求天下文章一大大抄把握产品重点点的性能要求求86常用方法和工工具87思维导图88鱼骨图89Pareto图90一张图胜过百百句话UML中的几种图表表：动态的观察系系统：Usecase图序列图(SequenceDiagram)协作图(CollaborationDiagram)状态图(StatechartDiagram)活动图(ActivityDiagram)静态的观察系系统：部署图(DeploymentDiagram)组件图(CompomentDiagram)对象图(ObjectDiagram)类图(ClassDiagram)91更多的…….请参考RUP2000中文版本学习各种图表表工具学习工作方法法不是去学UML!记住：产品经理的图图，应该是用用户可看懂的的不是程序设计计图可以不用Visio，用Powerpoint就可以画出来来不会超过OnePage的规模，最好好是Halfapage92以马内利利仁爱、喜乐、、和平、忍耐耐、恩慈、良良善、信实、、温柔、节制制9、静夜四无邻邻，荒居旧业业贫。。12月-2212月-22Saturday,December17,202210、雨中黄叶树树，灯下白头头人。。14:02:3714:02:3714:0212/17/20222:02:37PM11、以我我独沈沈久，，愧君君相见见频。。。12月月-2214:02:3714:02Dec-2217-Dec-2212、故人人江海海别，，几度度隔山山川。。。14:02:3714:02:3714:02Saturday,December17,202213、乍见见翻疑疑梦，，相悲悲各问问年。。。12月月-2212月月-2214:02:3714:02:37December17,202214、他他乡乡生生白白发发，，旧旧国国见见青青山山。。。。17十十二二月月20222:02:37下下午午14:02:3712月月-2215、比比不不了了得得就就不不比比，，得得不不到到的的就就不不要要。。。。。十二二月月222:02下下午午12月月-2214:02December17,202216、行行动动出出成成果果，，工工作作出出财财富富。。。。2022/12/1714:02:3714:02:3717December202217、做做前前，，能能够