Month: February 2007

The Cornell Method of Note-taking

Ok, so a lot of folks nowadays will type their meeting notes directly into their laptops, and that’s not a bad thing. It certainly saves time. However, there are situations where the old pen and paper is not a bad thing. I, for example, am still a traditional pen-and-paper note taker. Much like in college, I find that I retain things better in my memory if I jot them down, and then enter them electronically into a more “official” format. Also, if, Heaven forbid, I should lose my electronic copy, I like to have a hard, handwritten copy laying around. Call me old fashioned. Ok, so we’ve established the fact that manual note taking is not a bad thing, and that I do it myself. Great. So what’s my point? Well, I recently came across a method for note taking that I’ve really come to like. It helps the note-taker to retain information, and also makes it easier to scan old notes for key information. The method is the Cornell note-taking method. Basically, the sheet of paper is laid out something like this: For standard use of the template, you take detailed notes in the larger section to the right, and then write down questions and cues that you’ll look to later when reviewing the notes in the narrow column to the left. For example, when it came time...

Read More

What's the value of good requirements?

Numerous professional studies have shown that poorly understood software requirements are the number one cause of schedule and budget overruns and ultimately project failure. Studies have also shown that the earlier in the SDLC that scope is understood, and defects averted, the greater the cost efficiency of the project. In fact, the cost of fixing errors in the requirements phase is only 1% to 5% of the cost to fix bugs in later phases of the lifecycle (1). It has been said that $1 spent on developing thorough, clear and concise requirements technology, processes, procedures, templates and standards is worth $100 spent on fixing a system that does not meet user requirements(1). “Investing” in requirements engineering technology bears the following returns: Happier customers Better communication Lower system defects Reduced rework Faster development Reduced scope creep Less chaos! (2) Software requirements engineering is a blend of art and science. For that reason, and because each industry (and company, for that matter) has its unique own quirks and challenges, every IT shop has its own standards and agreements around what constitutes a “good requirement”(2). However, there are some global standards that should be followed, or at least leveraged as guiding principles. One of the chief goals of this site will be to attempt to gather and share industry standards and best practices in hopes that others in the field may benefit....

Read More

Business Analyst Job Description

So, what exactly is a Business Analyst? What is the role of the Analyst in the software development lifecycle? If you don’t want to be completely confused, don’t bother trying to get a conclusive definition by just “Googling” it. There are dozens of variations on the BA role depending on the company, and on the software engineering methodology used.

Read More

Functional Specs: Don't write them??

“Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different.”

Read More