基于SysML的需求管理
什么是SysML
对象管理组织OMG 决定在对UML2.0 的子集进行重用和扩展的基础上,提出一种新的系统建模语言——SysML(Systems Modeling Language),作为系统工程的标准建模语言。和UML 用来统一软件工程中使用的建模语言一样,SysML 的目的是统一系统工程中使用的建模语言。
相信大家都听说过UML。
呃,没听说过的自己去度娘学习一下。
SysML是基于UML扩展而来用于系统工程领域的一种图形化语言。
什么是需求管理
平常我们提到的比较多的是“需求分析”,对于这个概念大家应该很熟悉了。
而同样作为“需求工程”的组成部分之一,“需求管理”却很少被提及。
其实,我提到几个需求管理的工具,大家就明白需求管理是干嘛的了。
需求矩阵、禅道、DOORS、QC……
需求管理就是管理需求,包括需求的定义、变更、追踪、验证、关系维护等。
需求管理的现状与问题
一般做需求的小伙伴,入门接触的是“需求分析”,待做到一定的程度后,就会开始或多或少的接触到“需求管理”了。
我们都承认需求变更是不可避免的。
而一个需求的变更可能会是“牵一发而动全身”的。
如何分析评估需求变更的影响程度、影响面是一项难题。
而我们尽自己所能,可以做到的是管理需求的验证过程。
而当需求发生变更后,相应的验证脚本等也需要随之变更。
如果一个产品的需求比较少,还好。
凭借你高超的记忆力和逻辑思考能力,拍拍脑袋可以分析出需求之间的关联影响。
当需求非常多,并且变更频繁时,单靠人脑,这简直就成了mission impossible。
为什么用SysML
其实提到SysML,不得不提另外一个概念:系统功能。
更准确的说是:基于模型的系统工程(MBSE)。
问问看文的小伙伴,大家是用什么方法记录和阐述需求的呢?
现在常见的是两种方式:
- Word版的SRS(需求规格说明书)
- 原型+注释
那么当需求变更,你们怎么处理呢?
因为我是使用SRS的,所以我会用修订功能进行记录。
(这个部分之前写过一篇文,关于如何使用修订功能记录需求的,如果找不到的小伙伴可以给我留言)
但是,请注意,你这个时候仅仅是记录,影响程度和影响面并没有办法进行管理。
这就是使用文档(原型其实也是文档的一种)的方式进行需求管理的最大弊端,因为它并不是结构化的。
所以需求管理软件,如DOORS,做的事情就是将需求进行结构化,然后再自动拼接生成需求规格说明书。
MBSE中的需求管理与DOORS的理念一致。
即管理的不是文字,而是需求模型。
将需求对象化处理成模型,建立之间的关系,方便管理和追踪。
熟悉面向对象的设计方法的话就知道,建模后对模型管理
而SysML是为MBSE服务的一种图形化语言。
SysML中有一种图形化预研叫做“需求图”,专门用来管理需求。
如何用SysML管理需求
SysML的需求图并不复杂,主要包括两个属性:ID和Text。
下面这张图就是一个示例,来自《SysML精粹》。
这张图上表述了几种需求的关系:
-
包含(十字剪头):可以理解为需求的分解
例:用户的信息管理包括:基本信息管理、个性化设置、关联账户信息管理 -
跟踪(trace):一个需求的变化会引起另外一个需求的变化
例:用户的积分管理规则的变化会引起用户使用权限的变化 -
继承(deriveReqt):一个需求继承另外一个需求与其他对象的关系
与包含不同的时,这个对象可能不是一个需求 -
改善(refine):对抽象需求的具象化处理
-
满足(satisfy):一个需求的实例会满足另外一个需求
-
验证(verify):将测试用例(可以是活动、交互或者状态图)与需求进行关联,表示用关联的测试用例可以验证这个需求
-
复制(copy)
SysML还提供了五种不同的需求标识方法。
上图是“直接标识法”,下面是另外四种标识法,来自《SysML精粹》。
基于SysML的需求管理
还有哪些需要注意的地方
我一直欠了一篇文,关于如何编写UserStory的。
提到这点是因为,如果你不将需求拆分到足够小的对象(原子需求),即便是用SysML也无法管理好需求。
最明显的一个例子是,有一个需求是管理用户信息。
有一个变更是针对用户信息中的隐私设置的,而如果你将隐私设置的部分和用户基本信息(账号等)放在一个需求里进行管理时,就无法很好的分析到影响。
所以,需要使用包含、继承等关系进行需求拆分并关联。
写在最后:
今天介绍了这个方法,建议大家可以尝试将自己产品的一部分需求拿出来做个尝试。
这类方法总会要求你在前期投入,后期的隐形回报是无穷的。
如果你在实践中有任何的问题、想法,欢迎和小婧进行交流。
小婧是一名行走在产品路上的资深业务分析师,如果想与我同行就请关注我吧!