Monthly Archives: January 2008

Requirements: Knowledge and Understanding

the thinker, by henkster [photo by Henkster]

Writing good requirements is more than just about following a set of rules. You can capture knowledge about your goals and your product with a set of well crafted requirements. But to truly write good requirements, you have to gain a level of understanding that surpasses knowledge. Insight springs from understanding, and insight leads to great requirements and ultimately great products.

Continue reading Requirements: Knowledge and Understanding

Enterprise Product Management – Broad and Deep

odd tree

When we’re part of a team creating software for the enterprise – an internally focused, IT initiative, we usually don’t think about product managers. Business analysts, systems analysts, and architects (of all varieties) are all commonplace. But not product managers. Product managers bring a perspective and a strategic focus that can influence the success of an IT enterprise initiative.

Continue reading Enterprise Product Management – Broad and Deep

User Adoption ROI

using or bypassing the software

You want your software to be used, not to sit on the shelf. You can’t achieve the ROI of your software if people don’t use it. And you can’t achieve the ROI of your software by forcing people to use it either.  Some will fail to achieve the benefits, and others will delay using it or refuse to use it entirely.  You have to make them want to use it, and you have to design the software for the users who must use it.  Otherwise, you won’t achieve the ROI.

Continue reading User Adoption ROI

Why You Should Test Your Requirements

checklist

We’ve written before about several characteristics of well written requirements, and one of those characteristics is testability. Ahamad has written an list of 10 tests of requirements, with an emphasis on assessing the testability of the requirements. The testability of the requirement determines if the resultant product can be tested to determine if it meets the requirement.
Continue reading Why You Should Test Your Requirements

Agile Absolves Developers

absolution

A client at a large company with large development teams and a long history of waterfall development made a comment: “The only people who are talking about doing this project in Agile are developers who think it will allow them to avoid responsibility.” My client may have been right (that people were saying that) but the developers who were saying it were wrong. Agile increases responsibility – it doesn’t absolve it.

Continue reading Agile Absolves Developers