先看看什么是需求,人要吃饭,要喝水,要娱乐。同样,软件也是因为人的某种需求而产生的。
再来看看如何表达需求,人如果饿了,就会去做饭。这个过程,是不需要表达的,需求产生动机,动机支配他的手脚,最后需求得到满足。
换一种方式,如果他不想做饭,或不会做饭,他可能会去外面的餐馆。这时候,他的需求是他的协作方来满足的。比如说他来到了一家兰州拉面馆,说“一碗牛肉刀削面”,很少有做兰州拉面不知道“牛肉刀削面”是什么的。这里准确表达依赖于客户方与供应方对概念有一致的理解。也就是说,对“牛肉刀削面”这个概念,客户方和供应方理解是一致的。在软件需求中,对核心概念的理解可能是以术语表来体现的,这是双方达成共识的基础。
继续这个场景,看看还有哪些情况:
1. 要了一碗牛肉刀削面,结果来了一碗牛肉拉面。可能客户普通话不标准,或者场所太嘈杂,服务员没听清楚,导致出现偏差。沟通不畅。
2. 面做好了,来了。一吃,怎么这么淡阿,店家根本不知道客户的口味。需求遗漏。
3. 来,给我加点香菜。来,给我加点蒜。需求变更。
4. 正吃着呢,抬头一看,邻桌有人在吃羊肉串,其实他已经吃饱了,说,给我也来一串。典型的客户心态,别人有的我也要有。Feature envy.
5. 服务员过来,你这面里怎么有虫子阿? 软件有bug,迟迟不付钱,吃霸王餐,很多软件公司就是这么被拖死的。
6. 要了一碗牛肉刀削面,结果来了一碗拉面。结果:“我发现这拉面比刀削面还好吃阿”。用户说出的需求并不是真正的需求。
客户的需求是很难琢磨的,软件不是像刀削面这样,是标准的产品,每一个软件,在未开发完成前,用户是是不知道实际的体验的。不像刀削面,用户早就体验过了。
使用明细的需求规格来定义需求。
“你要拉面还是削面阿?” 削面
“要不要加鸡蛋阿?”不要
“牛肉还是羊肉阿?” 牛肉
“有汤还是没汤阿?” 有汤
“要不要加香菜阿?” 不要
“口味重还是淡阿?” 咸点
“大碗还是小碗阿?” 大碗
“打包还是这里吃阿?” 这里吃
使用严格的需求规格来定义需求,有几个前提:
第一:就是需求调查者/分析师对领域/产品有非常完整的理解,不能遗漏。
第二,对规格的定义无歧义。比如:上面的每一条,双方理解都是一致的,是明确的。
第三,依赖客户对自己的需求有相对比较准确的理解。如果用户从来没吃过什么牛肉面,不知其为何物,他表达的东西不具备准确性。
第四,时间允许,这种描述方式,耗时肯定是相当长的。用这种方式问客户,可能客户早就跑到旁边的那家快餐店去了。
第五, 用户没有体验。在整个调研过程中,用户根本就没尝到过面是什么滋味。
使用迭代和紧密交流获取需求。
第一次来,用户觉得有点淡,下次就加点盐。第二次,用户觉得应该加点醋,下次就加点醋。第三次,店里建议他加个鸡蛋,味道果然不错。
。。。。。。
经过几次迭代以后,用户来到店里,基本上小二已经知道这个客户喜欢吃什么样的面了。这里面有几点:
第一. 用户尽早的获取到了真实的体验,无论是不好吃还是好吃。这也是敏捷软件开发方法所推从的尽早的发布可用的软件。
第二. 用户补充了他想要的需求。在经过体验的基础上,用户表达了他的需求,需求更具备针对性。
第三. 需求是一个交流的过程。完全可以引导用户的需求。
总的来说,软件需求的本质是用户同服务供应者理解一致的过程。
写具的需求规格说明书文档只不过是一个媒介,它并不一定能使双方达成一致的理解。将真实需求转换成语言描述,本来就可能有失真。即使写了文档,也要和最终用户作频繁的沟通,才能确保双方一致理解。要想真正用户满足需求,必须让用户及早参与,多次迭代。
腾讯产品的策略就是“用户体验,快速迭代
”, 看它现在的发展就知道了,它找到了发展的本质。
PS:很久没写博客了,思路不是很清晰,大家对付看吧,不妨谈谈你对需求本质的理解。
分享到:
相关推荐
4、如何进行软件需求分析 5、软件工程之需求分析 6、软件和需求的实践1 7、软件和需求的实践2 8、软件需求说明书模板 9、探究需求管理的本质 10、通过RUP用例进行需求管理的可追踪性策略 11、新产品开发项目中的需求...
软件需求工程,讲述了需求工程的主要概念与主要问题
《程序员》:基于需求的测试是软件测试的本质.pdf
需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性,可以是一种对系统开发进程的约束。
应用程序架构本质,要保证体系结构的正确,就要求人们能够使用相应的技术技能来捕获和细化正确的需求。发现用于需求建模的有价值的技能和工具,并且了解如何评估能力方面的进展。
而每个阶段又可以细分成若干个更小的阶段、快速原型模型的主要特点之一是、瀑布模型本质上是一种、甘特图指定项目计划的优点不包含、按照风险的可预测性分类,可以分为、 IEEE1998将需求分为功能需求、非功能性需求...
此需求分析是对《自来水公司综合管理平台》软件做了全面细致的用户需求分析、项目的可行性分析,明确所要开发的软件应具有的功能、性能与界面,使软件开发人员能清楚地了解用户的需求,并在此基础上进一步提出概要...
另一项基础则是实质性需求分析与研究(ERAR)。ERAR的要点,是揭示需求演变规律与应用模式创新。它是由技术导向过渡到用户需求导向的关键。MDM是实现与控制系统或其功能和行为的一种方式。对EIS,它既是功能也是技术...
需求开发的核心是需求获取,是为软件系统确 定各类干系人的需要和约束的过程 ...参与需求获取的人避免在理解问题本质之前就 开始设计系统 我们要强调用户任务而非用户界面 关注真正的用户需求而非口头诉求
从本质上说,软件测试是“探测”。 软件质量 高质量的软件是适当的、无错误的,能在预算内按时交货,满足需求/或期望,并且是可维护的。所以,质量是一个主观的术语。它取决于谁是客户以及客户对项目计划的...
三、软件需求及系统/产品(需求)规约 --试图回答软件开发的启始点及其工作产品 是产品/系统确认(测试)的标尺 四、软件开发方法学 --试图回答如何从事开发活动 五、CMM(the Capability Maturity Model for ...
软件是异化的,一般异化为具体、特例(对抽象力最好的归结方式)(没有完美满足需求的软件,相对于需求,软件只能满足固定的需求,而不能满足需求的变化,即一款软件总是具体的;由一般产生出具体的思考方法,也就是...
1.2 参考资料本文主要参考资料如下所示:[1]软件工程的本质–运用SEMAT内核,陈钟等译,机械出版社,2013年[M]. Ivar Jacobson.[2]
软件危机:随着计算机的广泛应用,软件生产率、软件质量远远满足不了社会发展的需求,成为社会、经济发展的制约因素,人们通常把这一现象称为“软件危机”。 2、简答题 简述软件开发的本质 软件开发的本质:不同抽象...
4.2 软件架构的本质 4.3 软件架构的设计 4.3.1 业界技术成果 4.3.2 软件框架 4.3.3 隐喻的价值 4.3.4 架构模式 4.3.5 软件架构师的素质 第5章 关于软件实现的思考 5.1 软件实现的实践场景 5.2 模型的设计 ...
本文在进行大量的实践和深入研究的基础上基于国际领先的理论框架结合商业银行的信息系统特点基于业务流程软件项目把需求分析活动引入到建模框架中把其看作体系结构层次的一个过程描述需求过程的结构提出一种新的需求...
1. 用户声称他们需要的[[0第一章 软件需求的本质#特性|特性]]并不等于他们使用新系统完成任务时需要的功能。 2. 业务分析师必须广泛收集用户的收入,分析和澄清这些信息,明确提出需要实现什么的功能才能帮助用户...
表现:1、软件需求增长得不到满足。2、软件生产成本高、价格昂贵。3、软件生产进度无法控制。4、软件需求定义不准确。5、软件质量不易保证。6、软件可维护性差 软件工程方法学的要素 四大要素:方法、语言、工具、...
如何进行软件需求分析.doc 如何写系统分析书.doc 软件工程之需求分析.doc 软件开发需求60条法则.doc 什么是极端编程.doc 探究需求管理的本质.doc 相信任何一位程序员都曾经见过面条状的代码.doc 星型模式建模和雪花...
软件需求分析产生两个重要文档,一个是软件需求规格说明书,另一个是(概要设计说明书)。 下面建立功能模型的步骤哪个顺序是正确的(确定角色/确定用例/确定用例模型)。 在图书馆信息管理系统中,已经构造了一个...