Browse by Tags

All Tags » Requirements (RSS)

Physics and the Law of Lossy Requirements

This post over at The Eternal Universe is a physicist complaining about how he’s not seeking a computer science degree, yet he has to keep learning computer languages just to publish physics papers. He should have read my previous post about the Law of...

Software is Not Coding, It’s A Cooperative Game of Communication by Bruce Nielson

In my post on “code is really design” post, I mentioned that I would further address the paradox that software is created in “thoughts units” but the most important people to the success or failure of a project are the sponsor and customer . In this post...

The Law of Lossy Requirements by Bruce Nielson

Lossy Compression

In computer science, compression is an indispensible tool. Anyone familiar with .zip files knows what I mean. Interestingly, there are two kids of compression, lossless and lossy. Lossless compression is like .zip compression, you put a file of, say, 100kb in and the end result is a file of, say, 50k. But when you reverse the process, you get back your original 100kb file.

Lossless compression relies on the fact that in real life information contains patterns. Just imagine taking this post and finding the most common used words in it. Then replace the most common word with a the tag “<1>” and the next most common with “<2>”, etc. The end result would generally be a smaller file, yet by replacing “<x>” with the original words you could recover the original file in its entirety.

I used to wonder what possible use lossy compression could ever be. Why in the world would I ever want to save off a compressed version of my files if I couldn’t get them back to their original state ever again?


Comprehensibility vs. Precision by Bruce Nielson

Abstraction vs. Precision in Requirements

I used to be an instructor for Rational Software’s RequisitePro software, which included a class called “Requirements College.” This useful class helped teach people how to elicit requirements from their customers.

Three things that really stuck with me from the class were, first, the idea that one does not “gather requirements’ per se, but elicits them. If taken literally, “gathering requirements” implies that requirements are readily available and you just have to pick them up and take them. This flies in the face of reality; requirements have to be created from nothing.

The second was the idea that How and What are relative to a point of view. I’ve written about this in the past.

The third was that, according to the course, abstraction and precision form a spectrum that affects comprehensibility.  The idea was that if you are too abstract, your writing won’t be comprehensible at all. But if you are too precise, it’s also not comprehensible. The following graph illustrates the idea:


Tell me What to Do, Not How to Do It! by Bruce Nielson

Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. – George Patten This sounds like good advice doesn’t it? It is, actually, but we need to understand it correctly. The first thing we...

Does Robert Glass’ Formula for Estimation Success Actually Work? by Bruce Nielson

In a previous post I mentioned Robert Glass’ “fact” that estimates are made at the beginning of the project before the problem is even defined, thus the estimate is invalid from the get go. While I don’t disagree with Glass, I do believe he is under estimating...