BABOK Requirement Types in Haiku

Business has a need
Stake holders require outcome
Function shows the way

(This may be one of the geekiest things I have ever done.)

Classic Software Engineering Essay

While I was doing some research for a requirements health check offering for work I came across this classic article that I remembered from an old battered copy of mythical man month called “No Silver Bullet”.


What it drove home to me was how little has changed in the 20 or so years since it was published. Good requirements are still central to the value IT delivers and we (as a society) still suck at them.

It’s an old article (1987) but still as valid as the day it was written. I especially love the way you can see the ideas that will come to be known as agile and cloud in it.

Article Text:http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

Lecture Notes on Article:http://www.cs.colorado.edu/~kena/classes/5828/s09/lectures/02-nosilverbullet.pdf

It's amazing how little the fundamental problems of building solutions have changed despite all the technical hype. Especially this quote “I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.”

Requirements are probably the hardest part of the solution development process, and the part that adds the most value. If technical design, project, and implementation are all fantastically then the result is that the solution is on budget and on time. But if the requirements and solution design are fantastic then it makes a real impact on people’s day to day lives, how well they do their job, and the effectiveness of their enterprise as a whole.

If you have an opportunity I recommend reading the article on the way home not in the office on your screen. It’s way too dense for that.

P.S. Some of the article is a touch dated. Time-Sharing is no longer a big change for example, and OO is not an innovation anymore; however Ada remains sadly under-used. Other bits are very prescient, such as a move towards iterative change driven development (e.g. agile), buy-vs-build, and even a touch of cloud.

Service/Security Levels

Here's an idea - next time you need to classify a service, product, or outcome based on quality - use a method that matches the service. Don't fall back on the old Gold/Silver/Bronze. Instead use a classification that gets across the trade-offs that are always implicit in classification.

For example when I'm doing security classification I like to use Titanium, Steel, Glass. This gets across that working with titanium is quite difficult, steel is easier, but if I want the service to be open and easily visible glass is a better choice.

It also gets away from the idea that more expensive is better.