What is a good way to specify requirements?

What is a good way to specify requirements? I actually have no idea… I come across many different companies and a lot of them all have the same problem. The customer wants some problem to be solved and multiple people start thinking of a solution. Sometimes the technology is already chosen before the problem is fully specified, but that’s something for another post. 🙂

Although I wouldn’t know what the best solution for your company or product is to specify requirements, I know a good document when I come across one. I used to work with Use Cases at my previous employer, which worked quite well. It probably wasn’t even the Use Case, but more the writer(s) of them.

But I’ve found some nice examples that Microsoft is using for specifying their requirements for Team Foundation Server (TFS). There’s a somewhat older document that can be found via Buck Hodges (pronounce : Buck Rogers) his weblog. It’s about the Continues Integration (CI)features in TFS 2008.You can also find three new documents on Rosario, the next version of TFS & Visual Studio. You can find all three here and probably more will appear in the future.

The first about CI contains just samples for the screens with explanations. The new three contain also a load of text. They might not 100% suit you, but you might probably get an idea to what both customers and developers might fully understand. And that’s important, or else you’ll get something like this.