产品经理应该熟悉的软件需求工程

编辑导读:产品经理每天都在与需qiú打交道,《软件需qiú工程》是产品经理的必修课。本文是zhēn对新人产品经理的简介性文章,目的是让产品经理在开始需qiú分析工作之前,对软件需qiú的相关常识有所理解。希望文章对你有帮助。

一、需qiú工程

需qiú分析的重要性毋庸置疑。在20世纪80年代,逐步形成了软件工程的子学科——软件需qiú工程。90年代后,需qiú工程成为软件界研究的重点之一。从1993年起,每两年举办一次需qiú工程囯际X(ISRE);1994年起,每两年举办一次需qiú工程囯际X(ICRE)。一些关于需qiú工程的工作小组相继X,使需qiú工程的研究得到了迅速进展。

1.1 需qiú的定义

IEEE软件工程标准词汇对需qiú的定义:

  • 用户解决问题或达到目标所需的条件或能力;
  • 系统或部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力;
  • 反映上述的条件或能力的文档说明(SRS,软件需qiú规格说明书)。

业界对需qiú的通俗解释 :

  • 需qiú来源于用户的一些“需要”;
  • 这些“需要”被分析、确认后形成完整的文档;
  • 该文档详细地说明了产品“必须或应当”做什么。

需要说明的是:并没有一个清晰的、无二义的“需qiú”术语定义存在。X的“需qiú”实际上在人们的脑海中,甚至在脑海深处自己都不知道。

“任X档形式的需qiú(比如:需qiú规格说明书)都只是一个模型/一种叙述。”

——Lawrence 1998

我们需要确保的是所有项目风险承担者(stakeholders,干系人)在描述需qiú的X的理解上务必达成共识。

1.2 需qiú的三个层次

  • X需qiú是高层用户(即客户)提出的,比较笼统、宽泛,在项目视图与范围文档中说明。
  • 用户需qiú是最终用户(实际使用者)提出的,已经比较具体了,在实例文档或方案脚本中说明。
  • 产品需qiú是开发团队需要的(甲方监理也需要),定义了开发人员要实现的软件功能,使得用户能完成他们的X,从而满足X需qiú。

X需qiú和用户需qiú都是用通俗语言描述的,即用户能看懂的语言;产品需qiú是用技术语言描述的,是开发人员能看懂的语言。用户和开发人员是在用不同的视角观察需qiú的,他们看到的内容是不一样的。就软件而言,这里的产品需qiú就是软件需qiú。

这样的解释可能还不容易理解,我来举个“咖啡店新老板要更换定制咖啡杯”的例子。

X需qiú:

咖啡店老板要订做一种咖啡杯。

找高层用户X和确认需qiú是一件痛苦的事,因为他们不关注需qiú具X容,甚至常常不知道具体需qiú,他们关注的是“高屋建瓴”的比较务虚的内容,例如:咖啡杯要好用、要漂亮之类的。

真正去调研需qiú,需要先识别出产品的最终用户X,选出用户X,对用户X进行调研。这里的用户X为:消费者,喝咖啡;X员,端咖啡;洗碗工,洗杯子。zhēn对消费者调研可以采用问卷X的方式来获取用户需qiú;zhēn对X员和洗碗工可以采用用户访谈的方式来获取用户需qiú。

用户需qiú:

  • 消费者希望“杯子不能烫手”。消费者反馈:原来的杯子手柄很短,杯身隔热效果很差,拿杯子的时候,手指容易被烫。
  • X员希望“杯子在托盘上要稳,不容易滑倒”。X员反馈:原来的杯子瘦且高,杯底很滑,用托盘端盛满咖啡的杯子时,杯子在托盘上容易打滑或倾倒。
  • 洗碗工希望“杯子要容易清洗”。洗碗工反馈:原来的杯子X不够光滑,咖啡渍很难清洗。

这样的用户需qiú似乎很清楚了,但是你得明白这只是zhēn对用户侧,对开发人员来说还是不清楚,因为这是自然语言描述的内容,不是技术语言描述的内容,开发人员无fǎzhēn对此开展工作。

你还需要把以上内容翻译成为技术语言描述的产品需qiú:

  1. 采用隔热材料,导热率λ < 1.22 W/(m.K),厚度> 5mm。经过原型测试,采用了这样的材料和厚度做成的杯子,加入100℃的热咖啡时,杯子外壁的wēn度大约50℃,轻微X时不会感觉烫手。
  2. 杯底的静摩擦系数 µ > 0.5,满杯的重心高度 h < 10cm。经过原型测试,符合这种要qiú的杯子在装满咖啡时,不容易打滑或倾倒。
  3. 杯X表面cū糙度 Ra < 1.0。经过原型测试,符合这样要qiú的陶瓷表面不容易附着咖啡X,很容易清洗。

拿到这样的产品需qiú,开发人员就可以开展工作了:

  • 根据产品需qiú1,开发人员可以从工厂常用的陶瓷材料里选择符合要qiú的,然后把杯子设计为略高于指定厚度。
  • 根据产品需qiú2,开发人员可以把咖啡杯的底座设计为条纹或其他形式来加大摩擦系数,然后把咖啡杯设计为较矮、较宽的外形,以满足在满杯时的重心要qiú。
  • 根据产品需qiú3,开发人员可以对咖啡杯的X采用某种抛光或镀釉的工艺来达到表面比较光滑的要qiú。

这就是需qiú的三个层次:高层用户关注X目标的实现,最终用户关注X执行的效率和使用体验,开发人员关注产品需qiú是否准确和清晰。

产品经理就比较惨了,需要从多种角度去描述需qiú:高层用户视角的需qiú,即市场需qiú文档MRD;最终用户视角的需qiú,即X需qiú文档BRD;开发人员视角的需qiú,即产品需qiú文档PRD(或软件需qiú文档SRS)。

“需qiú”,这是所有人都可以说上几句的话题。但最X的,还是产品经理描述的需qiú,这正是产品经理的价值所在。

1.3 需qiú工程RE

应用已证实有效的技术、方fǎ进行需qiú分析,确定客户需qiú,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科,即需qiú工程。需qiú工程X合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需qiú文档,并对用户不断变化的需qiú演进给予支持。

通俗地说,需qiú工程就是把工程方fǎ引入到需qiú领域,用工程方fǎ开发清晰的、一致的,没有X、重叠和遗漏的需qiú,用工程方fǎ来管理需qiú和X变更。

1.4 软件需qiú工程SRE

软件工程的子学科,一门分析并记录软件需qiú的学科,它把系统需qiú分解成一些主要的子系统和任务,把这些子系统或任务分配给软件,并X一系列重复的分析、设计、比较研究、原型开发过程把这些系统需qiú转换成软件的需qiú描述和一些性能参数。

需qiú工程是系统工程和软件工程的分支,分为系统需qiú工程(zhēn对由软硬件共同组成的整个系统)和软件需qiú工程(专门zhēn对纯软件部分)。我们都知道软件需qiú是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。软件开发的最终目的是生产出满足客户需qiú的软件产品,满足客户需qiú是软件开发的本质。

1.5 为什么有软件需qiú工程

软件需qiú是软件开发中的关键问题,没有需qiú就没有软件。

开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需qiú,包括所有面向用户、面向机器或其他软件系统的接口,此工作一旦失误,将会带来极大的危害,修改也极其困难。

——Frederick P. Brooks,《No Silver Bullet》

备注:Frederick P. Brooks,60年代初只有29岁时就主持了被称为人类从原子能时代进入信息时代标志的IBM/360系列计算机的开发工作,取得辉煌成功,名噪一时。他作为硬件和软件的双重X和出sè的教育家始终活跃在计算机舞台上,在计算机技术的诸多领域中都做出了巨大的贡献,直到69岁才获得迟来的荣誉——1999年的图灵奖。

需qiú是软件项目成功的核心,良好的需qiú可以减少开发后期的返工和整个维护阶段的工作,做好需qiú等于项目成功了一半。

1.6 需qiú沟通是如此困难

需qiú是以交liú为核心的工作,如果在开发过程的各个环节缺乏交liú或交liú不恰当,就会导致下图(如果学计算机,你必定见过此图)的效果。

  1. 客户如此描述需qiú:我有三个小孩,我需要一个能三个人用的秋千。它由一绳子吊在我家huā园里的树上。
  2. 项目经理如此理解:秋千这东西太简单了,不就是一块板子,两边用绳子吊起来,挂在树的两个枝桠上嘛。
  3. 分析员如此设计:真是无知的项目经理,两个树枝挂上秋千哪还能荡得起来?除非是把树从中截断再用支架支起来,这样就满足要qiú了。
  4. 程序员如此编码:哦,两条绳,一块板,一棵大树,接在树的中段。太简单了,“啪啪啪(敲击键盘的声音)”,搞定!
  5. 商业顾问如此诠释:您的需qiú我们已经完成了,我们XX工学和工程力学等多方面研究,实现了本产品。本着为顾客X出发,我们的秋千产品在使用时,将给您带来如同游乐园里的过山车一样X的感受,如同你在地面上坐沙发一样的舒适与安全。
  6. 资料员如此写文档:这么小的工程没有文档很正常,只要有需qiú说明书与合同就可以了。
  7. 实施人员如此交付:我们的产品用户自己都可以完成安装,只要把绳子系在树上就可以了。
  8. 客户得到如此结果:huā了建过山车的投资,得到个如此产品,也是醉了。
  9. 维户人员如此支持:我们X不了什么技术支持,但我们态度很好,我们的队伍在成长中。
  10. 项目完成了,X的需qiú也清楚了:客户需要一个跳圈,给三个小孩养的小苟训练和玩耍。

很明显,项目开始时客户也不知道X的需qiú,他表述的只是他理解的需qiú(小孩曾经给他说过,但显然他并没有认真聆听)。项目经理没有认真调研需qiú,他甚至根本不知道最终用户是谁。项目经理和分析员之间,分析员和程序员之间,明显没有良好的交liú和反馈。像漏斗一样,每个环节都在遗失信息;像传声筒游戏一样,每个环节都在加入自己想当然的理解。所以,最终的结果必然的天差地别!最重要的是,他们缺一个打通各个环节的产品经理。

对于产品经理,有个常识你必须知道:

用户嘴里说的,不一定是他脑子里想的。他脑子里想的,也不一定就是X实际运行的情况。X的现状,不一定是合理的,也许正是客户需要你帮助改进的。

所以,我们要倾听用户,但不能完全按照用户说的去做。我们要倾听多方用户X,特别是要关注那些互相X、需要妥协的部分。我们不光要听用户怎么说的,还要看他怎么做的。我们要听X用户的X意见,更要听付费用户的付费意见。我们要听用户的意见,更要听决定付钱的客户的意见……等等,自己总结吧,自己总结的才是最适合自己的,我不想展开了。

1.7 软件需qiú工程框架

CMMI对软件需qiú的描述集中在两个PA里:需qiú开发RD(3级),需qiú管理REQM(2级)。

  • 需qiú获取:从用户获取、挖掘需qiú。
  • 需qiú分析:提炼用户需qiú,分析转化,需qiú分析的过程重视用户参与。
  • 需qiú定义:把分析得到的需qiú文档化,编制需qiú规格说明书。
  • 需qiú验证:确定需qiú准确、完整,得到实现,对应测试活动。
  • 需qiú变更X:对需qiú的变更进行X,降低影响。
  • 需qiúX:监控需qiú在开发过程中不走样、不遗漏。

二、需qiú开发

2.1 CMMI关于需qiú开发的描述

SG1 干系人的需要、期望、约束与接口得到收集并转化为客户需qiú。

– SP1.1 挖掘干系人对产品生命周期所有阶段的需要、期望、约束与接口。

– SP1.2 将干系人的需要、期望、约束与接口转换为划分了优先级的客户需qiú。

SG2 客户需qiú得到提炼与细化,以开发产品与产品组件需qiú。

– SP2.1 依据客户需qiú,建立并维护产品与产品组件需qiú。

– SP2.2 为各产品组件分配需qiú。

– SP2.3 功能之间(或者是对象或其它逻辑实体之间)的接口进行了识别。

SG3 需qiú得到分析与确认。

2.2 需qiú获取方fǎ

相比“需qiú获取”,我个人更喜欢“需qiú挖掘”这个词。因为“需qiú获取”让我感觉需qiú就是树上的果子、地里的庄稼,只要产品经理去采摘就可以了。这样的描述,未免低估和轻视了得到需qiú的困难。反之,“需qiú挖掘”让我感觉需qiú是地里的金子等矿zàng,需要产品经理去弯腰、埋头挖掘,而且挖掘了也不一定有成果,因为你需要寻找正确的地方挖,否则只能是徒劳。另外,在很多人都挖过的地里,你只有挖得更深才可能挖到矿zàng。

常见的需qiú挖掘方fǎ有:客户交liú、竞品分析、市场调研、问卷X、技术引导及其他。

客户交liú是最常用的需qiú挖掘方fǎ。大多数情况下,用户虽然知道自己的需qiú,但他们并不一定能或者也不想准确表达他们的需qiú是什么。如果用户第一次告诉你需qiú就是这些了,不要轻信,继续刨根问底,直到你们都筋疲力尽。

产品经理作为一个需qiú分析者,所谓的聆听客户需qiú,指必须透过客户所提出的表面需qiú理解他们的X需qiú,避免理解不同会带来的期望差异。尽量把客户所持的假设解释清楚,特别是那些发生X的部分,甚至要逐字逐句去理解,以明确客户没有表达清楚但又想加入的特性或特征。

有经验的产品经理能深入地理解客户的X(可以提取做大量准备工作),这样他才能X询问客户一些合适的问题(需要提前设计),从而挖掘出高价值的用户需qiú。

2.3 需qiú分析方fǎ

需qiú分析方fǎ大致分为两类:模型fǎ和原型fǎ,都可以从不同角度说明需qiú,把一些模糊的需qiú变得清晰,便于理解,减少返工。不管是模型,还是原型,都是用来增强自然语言描述的需qiú规格说明,而不是代替。

模型一般分为面向过程的模型和面向对象的模型两类。建立需qiú模型的分析过程,称为“需qiú建模”。建模的目的是把模糊的东西搞清晰,把复杂的东西搞简化,而不是把简单的东西搞复杂(这是X人员做的事,比如:X运营商的话费套餐)。

原型fǎ是一种减少软件项目失败风险的技术,它可以加快开发进度,增加用户满意度,减少需qiú错误和用户界面缺陷。

2.4 需qiú建模

常用的面向过程的需qiú建模方fǎ(结构化分析):

  • 功能模型:数据liú图DFD
  • 行为模型:liú程图Flow Chart
  • 状态模型:状态迁移图STD
  • 数据模型:实体关系图ERD

常见的面向对象的需qiú建模方fǎ:

  • 功能模型:用例图
  • 行为模型:活动图
  • 状态模型:状态图
  • 交互模型:时序图(也叫“顺序图”)

2.5 原型设计

建立原型的目的是为了解决在产品开发早期需qiú不确定的问题,X这些不确定来判断系统中那一部分需要建立原型和希望从用户对原型的评价中获得什么信息。其优点是能减少软件项目失败风险,加快开发进度,增加用户满意度,减少需qiú错误,尤其是界面错误。其风险是当用户或项目经理看到一个正在运行的原型,会以为产品即将完成。

对于发现和解决需qiú中的二义性,原型是一种很好的方fǎ。关于原型,不在这里赘述了,后面会另起一文。

常用的原型设计方fǎ:cǎo图(手绘图)、线框图、交互原型、高保真原型。

原型fǎ不仅是需qiú分析方fǎ,同时是需qiú验证方fǎ。

2.6 需qiú定义的方fǎ

  • 采用需qiú文档模板。
  • 指明需qiú的来源。
  • 为每项需qiú建立编号。
  • 设定需qiú优先级。
  • 记录X规范。
  • 创建需qiúX矩阵。
  • 其他方fǎ。

2.7 好需qiú的标准

  • 清晰:不同的读者只能从需qiú文档中得到唯一的解释说明,没有二义。所以表述中不要出现“也许、大概、可能、左右”之类的表述模糊的词语,比如:响应时间5秒左右,宽度大概10米。
  • 完整:一个不能少,所有功能都要描述。
  • 一致:上下文一致,jú部与整体一致。
  • 可行:每一项需qiú必须在已知系统和环境的X范围内可以实现,不能是空中楼阁。
  • 可验证:每一项需qiú必须能够用测试用例或其他方fǎ来验证是否按定义实现了。
  • 可X:每一项需qiú必须能与HLD、LLD、Code、UT、IT、ST等各阶段工作产品对应X。

三、需qiú管理

3.1 CMMI关于需qiú管理的描述

SG 1  管理需qiú

– SP 1.1 理解需qiú

– SP 1.2 获得对需qiú的承诺

– SP 1.3 管理需qiú变更

– SP 1.4 维护需qiú的双向可追溯性

– SP 1.5 确保项目工作与需qiú间的协调一致

3.2 需qiú管理的方fǎ

  • 确定需qiú变更X过程,建立CCB(需qiú变更XX会)。
  • 进行需qiú变更影响分析,X变更影响的工作产品。
  • 建立需qiú基准版本和需qiúX版本文档。
  • 维护需qiú变更的X记录,X每项需qiú的状态。
  • 使用需qiú管理工具,衡量需qiú稳定性。
  • 其他方fǎ。

3.3 需qiú变更X

大师说:“没有不变的需qiú,世上的软件都改动过3次以上,唯一只改动过两次的软件的拥有者已经sǐ了,sǐ在去修改需qiú的路上。”

需qiú变更是正常的,但不加X的需qiú变更是不正常的。所以,不怕需qiú变更,但要严格X,要让客户知道变更的代价(影响和成本),客户在理解变更的代价后再拍板会理智很多。

需qiú变更的原因:客户说不清楚需qiú;需qiú自身经常变动;分析人员或客户理解有误。

需qiú变更X不是为变更设置障碍,而是建立一个渠道和过滤器,保护客户和开发者双方的泉益,减低变更的影响。

参考资料:

CMMI-DEV 1.3

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理应该熟悉的软件需求工程 https://www.xiongfawang.com/1540.html

常见问题

相关文章

产品经理应该熟悉的软件需求工程-海报

分享本文封面