What on earth do pictures have to do with Requirements? While I was at university studying Software engineering management I was lucky to have Dr Ian K Bray provide a unit of Requirements Engineering. Why is that such a big thing for me? I’ll tell you, Dr Ian K Bray is the author of one of the most popular published books on Requirements Engineering (An Introduction to Requirements Engineering)

The biggest eye opener in all of this was the fact that, using use-cases and diagrams to explain the functionality and intent of a software system would drastically reduce the incongruent nature of written requirements. Barry Boehm (and any other reputable author on software engineering) defines one of the biggest reasons for a project failure lays in inadequate requirements documents. This is also not due to the fact that we just miss requirements, or that the client may explain things in an ambiguous way, even if we get all this right, the very nature of our language is inert and has room for open interpretation. This is great for poetry and the arts but when we enter the domain of requirements engineering it lacks something we desperately need… a coherent, defined and accurate understanding of the intended outcome.

How can pictures help?

Well, I don’t want to regurgitate Dr Bray’s work to you; for starters I would not do it justice in a blog post. I do however recommend you pick up a copy when you can.

I also like a blog Published by Brad Egeland | January 20, 2010

“People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.”

You can find the full article by Brad here!

What do you use to document requirements? Pictures? Use-cases? UML? VDM? Let’s hear what you think of the methods you use…