Meet Elaine: A Persona- Driven Approach to Exploring Architecturally Significant Requirements

This article first appeared in IEEE Software magazine and is brought to you by InfoQ & IEEE Computer Society.

More often than not, requirements elicited from stakeholders describe a system’s intended functionality but fail to address qualities such as performance, reliability, portability, and availability. Documenting these requirements is often overlooked because there are implicit assumptions that the system will perform to expected levels. Unfortunately, stakeholders and developers might think they are in agreement, when in reality they have very different expectations. Failure to sufficiently understand quality concerns prior to designing a system can result in stakeholder disappointment when the delivered  system falls short of expectations and results in costly refactoring to accommodate critical requirements as they emerge late in the process.

Projects with Significant Architectural Trade-Offs

I’ll share a simple technique that we recently used to address such problems. During early phases of our TraceLab project, we realized that designing an architectural solution capable of satisfying all stakeholder concerns would be very difficult. TraceLab delivers a virtual laboratory environment in which researchers design, execute, evaluate, and exchange empirical software engineering experiments. Our stakeholders’ demands for a high-performance, multiplatform solution that allowed executable components written in multiple languages to be loaded dynamically into a plug-and-play environment were challenging, to say the least. To design a viable solution, we developed a process centered on the idea of persona sketches.¹

These sketches helped us to capture explicitly our various stakeholders’ quality concerns and then to design and evaluate an architectural solution that met their needs. We applied the same approach to another project we were working on with an industrial partner in which we designed and prototyped an enterprise-wide mechatronics traceability system. This system used information retrieval methods to allow engineers to search for related artifacts across distributed third-party case tools. For example, engineers working on a thermodynamic model of a system or programmers developing code could open a plug-in to their integrated development environment and request a list of all requirements (perhaps stored in IBM’s Rational DOORS tool) related to an element in their model. The mechatronics system therefore needed an underlying trace engine, features to retrieve data from third-party case tools, and GUI plug-ins that provided interactive features that engineers could use to issue trace queries and view results. We initially explored a variety of push–pull and centralized–distributed solutions, and then evaluated them using a set of persona sketches.

Personas to the Rescue

Personas represent fictitious people. They’re usually created by humancomputer interaction (HCI) experts to support user interaction design. In a typical scenario, a team of HCI experts survey potential users, categorize them into groups, and then propose, evaluate, and create a relevant set of personas that provide a lens for highlighting attitudes and contexts associated with the intended work.² The personas we created were intended to help us reason about architecturally significant requirements and to drive a series of architectural decisions. Our process was constrained by our project’s agile nature, which meant that we couldn’t afford to invest weeks or months upfront creating personas. Consequently, we created and verified our personas through a series of brainstorming activities and validated them by inviting feedback from our industrial collaborators.

Figure 1. An architecturally savvy persona depicting a life-like identity representative of a group of users. The persona description captures quality concerns as user stories.

Meet Elaine

Figure 1 depicts a persona sketch we created for the mechatronics project. Elaine is a mechanical engineer who frequently uses Pro/Engineer to create physical models. She plans to use the mechatronics traceability system to help ensure that her models comply with numerous regulatory codes. She’s particularly concerned with performance because she knows that her system’s requirements are stored in a remote repository, and she doesn’t want to slow down her modeling activities waiting for search results to be returned. She’s also concerned with access control. Although she needs to access the baselined version of the requirements specification, she still wants to maintain strict control over who accesses her current models.

In addition to Elaine, we created three other personas, shown in Figure 2. We chose these because they brought different perspectives to the table. John is a compliance officer whose interests include gathering and collating up-to-date, correct, information into a variety of reports. Les is the lead architect for the project and has concerns related to performance, security, and adaptability; in particular, he realizes that the system must grow with the changing enterprise and that it must support new case tools as various engineers adopt them. Finally, Mary is a requirements engineer responsible for eliciting, specifying, and managing requirements. These requirements are central to the mechatronics traceability system.

(Click on the image to enlarge it)

Figure 2. Four personas for the mechatronics system. The art of creating architecturally significant personas involves identifying a set of personas that covers the full gamut of quality concerns for a given system.

Evaluating Architectural Solutions

The most important part of each persona description is its user stories. These stories need to be architecturally significant, which means that the people creating them need to be able to recognize concerns that will potentially drive architectural design. In a recent IEEE Software article, Lianping Chen, Muhammad Ali Babar, and Bashar Nuseibeh characterized architecturally significant requirements as having wide impact on the system, exhibiting tradeoffs with other requirements, introducing constraints, breaking assumptions, and often being difficult to achieve.³

In our experience, creating architecturally significant user stories, from our personas’ perspective, helped us reason about and evaluate several different architectural solutions. Some of the most fundamental architectural decisions centered around whether to adopt a push or pull model, whether the trace engine should be centralized or distributed, and how access should be controlled and facilitated for a wide collection of independent, heterogeneous, third-party case tools. We assessed each  candidate architectural decision according to the extent to which it supported our persona goals. This analysis was supported by the template shown in Figure 3, which illustrates the goal of achieving fast trace query response times.

The analysis involved first identifying and listing all the user stories that related to the response time goals and then visually marking the specific concerns of each of our personas. We should note that explicit requirements, such as the ubiquitous demand for a 30-second trace query response time, should not be carved in stone until it’s possible to understand whether it’s achievable at a realistic cost. In this example, we explored the decision to build a centralized solution in which traceable data would be regularly pushed by its owners to the trace engine server.

(Click on the image to enlarge it)

Figure 3. A summary of architecturally significant user stories. This example focuses on the goal of response time and shows critical concerns and their impact on each of the identified personas. In the design process, the relevant architectural decisions and risks associated with those decisions are also documented.

Using architecturally savvy personas is a lightweight approach for capturing and reasoning about stakeholders’ concerns early in the design process. It fits perfectly into either an agile project environment or a more traditional one. Although we’ve only used our approach in two different projects so far, we have found it simple to implement and effective for highlighting important architectural concerns. Personas should be created at the start of the project, introduced and refined during the project launch phase, and then used to build a communal and evolving understanding of architecturally significant concerns that drives ongoing conversations among developers, architects, and other stakeholders.

I hope that you’ll find this approach interesting and will try it on one of your upcoming projects. I’d love to receive feedback from you. Please contact me here.

References

¹ 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.

About the Author

Jane Cleland-Hu ang is an associate professor at DePaul University. Contact her here. 

This article first appeared in IEEE Software magazine. IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change.