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

这次主要读了这本书的第五六章,这两章被作者称为流程分析的利器。对于第五章来说,这一章主要讲的是状态机图,以前老师讲uml的时候,对于这一部分讲的并不多,通过一个请假的流程图引入,流程图可以将流程分解为一个一个的活动,通过活动的先后顺序来展示流程,而状态机图从某个事物的状态是如何变化的角度来展示流程。

对于此案例,当一个申请者提出请假后,该申请的状态为提出,表示该申请正在等待审批。审批者审批这个申请,如果批准,则申请状态变为“批准”,这样流程便结束。如果拒绝了申请,则申请的状态变为拒绝,这样申请者可以考虑修改申请,则申请重新变为提出状态,则审批者再次审批,或者审批者放弃了这次申请,则流程也进入结束状态。

我觉得请假申请者当一个申请者想申请一个重要的请假,写下了一段诚恳而又长篇的请假理由,但是没有写完。他想先把这个请假申请保存起来,可是只要他单击确定按钮,这个请假申请就会变为“提出”状态,领导就可以审批这个请假申请,于是乎增加一个“草稿”的状态,请假申请还没有写好之前,可以先保存起来,状态为草稿,这个时候审批者还不能审批这个请假理由,只有等请假申请人提交申请后,请假申请才会变为提出。

对于第六章来说,这章主要讲的顺序图,以前都说是序列图,顺序图的读法是由上到下,由左到右来读的,在书中讲的那个案例,当顾客去饭店吃饭时,顾客首先向服务员要菜单,而服务员将菜单给顾客,给菜单这个动作其实是对上一个动作的反馈,我们可以简化画法,而虚线箭头由服务员指向顾客,同时用文字表示反馈的内容,“反馈”需要些名词或者名词短语,而不是动宾得表达方式1.从复杂的流程中的分析出一条条流程,然后将每条流程按以下方法进行解析。2.分析出有什么角色参与到这个流程?3.分析各角色在流程中担任的职责和各角色的专业特色。4.将流程分解为角色之间的交互,想清楚各角色之间的“接口”是怎样的。5.用顺序图将这些“交互”组织起来。6.在上述过程中,不断思考业务流程的合理性,是否可优化或重组。流程图,顾名思义,就是展示流程的图,只有对整个流程有了清晰的思路,才能找到系统需要做到事情,而流程图是这个找到的过程更加形象具体,不至于有大的纰漏;接下来的就是最常用、最不可缺少的用例图了。实际工作中,我们需要将需求调研中了解到的所有业务对象、人物等列出来,画出他们的关系,反复推敲,才能逐步得到合适的业务模型。所以,类图的实际显示让我们全面系统的了解到涉众之间的关系,若有错漏、冗余,也一目了然,减轻了需求分析的负担。

时间: 2024-08-08 12:38:54

《uml大战需求分析》阅读笔记03的相关文章

掌握需求过程阅读笔记01

掌握需求过程 第一章什么是需求 阅读笔记 我们为什么要进行需求呢? 这样是为了使效率更高,并且减少错误步骤所不必付出的代价. 在我们构造产品之前就要知道客户的需求是什么,大多数的组织都是通过系统分析来进行的,但是需求过程与系统分析并不是一回事,虽然他们之间有联系,但并不完全相同.除了系统分析以外,需求也是很有必要的.他可以对你的分析师生涯有更进一步的促进.当我们接触到一个新的产品时,业务事件和使用情况逐渐清晰了起来,系统分析可以对产品进行更清楚的建模,并为需求过程提供有价值的反馈.对需求的了解增

《敏捷软件需求》阅读笔记03

今天我阅读了<敏捷软件需求>的第三章<团队的敏捷需求>.在敏捷方式中,对需求工作的组织和对团队本身的组织不是彼此独立的.相反,敏捷团队是围绕需求进行组织的,以便优化代码的定义.构建与测试以及向终端用户交付价值的效率.敏捷团队的基本工作单位是用户故事,团队的目标是在迭代时间盒内,定义.构建和测试一定数量的用户故事,在迈向发布的过程中逐渐实现更大的价值.  对每个故事的实现可以采用相同的模式:定义故事.编写代码和测试用例.针对代码运行测试. 在每支敏捷项目团队中有三种角色:产品负责人.

掌握需求过程阅读笔记—2

通过对事件驱动的用况.网罗需求.功能性需求这三个章节的阅读.使我们明白了在事件的驱动用况上,我们需要通过一些经验法则来定义用况,发现合适的用况:在网罗需求上,我们最需要做的就是进我们的一切可能去罗列用户的需求,并能及时的与用户沟通交流,确保产品符合最新的要求:在功能性需求方面上我们应当明白它是因为产品的存在的根本原因而存在的需求,它描述的是产品的动作,并能够形成一份完整的尽量避免二异性的功能描述. 事件驱动的用况是业务实践相应(活动和数据)的一部分,这些事件响应有产品来执行.用况成为了需求的锚,

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

我们都知道要站在用户的角度考虑问题,可是作为用户的我们也是存在思考的缺口的,那些根深蒂固的东西会使我们忘记了它们的存在,这就是未意识到的需求.还有未梦想过的需求,我们习惯了类似软件拥有的功能,未曾想过一些新的功能,在我们看来,技术还没有成熟.作为软件工程师,我们一定要在初期让这种需求浮现出来,否则后续阶段发现会付出太多代价. 开始阶段我们会画上下文范围图,输入输出流表示数据的流向,如果画图过程中有不知去向何处的数据流,那正是我们需要向用户询问的地方.需求调研是主动的,用户在工作的时候才能精确描述

《探索需求》阅读笔记二

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

《探索需求》阅读笔记一

这本书主要讲述关于开发项目的问题,讨论的主题是问题陈述或需求集合,需求在很多方面都是非常重要的.我们通常使用的是需求映射图而不是需求本身,所以我们需要探索许需求. 一旦在探索需求过程中使用了忽略了人的因素的工具,就不可能完美的描述需求,这会造成含混性,同时当需求被明确说明,但是使用了含混的词语也导致含混性问题的出现.含混性需要成本而且对于我们解决问题产生巨大影响,即可以发现需求含混性的重要性,所以在探索需求过程中要及时尽早地消除含混性,使用一些可以很好的抑制含混性的探索需求工具.许多含混性不一定

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

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

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

这次阅读的是这本书的第二部分,这部分内容相对较多,所以还没有看完.这部分介绍了一些文档的主要内容.首先是项目视图和范围文档的模板,书中一一介绍了这个文档中应该包括的内容.主要就是业务需求,项目视图的解决方案,范围和局限性,业务环境,产品成功的因素.所以,我们在做项目的时候,无论如何都要注意这个项目的范围,所想到的不要超出范围.有时候你感觉好的功能用户可能并不需要.所以,明白项目范围,并在范围内进行工作相当重要.我们所用到的需求基本全部来自于用户,获取用户需求的方式也相对较多,在获取某用户群体的需

构建之阅读笔记03

1.我认为在团队合作的过程中,编写程序之前,应该要首先规范命名,通过第四.五章我知道了,作为一个软件工程师不仅要有出色编程能力还要有对代码注释的意识,因为在团队工作中,你如果不注释你写的代码,那么当你有事,别人接手你的代码时,就会遇到很大的问题,他需要一点一点读懂你的代码,这会对团队的进程造成影响.我们还要在编写程序前先要对代码的命名和缩进等问题进行同一的规定,这样会使得团队的进程得到很快的发展. 2.在团队合作中,刚开始也许我们并不知道应该怎样进行合作,通常我们都是自己编程,没有和其他人合作的

《构建之法》阅读笔记03

我一直认为软件工程就是用很好的方法设计出很好的软件.那么这个过程从头到尾都要好好研究,然而刚开始的阶段并不是软件开发的开端,而是对用户的需求分析,是想,如果我们都没有把用户内心里真正想要的东西搞清楚,怎么能够开发出来令用户满意的软件呢? 软件的需求共有三类: 获取和引导需求:软件团队要找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 分析和定义需求:对各个方面的需求进行规整,定义需求的内涵,从各个角度将需求量化. 验证需求:软件团队用各种形式向用户验证软件团队对需求