用例
adwu73
这个作者很懒,什么都没留下…
展开
-
需求工程系列(一)- 软件需求的困境 - 分析代替了需求
十年来国内软件工程方面的进展有目共睹,在软件需求方面,我们看到在大多数组织中已经建立起了一级或两级需求体系(业务需求和软件需求);在某些组织中,需求分析员已经成为一种专门的职位;甚至在某个大型国有商业银行已经成立一个专门的部门来负责需求分析工作。应该来说,这是一些非常可喜的进步。 然而,目前大多数的项目参与者都对需求工程的现状不满,这又是为什么呢?首先,我们必须承认市场快速变化而带来的需求原创 2008-07-13 22:09:00 · 8543 阅读 · 16 评论 -
吴穹博士谈:《运用UseCase方法来沟通需求》
周六的活动,感兴趣的朋友可以来参加http://news.csdn.net/n/20090407/124580.html Use Case是软件产品经理(或者系统需求分析师)的必备利器。二十年来,Use Case的基础概念和技术都没有改变,但Use Case技能的培养,则是软件开发人员适用未来任何软件系统开发的需要。由UseCase方法论的发明者Ivar Jacobson创立的原创 2009-04-23 10:19:00 · 4465 阅读 · 0 评论 -
用例、用户故事、特性的异同和关系(一)
在最近的咨询过程中,经常有客户问到“用户故事和用例是什么关系?”、“用户故事是不是取代了用例?”、“什么时候用用例、什么时候用用户故事?”、“特性和用例是什么关系?”。以下把我的想法整理了一下,首先先驳斥一些观点吧: 错误观点1:用户故事会取代用例;如Martin在他的博客中所说的,用户故事和用例都是组织需求的方式,只是目的不同而已,用例的目的是为了把需求描述清楚,而用户故事的目的是把原创 2009-02-18 13:56:00 · 7167 阅读 · 2 评论 -
需求工程系列(七)- 如何编写用例的前置条件
在最近的咨询过程中,经常遇到客户提出这样的问题:应该为用例编写什么样的前置条件呢?Wikipedia里面是这样定义的:A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below)原创 2008-11-02 21:49:00 · 8246 阅读 · 1 评论 -
只需要一份需求
这两个月来,主要都是在进行和需求相关的培训和咨询,我发现在行业里一个根深蒂固的认识是需要/可以存在多份不同格式的分立的需求文档:业务人员可以写一份意识流的业务(客户)需求文档,开发人员可以在再写一份充斥着分析结果及IT术语的软件(软件)需求,测试人员则可以写一份闭门造车的测试需求。好像每个人都很好的完成了任务,但是谁来保证这些需求的一致性呢?我们有很好的答案—请业务人员确认他们看不懂的软件需求,原创 2008-10-18 08:29:00 · 2753 阅读 · 7 评论 -
需求工程系列(六)- 在已有系统改造中如何使用用例技术
目前大多数用户的开发都是对现有系统的升级和改造,在这样的情况下还能使用用例技术吗?很幸运答案是肯定的,你可以按照以下步骤进行:1. 确定系统边界:通过标识Actor来定义系统边界; 2. 重构用例模型:简要地捕获和描述现有系统的用例模型;3. 扩展用例模型补充用例规约:根据系统的升级和改造要求,增加新的用例或对已有用例进行扩展;在对现有用原创 2008-08-24 22:54:00 · 2481 阅读 · 1 评论 -
需求工程系列(五)- 确定用例的粒度几个基本原则
用例的粒度问题一直是困扰着需求分析员的常见问题,对于这个问题,抱歉,没有银弹,我只能给出一些解决这个问题的基本原则:1. 控制用例的总体数量:一般来说,一个相当复杂的系统的用例数量可能在30-50个之间,如果一个系统的用例数量大大超过了这一范围,那就该看看是不是陷入了功能分解的误区;2. 高内聚、低耦合:用例是一种结构化写作需求的技术,用例是被从现实的场景中原创 2008-08-18 21:44:00 · 3552 阅读 · 4 评论 -
需求工程系列(四)- 用例基本与UML“无关”
最近在与用户的沟通过程中,发现用户经常会认为用例是一种基于图形描述或UML的方法,从而质疑用例是否能够有足够的描述能力,或者用例是否易于被业务人员理解。其实,这是对用例的另一种典型的误解。 在用例模型中,的确会用到一些UML的图符(一个小人代表Actor,一个椭圆代表Use Case,等等),但这些图符是非常容易理解的。而且用例的主要信息是在需求规约当中,用例模型传递的信息可能只占所有相关原创 2008-08-03 14:41:00 · 2459 阅读 · 1 评论 -
需求工程系列(三)- 对用例的典型误用 - 功能分解
用例是一个门槛很低的技术,任何人都可以随便画几个小人和几个椭圆,然后向全世界宣称我在用用例进行需求建模了,但是好像也没有真正解决我的问题。在这种情况下,用例技术很可能被误用了。在对用例不同类型的误用之中,最严重、最普遍的莫过于利用用例来进行功能分解了。刚在为了偷懒,想找张现成的错误使用用例的例子,结果找的了2001年Kurt写的在这方面的文章以及最近一位老兄在CSDN上给出的翻译(已经收藏在我的网原创 2008-07-27 21:34:00 · 2636 阅读 · 1 评论 -
需求工程系列(二)- 基于用例的需求管理框架
为了解决前文所述的软件需求困境,我们首先需要找到一种可以被各方真正理解和沟通、并可以被逐步精化的需求体系。我认为,这种体系应该是基于用例(usecase)的。 首先,让我们仔细研究一下用例的定义:一个用例抽象了目标系统在现实中将执行的一组场景(每个场景由一系列动作组成);这些场景会产生一个对某个Actor有价值的、可观测的结果; 在这个定义中,我们强调了两件事情:一、用例是被原创 2008-07-20 21:09:00 · 2911 阅读 · 2 评论 -
解读敏捷需求分析五大关键因素
<br />大多数学计算机语言的人都会有过这样的感受,过去一直认为编程和架构是整个软件生命周期里最了不起的部分,但实际工作后才会发现在商业产品里,需求分析才是一个商业软件成功与否的关键。<br />放眼望去,在当今软件工程领域出现的许多问题,诸如缺陷及资源运用不当,都源于需求的不清晰,甚至有软件人戏称:“需求变更乃万恶之源”,一时也获得了颇多响应。时至如今,业务IT间需求分析过程中存在的问题主要有哪些?什么是敏捷需求分析?产品级和项目级需求有何异同?敏捷需求分析方法论中的五大关键点是什么?就以上热点话题,雅原创 2011-04-28 08:36:00 · 2851 阅读 · 7 评论