One of the hot topics during my visits with Forrester clients this week was requirements. How do other people do them? How do they change when development teams go Agile? Why is it so damn hard to re-use the information written for the development team for other purposes, such as training the salespeople? And so on.

I’ll be starting some research on requirements in a month or so. Meanwhile, as busy as my writing agenda is, I can’t help but ponder the topic. To complete the distraction, I was also reading some of Tyner Blain’s recent posts on the topic, such as this interesting discussion about user stories and use cases.

To a large degree, requirements have to conform to the peculiarities of an organization. While there might be some Platonic ideal of requirements, manifested incompletely in this imperfect world of ours, there’s no escaping the regular back-and-forth between the authors of requirements and their readership. Development teams have their own preferences for information, both quantity and format. You’d be a very bad product manager (and probably not employed for too long) if you were to ignore that reality.

Still, requirements design isn’t as simple as adding or removing pieces into a requirements data model until all parties involved are happy with the results–particularly since one kind of requirements information doesn’t really seem like it has a data model at all.

Measurable facts
Suppose you were to write requirements for a salesforce automation system. One of the target users for this flavor of CRM is a salesperson. Assuming you haven’t worked in Sales yourself, how do you find out what sort of technology this person needs?

One way to find out is to grab every piece of hard data available about the job. What’s the average income of a salesperson? What are the tasks that person performs? What obstacles do they encounter along the way? How strong or weak are the computer skills of that person? What kinds of software and hardware do they use?

After collecting this Grey’s Anatomy of the sales profession, you can pinpoint where the CRM technology  can help the archetypical salesperson. According to our research, salespeople spend 72% of their time away from their laptops, which makes mobile support a top priority, etc. etc.

If that approach seems a little bloodless…Well, it is. Not every important aspect of human behavior reveals itself through this sort of information. After poring over Department of Labor statistics, you might also need to go to the movies.

Observational insights
Statistics may tell you how people spend their time. Observation, on the other hand, reveals many of their attitudes, inclinations, hopes, dreams, enthusiasms, and complaints that you might otherwise miss.

The trick, of course, is knowing how to observe people well, and whether you’re observing the right person. If you want to know what life looks like from inside the head of a salesperson, you might rent Glengarry Glen Ross, or Death of a Salesman:

You don’t understand: Willy was a salesman. And for a salesman, there is no rock bottom to the life. He don’t put a bolt to a nut, he don’t tell you the law or give you medicine. He’s a man way out there in the blue, riding on a smile and a shoeshine. And when they start not smiling back―that’s an earthquake. And then you get yourself a couple of spots on your hat, and you’re finished.

After Salesperson Movie Night, you might look a little differently at the CRM feature list. Something that makes it easier for salespeople to keep their customers feeling as though they’re getting special treatment might have much greater appeal, even though that task might consume only 10% of that person’s time, and may not even figure all that clearly in the scientifically-collected work profile that you’ve collected.

This type of information has its own perils, however. David Mamet and Arthur Miller might be fantastic playwrights, but there’s always the risk that even the best artists don’t do their subjects justice. We judge these two plays on their own merits as dramas, not as social-ethnographic profiles of salespeople. Similarly, you might spend a quality day shadowing a salesperson, only to find out that she’s not typical of her profession. For example, she could be the very best, or the very worst. Either extreme might not tell you what the average salesperson really needs.

Plus, what do you do when you have to write the requirements? Use cases don’t exactly capture the "smile and a shoeshine" aspect of Sales. Nor do carefully-maintained functional requirements. While people often make fun of personas, or lack the time to pay careful attention to them, they do have their place (when done well) in transmitting some important insights to anyone–developers, support technicians, product marketers, you name it–who has contact with that user.

So, what then is the ideal form of requirements? Maybe the triune division of business, user, and functional requirements makes the most sense. Or maybe these are just expressions of another level of distinction behind them: knowing facts about people, versus understanding them at a deeper level.

[Cross-posted at The Heretech.]