《你的灯还亮着吗》阅读笔记二

正如上篇所说我们在分析解决问题是要先对问题有一个定义,在对问题有了相对正确的定义之后

那下面就是要要思考和分析问题,尤其是在团队中,我们要搞清楚这是谁的问题?问题的来源是什么?

当负责这一块的模块的人能自己解决问题时,其他人最好不要“大包大揽”“越俎代庖”这样才有利于团队的和谐相处

在准确定义和全面深入分析问题之后,我们就有机会全面解决问题

书中有说:“鱼总是最后一个看到水的”

我们必须努力去寻找、观察将水变成沙

时间: 2024-11-01 08:53:18

《你的灯还亮着吗》阅读笔记二的相关文章

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

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

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

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

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

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

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

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

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

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

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

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

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

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

软件需求最佳实践

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

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

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

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

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