I have the opportunity to talk about Requirements Engineering (RE) pretty frequently.

Most of the time, I’m talking with people who are familiar with software development in general, and some of the time those folks are also familiar with the specifics of RE. There’s a shared understanding of the work that we do in RE, even if there are differences of opinion regarding just HOW we do that work, or the specific outputs of the work.

Today, I had a unique opportunity to discuss RE with a group of people who are not involved with software development or RE. I presented a paper at the American Society for Information Science and Technology (ASIST) conference (as a bit of background information, I’m currently a grad student at The University of Texas’s School of Information).

My paper is a review of the work on Information Behavior (generally speaking, the theories and models of how people identify an information need, look for that information, and then put it to use) in RE. My audience today was quite familiar with Information Behavior, but only a few people there had ever been directly involved with software development.

Now, we’ve probably all had that moment when we have to explain what we do or what RE is. And usually we’re explaining it to a relative or friend or someone on the elevator who has no exposure to the ways in which software development takes place, so we say things like “I’m a translator between people who NEED software and people who BUILD software,” or “I take the requirements from the users and give them to the developers. I have people skills.”

But today I wasn’t talking about MY job, I was talking about OUR collective job. I was trying to explain what RE is and what Requirements Engineers (or Requirements Analysts, or Business Analysts, or….) do and how those both overlap with the world that ASIST members work in.

What I discovered is that, in some ways, it was easier to explain RE to a “foreign” audience than it is to talk about it with “insiders” like fellow analysts. All I had to do was provide an overview of our work, and then I could spend more time drawing parallels between the specific aspects of that work and the theories of Information Behavior.

What’s more, I could use the language that my audience was familiar with to help make my point. I could have spent 30 minutes trying to explain the nuances of eliciting requirements, but when I said that it’s like the reference interview for a librarian, everyone in the room knew what I meant. Of course, being able to talk that way required that I be an “insider” in both camps — RE and Information Studies — but it worked, and it worked well.

So, what’s my take-away point for you? Figure out what YOUR audience understands, get familiar with that domain, and learn how to use examples from it to do a great job at analysis. You don’t have to understand the entire domain at an expert level — just get familiar with a few of the main practices, problems or current issues, and you’ll be able to connect with people much more effectively. That skill will help you with everything from elicitation, talking to librarians, and explaining to Aunt Sally exactly what you do for a living!

PS – If you’re interested in talking about RE and Information Behavior, post a comment and let’s chat!