认识Elaine：一种以人物角色驱动探索架构重要型需求的方法-InfoQ



 写点什么

本文由《IEEE Software》杂志首发，现在由InfoQ 和IEEE Computer Society 联合向您呈现。

从涉众那里获得的需求，常常只描述了系统的预期功能，而不涉及性能、可靠性、可移植性和可用性等系统质量方面的需求。人们常常假定系统会按预期标准运行，而忽视将这些非功能性目标写入需求。不幸的是，涉众和开发者们会以为他们已经达成了共识，而实际上却有着不同的期望。若不能在系统设计之前充分理解这些质量上的需求，那么在系统交付之后，很可能出现涉众因系统不符合期望而不满意的状况。而且，在后期针对这些关键性需求进行重构，要付出高昂的代价。

存在重要架构权衡的项目

下面，我把我们最近用来解决这一问题的简单方法分享给大家。我们有一个叫 TraceLab 的项目。在项目早期阶段，我们意识到很难设计出一个能够满足所有涉众关心的问题的架构方案。TraceLab 提供了一个虚拟的实验室环境，研究者们可以在这个环境中设计、执行、评估和交流实证软件工程实验（empirical software engineering experiments）。该项目的涉众要求一个高性能、多平台的方案，而且要能把用不同语言编写的可执行组件动态地载入到即插即用的环境中——保守地说，这是一个具有挑战性的需求。为了设计一个可行的方案，我们开发了一个以人物素描（persona sketch）为中心的方法流程 1。

这些人物素描有助于我们显式地获取各种涉众对系统质量的需求，并设计和评估要满足这些需求的架构方案。我们在另一个工业合作项目中也运用了同样的方法。在该项目中，我们设计并原型化了一个全企业范围的机电一体化追溯系统。这个系统采用了信息检索方法，使工程师们可以在多个分布式第三方 case 工具之间搜索相关的工件。比如，无论是从事热动力模型设计的工程师，还是从事代码开发的程序员，都可以通过打开集成开发环境（IDE）中的插件来查询与他们的模型中某个元素相关的需求列表（可能是存放在 IBM Rational DOORS 工具里）。因此，这个热动力系统需要有一个底层的追溯引擎（可以从第三方 case 工具获取数据）和一个图形化的用户界面插件（提供交互功能），这样工程师就可以发出追溯查询并查看结果了。我们首先研究了从推到拉、从集中式到分布式的各种方案，然后通过一系列人物素描对这些方案进行了验证。

发挥人物素描的作用

人物角色（persona）代表虚构的人物。在人机交互（HCI）领域，人物角色被用来支持用户交互设计。在一个典型的案例中，HCI 团队先对潜在用户进行调查研究，再对用户进行分组，然后设计、评估、确定一组人物角色。这些人物角色提供了一个透镜，使得与预期工作相关的看法和环境更加突出 2。由于我们的项目采用敏捷开发，我们无法承受在先期就投入数周乃至数月的时间来创建人物角色，因此，我们开展了一系列头脑风暴活动来创建和验证人物角色，然后通过工业合作伙伴的反馈意见来确认这些角色的确是有效的。

图 ****1 一个精通架构的人物角色。这个人物角色栩栩如生地描绘了一个典型的用户代表，它以用户故事的形式描述了质量需求。

认识 Elaine

图 1 描绘了我们为机电一体化项目创建的一个人物素描。Elaine 是一个经常使用 Pro/Engineer 来构建物理模型的机械工程师。她准备通过机电一体化追溯系统来帮她确保自己的模型符合监督管理规范。她特别关心性能问题，因为她知道系统需求保存在远程的资源库中，她不希望在建模时把时间耽误在等待搜索结果上。另外，她还关心访问的控制。虽然她需要访问需求说明书的基线版本，但她仍然希望对她的当前模型维持实施严格的访问控制。

除 Elaine 以外，我们还创建了其他三个人物角色（见图 2）。我们之所以选择这些人物角色，是因为他们能够带来不同的视角。John 是一个规范监察员，他关心的是把最新、最准确的信息汇总整理到各类报告里。Les 是项目的首席架构师，他关注性能、安全性和自适应性；特别要说的一点是，他意识到系统必须能够随着企业的变化而变化，而且如果各类工程师们采用了新的 case 工具，系统必须要能够支持这些工具。最后一位是 Mary，她是一名需求工程师，她负责需求的获取、规格化和管理。这些需求是机电一体化追溯系统中的重要部分。

（点击图片放大）

图 2 为机电一体化项目创建的四个人物角色。创建架构重要型角色是要讲究一定技巧的，识别出的人物角色组合要能够覆盖给定系统中的所有质量问题。

评估架构方案

用户故事是各人物角色描述中最重要的部分。这些故事应该是关乎架构的，也就是说，故事创建者们要能发现那些可能会驱动架构设计的问题。在《IEEE Software》杂志最近刊载的一篇文章中，Lianping Chen、Muhammad AliBabar 和 Bashar Nuseibeh 这样描述架构重要型需求（architecturally significant requirements）：它们对系统有着巨大的影响，它们制衡其他需求，它们引入了约束、打破了假定，而且常常难以实现 3。

根据我们的经验，从人物角色的视角创建架构重要型用户故事，有助于我们对多种不同架构方案进行分析和评估。一些最基本的架构决策主要是决定采用推模型还是拉模型，追溯引擎应该是集中式还是分布式，如何针对各类独立、异构、第三方的 case 工具进行访问控制。对每一个候选的架构决策，我们根据它对人物角色实现其目标的支持程度来进行评估。图 3 是我们在分析过程中使用的模版，从中可以看出此分析针对的是“实现最快追溯查询响应时间”这一目标。

在进行分析时，首先确认并列举出所有与“响应时间”这一目标相关的用户故事，然后直观地标注出各个人物角色所关心的具体问题。值得注意的是，对于诸如“30 秒内追溯查询响应时间”这样的显式需求，在弄清能否以合理的代价实现它之前，我们不应把它看成是板上钉钉的。就这个例子来说，我们探索出了这样的一个集中式方案，那就是由数据所有者定期把追溯数据推送至追溯引擎服务器。

（点击图片放大）

图 3** 架构重要型用户故事总结。本例关注的是“响应时间”这一目标，表中列出了几个关键性问题及其对各角色人物的影响。在设计过程中，相关架构决策及其风险也被记录了下来。**

在设计过程早期，创建一些有架构经验的人物角色，是获取并分析涉众关切问题的一个轻量级方法。它既非常适合敏捷项目环境，也非常适用于更传统的环境。尽管我们目前只在两个项目中运用了这一方法，但我们已经发现它是一个易于实现的方案，而且能有效地使重要的架构问题更为突出。人物角色应该在项目开始时就被创建起来，接着在项目启动阶段引入并细化，然后用来达成共识并不断演进对架构重要关注点的理解，这促成了开发者、架构师和其他涉众之间持续的交流。

希望各位关注我们的方法，并在自己的项目中尝试运用。期待大家的反馈，点击这里与我联系。

参考文献

J. Cleland-Huang, A. Czauderna, and E. Keenan,“A Persona-Based Approach for Exploring Architecturally Significant Requirements in Agile Projects,” Requirements Engineering for Software Quality, LNCS 7830, J. Doerr and A.L. Opdahl, eds., Springer, 2013, pp. 18–33.
L. Nielsen, (2013): “Personas,” Encyclopedia of Human-Computer Interaction, 2nd ed., M. Soegaard and R.F. Dam, eds., Interaction Design Foundation, 2013.
L. Chen, M. Ali Babar, and B. Nuseibeh, “Characterizing Architecturally Significant Requirements,” IEEE Software, vol. 30, no. 2, 2013, pp. 38–45.