基于SysML的需求管理.jpg
什么是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精粹》。
图片发自简书App
这张图上表述了几种需求的关系：
包含（十字剪头）：可以理解为需求的分解
例：用户的信息管理包括：基本信息管理、个性化设置、关联账户信息管理跟踪（trace）：一个需求的变化会引起另外一个需求的变化
例：用户的积分管理规则的变化会引起用户使用权限的变化继承（deriveReqt）：一个需求继承另外一个需求与其他对象的关系
与包含不同的时，这个对象可能不是一个需求改善（refine）：对抽象需求的具象化处理
满足（satisfy）：一个需求的实例会满足另外一个需求
验证（verify）：将测试用例（可以是活动、交互或者状态图）与需求进行关联，表示用关联的测试用例可以验证这个需求
复制（copy）
SysML还提供了五种不同的需求标识方法。
上图是“直接标识法”，下面是另外四种标识法，来自《SysML精粹》。
图片发自简书App
图片发自简书App
还有哪些需要注意的地方
我一直欠了一篇文，关于如何编写UserStory的。
提到这点是因为，如果你不将需求拆分到足够小的对象（原子需求），即便是用SysML也无法管理好需求。
最明显的一个例子是，有一个需求是管理用户信息。
有一个变更是针对用户信息中的隐私设置的，而如果你将隐私设置的部分和用户基本信息（账号等）放在一个需求里进行管理时，就无法很好的分析到影响。
所以，需要使用包含、继承等关系进行需求拆分并关联。
写在最后：
今天介绍了这个方法，建议大家可以尝试将自己产品的一部分需求拿出来做个尝试。
这类方法总会要求你在前期投入，后期的隐形回报是无穷的。
如果你在实践中有任何的问题、想法，欢迎和小婧进行交流。
小婧是一名行走在产品路上的资深业务分析师，如果想与我同行就请关注我吧！
