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

代码可以重用,那么需求是否可以重用,答案是肯定的。但是需求并不是免费的,成功的重用需要我们做一些工作。需求规格说明书就要发挥作用了。我们不可能只与一个系统打交道,那么不同项目之间的底层功能实际上很有可能是一样的。我们可以以不同的方式遇到潜在可重用的需求,某些将被精确地表达,从而可以直接重用。在项目一开始时,可以通过画上下文范围图对目标工作的上下文范围进行建模,从而使系统可见。需求的可视化使它们可能被更多的人重用,重用可以带来不可估计的好处。

需求规格说明书一直被鉴定,更改。鉴定工作进行无数次,质量关单独检查每项需求,鉴定考虑所有的需求以及它们之间的相互影响。鉴定要发现遗漏的,冲突的,二义性的需求。遗漏的需求需要通过用况推演来发现,冲突的需求,二义性的需求拒绝使用“应该”等字样。

需求也需要管理,需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性,以及与其他需求和其他项目工作之间的可追踪性。

需求必须是可追踪的,这样可以保持产品和使用产品的外界之间的一致性,为了追踪需求我们需要追踪业务事件,进行用户复查。

产品一直在变化,我们要将注意力集中在复查您收集和制定需求的有效性上面,发现主要的失误以及成功之处,事后分析是一种反馈机制,好的反馈机制有助于识别变化,事后分析是为了收集经验财富,指出了在项目中学到的内容和经验反思。就像我们高中的错题本一样,记录的那些错题都是自己犯下的错,项目的事后分析报告将会使你进步,或许也会多了一些捷径,使你不至于在同样的地方摔倒第二次,就算摔倒了,也会自己站起来。

时间: 2024-08-06 07:56:51

《掌握需求过程》阅读笔记06的相关文章

用户故事与敏捷方法阅读笔记二

第8章 估算用户故事 使用故事点 我们用“速率”(velocity)来代表一个团队在一轮迭代中完成(或期望完成)的故事点数.因此,务必保证每次迭代的故事点的度量是一致的. 如果用结对编程呢? 团队用不用结对编程,对故事点估算并没有影响.团队可以采用理想结对日或理想个人日来估算故事点,区别会表现在速率值上. 一些提醒 一个故事(可能是一个史诗故事)分解成一些小故事后,这些小故事估算的总和不需要与开始那个故事或史诗故事的估算相等. 类似地,一个故事分解成一些任务.这些任务估算的总和不需要与故事的估算

用户故事与敏捷方法阅读笔记三

第12章:故事是什么 用户故事有别于IEEE 830软件需求规格.用例和家傲虎设计场景. 考虑用户的目标比列出方案的特性更重要. 用户故事与用例场景类似.他们的完整性和寿命不同.他们以不同的目的编写. 第13章:用户故事的优势 用户故事促使我们重视口头交流,这一转变提供了迅速的反馈周期. 用户故事的典例范围比用例及场景小.他适合于迭代开发.鼓励延迟细节,鼓励应变的开发. 第14章 用户故事不良症兆一览 故事太小:故事相互依赖:镀金:故事中包含太多的细节:过早包含用户界面细节:想的太原:故事划分太

用户故事与敏捷方法读书笔记02

开发软件可以通过编写用户故事来确立开发的目标和方向.而在编写故事前首先要对所有用户进行分类,根据角色的不同属性进行分类.步骤为:1.通过头脑风暴,列出初始的用户角色集合:(要坚持‘已确认的角色代表的是单一用户’的原则)2.整理最初的角色集合:(确认角色之间的关系:用户角色定义的是人而不是外部系统)3.整合角色:(对于完全重叠的用户进行重新定义,舍弃对系统成功作用不大的角色)4.提炼角色(根据角色特征来建立角色的模型). 编写故事之前需要搜集故事,通过与用户沟通来发现故事.可以像用渔网捕鱼一样获取

《用户故事与敏捷方法》阅读笔记01

用户故事与敏捷方法第一章是对用户故事的概览.      首先第一个问题用户故事是什么?用户故事描述了对用户.系统或软件购买者有价值的功能.用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示.2.有关故事的对话,用于具体化故事细节.3.测试,用于表达和编档故事细节且可用于确定故事何时完成.      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事.书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事.例如将"用户可以搜索工作

《用户故事与敏捷方法》读书笔记

1.采用用户故事这一方法,是从写下两条信息开始的:每一个系统需要实现的目标和实现那个目标所需要的大致成本. 2.3C原则:"card.conversation.confirmation",任务卡片.交流.确认 3.大量预先的需求收集和文档会议很多方式导致项目失败.最常见的是需求文档变成软件开发的目的.应当只在对交付软件有用时才写需求文档. 4.对用户故事的最佳诠释:卡片包含故事的文字描述,然后需求细节要在"对话"中获得,并在"确认"部分得以记录.

《用户故事与敏捷方法》阅读笔记06

第八章 估算用户故事 故事点有一个很好的特性是团队可以定义自己认为合适的故事点,一个团队可能定义一个故事点为一个理想日的工作,也可能定义为一个理想周的工作.故事点有很多意义,所以故事点代表时间的模糊单位. 故事估算应该由整个团队集体来完成.故事估算属于团队集体有两个原因,第一个,还不确定团队中谁负责完成这个故事,第二个,团队决定的估算可能比个人估算更有用.在估算时,作者介绍了他所用的方法迭代的方式进行估算.在初步估算好后,成员进行讨论,然后进行下一轮的讨论,最终达成一致. 三角测量.估算一个故事

《用户故事与敏捷方法》阅读笔记05

第13章 用户故事的优势 从上一章我们得知,处理需求的方法多种多样,但是我们为什么要选择用户故事?因为它会带来多种好处: ①用户故事强调口头沟通:自古以来,口头表达是十分重要的.而且相比于书面书写的易产生歧义,口头表述更见简单明了,需求文档也是如此. ②人人都可以理解用户故事:相比于一些墨守成规的软件需求里的技术术语,用户故事使用的语言更容易使用户理解,简洁明了,同时更能增强用户对故事的记忆. ③用户故事的大小适合做计划:其他类型的需求分析关联性太强,并且还比较笼统,大小不能称得上是易实现的适合

《用户故事与敏捷方法》阅读笔记03

第10章 迭代计划 制定出上一章的成果发布计划,我们可以顺利地将粗细度的故事分配到多伦迭代中.多伦迭代是发布计划的进一步激化,但只在迭代即将开始的时候才开始做迭代计划.为此,迭代计划会议必不可少,客户以及团队的所有人员都要参与其中.在这一过程,各个人员仔细讨论每个故事,从故事中分解出任务,开发人员承担每个任务的职责.这个会议是客户为团队调整故事的最佳时机,但是切记项目团队不要随意被客户打乱开发计划. 任务的大小没有强制的范围(例如:3小时到5小时).相反,从故事中分解任务,用来帮助估算或鼓励多个

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之

用户故事与敏捷方法①

在读这本书之前,自己觉得有点好奇,用户故事指的是什么呢,读完之后,有了体会:用户故事描述了对用户.系统或者软件购买者有价值的功能.它由3方面组成:1>一份书面的故事描述,用来做计划和作为提示:2>有关故事的对话,用于具体化故事细节:3>测试,用于表达和编档故事细节且可用于确定故事何时完整. 它总共分为了五大部分来介绍: 第一部分是一些简单的概念或者使用故事的细节方面,比如如何编制用户故事,有哪些细节要求:在故事中找出用户角色模拟使用情节:怎样搜集到用户故事,通过各种途径:如何找到用户代理