Again, a simple, but powerful approach that provided a high degree of usefulness for both the author and the author’s different stakeholders, as well as the vendor having to evaluate the request. Both sides found it valuable, which isn’t often the case with long, tedious requirements docs.

I really like the approach, and the clarity it gives to the vendors. And also to yourself, so that you are always keeping in mind why you are asking for something and not just creating a shopping list of cool functionality, or attempting to identify the solution.

I’m going to try this out on some upcoming enhancement requirements!

There’s lots of methods out there for prioritizing requirements. Our roots are in custom web development and we continually challenged our clients to prioritize their needs and wants. You can take a look at a fairly rigorous process from “Mr Requirements” Karl Wiegers (some great reading on his website and also in his Microsoft Press books on requirements).

These types of approaches rely on some kind of group consensus on the value of a requirement. When you’re not working in a custom development world however, it’s really easy to get caught up in the “it’s not costing me anything to have all of these features!” approach. The risk is to have 1000 requirements and for them all to be mandatory.

For introducing new intranet software into the organization and in particular social intranet software which may be very different from the previous intranet 1.0 paradigm, I’d argue that you need to focus the most on features that will aid in acceptance and adoption. What will get people using this tool? What’s our biggest problem that we’re trying to solve? If I could only pick three things I needed this intranet to help me with, what would they be?

What drives acceptance and usage (and therefore value) is perceived usefulness and perceived ease of use. I’d suggest starting there as an investigation with a larger group on what’s really important and what’s just window dressing.