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.”
Benefits
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.
http://www.dswillis.com (a shameless pitch of his consulting services) and http://www.dswillis.com/draw (another shameless pitch, this one a showcase for his illustrations and cartoons).
Thanks for writing this article. As an frustrated IA at a smallish tech company that just doesn’t quite get IA just yet, your article is most helpful in our on going discussions. I’ve printed out copies and put them on the desks of our project managers and a VP.
Thanks Dan for the article. I think writing effective and useful requirements is a problem thoughout product development and managment teams. Looking back to the days, when I did product managment and development – few engineers , engineering managers, and product managers actually get formal training in writing good requirements – this is especially true if you work for smaller technology company. Writing effective requirments is a team effort, and I would recommend getting somebody in staff who has experience with this (please read past article – http://www.boxesandarrows.com/archives/getting_creative_with_specs_usable_software_specifications.php).
I don’t doubt there are some smart IA’s or UI designers out there who could write requirements – but let’s be real. Lot of us in our community lack the experience in this area. You’r right by pointing out that there are lot of companies out there who produce poor requirements – however, there are also good companies out there where product or program managers write the good specs and requirements – and they even work with us user experience folks.
Adapting useful requirements into product design process doesn’t happen over night – it may take many months or even years (depending on size of the company, culture, etc). So what if someone one day wrote very good requirements – it won’t matter if no one will read it or endorse it. Producing good requirments will take time (there are variety of methods and best practices). But I think it’s more important to have general consenus/committment in the company to really adapt and design products by requirements. Producing good requirement document/process could come next.
Tip for the IA’s or UI designers, you will have more influence during “business requirement or marketing requirment stage”. By the time it gets to “product or software requirement” stage, our influence will signifiantly decrease.
thanks again for your aticle Dan 🙂
Is that requirements aren’t done well? Or that there is a concept of this holy grail document called the requirements document? I’ve written a great deal of thes documents, and depending on the audience they are narrative tombs which I can not fathom being read to satisfy the sense that ‘work has occured’ to very detailed annotated flows and wireframes each time all the documents had to be translated in some other form in order to adequately meet the needs of the audience readng and approving the document. In the end the requirements document has always served more a dramatic minutes from large group discussions than something everyone took away and worked from. This is not to say that i don’t think requirements are critical, but I wonder at times if it’s better to break out requirements into stages written by the people who need them to serve their end goal, then to have one person be the ultimate transcriber?
The article’s take on the old “What vs How” issue is an interesting one. I’ve not seen it applied in the context of “business” and “functional” requirements before, but the “classical” view on this is not that the “What” is business and the “How” is function, but that one man’s what is another man’s how. The trick is to understand where you are in the chain.
For example, take this “cascade” from high-level “what” to low-level “how”:
CEO: What do we need?
We need to lower costs.
Divisional Manager: How do we lower costs?
We need to replace our paper-based ordering system.
Middle Manager:
How do we replace our paper-based system?
We need to build a replacement using XYZ.
Project Manager:
How do we build a replacement using XYZ?
We need to define the requirements.
Development Lead:
How do we define requirements?
We describe the functions of the system.
Developer:
How do I implement these functions?
I write some code.
In my experience, the confusion over requirements is not going to be solved by saying “here are the business requirements, and here are the functional ones” because it totally depends on what level you’re dealing with in the above cascade. “Business requirements” to a Middle Manager are usually pretty useless to a Development Lead, foe example.
So – I think the article is actually pretty weak in that respect.
However, he mentions using common vocabulary. Now that IS worth doing, since all levels need to use the same terms.
I was also surprised to note the absence of the most important thing about a document that starts “The system shall…” – the definition of scope. Scope equals money, either losing it or making it, and the only way you’re going to stop scope from creeping is to write down what you are going to do…
bearing in mind the above what/how cascade of course … 😉
Dan: Thanks for pointing out the distinctions in requirements. Years ago I stumbled on a similar distinction but a bit more in-depth. I aligned the distinctions to “people, process and technology” — three distinct sets of requirements needed to be gathered by three distinct perspectives and then mitigated together in the end. The “process” dimension aligns to your business dimension. The real distinction here is that when interviewing an employee most questions are not carefully made distinct between their roles. They are both an employee and a human being. As an employee, they may be prepared to defend the needs/perspectives of the department or their role, as a human being, they might see things differently. To not allow for these mental distinctions asks individuals to be psychotic when answering questions.
Several years ago I offered a ‘test course’ at a national technology conference titled “Why Requirements Don’t Work”. The draw was phenomenal…as an unscheduled class it drew 32 people to an evening event (when they could have been at the beach or out on the town).
Great article, Dan. I’m finding more and more often that issues around requirements are the underlying cause of many project disasters. Being involved early and often in the requirements definition is critical, but also incredibly important is a process for managing changes to those requirements. I often find that organizations have intricate rules in place for managing change that impacts requirements during the development phase. However, those same organizations have no concept of managing requirements churn during the design phase. A few companies in my past have had the concept of “feature freeze” or “design freeze”, but rarely stuck to their guns when change came a’knocking. I would love to hear of some real-world examples of successful processes for managing requirements churn.
The distinction what-how is only a start.
First you need (as pointed out in other comments) the scope of the application.
Next you need the what, you business / user requirements.
Next you need the how, but translating the how merely to ‘an ability’ is far too weak to get ‘well-defined’ requirements. If you give all the abilities / functions as such to a engineering team, you will get an application that does not even get close to your users’ expectations (or only if you get very lucky) and your user-centered approach will not lead to the ROI you seem to be expecting.
The how should be expanded with your understanding of the user context (how do they work, what do they know, how fast do they need specific results, what are the main tasks and what are less important tasks, which tasks are related, is their a specific work or task flow, what are the relations between specific functionalities / abilities, where should specific functions / abilities be made available, the users that must and may not access specific abilities etc.).
Abilities need to be translated into behavior and design. The how should not be limited to the ability (e.g. users should be able to sort the results) but should describe how users will be able to sort the results, e.g. by clicking the table headers in addition to a separate sort dialog. If you omit such requirements or if you prefer ‘specifications’, you design will never address the users’ needs although your functional requirements correctly describe them.
I’ve worked for companies that have very strict policies in business and functional requirements, that strongly believe in their usefulness, that even think they’ve involve the users from the very beginning by making them sign off the requirements. Of course, users will think the list of requirements is complete, but listing abilities says nothing about in what way they can use these abilities and whether these abilities are depending on other ones.
So pls. translate business requirements into functional requirements and functional requirements in behavior, design and interaction requirements and the latter ones in screen specifications or user interface mock-ups so the stakeholders can visualize, grasp and understand that ‘what’s and how’s) before any coding is done. The more the engineering work will be outsourced the more specific your design and behavior rules must be. Don’t make engineering teams guess about this (and don’t you expect them to figure this all out by their selves)!
This reminds me of the User Stories used in Extreme Programming. The business requirements in this article fits nicely as the title of such a story, and the functional requirements would be the body of the story.
Personally, I like to write a combination of User Story and Use Case. I prefer the Brief Use Case using prose only, extended with numbered lists when that is useful, perhaps with some technical notes about backend systems, possible user interface and business rules.