The Storied History Of Requirements

In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. –  has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.

A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.

As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.

Different narrative, different structure. Because of its broader scope, The Pacific moves rapidly from the point of view of one Marine to another's, often in locations thousands of miles from each other. No single Marine experienced everything that The Pacific wants to show us, so the storyline, by necessity, often feels disconnected.

Requirements as story-telling
Requirements have to make similar narrative choices. In some cases, teams need requirements to document the behaviors of a very specific target user. For example, anyone who has ever worked on a CRM system knows how important it is to understand, at a fairly deep level, why salespeople should stop what they're doing to chronicle their activities. If salespeople don't enter this information, then nothing else you build into the salesforce automation application will help build a better repository of information about customers and prospects.

Requirements for a CRM system must therefore provide, or make reference to, a detailed profile of the archetypical salesperson. Rather than write obliquely about salespeople in PRDs, UI mock-ups, and other requirements media, many product managers cut to the chase with personas (who salespeople are) and user stories (what they're doing). 

That approach is not always necessary, or even desirable. For reasons as simple as force of habit or personal taste, personas may not be the best way to convey this information in a particular team. For different kinds of technologies, personas might have less relative value than other kinds of requirements content. If you're trying to educate people about how privacy requirements work, and what effects they will have on the medical case management system your team is designing, a handy Wiki full of information about HIPAA and other standards may be the right way to go.

Even if two teams find personas useful, the PMs won't necessarily fill in the same set of details for both groups. Some groups can't get enough of the fictional "day in the life" details, because they're trying to devise a UI that would appeal to that person. Another group might want to understand the top challenges that a typical person in that role faces, to help prioritize features in the roadmap. As character studies, personas differ among teams, because they have different aspects of the character that they need to study.

The requirements of requirements are complex. There's no single template that everyone can use, given these differences among technologies and teams. (That's the subject of an upcoming teleconference that I'm doing with colleague Mary Gerush, by the way.) So how do you figure out the right mix of requirements content, and the data structure that goes into each of them? The best answer is, "Who is the audience, and what story do you need to tell?"

Comments

Capturing requirements

Great post Tom,

The harsh reality is that very few people read requirements documents anyway. We write them, we make them incredibly complex and no one read them #FAIL

Far better to have a narrative, a story that engages people and encourages contribution. If you want a really brillant functional spec - encourage users to write narratives and share stories. After all, it is the end user that matters. It is amazing how we can design 'new' software solutions that are slower, more complex and confusing - completely ignoring the end users' needs.

Want the simplest test?

Here ... explain the function to your Mum. If she can't understand it, then it is likely to be too complex. If not, then go back to the drawing board.

When my 4 year old son who couldn't read could pickup a iPhone and use it, you know you were experiencing great design. He has never read a manual and never will. This is the bar that we need to cross. The more we start talking in plain english and behave in a way that encourages input and open discussion the better. Long live the story.