阅读笔记 火球UML大战需求分析4

    在我们整个团队的需求分析过程中,是否要单枪匹马的尽心作战,还是要一项目团队为集体来进行作战呢?在本章要学习的就是需求分析的团队作战的方式

    所以,要想了解团队作战的方式,必须要知道项目团队如何集体的获取需求

    1.首先,让项目组的成自己活得一手的需求,要比得到的二手的需求肯定要好的多,所以,项目组的成员一定要积极地去进行需求的获取,不能依靠队伍内提供给自己的数据来进行分析,因为每个人的思路不一样,获取的需求的方向也有可能有略微的区别

    2.写需求和读需求还是有很大的区别的,所以一定要自己去写需求,加深自己的理解和记忆

    3.在得到了自己的调研需求后,一定要去从现实的角度去思考问题,避免一些技术上的难题如破不了,

    4.需求调研过程中一定要好好的进行思想上的磨合,理解上达成一致,这样可以避免后期很多的问题,特别是沟通的问题,所以,在团队调研的过程中,也是培养默契的一样过程

    当然,一个团队,不能像没王的蜂一样,那样就会乱了套。所以整个需求调研的团队要以高手为核心,以其他的成员为骨干,大家一起互相努力互相激励,去完成调研需求的任务。

    再达到了大家能够共同调研的前提下,接下来要做的就是互相分享自己的需求,所以,这里讲究的就是速度了

    那么,如何快速的分享需求,以达到一个效率呢

    1.一个任务只做一个事情

    2清楚地描述任务的要求,明确的完成目标

    3每个任务至少有一个可以检查的输出物

    4一个任务完成时间在吴天以内最好

    5.一个任务安配一个负责任

    6.任务有两种状态,完成,未完成。

以上就是团队需求调研要注意的点

时间: 2024-10-13 21:15:39

阅读笔记 火球UML大战需求分析4的相关文章

02《火球——UML大战需求分析》阅读笔记之二

02<火球----UML大战需求分析>阅读笔记 在上一次的阅读笔记中,:我阅读的是开始部分和第一章,总结了其实UML不仅对于软件设计有很大的用处,对于软件的需求的分析也处于很高的地位.现在,读了第二章,真正的明白了UML对于需求分析的真正用处. 其实客户与我们所处的关系和医生与病人之间的关系,认识永远存在着偏差,就像对于用户和软件公司,对于需求的分析永远的存在着偏差.因为对于客户而言,每天的需求总是多变的,并且词不达意--à分析员的错误理解--à程序员的错误编码----à返回客户,客户的不满意

读书笔记---《火球:UML大战需求分析》

书评 作为一本UML和需求分析的入门书来说还算可以,写的比较接地气,如果是做过很多项目的读者,很容易找到共鸣点. 美中不足:部分概念可能有错误,其中对于Component和Artifact的解释明显和Wikipedia的解释不一样,感觉应该是错误. 结论:三星推荐. 需求分析 需求分析的难点 屁股决定脑袋,眼界决定境界,各人有各人的想法 词不达意,想到说不清楚,说清楚写不清楚,写清楚理解不清楚 需求的持续演进,一天一个样 自学业务,争取尽快超越客户对需求的理解 认真考虑,认清客户真正的需求是什么

火球-UML大战需求分析(体验版3.0.2).pdf

http://files.cnblogs.com/files/happlyonline/%E7%81%AB%E7%90%83-UML%E5%A4%A7%E6%88%98%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%EF%BC%88%E4%BD%93%E9%AA%8C%E7%89%883.0.2%EF%BC%89.pdf

2016年秋季-《UML大战需求分析》-阅读笔记2

<火球--UML大战需求分析>的第二章的语言很有趣,而且在开始介绍的地方有一个我们非常熟悉的一个关于"软件需求与分析"的案例,在从上大学的第一门课"信息科学技术导论"上,王老师给我们看过一张非常有趣的组图,讲的就是:客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子!需求分析是高难度和折腾人的工作,以一个示例全过程的了解需要的挑战.在通过这几天的阅读后我认为:软件需求分析存在的主要困难是由于角色的不同引

《uml大战需求分析》阅读笔记一

首次接触UML是去年的时候,当时是刘立嘉老师为我们讲授的,因为之前并没有接触到具体的项目,所以对UML这门课不是很重视,我想大多数人应该和我一样对UML没有给予足够的重视,这学期我们开设了软件需求分析这门课,又使我重新接触了UML,我选择阅读<UML大战需求分析>这本书来增强我对UML的理解. 根据作者所说他开始和我一样认为UML图并不能简化项目,反而成为了一个负担,但是在作者开始工作了以后渐渐了解UML对于项目的重要性,他可以明确的表达一个软件的功能,边界,交互过程.虽然没有学过UML的人并

《UML大战需求分析》阅读笔记01

在刚学习软件开发的课程时,首先学习了UML设计,但只是学习了基本的语法,虽然在学期通过课堂练习进行了实践,但并没有真正理解其中作用.为了进一步的理解UML的用法,我阅读了<UML大战需求分析>这本书,希望可以详尽的掌握UML语言. 首先我阅读了第一章,学习了什么时候使用什么图,并从整体的角度对各类图进行了认识.UML是一种语言,UML语言用于软件需求中更能直观的进行交流,易于理解.UML大体可以分为两类图:结构型的和行为型的.结构型的图描述的是某种结构在某段时间内具有固有的结构,是静态的:而行

UML大战需求分析——阅读笔记04

读<UML大战需求分析>有感04 开发某系统的重要前提是: 这个系统有谁在用? 这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某某系统能做什么事情,关注的是系统的外在表现.系统与人之间的交互.

UML大战需求分析——阅读笔记03

读<UML大战需求分析>有感03 状态机图和活动图在样子比较相似,但状态机图是用来为对象的状态及造成状态改变的事件建模.我们大二学习UML统一建模语言状态机图模块时了解到,UML的状态机图主要用于建立对象类或对象的动态行为模型,描述系统中某一个对象所经历的各个状态.引起状态或活动转移的事件,以及因状态或活动转移而伴随的动作.但在以前的学习过程中,我们并没有学到过"伪状态",后经查阅知:伪状态是指在一个状态机中具有状态的形式,同时具有特殊行为的顶点.它是一个瞬时状态,用于构造

04《火星——UML大战需求分析》阅读笔记之四

在上一章我看了UML大战需求分析分析中的类图,在上课中老师也提到了类图对于需求分析的重要性.其中在软件需求分析中重要的有:类图(结构建模是最常用的UML图).时序图.用例图.现在看着这一章虽然没有那么的重要,但是在软件需求分析中也有很重要的地位: 在书中提到活动图可能用来表达流程的最常用的一种UML图,是行为建模的重要工具之一.在这就会出现一个问题:如果我们想要做一个项目,我们就要问自己几个问题:1.没有应用系统的时候,系统是怎样运行的(事物内容和事物之间的关系/流程相关的问题)2.应用了系统后