I’ve heard of a fantastic land far, far away where magical people called “project managers” collect something called “requirements.” These requirements so clearly, concisely, and completely describe work to be done that all the villagers involved share a common understanding of a project’s goals. Before a single pixel is plotted in this amazing world, villagers are able to agree to what a project will (and will not) accomplish.
In many of the real worlds I’ve worked in, however, requirements either didn’t exist or, if they did, they existed in a state that made me wish they didn’t.
Where requirements didn’t exist, it was usually because the company’s culture had wished them away. Every suggestion to collect requirements was met with a heavy sigh and an exaggerated glance at a wristwatch. When requirements were produced despite the resistance, the same people impatiently flipped through a few pages before choosing a couple of requirements to argue about for the life of the project.
In the culture of the other worlds, people didn’t really believe in requirements so much as they agreed to accept that requirements, in fact, might exist.
In some cases, this resulted in spotty requirements that only vaguely described parts of the challenge. These requirements lacked credibility and people tended not to pay much attention until they saw the user interface. Because of this, even points of conflict described well in the requirements weren’t addressed until the design was near completion.
Sometimes, companies with only tepid support for requirements bring in consultants who are zealots. I worked at a place that hired an engineering-centric third party. The consulting engineers produced requirements that were so extensive and detailed that nobody else could get past the first few pages of the thick documentation. I suspect this was the consultant’s intention all along because, throughout the project, their response when anything was brought into question was “Well, it’s right there in the requirements documentation.”
But why should an information architect care about requirements when it’s not his or her job to collect or create them? It comes down to simple math: it’s been my experience that a blurry definition of what a project needs to accomplish leads to a lot of extra work for the IA. So much extra work, in fact, that revisions end up taking much more effort than helping the team nail down useful requirements earlier in the process.
An IA who generates requirements just to satisfy his own selfish needs actually serves the team quite well. But the IA may not produce the kind of detailed requirements an engineer would need for coding. These UI-related requirements are intended to give the team an easy mechanism to identify and reconcile differing visions for the project before the IA starts organizing information or user goals.
So every information architect has to decide for himself. I, for one, choose to believe in requirements. I believe in a very specific approach to requirements, an approach that has a lot to do with frustration.
The frustrated designer
Something that first started to drive me nuts when I was the art director for a print magazine, and continued to bug me while I was designing web products, was confusion between “the what” and “the how.”
To me, design isn’t a mystical experience. It’s a tool used to address specific challenges. So my version of Design Hell is to be stuck in a room as part of an endless subjective argument about how something should be designed. By trial and error, I learned how to turn those arguments into objective discussions of what needed to be accomplished by the design.
As I started to work in jobs where some people communicated with one another using requirements, it seemed reasonable to keep separating “the what” from “the how.” These two definitions are the result:
- Business requirements: What the project, system, or solution needs to accomplish.
- Functional requirements: From a high level, how the project, system, or solution needs to accomplish what it needs to accomplish.
The frustrated strategist
I’ve had a few jobs now that involved helping teams plan strategically. Unfortunately, if you give groups of human beings the opportunity, they will argue to their last breath (I worked with one strategic task force that took three meetings just to argue about what the word “strategy” meant.) I’ve found that the key is to get diverse people to talk about the same things using the same words.
That can be useful with requirements, too. To that end, I like to use two distinct formats:
Business requirements describe the entity (system, company, or user) that most needs the thing to be accomplished. For example: “The user needs to manage class attendance.” By identifying a specific entity, we also help people see the information from the same perspective. This commonality can be powerful.
Functional requirements describe the ability that will fulfill a specific business requirement. For example: “Ability to display students in a teacher’s class.” The hierarchy between what will be accomplished (the business requirement) and how it will be accomplished (the functional requirement) makes both types of requirements much easier to grasp. Sticky, easily understood requirements lead to arguments and arguments lead to solutions. These solutions then lead to a well-crafted strategy widely supported by the team. And all of this can happen long before a single pixel is planned.
The frustrated development guy
Does this process sound familiar?
First, you get a group of stakeholders in a room so they can “blue-sky brainstorm” to figure out how they want to improve their product. The group comes up with a list that has everything from “Make the little blue buttons bigger” to “Bring world peace.” The list goes to an engineering team who organizes the list into three categories: Things we can do now, things we can do by the end of the year, and things that will take a long time. They email the categorized list to a project manager who changes the categories to Phase 1, Phase 2, and Phase 3 and sets up a project schedule for the first 10 things in the Phase 1 list.
It’s been my experience that incremental change is an essential part of any product’s improvement, but incremental change just can’t address big challenges. To truly evolve a product, those big challenges need to be defined. The approach to requirements I’m suggesting can both define and address big challenges, while the blue-sky approach described above just checks arbitrary items off of a symptom-generated list.
How it works
Let’s say you’re launching a new Help section for a website. You interview all or some of the project stakeholders, either one-on-one or as a group. Either with the stakeholders or later by yourself, you take the data and start trying out some business requirements. You’ll want to use simple language and simple sentences. If you have to use jargon or technical terms, they should be understood without explanation by every member of the team. Two examples:
“The user needs help completing their tasks.”
“The company needs to minimize phone calls to Customer Support.”
A nice test for these business requirements is to ask: “Okay, how do I do that?” If the requirements are too high-level, answering will require asking more questions. For example, “The user needs help completing their tasks” begs the question: “What are the tasks that need completing?” Revisions are used to get the requirement down to the right level of detail.
If a requirement is at the right level of detail, the answer to the “how do I do it?” question will serve as a functional requirement. For example, “the company needs to minimize phone calls to Customer Support” would lead to the functional requirement: “Ability to compare total calls to Customer Support before and after implementation.”
Identifying when a business requirement is too detailed is a bit trickier. These requirements will mire the team in conversations about things for which they may have an opinion, but about which they don’t really care. For example: “The system needs to link customer’s account information and order form troubleshooting advice.” As requirements get closer to a base level, they also run the risk of dictating solutions. For example: “User needs list of help topics including ‘shipping,’ ‘account,’ and ‘returns.’ ”
Once you’ve got a collection of these requirements that you feel define the space where the user interface (or interfaces) will exist, it’s time to get your stakeholders together in a room. Your goal is to review, revise and, as needed, replace your business requirements (this may lead to adjustments and additions to the functional requirements as well, but your focus should be getting the group to agree with “the what” described by the business requirements).
Remember, and remind the team, that the references came from the team members and you were only the editor. Discuss each business requirement and adjust as needed. When you ask people to concentrate on “the what,” they’ll invariably veer right to “the how.” Don’t fight it (because you’ll lose); just add their comments to a running list of functional requirements that you can integrate after the meeting.
You’ll probably get plenty of nodding heads (from agreement, not sleep), but don’t be afraid of arguments either. Skipping conflict at this point will just cause it to come out later. In my experience with more traditional processes, delayed arguments always blow up as part of the craziness right before launch. That’s when an IA is forced to defend against last minute, willy-nilly changes to navigational strategies, taxonomies, and other key, sophisticated solutions. Your UI-centric requirements are a new tool that warring parties can use to forge agreements earlier, rather than later in the project.
(It’s also important to mention that if you’ve developed these requirements but feel like your skills aren’t well-suited to leading the group through them, you can outsource the group facilitation.)
Here are some examples of business and functional requirements:
Business: “The system needs to send an order to vendors within one hour of approval.”
Functional: “Ability for system to be automated.”
Business: “The user needs to modify an order.”
Functional: “Ability to search orders.”
Business: “The user needs to approve an order before it is assigned to vendors.”
Functional: “Ability to display only those orders pending approval that are relevant to the user role.”
Functional: “Ability to cancel orders that have been rejected.”
Functional: “Ability to record person granting approval.”
The primary goal for this approach is to define the thing being built in a way that allows discussion and support among the widest variety of stakeholders. The requirements should:
- Separate “the what” from “the how.”
- Help different people talk about the same things using the same words.
- Be sticky by connecting each functional requirement to a specific business requirement.
- Facilitate product evolution (not just incremental change).
Frequently, it will be more helpful to the IA when these requirements lead to deep arguments rather than shallow agreements. Arguments can lead to an alignment between the work of people who deal primarily with “the what” and the work of people who deal primarily with “the how,” while protecting the expertise of both. When this happens, the enormous return on the IA’s investment of time and effort will be obvious.
And they will all live (and work) Happily Ever After.