On Wednesday at RE07, I was part of a panel of requirements experts from industry. The other panel members were:

• Brian Berenbach (chair), a manager for Siemens’ RE focus program as part of the corporate research organization there.
• Kousik Sankar, a senior software architect in the Philips Bangalore CE Technology office.
• Ian Alexander, an independent consultant specializing in RE and author of a few. requirements books including Writing Better Requirements and Scenarios, Stories, Use Cases.
• Juha Savolainen, a principal member of the research staff at Nokia Research Centre in Finland.

We each presented what we believed to be the common and interesting problems we are seeing with requirements in industry. Here is a quick summary of mine which are based on discussions with all of our product managers:

1. Flavor-of-the-month methodology – where we actually do see project team members who believe they do not need to have written requirements. Obviously, I’m thinking of agile-like methodologies here. And while we love such methodologies for the right project, we unfortunately see people who misunderstand how to practice them, and that is the actual challenge.
2. Eliciting requirements in a global environment – the challenge here is in dealing with time, location, language and cultural differences. There are tools to help these, but our experience is that they still are not sufficient.
3. People do not really understand best practices for requirements…but they think they do – the issue is that they often read bad literature or got bad training and developed poor habits. We have to work with or un-train those habits.
4. Requirements tools are hard to use – we are seeing a lot of resistance to the use of requirements tools on projects with our customers. Our favorite saying “did they actually gather requirements for this requirements tool?”
5. People have made it boring to gather requirements – unfortunately, people have sucked the fun out of building new products. When people attend requirements sessions, they are bored and only in attendance because they really have to be.
6. There is a focus on number of features instead of quality features – we often see when our customers build a new product or add features, they want to cram in lots of features. They actually start with too many features and are never able to focus on how to build the really important ones to be usable.

I’m going to do my best to summarize the key challenges that each of the other panelists brought up, though I apologize because I’m quite sure this won’t be a perfect recount.

Brian’s top challenges are around working with very large projects, creating and managing end-to-end traceability, people other than RE’s are writing requirements and making verifiable RE work products. He works in an industry where the FDA requires the end-to-end traceability be complete, so this is of particular importance to them.

Kousik’s challenges included dealing with multi-site projects where domain competency levels vary and they are multiple product lines that share common requirements. Another challenge is with OEM development and things like making use of requirements patterns and capturing emotional requirements.

Ian’s challenges were divided into the types of work he engages with customers on. In workshops, a challenge he faces is in firefighting. In processes, his challenges include a tension between the people who demand we follow process and those who just want to get the job done. They want simple but comprehensive processes, for example. In the training space, the challenge is how do you fit a training class in 2-3 days and that it is very hard to change people’s behaviors. In tools, he finds people want to try to use the same tool for everything, they really want to integrate it to other tools and they try to force everyone to use them without success.

And finally, Juha’s challenges were that they have a huge number and variety of potential customers to please and they have a large number of products to develop each year (in the 100’s). They have some interesting challenges around innovation and what adding value looks like. And it’s not always clear who is playing the RE role.

Juha’s (and to some degree Kouski’s) challenges are interesting because they work on a consumer product line (i.e. cell phones!), whereas most of the rest of us are working on large internal systems projects.

The panel made for was a fantastic blend of experiences, roles and types of projects. I will say that participating on it was a lot of fun! Brian did a great job chairing the panel. In particular the focus of the panel was on the audience’s interests and questions, so we had very good discussions out of that. I have jotted down notes on some of the interesting questions asked by the audience, but I will post that on another day!