Interaction Design and Structured Requirements

subtitle: Wiegers and Cooper assimilated

Wiegers promotes structured requirements. Cooper touts Interaction Design. Both have great ideas. Both “wave their hands” at different parts of the process. In this post, we’ll talk about how to combine the two philosophies to get the best of both worlds.

Background

Regular readers can brush up on the following posts. Folks who are new to Tyner Blain (welcome aboard!) can get the immersion treatment to understand our perspective on requirements, design, and product management / development process by reviewing the following posts.

• In our Foundation series post, Structured requirements, we presented the Wiegers view of the structure of software requirements.
• We recently posted an overview of the Interaction design process.
• In a post covering a debate between Alan Cooper and Kent Beck, Michael asked (in the comments) about who should play the role of interaction designer. This got us to thinking about how to incorporate Cooper’s great ideas with Wiegers’ (and Beck’s). This post sets out to do part of that job.
• We’ve engaged in a multi-blog conversation / debate about where to draw the line between requirements and design. We established our position mainly in two posts – Requirements vs. design – which is which and why and Software requirements process and roles.
• When deciding what features to include in our software, we have leveraged Kano techniques to prioritize features for the first release, and defined a multi-release requirement prioritization strategy.

Summary

Our combination of interaction design and structured requirements principals makes it even more difficult to differentiate between “requirements” and “design.” We’re ok with this, because the distinctions are purely semantic, and distract us from our goals – developing great software. The combination we promote is to replace use cases (from Wieger’s structured requirements approach) with scenarios. This replacement adds interaction-design elements into the process of goal-definition. It is also worth noting that it splits the nebulous design activity into two activities – program design and interaction design.

First we will review the Wiegers structure, then a modified structure incorporating the interaction design elements.

Conclusion

This approach provides us with the organizational benefits of a structured approach, while incorporating the techniques of interaction design that can lead to great software by driving proper prioritization decisions. The decision process is key to choosing to build the most important stuff, and more importantly, not build the unimportant stuff. Avoiding the less valuable features improves the product for the most valuable users. Wiegers’ approach doesn’t prevent this from happening, nor does it encourage it. Our approach will encourage it.

Wiegers’ structured requirements

The structured requirements approach starts with the goals, expressed in a product requirements document (PRD). There is a step that happens before the Wiegers process. Market requirements are identified before this first step, and captured in a market requirements document (MRD). This MRD is converted to a PRD, as requirements are identified as being in-scope or out-of-scope for the software. Wiegers doesn’t address this preliminary step (but Cooper does).

Once we have our PRD goals, we define the use cases to support them. Then we write functional requirements to support the use cases. The functional requirements are augmented with non-functional requirements and must comply with constraints.

The design and implementation phases follow this process, and again are unaddressed by Wiegers.

Adding interaction design to the mix

In the diagram above, the changes (relative to the Wiegers process) are marked in blue.

The interaction design process starts with two parallel activities. On the left is the identification of corporate goals, which is analogous to the creation of an MRD. An MRD can be a reasonable mechanism for documenting the corporate goals. It provides more detail than “Increase profits” with statements like “Increase profits with improved pricing.” On the right side is the creation of personas to represent the most important users.

The persona creation process involves identifying the practical and personal goals of the representative individual. The personal goals are used later when designing the user interface. The practical goals are integral to the requirements process. The practical goals represent the role that the persona plays in achieving the corporate goals. A practical goal for a pricing analyst might be “Increase profits for product line X by 10%.”

The practical goals are an analog to the Wiegers goals – they represent the software-relevant goals of the company, in actionable language, associated with a particular persona (class of users). The association with the persona is the key element that allows for great design. The actionable nature of the goals may incorporate or imply particular business process design decisions (made outside of the scope of either process).

The main benefit we get from this approach is the ability to not implement the non-essential features. The absence of these fluff-features allows the most important users to master the software faster without having to deal with low-value complexity.

The scenarios are effectively the same as informal use cases. The distinction may be that Cooper stresses that it is more important for a scenario to run end-to-end than it is to be deep with precision or detail. A use case is normally scoped to a subset of the overall process, where a scenario may cover behaviors that would map to multiple use cases.

Functional requirements, non-functional requirements, and constraints are all defined in support of the scenarios – with the same approach as in the Wiegers model.

The design step is distinguished as having two clear elements in our combined process. Cooper separates program design (what users don’t see) from interaction design (what users do see). This makes sense for two reasons. First – the personal goals of the persona influence how the user will interact with the software. These goals will only indirectly influence the program design decisions. Second – these two tasks require different areas of expertise and should probably be covered by different individuals. The program designer is our canonical developer. The interaction designer is an expert in psychology as well as the other user experience disciplines.