需求工程
文章平均质量分 73
zhangmike
这个作者很懒,什么都没留下…
展开
-
ExcelBDD Guideline By Java Example
01- Excel BDD Tool Specification By a simple and open ExcelBDD MethodThis tool is to get BDD test data from excel file, its requirent specification is belowThe Essential of this approach is obtaining multiple sets of test data, so when combined with原创 2021-06-24 22:29:01 · 427 阅读 · 2 评论 -
需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指软件开发的常见情境,本文选择如下来进行分析: 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审传统瀑布模型下的需求评审对传统瀑布模型现有需求评审的分析传统瀑布模型在需求阶段末期安排有关键的需求里程碑评审,其特征参见2.8节情况1。在业界实际操作中,往往出现如下情况: 1,召集包括领导在内的各方代表,历经1~2小原创 2016-06-09 10:21:08 · 14604 阅读 · 0 评论 -
需求评审五个维度框架分析及其带来的启示-4-需求条目化管理
需求条目化管理是指需求的主体分条目管理,比如对于用例、用户故事、特征点的条目化列表管理,有些工具中条目称为工作项(work item)。条目化管理的特征是1,状态流转实现工作流;2,条目属性字段可定制。3.3节所分析的敏捷开发下的需求绝大多数是已经实现了条目化管理,产品待办列表就是Scrum进行条目化管理的载体。而条目化需求管理并不是敏捷开发的专利,当前已经有不少组织在非敏捷环境下采用条目化需求管理原创 2016-06-09 10:29:04 · 9185 阅读 · 0 评论 -
需求评审五个维度框架分析及其带来的启示-5-结束语
本文整理归纳了需求评审的各种类型,分析识别了需求评审的5大关键方面,提出了五维需求评审框架,并分析验证了此新需求评审框架的有效性。结合此新需求评审框架,对软件开发主要情境进行了分析,得到了15个高效需求评审的启示,得到了结合需求条目化管理的多级小瀑布模型,这新瀑布模型也许将为陷入困局的传统瀑布模型打开一条新路。软件需求评审还有一些其他重要的方面,比如检查表和度量等等,本文限于篇幅不再更多分析,但值得原创 2016-06-09 10:31:11 · 5260 阅读 · 0 评论 -
User Story的常见困难
User Story已经在业内使用了多年,到目前为止,在与业界交流时,仍然存在着不少困难,试图列举下,再来看看解决方法。 常见的困难1:如何分拆故事? 往往故事来自于史诗,刚开始比较模糊,到后面发现有许多细节要处理,而一个迭代内来不及处理了,如果坚持一个故事在一个迭代内能够处理完,那么这个故事就要分拆。 分拆之后,2个故事是存在上下文关联的,如何保持关联追溯?常见的困难2:如何处理关联到以前故事的原创 2016-07-07 12:15:36 · 6501 阅读 · 0 评论 -
用户故事的扩展-新的故事类别
用户故事自最早1998年诞生以来,由于其突出的优点,到现在得到了广泛的应用。从最开始的克莱斯勒C3项目,用户故事当中的用户一般是指软件系统的人类用户,这类用户故事一般涉及人机交互界面。 而随着用户故事在多种场合扩展使用,慢慢衍生出另外两类故事。本文试图来整理下新的故事。新的故事1,系统故事 System Story 2,赋能故事 Enabler Story,也称推动者故事,或者使能故事 为什么不原创 2016-08-21 13:18:33 · 1776 阅读 · 0 评论 -
用户故事地图对应到Epic及其缺点
用户故事地图,提供了2维的角度来分析用户故事,直观,更加有利于优先级的表达。 在理解用户故事地图时,需要注意其作者的用词跟一般的用户故事不一致,因此要注意跟普通的用户故事用词之间的对应关系。 推荐一般理解如下: 一幅用户故事地图展现1个史诗Epic User Acitivites(Backbone)行,可以理解为对史诗Epic的一级功能分解 User Tasks(原创 2016-09-02 08:25:31 · 4504 阅读 · 0 评论 -
写好用户故事的10个提示
用户故事可能是在捕获产品功能方面流传最广泛的敏捷实践。 利用用户故事来工作是容易的,但是讲述有效故事却是有困难的。 如下的10个提示能帮助到写好用户故事。1 用户先来如同名字所说明,一个用户故事描述了一个顾客或者一个用户如何使用产品;它是从用户角度来翻译 2016-08-13 12:37:17 · 3945 阅读 · 0 评论 -
用户故事的简要历史
【说明:敏捷类实践大都集中在最近20年出现,但变化很快,通过了解变化的历史,可以更好得理解趋势和当前为什么要这样。正因为此,笔者试图整理了用户故事的历史,所费时间不多,错漏难免,请大家点评,纠正补充,进而得到更加全面准确的记录】1998年,用户故事首次提出。 用户故事的起源是来自与XP极限编程的计划游戏环节,据现在能够追查的记录,最早是在1998年这样提到“用户故事”的:客户通过用户故事(像用例)原创 2016-08-14 12:27:41 · 2850 阅读 · 0 评论 -
用户故事之好标题
在利用电子工具的情况下,经典的用户故事句型的长度是超出电子工具的标题栏,而且标题过长,也难以让读者最快的抓住用户故事的重点。因此在电子工具的情况下,需要探索更短更好的用户故事标题写法。 用户故事的标题希望达到的效果是能够让读者快速了解这个用户故事的要点和大致范围。常见的做法有: 1. 从用户角度提炼动宾短语; 1. 从系统角度提炼动宾短语; 1. 主谓宾齐备写法1:用户角度的动宾短语样例:新原创 2016-08-14 18:37:51 · 3894 阅读 · 0 评论 -
产品待办列表如何精化?
Scrum中安排了精化活动,早期版本的英文是Grooming, 现在是Refinement,原来翻译为细化,最新版Scrum Guide中文版采用了“精化”。最新Scrum是这样说明精化的。产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续的过程,产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精化过程中,产品待办列表项被重新评审和修改。Scrum原创 2016-09-20 07:37:31 · 1608 阅读 · 0 评论 -
系统故事 --- 让系统讲故事
用户故事自最早1998年诞生以来,由于其突出的优点,到现在得到了广泛的应用。一般而言,用户故事里面的用户是人类用户,用户故事在表达人类用户与系统的交互方面已经证明了其有效性。 那么当处理系统之间交互时,我们能不能参照用户故事来说明系统交互的需求? 让系统来讲讲故事? 这样的故事不妨称之为系统故事。 微博上有朋友形象的说这是瓦力和伊娃之间的故事。原创 2016-10-09 14:32:55 · 3975 阅读 · 0 评论 -
讲故事的用户故事样例之1
曾几何时开始,用户故事的写法成了 用户故事经典句式+验收条件。 在https://blog.versionone.com/agile-acceptance-criteria/ 上提供了如下一个故事的样例。As an executive, I want to be able to filter the dashboard by department so that I can isolate dat原创 2016-12-21 08:22:26 · 5464 阅读 · 0 评论 -
让用户故事真的像故事那样
早期用户故事写在卡片上,只需一个句子。随着越来越多的系统和产品采用敏捷开发,对于有些复杂长生命周期的系统和产品而言,用户故事的内容值得积累,以便后续追查和修改。另外一个情形是为了确保用户故事真的完成,需要在前期就明确其验收条件(也翻译为接收条件),因此曾几何时开始,用户故事的写法成了 用户故事经典句式+验收条件。原创 2017-06-23 18:00:51 · 915 阅读 · 0 评论 -
敏捷DoD和DoR的多种形态
关于Definition of Done 完成的定义DoD在以往的说法中,常见用 退出标准 , 完成条件,成功标准,等等典型的是迭代的DoD,这也是最初DoD应用的地方。 常见在Scrum中,需要预先定义DoD。常见的迭代DoD条款1,所有完成的用户故事得到PO的验证2,所有代码得到静态分析,纠正最高级别的不符合项,静态分析的规则参见…3,所有新增代码得到人工评审4,所有完成的用户故...原创 2018-10-02 13:56:39 · 16363 阅读 · 1 评论 -
需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法,全面涵盖系统性评审和非系统性评审,提出五维需求评审框架。首先确定对于需求评审的定义,结合传统需求阶段评审和敏捷迭代开发中相关需求实践,得如下定义。 定义1(需求评审). 需求评审是指基于需求文档阅读或者观察软件运行并且对当期工作有时效性的人工检查。根据以上定义,需求评审的范畴不包括机器自动检查,不包括需求审计;包括了需求上线后的校对,包括了系统性需求评原创 2016-06-09 10:07:38 · 5827 阅读 · 1 评论 -
需求评审五个维度框架分析及其带来的启示-总起
摘要 近年来随着CMMI、敏捷软件开发的推进,出现了多种多样的需求评审类型,这些类型超出了标准评审类型的范围。根据这些情况进行分析,得到了一个新的软件需求评审框架,这个新框架由5个维度组成: 1,组织形式;2,时机;3,侧重;4,评审者;5,对象 分析了分别在传统开发和敏捷开发下的典型需求评审情境,显示新框架能够适用于所有系统性的和非系统性的评审类型上。从分析中得到了15个有价值的启示。新需求评原创 2016-06-09 09:42:51 · 6682 阅读 · 0 评论 -
需求用例分析之四:业务规则
在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有“业务规则”的属性,在科伯恩方法中有个相近的属性是约束条件。但是业界使用中常常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢?从时间和传播上很容易推断,业务规则的来源是传统的需求规格说明书。在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是其中核心的分析产物。受到传统需求规格说明书的原创 2014-05-24 21:01:05 · 19816 阅读 · 0 评论 -
需求用例分析之九:序列图
作者:张克强 作者微博:张克强-敏捷307序列图,也称时序图、顺序图,英文名Sequence Diagram。在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图。而科伯恩用例分析方法以结构化/半结构化文本用例为中心,强调基于目标的文本格式,对UML各类图所提甚少。在RUP和OOAD中,UML序列图的最基本定位是用于识别类与类之间的信息传递,是识别类的方法的最佳场合。它是原创 2014-06-25 21:00:20 · 5414 阅读 · 0 评论 -
Agile Use Cases in Four Steps
Use Cases in an Agile Backlogby Matt TerskiA question I’ve been asked a lot lately is, “How do I make use cases work in an agile setting?” I found myself struggling for an answer because a) agile is a转载 2014-06-26 06:20:06 · 1645 阅读 · 0 评论 -
需求用例分析之七:业务用例之小结
作者:张克强 作者微博:张克强-敏捷307RUP虽然对于业务对象建模进行了详细的说明,但其本身并没有把业务对象建模(领域模型)、业务用例作为必须的工件。Rational系方法把业务用例作为需求规格说明(SRS)前的推荐工件。 在《编写有效用例》中,业务用例被放在很次要的位置,前面提到云朵和风筝时,科伯恩并没有清晰的指出这是业务用例,相反的还是在系统范围内讨论用例。而且科原创 2014-06-08 11:43:40 · 4874 阅读 · 0 评论 -
需求用例分析之五:业务用例之Rational系
业务用例的定义:"业务用例从一个外部的,增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值,业务用例是超越组织边界的业务过程,很可能包括合作伙伴和供应商。" 围绕着业务用例的使用起源于RUP,后续虽然有演化,仍然有明显的RUP痕迹,后续配套手段需要UML工具支撑,后续可以关联到了类和类图。相关于业务用例的术语在RUP中有:业务用例,业务用例实例,业务用例实现,业务角色,业务实体,具体业务用例,抽象业务用例,业务流程,业务参与者和业务执行者等等。除了搞需求方法论研究的人(比如笔者),谁还能分辨其中原创 2014-06-02 21:35:14 · 4089 阅读 · 0 评论 -
需求用例分析之三:补充规约
补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求。这些需求包括: § 法律法规方面的需求和应用标准。§ 要建立的系统质量属性,包括可用性需求、可靠性需求、性能需求和可支持性需求。§ 其他需求,诸如操作系统和操作环境、兼容性需求以及设计约束。补充规约是对用例模型的重要补充。补充规约和用例模型应该一起获取对系统的一整套需求。通过以上文字可以知道,补充规约是原创 2014-05-18 20:26:02 · 6494 阅读 · 0 评论 -
需求文档可以不签字吗之二-理论推导
怎么可能在没有需求文档的情况下,把软件开发出来?完全有可能。回想下当年读书的教研组,回想下自己的编程经历,总有至少那么几次,在种种的原因下,在没有需求文档的情况下,软件已经编写好了。也许那个软件规模小些,质量不是太好,但确实是没有需求文档的情况下把它编了出来。所以没有需求文档是可以把软件开发出来的。为了保证这样的软件达到要求,显然需要另外的手段。笔者认为最要紧的手段是快速地将运行的软件给用户试用或原创 2015-01-12 21:21:09 · 1647 阅读 · 0 评论 -
需求文档可以不签字吗? 之一
在软件开发中,需求分析和需求管理一直被认为是软件开发成功与否的关键。在CMMI中,需求管理是CMMI2级的过程域,需求开发是CMMI3级的过程域。在瀑布型生命周期当中,安排了需求分析阶段,一般也安排需求分析里程碑评审。瀑布型生命周期存在了很多年,曾经几度写入到软件开发的国际标准、国家标准当中。由于瀑布型生命周期如瀑布般顺流而下,在设计阶段开始后,根据需求文档的结果来开展工作,要求需求文档的结果比较原创 2015-01-12 21:15:38 · 2779 阅读 · 0 评论 -
需求文档可以不签字吗之三-一个实例
AB公司试图管理自主产品的许可证发布,保障软件不被盗版,并进行统计,要利用已经有的AI系统扩充这部分功能。新功能主要分成2块:1,产品管理,2,许可证发布在产品管理里主要维护产品和产品版本的信息。许可证发布中,根据已经有的产品版本来申请许可证,产品开发部门审批后,IM系统能够自动生成许可证。为了开发这部分功能,在2010年,项目组首先书写了长达86页的《产品管理模块功能需求规格书》,历经了2次会议原创 2015-01-12 21:24:25 · 1900 阅读 · 2 评论 -
在“软件工程:研究与实践”研讨会上关于UML Use-Case的开放空间讨论
2014年12月20日我有幸参加了复旦大学承办的“软件工程:研究与实践”研讨会。在下午的开放空间活动中,我推荐了UML Use-Case作为6个话题之一,成为了这个话题的主持人。就这个话题与多位老师和业界专家进行了探讨。最后我作为此话题的代表向大家汇报了话题讨论。本文试图来整理记录下当时的讨论。1,在产业界UML和Use Case并没有得到很广泛的使用,能够用Use Case表达出原来SRS表达的原创 2015-01-02 10:56:49 · 2071 阅读 · 1 评论 -
说说#条目化需求#
之1:需求不再是传统的SRS文档,而是一条一条的,能够逐条查询,编辑,修改,状态跟踪。比如scrum提出的Backlog中的user story。之2: 需求条目的层级划分,一级的划分往往是不够的。第一级需求往往收集原始需求素材,难以控制其范围和规模,所以不便于直接开发;第二级需求经过第一级的过滤整理,适合提供给程序开发。在敏捷里常见划分出epic和story,在cmmi中分成了客户需求,产品需求原创 2015-03-28 17:02:02 · 6710 阅读 · 0 评论 -
说说长篇文档的评审
对于长篇文档的评审,其实结果是很滑稽的,往往是通过稍作修改。很少有不通过的。而稍作修改就是随便改改。最终文档质量是没有保障的。因此现在条目化文档处理成为了新常态。比如需求是分条起草并评审的,通过就是通过。 diabloneo:确实是这样,我还没遇到完全重写文档的情况因此,有效评审长篇文档的办法就是把长篇文档拆短。需求被分解为小颗粒度的条目,请产品经理或者产品主管逐条确定,让各方理解。us原创 2015-03-28 17:14:26 · 1440 阅读 · 0 评论 -
软件需求分层处理的多种常见方式
当前的需求 常见分 几个层次来管理? 原先的SRS只有一个层次,在瀑布型生命周期中发挥了重要作用,需求里程碑评审和需求变更管理都是围绕着SRS来进行的。随着时间推移,瀑布型生命周期的弊端越来越明显,而瀑布型生命周期的需求管理是首先被改进的。一个明显的趋势是不再只有SRS,而是分多个层次来分析需求,进而开展需求管理。目前,业界出现了多种需求层次划分方式,本文来列举下。原创 2015-10-31 07:36:05 · 3921 阅读 · 2 评论 -
关于敏捷规划的微信对话
敏捷 规划会议 看板原创 2015-10-07 10:55:21 · 1774 阅读 · 2 评论 -
需求用例分析之一:异常流
问题的引出备选流,又称备选事件流,英文是Alternative Flow。在RUP和UML中,备选流的解释如下:备选事件流包括与正常行为相关的可选或异常特征的行为,同时也包括正常行为的各种变形。您可以将备选事件流看作是基本事件流的“绕行道”,有些备选事件流将返回到基本事件流,而有些将结束此用例的执行。 分析RUP对于备选流的定义,可以看到备选流可以分成两类:1,不同做法但仍然达成用原创 2014-05-03 14:54:30 · 15039 阅读 · 0 评论