我刚才支付了29元,怎么还不能用啊会员功能
660
2022-05-30
事实1
需求其实并非在谈需求。
对于软件产品、硬件产品、服务或任何你想构建的东西,需求就是它们要做的事或要成为的东西。不论你发现还是没发现,写下来或没写下来,需求都存在。显然,除非产品满足需求,否则就不对。所以从这个角度你可以认为,需求是某种自然法则,等着你来发现。
这就是说,需求活动主要不是编写需求文档。相反,它专注于理解业务问题,并为之提供解决方案。软件是要解决某种问题,硬件和服务也是。需求发现的真正艺术是发现真实的问题。只要你做到了这一点,就为识别和选择不同的解决方案奠定了基础。所以,从本质上说,需求与编写需求无关,而是发现要解决的问题。
另外,当我们说“业务”、“业务问题”或“工作”时,我们的意思就是你所关心的各种活动,它们可以是商业上的、科学上的、嵌入式的、政府的、军方的,实际上也可以是所有其他类型的活动、服务或消费品。
此外,在本书中,当我们说“他”(常指业务分析师)时,我们的意思是“他或她”。我们发现说“他或她”或“他/她”很不方便。请相信,需求工作不分性别。
事实2
如果我们必须构建软件,那么它必须为拥有它的人提供最理想的价值。
请注意,我们关注最终结果的拥有者,只是间接地关注用户。这种关注似乎与通常的优先级相反,所以我们最好解释一下。
拥有者是为软件(也可以是硬件或其他要构建的产品)付费的人或组织,不论拥有者为该软件的开发付了钱,还是从别处购买了该软件。软件部署时造成的业务影响,也是拥有者付出的成本。另一方面,拥有者从软件中得到好处。描述这种关系非常简单,拥有者花钱买好处。
我们可以用另一种方式来表述:除非产品提供了利益,否则拥有者不会付钱。这种利益通常表现为提供某种以前没有的能力,或改变某种业务过程,使之更快、更便宜、更方便。自然,这种利益为拥有者提供的价值,必须超过开发该产品的成本(参见图1)。
图1 随着软件变得越来越强大、成本越来越高,软件带来的利益也越来越大。但在某一点,构建的成本开始超过利益,项目就不再盈利了
要最好地体现价值,产品提供的利益必须与产品的成本相称。在某些情况下,如果带给拥有者的价值足够大,产品可以成本很高。例如,航空公司愿意付大量的钱来开发模拟器,确保飞行员获得合适的资质和技能。如果他们没有合适的资质和技能,就会造成生命财产损失。航空公司可能也会花大量的钱来开发自动化的值机系统,因为这将大幅减少乘客登机的成本。同一家航空公司只愿花很少的钱来开发食堂员工花名册系统,因为事实是:这类任务可以手工完成,食堂里的人不对可能带来烦恼,但几乎不会对生命构成威胁。
需求发现者(称为“业务分析师”、“需求工程师”、“产品拥有者”、“系统分析师”或其他头衔)的职责,就是确定拥用者看重的价值是什么。在某些情况下,提供一个小系统,解决一些小问题就能够为拥有者提供足够的利益,让他们觉得值。在另一些情况下(可能这种情况很多),扩展系统的功能将提供很大的价值,并且可能只要增加少量成本就可以实现。这都取决于拥有者认为什么有价值。
然后就是最佳价值:充分理解拥有者的问题,以便交付一个解决方案,以最好的价格提供最好的回报。
事实3
如果软件不必满足要求,那你怎么干都行。但是,如果它打算满足要求,你就必须知道要求是什么,才能构建正确的软件。
这样思考很有价值:如果开发者正确地理解了产品打算为用户完成什么,以怎样的方式完成,这些产品就是最有用的。要理解这些事情,你必须理解拥有者的业务工作,并决定将来工作如何进行。
如果这些事情得到理解并达成了一致意见,业务分析师就与拥有者沟通,探讨怎样的产品能为工作带来最大的改进。业务分析师得到需求,描述产品的功能(它要做什么)以及产品的属性(它做到什么程度)。
不知道这些需求,开发项目得到的产品就不太可能有太大价值。除了少数撞大运的意外,没有产品能在事先不理解需求的情况下成功。
不论拥有者希望做哪种工作,科学的、商务的、电子商务的或社交网络的,也不论使用什么开发语言或开发工具来构建产品,开发生命周期(敏捷、原型、螺旋、Rational统一过程或其他方法)也与理解需求的要求无关。
这一事实总是会出现:你必须得到需求的正确理解,并与客户达成一致意见,否则你的产品或项目就会有严重的缺陷。
有两次我被问到:“请告诉我,Babbage先生,如果向机器输入错误的数字,会得到正确的答案吗?”我无法理解问出这种问题的混乱思维。 ——Charles Babbage
事实4
构建一个软件和解决一个业务问题之间,存在巨大的差别。前者不一定实现后者。
许多软件开发项目只关注软件。这也许看起来很合理,毕竟,大多数软件项目设法开发出某种软件。然而,只关注软件有点像在建帕台农神庙时只关注石头。软件要对拥有者有价值,就必须解决拥有者的业务问题。
我们开发了相当多的软件。每年产生数千万行代码(也可能是数亿行)。这些代码中包含许多错误,最多的错误是需求错误。因此,世界上相当多的软件不能解决正确的问题。
某些开发过程基于一种理念,即向目标用户交付某种功能,然后请他们来说是否能解决他们的问题。如果不能解决,软件就返工一下,然后再次展示并请求批准。这样做有一个问题:我们永远不知道用户批准前一次交付是因为对它满意,还是因为被过程搞得筋疲力尽。
最重要的是,很难让单个用户理解部署一个软件在更大范围内造成的影响。通常软件用户不知道更大业务的足够信息,不能确定具体应用这种软件是否会对业务的其他部分带来问题。
就算是啰嗦,我们也要再次强调,软件就是要解决一个业务问题。于是很清楚,所有开发工作都必须从问题开始,而不是从看到的解决方案开始。
事实5
需求不一定要写下来,但构建者必须知道它们。
通常,需求项目的目标看起来就是尽可能得到一份厚厚的需求规格说明书。很少有人能理解它的大部分内容,甚至更少的人有耐心去读它,但这似乎都不重要。需求编写者相信,需求规格说明书越厚,他们的工作就越会受到欣赏。
在写好之后,这份可观的文档就被抛过墙头(或者应该说用铲车抛过墙头),交给开发者,盼望这些人对厚厚一叠规格说明书感到高兴。毕竟,它的页数越多,内容遗漏的可能性就越少。也许理论上是这样。自然,开发者几乎总是对这种文档毫无兴趣,要么忽略它,要么固执地坚持它。这两种方式的最终结果,通常都不能令人满意。
虽然有这种奇怪的行为,我们仍然需要分析需求,并将这些需求告诉给开发团队(参见图2)。
图2 自然,需要和产品构建者沟通需求
需求是否写下来,这不是问题的要点。在某些情况下,口头沟通需求更有效,在另一些情况下,必须永久地记录下需求。
虽然口头沟通需求效率高,但我们觉得,所有需求都用这种方式来沟通是不可行的。在很多时候,编写需求的活动有助于业务分析师和利益相关者彻底理解需求。除了改进理解之外,正确编写需求也提供了追踪文档。需求的理由,或故事卡上的缘故,记录了团队的决定。它也为测试者和开发者提供了清晰的指示,说明了需求的重要性,从而建议需要花多少工作量。此外,如果维护者知道为什么有这项需求,也会降低将来维护的成本。
需求并不是要为项目增加额外的负担,所以除非很有必要,否则就不应该写任何东西。但是,如果有需要,那么编写需求的工作将带来数倍的回报,因为需求的准确性和对将来维护工作的减少。
事实6
客户不一定总能给你正确答案。有时候客户也不可能知道什么是对的,有时候他就是不知道需要什么。
传统来讲,需求活动被看成是某种类似速记员的任务。也就是说,业务分析师仔细聆听利益相关者,准确记录他们说的所有东西,并将他们的要求翻译成产品的需求。
这种方式的缺点是,它没有考虑到利益相关者在试图描述需求时的困难。展望一个产品来解决一个问题,这不是一项简单的任务,尤其是问题并非总是理解得很彻底。考虑到今天业务的复杂性和规模,个人确实很难理解业务所有适当的部分。
我们也有“增量改进”的问题。在询问有关新系统时,利益相关者常常会描述原有的系统,并加上一些改进。这种增量的方式通常排除了所有重大的创新,常常会导致平庸的产品,不能满足期望。
业务分析师必须表演戏法。有时候他必须记录下客户的要求,有时候他必须说服客户,他们要求的并不是他们需要的,有时候他必须从客户的解决方案中导出需求,有时候他必须提出没有人提到的创新,得到更好的解决方案。在所有情况下他都应该想到,每个利益相关者都可能是匹诺曹(见图3),不要什么都相信。
图3 有时候,你的客户就像匹诺曹,不会告诉你全部事实
事实7
需求不是偶然得到的,要通过某种有序的过程得到。
所有重要的努力都需要有序的过程。随机使用钢筋和水泥不会建成大楼,需要一个定义的过程来设计和建造这样的结构。类似地,有一个定义的、系统的过程来拍电影。摩托车也是通过有序的过程来设计和建造的,你的最近一次飞行也是一组有序的过程,几 乎是逐字执行的。甚至艺术工作,如写小说和画画,艺术家都会遵循一个有序的过程。
这些过程不是因循守旧的过程,不是无头脑地执行所有指令,不问任何问题,按预先描述的顺序,没有任何变通。相反,有序的过程由一组任务构成,实现预期的结果,但这些任务的次序、重点和应用程度需要采用该过程的人或团队来决定。
最重要的是,参与这个过程的人必须能看到,为什么过程中不同的任务是重要的,哪些任务对项目最重要。
事实8
你怎么迭代都可以,但仍需要理解业务的需求。
迭代式开发方法变得越来越流行,这肯定是有意义的进步,但像很多进步一样,这些技术有时候炒作过度了。例如,我们曾听到有人说(也有人印刷出版),迭代式交付让需求变得多余。
冷静的头脑会意识到,任何开发技术都需要发现需求,这是认真开发的先决条件。因此,冷静的头脑已经将需求过程吸收到他们的开发生命周期中。聪明的方法不是废除需求,而是从一个不同的方向接近需求。
真正值得关注的是既要发现需求,又不必编写无用的、不成熟的、浪费的成堆文档(这适用于所有类型的开发技术)。
不论你怎样开发软件,总是要理解客户的业务问题,以及产品必须做些什么来解决这个问题(即它的需求)。
事实9
没有银弹。所有方法和工具都无法弥补糟糕的想法和糟糕的手艺。
虽然我们需要一个有序的过程,但不应该认为它能够代替思考。过程有帮助,但它们对聪明人帮助较大,对不准备思考的人帮助较小。对于需求过程来说,这一点尤其正确。在需求过程中,业务分析师需要面对几个版本的需求,同时还要想象未来最好的软件产品是怎样的。
需求活动一点儿也不简单,要想成功,就需要业务分析师的思考和理解。一些自动化工具可以有所帮助,但它们只能作为辅助手段,而不能替代好的需求实践。盲目遵循事先制定的实践,根本不能取得有经验的业务分析师能取得的结果。分析师使用最重要的工具:头脑、眼睛和耳朵。
事实10
要想成功地实现需求,需求就必须可度量、可测试。
从本质上说,功能需求是产品支持其拥有者的业务时必须做的事。非功能需求是产品要在拥有者的环境中取得成功,必须将功能完成得多好的量化描述。
要让构建的产品完全满足这些标准,在编写需求时就必须准确。同时,必须考虑到需求来自于人,而人并非总是准确,可能总是不准确。要达到必要的准确程度,必须对需求进行某种测量。如果可以用数字代替文字来测量需求,就能让需求可测试。
例如,如果你的产品有一个需求是“应该对新用户有吸引力”,那么就可以建立一个测量指标,即初次使用的用户能够在2分钟内成功建立一个账户,对于用户应该知道的所有数据项,都不会有超过5秒钟的犹豫,如他的姓名、邮件地址和类似的数据项。(犹豫时间是测量产品直观程度的指标,是对用户的吸引力的一部分。)自然,如果你用这种方式来测量需求,测试人员就可以确定产品(有时候是产品原型)是否满足需求。
可以很放心地说,如果你不能为需求找到测量指标,那它就不是需求,只是一种无根据的想法。
事实11
作为业务分析师,你将改变用户思考这个问题的方式,不是现在就是将来。
在你开始理解需求时,尤其在需求来自于不同的利益相关者时,你就开始建立一些抽象概念,并建立一个词汇表。你展示业务过程的模型,与利益相关者一起发现工作的本质,得到清晰和可测量的需求,并将所有这些事实反馈给利益相关者。在做这些事情时,你就会改变(改进)他们对业务问题的看法。
如果人们对需求的含义有了更好的理解,他们就可能看到改进的办法。你的一部分工作就是帮助人们尽早理解和质疑他们的需求,这样他们就可以帮助你发现他们真正的需求。
需求究竟是什么
在了解这些事实之后,我们一直在讨论的需求到底是什么呢?简而言之,需求就是产品支持其拥有者的业务所必须完成的事,或让拥有者接受并感兴趣所必须具备的品质。需求之所以存在,要么因为该类型的产品要求某些功能和品质,要么因为客户希望该需求成为交付的产品的一部分。
功能需求是产品必须完成的那些事。 产品应该生成一份所有道路的除冰调度表,这些道路在给定的时间参数内预计会结冰。
这类需求是产品要做的一件事。产品要在拥有者的业务背景下有用,就必须做这件事。你可以推断,上例中的拥有者是一个组织机构,负责保持道路的安全,实现方式是分派卡车,在快要结冰的道路上播撒除冰物质。
产品必须在0.25秒以内确定对方是“朋友”还是“敌人”。 非功能需求是产品必须具备的属性或品质。
有时它们作为需求的原因是为了改进产品,或让人们想买它。例如:
产品应该提供愉快的用户体验。
有时它们让产品可用:
产品应该能被到达大厅的旅行者使用,这些旅行者可能不使用当地的语言。
非功能需求可能开始看起来很模糊,或不完整。在本书后面的内容中,我们会看到如何为它们制定验收标准,让它们可度量、可测试。
限制条件是全局性的需求。它们可以是对项目本身的限制,或是对产品最终设计的限制。例如,这是一个项目限制条件:
产品必须在新的税务年度开始前准备好。 限制条件是一个全局问题,约束着所有的需求。
产品的客户是在说,如果顾客不能在新的税务年度中使用该产品,那么它就没有什么用了。其效果是,需求分析师必须对需求进行限制,只包括那些在最后期限内能够提供最大价值的需求。
还有一些限制条件是针对产品的最终设计和构造的。例如,下面的例子:
产品应该作为iPad、iPhone、Android和Blackberry应用来运行。
如果这是一个真正的业务限制条件,而不只是某种看法或观点,那么不满足这个限制条件的所有解决方案显然是不能接受的。
不论限制了什么,限制条件都可以看成是另一种类型的需求,参见图4。
限制条件只是另一种类型的需求。
图4 最终产品的功能受到限制条件的约束。功能性是用户能得到的好处,但“交付”功能性的非功能需求让产品可用,被用户接受
本文节选自《掌握需求过程(第3版)》
内容简介
本书可作为软件开发人员在开发过程中随时参考的手册,是产品经理、系统分析师、软件开发者和测试者必读的一本好书。
本文转载自异步社区
软件开发 软件开发
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。