Less of a technical post, but something I harp on about daily in the office – Requirements.

Requirements are the cornerstone of a project’s success. Unclear (or undefined) requirements without a ‘success’ criteria kill projects; over the years I’ve seen this happen repeatedly. It’s a difficult problem – often the customer themselves doesn’t want to think about the problem very much, or you have internal politics trying to drive the requirements different directions, or a timeline that says that the requirements would have been completed a month before the project started.

For this reason, I love the (frankly, slightly dull) book “Software Requirements, Second Edition“. Yes, it’s a bit dull – but it’s clear, sensible, and covers most of the angles. There may be better books out there about software requirements too, but of the few I’ve read, this seemed the best to me.

The message that I took away from it was, sadly, that most people involved with software – as users, purchasers, developers and managers – have at best a woolly idea of what a requirement is. Typically requirements are defined in ways that are vague, contradictory, unverifiable, incomplete, or just not feasible.

“Must be idiot proof” – my favourite requirement from a recent project. It had a lot of requirements like that. Interesting, there were no requirements about quality of service, logging, maintenance, or deployment

Meetdux seems to agree that requirement are key, and has written a some good posts about it:

• 6 Requirements for writing SharePoint Requirements
• How to Define Measurable and Traceable Requirements for SharePoint Projects
• 4 Key Steps in Developing Requirements for SharePoint Projects

They’re well worth reading – I can identify with the descriptions in there!

So, the message – take the time. Learn what a good requirement is. Communicate that to the customer, and take the time to think (and write) clearly. Think about the things that the customer (or user) might not think or care about (but actually needs).