standard Sherlock Holmes on the Necessity of Requirements

sherlock

Ok, now this is just for a little fun. During some time off a while back, I went to Project Gutenberg and downloaded The Adventures of Sherlock Holmes. I still haven’t read them all, but I was surprised to see the great detective speak out so strongly in favor of requirements in A Scandal in Bohemia.

It is a capital mistake to design and develop before one has the requirements. Insensibly one begins to twist business need to suit design preferences, instead of design preferences to suit business need.

Ok, so that’s not exactly what ole’ Sherlock really said. The actual quote is below.

It is a capital mistake to theorise before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.

The original quote actually stands well enough on its own in terms of practical software engineering advice. I just wanted to share the first one because, believe it or not, that is actually what I thought when I read that line. Wow! He could just as easily be talking about requirements before design, or understanding the problem before jumping to the solution! Yes, I’ve considered that deriving software engineering maxims from the dialog of fictional characters in my leisure reading may not be altogether normal.

But just so you know I’m not the only one that looks to apply business analysis to happenings outside the office (or vice versa, in this case), Terry over at the Requirements Defined blog posted an interesting article on how he, after some frustration in shopping for a car for his wife, decided to break down and elicit and prioritize her requirements for a vehicle. A few others (including myself) have commented on experiences we’ve had, or potential opportunities to use our project skills outside of the work-a-day world. Go have a look!

144 total views, 1 views today

About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.

Author Archive Page

Leave a Reply