码迷,mamicode.com
首页 > 其他好文 > 详细

《UML大战需求分析》-读后感一

时间:2015-11-15 20:46:05      阅读:217      评论:0      收藏:0      [点我收藏+]

标签:

可以用图表来突出设计范围,用适当的图标来标注每一个用例从而可以轻易的了解其范围,使用范围来确定工作产品,在Acura系统Dev用例中有业务用例和企业用例而该系统不会咋爱工作站和服务器范围内编写任何用例,因为这不是应该关心的,用例总是在一个设计范围内进行编写,这里就涉及到如何找这个范围的临界点构思陈述,设计范围图,‘内/外’列表,执行者-目标列表决定了系统的范围,这四个就是密不可分的工作产品。
用例的主执行者在收集工作刚开始时和系统将要发布之前的一段时间内是重要的,二在这两个时间段之间他们是不重要的“....詹妮站在银行的ATM机前,天色很晚。她已经输入她的PIN,正在寻找确认按钮.....”,主执行者是詹妮,目标是在天色黑的情况下很快找到ATM机的确认按钮。
    执行者的范围可以从系统的项目相关人员,用例的主执行者,被设计系统本身,用例的辅助执行者,内部执行者,在例子中公司没有注意系统的项目相关人员,导致系统没有提供完全的服务修改请求蜂拥而至。朱执行者是直接触发用例的执行者组织人或者是和该组织有关系的人,通过这些来描述用户主要场景,与我自己认知不同的是我认为用例必须用用例图来表示,不过语言文本的表示也是挺清晰的,一个编写良好的用例应该具有可读性,无论是业务人员还是软硬件开发人员还是设计人员都可以通过用例来描述需求,关接下来范围是指真正被讨论的系统是什么,主执行者谁有药实现的需求,层次指目标的高低,主成功场景一切都成功的情况下,在第一个一个人准备通过万维网购买股票的情况中这个用例应该是一次处理就能完成的目标处于用户级的目标而第二个则不能从一次中完成,需要多不的处理显然处于概要的目标,两个用例的共同之处有最小保证和成功场景和扩展场景扩展是执行过程中可能遇到的意外情况于用例黑盒子就是不用太关心具体的细节,说的挺对不同的方法适用于不同环境,软件的规模不同对用例的正规程度的要求也是不同的,正规的就按用例模式一项项添加场景,定义,而非完整的是只就场景进行描述,从用例中可以看出部分或者说是主要的需求,用例的目的原来是针对用户,让用户提前知道新系统是什么样的对于可行的需求大纲包括目的和范围、使用的术语、用例等等其中的目的和范围有整体的范围和目标是什么?项目的相关人员?什么在系统之内?什么在系统之外,关于用

《UML大战需求分析》-读后感一

标签:

原文地址:http://www.cnblogs.com/xizhenghe/p/4967245.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!