Month: September 2007

Dr. Pausch's "Last Lecture"

I just want to pass along a story I read in this morning’s WSJ that I think will appeal to this blog’s audience because a] it’s about one of our own; a “techie”, and b] it’s just a neat story. I really appreciated it, and think you will, too. Anyway, let’s take a short break from the rigors of discussing processes, documents, diagrams, meetings, deadlines, and the other everyday challenges of what we do as business and/or technology professionals while Carnegie Mellon Computer Science professor, Randy Pausch shares some of his “lessons learned.” [Dr. Pausch], was about to give a lecture Tuesday afternoon, but before he said a word, he received a standing ovation from 400 students and colleagues. They had come to see him give what was billed as his “last lecture.” This is a common title for talks on college campuses today. Schools such as Stanford and the University of Alabama have mounted “Last Lecture Series,” in which top professors are asked to think deeply about what matters to them and to give hypothetical final talks. For the audience, the question to be mulled is this: What wisdom would we impart to the world if we knew it was our last chance? At Carnegie Mellon, however, Dr. Pausch’s speech was more than just an academic exercise. The 46-year-old father of three has pancreatic cancer and expects to...

Read More

Handy Requirements Quality Digest/Checklist

This quick post is just to share an article I came across that I thought might be beneficial, especially to the relatively new analyst. “Specifying Good Requirements“, by Donald Firesmith, includes some good, basic information about requirement quality assurance. Basically, the article consists of a list of common requirement quality attributes (you know.. complete, correct, unambiguous, etc.) accompanied by questions that can be used as a checklist to ensure that your requirements meet the criteria of each attribute. Firesmith points out, [J]ust as we all had to learn the rules for writing grammatically correct English, we also have to learn the rules for writing high-quality requirements. And just as not everyone who can read and write can also author a publishable book, not everyone who can write individual requirements can organize them into a high quality requirements specification. Whereas the rules for properly specifying individual requirements are relatively easy to use once you learn them, experience shows that they are also not obvious to most people who actually specify real requirements on real projects. Considering that these rules may not be obvious to most, I thought I’d do my part and share the “good word”. Firesmith admits that the information he provides is really a summary of information that is readily available from many other texts and training. There is nothing new or groundbreaking here, but a quick scan...

Read More