IT帮需求工程公开课部分讲义

我发现身边学习EA的有些人/(大部分人)还未跳离IT思维,往往把业务分析和需求工程的工作就当做是业务架构了,所以我决定在业务域也开设一门关注实现级的课程,那就是「需求工程」。

目前国内学习EA的大部分还是IT人员,而且都/更加关注如何实现,所以经常看到大家在交流企业架构时,都会提到系统、开发等。在讲到数据架构时,往往会认为数据库的架构设计就是DA,而在讲到业务架构时,流程泳道图、组织结构图就是BA,围绕的都是IT系统的设计。企业架构的确应该是能顺接到系统开发的,但它绝对不是马上就到了软件系统级别。

IT帮这几年已经开设了不少课程,大部分都和实现无关。只有一个「数据建模」是和IT域实现有关的课程,而在业务域我只是一直和大家说到需求工程、业务分析、业务架构这条线。

我发现身边不少人还未跳离IT思维,往往把业务分析和需求工程的工作就当做是业务架构了,所以我决定在业务域也开设一门关注实现级的课程,那就是「需求工程」。

在需求工程学科中,我和大家推荐的是IREB。认识我的人都是知道,我不喜欢讲重复的东西。之所以开设需求工程这门课程,是因为IREB去年做了升级,我也没有在IT帮给大家讲过,所以决定开设这门课程。这样的话,上图中所示的从需求工程到业务分析,再到业务架构、企业架构在IT帮就都有对应的标准课程/实践课程了。

想要做好一件事,必须先了解这个事。想要做好需求工作,自然就得先了解需求是什么。我们先来自测一下,你给出下题的答案是什么呢?

不管是开发人员还是业务人员,每天都要面对需求,但是到底什么才算得上是新需求?需求有哪些种类?…… 我不知道有多少人能够说清楚。

IREB作为需求工程领域的一个标准,给了我们一些明确的定义。在新版中,我比较喜欢的一个地方是增加了9条原则。

需求工程目前主要还是在IT软件行业应用较多,主要目的就是把系统做出来,那系统的上下文、边界等概念的清晰对我们开发软件来说是至关重要的。

其中第5条原则中提到的问题、需求、解决方案是不可避免地交织在一起的三重因素和IT帮

BangBA中提到的需求公式息息相关

在RE@Agile中,对原则和实践也有专门的一页PPT进行讲解。如果上面的原则是我们要去遵守的,那有哪些实践/技术和活动是我们可以去做的呢。

在需求工程3.0的第三部分中,花了大量篇幅介绍第三部分,也就是在需求工作中的产出物。

如果是初次学习需求工程的同学,短时间学习这些会觉得信息量还是比较大的,这个也正常,因为作为方法学科,它并不会假定你使用特定的开发方法、特定的交付物,所以它会把软件开发中需求过程中一般都有哪些工作产物。

截取本周末的两张讲义,大家可以看到部分工作产物。熟悉敏捷开发和非敏捷开发的同学应该能看到里面的交付物是涉及不同的软件开发方法的,这对工作者对需求知识完整性是很有帮助的,否则在非敏捷方法工作的同学到了敏捷团队可能就不适应了,甚至会不接纳敏捷的做法。

前面我讲到,需求工程核心目的是帮助我们把系统做出来,所以它的工作产物和业务架构的产物是完全不一样的。

但是你会发现考虑的方面和架构还是能对应起来的。例如结构和数据在企业架构也是一个重要方面,但我们如果深入需求工程的具体产出物的时候,就会发现是不一样的了。

上面的产出物,可不要在业务架构中去使用。即使在业务分析方法中,在BangBA中,我们给出的一个参考产出也不会去做时序图,而是下图所示。

在业务架构中,产出物就有不一样了

工作产物是IREB内容最多的一个部分,其次就是需求细化实践了。

通过下图我们可以看到需求工程主要包括来源分析、获取、冲突解决和验证几个活动,在这个部分就是分别展开讲解这些内容。如果有了这些基本概念和技术之后,再来听BangBA实践课就更容易理解了。

内容太多,这部分就不多说了,截取两三张讲义吧

不得不说一下新加的第5部分:流程和工作结构。

这几年给企业做业务需求内训的也比较多。有不少企业会问到一个共同的问题,那就是他们的企业需求工作应该制定成什么流程?在BangBA中我们是不讲这个的,因为每个企业、每个项目都不一样,正如IREB所说的没有固定的需求流程。如果你想在自己的公式制定需求工作流程,那么可以借鉴这次课程的这部分内容作为设定的一个背后理论基础。

我在TOGAF认证公开课讲到ADM的需求管理中都会提到需求工程,ADM外环是需求开发,中心是需求管理。自然在需求工程课程中,需求管理也是必不可少。

我经常听到很多人抱怨TOGAF不落地,我总是和大家说,你需要补课。大家做到企业架构师级别,有些基础的概念和知识就应该是默认就懂的。但是我们也必须承认,大部分人其实还是不懂需求的,比如需求管理到底管什么?

如果上面的内容讲完了,我相信一定还会有人会问到工具的事情。

通过上面的内容基本就可以把完整的需求工程的掌握了。我自身也是敏捷教练,也比较推崇敏捷思想,另外考虑到目前敏捷方法比较流行,虽然上面的内容中已经包括了敏捷的产物等,我还是决定给大家补充一下需求工程和敏捷的结合。

这部分内容还是不少的。不过所有内容都设定为L1级,也就是了解就行。这个级别我觉得对于学习者来说是合适的。因为对于没有经验的同学可以了解概念,而对于有经验的同学可以把之前的工作经验做一次很好的梳理。

我自己有多年的传统开发和敏捷开发经验,通过这个方法的学习就帮我把一些方法工具做了一些整合。

具体内容也不说了,上几张讲义吧。

其中我觉得这张图把敏捷和非敏捷下的需求分解做了较好的表达

细心的同学会发现我的有些讲义左边是有蓝色侧边条的。我使用这个作为我补充内容的标识,例如下面这张就是来自SAFe的一个史诗描述。

不过没有这种边栏的讲义,也只是标题和蓝色底的文字是标准的而已,大部分图都是我做的补充,目的就是为了让学员能够更容易理解所学的内容,特别是对于刚学习的同学来说,这些补充我觉得还是有必要的。

以上为IT帮在需求工程学科做的分享概要介绍,也欢迎更多同学加入一起学习。

作者:周金根,一个在企业架构、业务分析、软件需求、敏捷研发、自我管理、创新思维等多个领域构建体系,并自在快乐、勇于践行的布道者。资深教练和培训讲师,致力于通过践行并持续完善IT帮体系方法,帮助客户激活面向未来的能力。

推 荐 导 读

更多文章

业务架构学习群资料

使用业务架构进行影响评估

我们已经知道业务架构包括一套业务元素,而且这些元素不是孤立存在的,它们之间有映射关系,可以表达企业的整体生态。影响评估分析海报给了一个简单表达,能让我们大致了解一下如何开展影响评估工作。哪个先做哪个后做呢?虽然没有固定顺序,以及必须完全分析一遍,但有一个步骤还是能够让初学者建立一个概念。

阅读更多»