There are a lot of traditional/waterfall projects out there. They continue to be very document-driven. Too much time is spent creating these documents, and they are not used effectively afterwards. They are wasting the time of the people producing and consuming (or not consuming) them.
One approach is to do just enough requirements (for example Stories) but focus on having real stakeholders or their empowered representatives interacting with the rest of the team. This certainly works, but is not the only way.
Another approach is to look at the outputs we are producing – and seriously questioning the value of each artifact. Documents, as something to read and absorb on the train home, are fine, but they must not be the outcome, just a stage in the transition from idea to working code. Having ideas, concepts, pictures, words – having a sea of requirements of one kind or another; and then pulling together different sets of requirements depending on the audience or the need – to me, this seems a lot better.
At the same time, it is high time that people working on requirements plan their work, and make that visible to the project team and beyond. Perhaps if we really understood how much time is wasted, we would do something more useful.
Working with Rational Requirements Composer and Team Concert has made me realize how easy it is to plan my work with requirements, and how I can help other people rethink the way they work with requirements. I hope you get the chance to try this too.