《探索需求》阅读笔记二

在任何相当规模的开发项目当中,孤军奋战显然是像是一种幻想,为了获得一个团队所能提供的容量和差异性,我们必须放弃任何个人英雄主义的幻想,为和他人合作付出代价。而这种人际的花费在会议中体现的最为明显,会议也是一种工具,一种社交工具。很多人都会感觉会议是很可怕的,它有的时候并不会产生什么效果,但是我们离不开它,一旦离开会议,就只能开发出最简单的产品。每一个会议能达到的结果是度量需求工作的健康状态,一个糟糕的会议,说明了需求过程的不完善。要想每一个参与者都完全的参与进会议中,这个会议就必须是稳定的,我们可以通过达成一些会议前的协议如建立一个打断机制、设置时间限制、反对人身攻击和贬低等来实现。

上次阅读的时候读到过关于含混性的问题,其在需求定义中是一个重要的问题,这次阅读了解到了用一些工具来启发我们确定在问题陈述中的含混性的源头,这些启发则是降低含混性的有力工具。例如我们可以根据记忆和含义之间的关系构造一种启发来确定问题描述的含混性;含混性投票是揭示问题描述含混性来源的另一种有用工具。得到这些启发还需要在一种幽默的气氛下能够得到完全的成功,会有效的找到问题描述含混性的来源,从而降低含混性。

探索中的工具在探索过程中很重要,利用这些工具,我们就可能在需求过程中找到一些激动人心的目标。

我们需要的不仅仅是召集一次能够产生想法的会议,也不仅仅是一些通用的优秀会议规则,真正需要的是专门为了产生想法而设计的会议,这种会议的原型就是头脑风暴,是许多启发方法的重要组成部分。头脑风暴分为两个部分,第一部分主要是增加想法的数量:对于一开始的想法不许批评和责备;你的想象要足够丰富;想法越多越好,及头脑风暴必须设计成能够产生大量想法的过程;最后在正确的头脑风暴设计中,最好要对列出来的想法进行合成或更改来创造出更多更好的想法。第二部分则是将想法列表中的想法数量减少到一个可操作的规模:门限投票法、合成想法、应用标准等方法。

在探索需求过程中,我们需要使用映射图,通过映射图工具在不同细节程度上产生映射图,在这个过程中,映射图也会越来越细化。草图和画曲线图两种工具可以帮助我们产生映射图。而头脑风暴后的可视化变化就是头脑作图,每个参与者在这个过程中循环画图形成头脑作图,这种方法能够将大脑的其他部分也带入创造过程。在每一个过程中我们都可以相似的做“右脑运动”,将语言的假设具体化,刺激新的想法。

名称是人们对一个项目的介绍,同时也是另一个容易产生含混性的地方,所以在探索需求中,我们要选择一个无含混性的名称。所有的项目名称——从工作名称到正式名称——都是具有含混性的,因此给项目起名的时候,为了探索项目需要做什么,做出选择是一种恰当的方式。一个项目的名称可以对它的结果和参与者的行为产生深远的影响,有几种方法可以帮助我们创造一个没有含混性的名称:启发式命名方法——首先提出一个名称,然后提出三条理由,说明这个名称为什么不合适,最后提出能够消除这三条理由的另一个名称。

每一次的探索中都会遇到一次或两次的冲突,这时候要准确的判断该冲突是否重要来控制非本质冲突的发生;另外还要能够让一些相关人员完全集中注意力,这也能够避免非本质冲突;要想会议更为有效,就要控制本质冲突。

对于我们的项目,做需求探索的时候要有明确的期望。通过从功能、属性、到约束条件,到偏好,再到期望的每个步骤,能够循序渐进的得到相应的信息,从而使我们更好的了解项目,有效的进行需求探索。

当然,探索需求中我们要获取信息过程首先要定义功能,了解系统的存在功能、并测试功能。通过客户的头脑风暴,记录所有潜在的功能;理解明显的、隐藏的以及装饰性的功能;识别未注意到的功能等方法会让我们更清楚、准确的把握项目功能。使用功能启发方法来识别真正需要的功能,减少忽略重要隐含功能的机会,为新的功能提供认识和机会,创造功能的一致。

时间: 2024-10-10 07:03:02

《探索需求》阅读笔记二的相关文章

<<软件需求最佳实践------SERU过程框架原理与应用>>读书笔记一(全书浅览)

这一学期上了软件需求分析这门课,在老师的建议下自己选择了这本需求最佳实践作为精读课本.大概的阅览了整本书后发现,作者引用各种实例与隐喻意图让读者更好的理解这本书的内容,而且每一部分内容都有一条精炼的SERU诫语来作为一个小结.在我看来,这本书确实对于我们软件需求分析的初学者来说确实是不可多得的“良本“. 全书分为三大部分,其中第一部分:“原理.模型与误区“涵盖前三章的内容.这部分作者主要分析并提及了影响软件项目实施,并导致软件出现“危机”的根本原因,即需求分析阶段. 主要是让我们认识到软件需求在

《软件需求最佳实践》阅读笔记一

这本书主要从软件需求实践中出现的主要问题和困难入手,指出了改造的主要方法,然后逐一说明了需求定义.需求捕获.需求分析与建模.编写规约.需求验证等需求开发活动的任务.要点和具体手段.还对包括需求基线.变更管理.需求跟踪在内的需求管理活动的操作要点进行了阐述. 软件项目实施过程中,会遇到很多的问题,有的甚至许多项目根本无法达到预期的目标,这些问题的根源就是软件需求实践.“在中国做软件太难了!客户连自己的需求都说不清楚!”,这种抱怨的话经常被做软件需求的人说到.需求失败也是因为不完整的需求.缺乏用户参

《软件需求模式》阅读笔记02

通过上一次对<软件需求模式>前两章的阅读,我了解了需求是什么,而作为这本书的书名,我们自然就要了解什么是需求模式以及如何编写和使用需求模式. 所谓的需求模式,就是定义一种特定类型需求的方法.然而使用需求模式能够给我们带来什么好处呢?第一,需求模式提供指导:建议包含哪些信息.提出忠告.提醒常见缺陷以及指出其他应该考虑的问题:第二,需求模式节省时间:不需要从头开始写每一个需求,因为模式给予了合适的出发点,以及开发的基础:第三,需求模式促进同种类型需求的一致性.在了解了需求模式的大概的内容之后,我们

《软件需求最佳实践》阅读笔记二

需求捕获是需求开发中的第一个活动,每个团队都必须提高需求捕获的有效性,要点在于计划性和科学性. 需求捕获的过程是人和人打交道的过程,需求捕获需要需求分析人员积极主动的去获取需求,是散网打鱼,而不是休闲钓鱼:在对用户进行需求提问时,要善于聚焦访谈话题:用户的需求是一个冰山,有很多潜在的需求我们不容易意识到,而理解业务场景有助于需求分析人员更深层次的理解用户的需求.需求捕获有很多种方法,(1)用户访谈:最常见.最基本的需求捕获技术,直接有效.形式灵活,但是要避免占用时间长和用户信息的片面性,最常见的

《软件需求模式》阅读笔记之二

在前面了解了什么是需求,什么是需求模式之后,接下来就应该学习如何使用和编写需求模式.我们不仅到了解需求模式的含义,更要学会在什么情况下使用需求模式.在定义系统期间,有两种场合使用需求模式:1.当定义需求时,看是否存在一个模式可以指导如何定义这种需求.2.当考虑系统需求是否完全时,浏览主题覆盖的整套模式——看是否有遗漏,或者是否需要添加什么东西.3.当评审需求规格时,模式可以帮助检查需求的质量,确定还有哪些主题没有定义,理解特定需求的意义和内涵.4.当评估系统的规模以及开发所需的工作量时,基于需求

《软件需求模式》阅读笔记03

在对需求模式的概念和内容方面有了深刻的了解之后,我将学习各类不同的需求模式. 基础需求模式是所有种类的系统都可能需要的一些东西,它包括了:技术.遵从标准.参考需求.文档.系统间接口.系统间交互.系统间需求模式是用来定义被定义的系统和任何与之交互的外部系统或组件之间的接口的基本细节,它包含了以下内容:接口名称.接口标识符.两端的系统.接口的目的.接口的所有者.定义接口的标准.用于接口的技术.在开发测试的时候,我们应该明确交互需求,找到隐含的交互以帮助满足间接陈述的目标.系统间交互需求模式是用来定义

需求工程——软件建模与分析阅读笔记二

需求的定义:用户为了解决问题或达到某些目标所需要的条件或能力:系统或系统部件为了满足合同.标准.规范.或其他正式文档所规定的要求而需要具备的条件或能力:对以上两点的一种文档化表述 满足需求就是解决问题:需求源于问题,要准确理解需求就必须明确它与问题的关系.,人们开发软件系统的目的就是希望用它作为解决方案来解决问题,使得现实改善到期望的状况.解决问题.改善现实.满足用户期望的状况. 问题解决的两个方面--问题域与解系统:问题在现实世界与软件系统的互动中的到解决,问题语是需求的背景,问题域的背景信息

软件需求最佳实践

需求建模与分析篇 需求分析基本遵循三个方向,依次是:流程,对象以及关系,用例(操作容器): 流程对应的是跨职能流程图以及活动图,对于活动图,实在是没有感到有什么优势可言:但是对于流程图究竟要细化到什么程度?只要是不影响泳道的变更就可以作为一个节点处理,这个还有待考证: 对象以及关系,作者首先推荐的是类图,但是对于类图其实使用在设计阶段,作为需求分析阶段拿了一张类图给客户看,给客户讲解你所识别出来的类?如果是给架构师以及开发团队来看还是有点意义,但是对于国内项目很多时候时间很紧急,你搞出这一套花活

《掌握需求过程》阅读笔记二

了解了一些需求过程中的方法和问题,接下来就要网罗需求.网罗工作是由需求分析师来策划的,但是要完成这个工作需要分析师.用户和其他风险承担者相互合作,要明确每一个角色各自的职责.意识到的需求是指那些用户最先想到的需求,这通常表明用户希望改进的一些事情:无意识的需求是指用户没有言明的事情:未梦想过的需求是指那些一旦用户认识到它们可能时就会要求的事情.在网罗活动的过程中,必须揭示和捕获所有的需求,网罗活动具有多面性,它使用了一些来自启动阶段活动的输出结果:业务事件在网罗活动中占主导地位. 需求网罗的第一

软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二 管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用. 客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集需求有着不可替代的必要性,所以导致项目最终失败的两个原因,一个是缺乏用户参与,另一个是不完整的需求规格说明. 在进行需求分析时,只有系统的实际使用者才能清楚的描述他们要用此系统