编辑导语：产品经理的日常，往往与需求离不开，其中很关键的一步就是描述需求。需求的描述需要一定的技巧，优秀的产品经理不仅可以清晰地描述自己的需求，还能让他人听懂并且知道接下来该如何进行。在本篇文章中，作者为我们分享的是规范产品体系中与需求描述技巧相关的内容。

“小美， 咱们到会议室去开个会，讨论下这个版本的新需求”

开发、测试、美工济济一堂， 产品经理把这个版本的需求概要地「说」了一遍，然后就打开小美设计好的「产品原型」讲了起来。

产品原型是个好东西， 非常直观， 一看就知道到底要做成什么样子， 页面之间的跳转关系也一目了然。

工程师一边听，一边心里琢磨着更细节的内容。数据库表该怎么设计， 表该怎么改，怎么做数据迁移，界面的流程该怎么跳转， 后台需要提供什么样的服务…

大家叽叽喳喳的讨论了一个下午，终于安静了。

看到大家的理解基本一致了， 经理开始做最后的总结陈述： “怎么样？ 还有问题吗？ 没有问题的话小美按今天讨论的结果，把界面修改一下， 大家估算一下自己的工作量，下班之间报到我这里。”

工程师心想，估算也没啥用， 反正上线日期都确定了。

就这样，越来越多更加细节的深层逻辑仅仅进入了工程师的脑海， 而没有形成文档，存在严重的项目「信息失真」隐患。

IBM Developer 的目的就是将程序员集结在一起，形成一个社区，进而挖掘我们的集体创新能力。换言之，我们有机会分享自己的一些诀窍，并学习到产品研发管理类的高效方法论。

IBM社区的工程师Donald Bell「序列图非常有效」。

对于研发人员，序列图能澄清业务在未来系统中如何体现；对于非研发人员（产品经理、架构师、业务人员），序列图能澄清未来系统中，不同对象间的交互，从而进一步传达清楚整个系统设计方案。

研发人员一般认为序列图仅对他们有意义，然而，深入了解过序列图之后，非研发人员（产品经理、架构师、业务人员）也会发现，序列图显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。

除记录组织的当前事件外，一个业务级的序列图能被当作一个需求文件使用，为实现一个未来系统传递需求。在项目的需求阶段，产品经理能通过提供一个更加正式层次的表达，把用例带入下一层次。

那种情况下，用例常常被细化为一个或者更多的序列图。

序列图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统（称它为“遗产”）的对象现在如何交互。当把这个系统移交给另一个人或组织时，这个文档很有用。

1. 概念

序列图（Sequence Diagram），亦称为循序图，是一种UML行为图。有的人翻译为时序图，实际上是不准确的，sequence这个单词并无”时间”的意思，只有序列，顺序等意思。

根据UML规范中对Sequence Diagram的描述：

A sequence diagram describes an Interaction by focusing on the sequence of Messages that are exchanged, along with their corresponding Occurrence Specifications on the Lifelines.

它描述了消息在生命线上按照约定顺序执行一种交互行为。它可以表示用例的行为顺序，当执行一个用例行为时，序列图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。

2. 构成

序列图是由5种元素构成：对象(Object)、生命线(LifeLine)、激活(Activation)、消息(Message)和“组合片段”。其中前4种是常用且重要的元素，剩余的一种“组合片段”元素不是很常用，但是比较复杂。

我们先介绍前4种元素，再单独介绍“组合片段”元素。

1）对象(Object)

对象位于序列图的顶部,以一个矩形表示，对象的命名方式一般有三种：

1. 显示“对象名” “类名”，例如：手机 – 华为手机；
2. 显示“类名”，不显示“对象”，例如：手机；
3. 显示“对象名”，不显示“类名”，例如：华为手机。