基于SysML的需求管理

发表于:2017-3-14 11:19

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:颜小婧    来源:51Testing软件测试网采编

分享:
  什么是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精粹》。
 
  还有哪些需要注意的地方
  我一直欠了一篇文,关于如何编写UserStory的。
  提到这点是因为,如果你不将需求拆分到足够小的对象(原子需求),即便是用SysML也无法管理好需求。
  最明显的一个例子是,有一个需求是管理用户信息。
  有一个变更是针对用户信息中的隐私设置的,而如果你将隐私设置的部分和用户基本信息(账号等)放在一个需求里进行管理时,就无法很好的分析到影响。
  所以,需要使用包含、继承等关系进行需求拆分并关联。
  写在最后:
  今天介绍了这个方法,建议大家可以尝试将自己产品的一部分需求拿出来做个尝试。
  这类方法总会要求你在前期投入,后期的隐形回报是无穷的。
  如果你在实践中有任何的问题、想法,欢迎和我们进行交流。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号