0°

BABOK Guide3.0(7.1) Specify and Model Requirements

Purpose


The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation results into requirements and designs. 


在BABOK中,所有的任务都被细化和拆分了。

有的时候我们在做一件事情的时候,会忽视很多细节,感觉稀里糊涂的就做完了。


在面对BABOK提到的任务时,我们需要进行细化和拆分。

其实大部分情况下,我们会将整个第7章作为一个任务,就是为下一步的实施、开发做准备。

BABOK想要搭建一个可执行的指导的框架,所以将这个任务拆分成了比较细的6个步骤。


我个人觉得在实际的工作中,你不一定要很严格的串联执行,毕竟这也是BABOK所强调的:任务的无序性。

但是有这样的整体的框架,在指导你进行需求分析以及解决方案定义评估时,可以更加有理有据。


第七章的第一个任务,就是进行需求的建模。

后面会提到,这里的输入其实是第四章的,需求获取的结果。


Description


Specify and Model Requirements describes the practices for analyzing elicitation results and creating representations of those results.


之前我们提到过需求和设计的区别。

其实在这个任务中,你会发现,当你聚焦在为Need进行建模分析时,输出的产物往往就是需求;而当你聚焦在为解决方案进行建模时,输出的产品就是设计。


简单的来说,你通过画活动图进行业务流程建模。

如果你的流程图是纯业务的,针对用户的需求做出的业务流程改善,那么这个就是需求的建模。

而如果你结合了系统实现,比如什么环节应该出一份报告或者日志,有哪些具体的字段需要传递,那么这个就是设计的建模。


更明显的例子在用例图上。

需求的用例建模是纯业务的,对象也是纯业务的。

只有设计的建模才会有CURD(增删改查)。


BABOK Guide3.0(7.1) Specify and Model Requirements



Inputs


• Elicitation Results (any state)


modelling can begin with any elicitation result and may lead to the need for more elicitation to clarify or expand upon requirements. Elicitation and modelling may occur sequentially, iteratively, or concurrently.


收集的信息将作为建模的输入,其实这是一个循环迭代的过程。

因为你根据目前的信息进行建模后,会获得新的疑问或者信息,再进行获取后,再次建模。

逐步深入的进行获取及建模,能够让需求和真正需要解决的问题浮出水面。


Elements


Model Requirements


模型是一种工具,是用来描述信息并且为分析、沟通以及理解提供便利的手段。

模型也会被用于进行信息确认,定义并复用信息。


我们经常用的模型包括以下几种:

• Matrices 矩阵

a matrix is used when the business analyst is modelling a requirement or set of requirements that have a complex but uniform structure, which can be broken down into elements that apply to every entry in the table.


矩阵其实我们经常看到并且使用。

最常见的就是需求矩阵,数据字典以及角色权限矩阵。

另外我们也会用矩阵进行差异分析,比如一个品牌不同款汽车的配置比较。


• Diagrams图

有一句话叫做“一图胜千言”,很多信息你用问题罗里吧嗦的说了一大段,其实完全不如一张图来的直接和清晰。

这也是为什么我会推荐大家使用UML之类的工具。

当然面向对象的分析方法是一个方面,另外一个方面是图更加的直观,减少歧义。


针对UML的不同的图的不同用途,大家感兴趣的话可以看一些UML的相关书籍进行了解,比如《UML精粹》。



我们一般进行建模的时候,其实会综合使用文字、图、表格。

这其实是一种横向的划分,针对使用工具的划分。



而针对建模的内容,我们可以有纵向的划分,包括:

• People and Roles

用于描述人和角色的建模工具有很多,比如组织结构建模、角色权限矩阵、干系人清单、干系人地图等等。


• Rationale

用来进行“WHY”的分析,包括:决策模型、范围模型以及根因分析等。


• Activity Flow

这是我们比较熟悉的一个部分——活动流程。

之前有小伙伴留言问:Visio里面的跨职能流程图、UML的活动图和数据流图有什么异同。

其实,区别并不大,特别是跨职能流程图和活动图,你完全可以视为同一个东西。

只是看你想要描述和分析的内容是什么。


比如你需要进行更细节的设计,用户通过一个按钮触发后台一系列的数据交互。

那这个时候用数据流图会更合适,因为它强调的是数据和信息的交互。

而跨职能流程图和活动图强调的是业务、角色的参与。


类似的建模还有:用例、用户故事。

这里的用例不是用例图,请注意。


• Capability

所谓能力也就是你的解决方案有什么样的能力和功能,涉及到的建模包括:能力模型、功能分解以及原型。


• Data and Information

针对数据和信息,除了上文提到的数据流图,还有很多我们耳熟能详的工具包括:数据字典、状态模型以及接口分析等。


Analyze Requirements


在进行需求分析的时候,重点是“挖掘”。

所以,请挖,请深挖。


• anything that must change to meet the business need

• anything that should stay the same to meet the business need

• missing components

• unnecessary components

• any constraints or assumptions that impact the components


在这个阶段的重点是达成一致,也就是说,我们通过与各类干系人的沟通、讨论,最终达成对于需求理解上的一致。

有的人可能会有疑问,不是之前在信息获取的时候就达成一致了吗?

要知道我们在这个过程中参与的干系人不仅仅是业务方,还包括开发实施方的干系人。

就算是业务方,也不妨碍在我们进行深挖的过程中有更加细节的部分需要与其讨论并达成一致的。


Represent Requirements and Attributes


这个阶段我们可以对一些重要对象进行属性的分析和确认。

这些属性我的理解还是一些关键属性。


以前有人问过我,我怎么知道针对一个对象需要哪些属性。

我觉得其实你可以从两个方面进行属性的筛选和定义。


一个是报表需求。

出报表就一定要有数据,数据哪里来的,肯定是一些属性的直接值或者间接(比如计算)值。


另外一个就是其他需求。

比如建立的关系表,两个对象怎么建立关系,通过什么属性进行关系的建立等等。


Implement the Appropriate Levels of Abstraction


很多人都知道我一致提倡面向对象的分析方法,那么必备的技能就是抽象。

抽象这个词本身就很抽象。


之前在研究DDD的时候,被所谓的充血模型和贫血模型弄的头晕脑涨,但是不妨碍我去更深的理解抽象的level。

没错,抽象是有level的。


比如对角色的抽象。

不管你是用枚举、头脑风暴还是用户画像、虚拟用户的方法,你总能得到一大串的用户角色列表。

但是真正分析和设计的时候我们不可能针对每个人都进行分析和设计。

那就不是产品也不是可以使用的软件了,而是针对每个人的个性化定制。

所以我们需要抽象,分析角色的共同点,结合需求和建设目标进行抽象。


所以,抽象的level是与需求相关的,太细了不好,太粗了也不好。


Guidelines and Tools


• Modelling Notations/Standards

• Modelling Tools

• Requirements Architecture

• Requirements Life Cycle Management Tools

• Solution Scope


Techniques


• Acceptance and Evaluation Criteria

• Business Capability Analysis

• Business Model Canvas

• Business Rules Analysis

• Concept Modelling

• Data Dictionary

• Data Flow Diagrams

• Data Modelling

• Decision Modelling

• Functional Decomposition

• Glossary

• Interface Analysis

• Non-Functional Requirements Analysis

• Organizational Modelling

• Process Modelling

• Prototyping

• Roles and Permissions Matrix

• Root Cause Analysis

• Scope Modelling

• Sequence Diagrams

• Stakeholder List, Map, or Personas

• State Modelling

• Use Cases and Scenarios

• User Stories



Stakeholders


• Any stakeholder:

business analysts may choose to perform this task themselves and then separately package and communicate the requirements to stakeholders for their review and approval, or they might choose to invite some or all stakeholders to participate in this task.



Outputs


• Requirements (specified and modelled)

any combination of requirements and/or designs in the form of text, matrices, and diagrams.






小婧是一名行走在实践路上的资深业务分析师(BA),如果想与我同行,就请关注我吧!

BABOK Guide3.0(7.1) Specify and Model Requirements

查看完整目录BABOK Guide 3.0分享目录


「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论