When it comes to requirements “communication” is the name of the game. An analyst could crank out top-notch technical documents or business cases, but if their intended audience isn’t able to consume it then ultimately the work was for naught. It’s to this end that we use things like visual models to help get the [...]

I do a lot of what could be considered firefighting on my current project.  I’m often given tasks with very short deadlines.  Tasks that would normally require days to complete need to be performed in a matter of hours.  One of these tasks was to perform an “audit” of the requirements for the project (I [...]

Number 7 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.” Short-change Time Spent on Software Requirements or Don’t do Them at All Don’t Listen to Your Customer’s Needs Don’t use Models Use Weasel Words [...]

Number 6 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.” Short-change Time Spent on Software Requirements or Don’t do Them at All Don’t Listen to Your Customer’s Needs Don’t use Models Use Weasel Words [...]

Traceability definedI first was introduced to traceability years ago by Karl Wiegers in Software Requirements (First Edition) and was immediately sold on the impact it brings to a project. As important as it is, I noticed that few projects actually did it. I’m in a position now where I do apply it, and I find [...]