Some books on how to write and manage requirements mention using a glossary. Most books on requirements don’t go into enough detail about either the importance of a glossary of terms, or the precise use of the glossary of terms. Or if they do, they under-emphasize the benefits of a well-defined glossary of terms. Walking a day in the moccasins of a business rules analyst helps us all appreciate the importance of a well-managed glossary of terms.

A look back at the best from a year ago.

Roger Burlton, of the Process Renewal Group, gave an excellent presentation Monday morning at the 10th annual International Business Rules Group: Developing a Business Process Architecture and Program of Change. A lot of good stuff about how to define, develop, and manage processes. One idea in his presentation was particularly compelling - that of driving process improvement strategy based on stakeholders. This approach looks at how much benefit the stakeholders can get from the improvement, and how much pain the current process causes them. A very compelling strategic prioritization tool.

I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design - and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.

A look back at the best from a year ago.

In our earlier article about managing stakeholder goals, we looked at the relationships between principal stakeholder goals and end-user stakeholder goals. We also showed a way to trace those dependencies. But that approach does not provide us with any insight about the alignment (or lack thereof) between differing goals. This article explores a means to visualize those relationships.

One of the most common mistakes people make when looking at data is to jump to conclusions about the data. We all live in a world of cause and effect. It is only natural that when we see data that appears to show cause and effect, we assume that it does. But it often doesn’t. This article shows the difference between cause and effect relationships and correlated data.

A look back at the best from a year ago.

A couple weeks ago we wrote about Outside-in Software Development, by Carl Kessler and John Sweitzer. One of their ideas about stakeholders and goals has got us thinking about traceability.

Microsoft has a product called Zune that is a competitor to the Apple iPod. They just recently announced their second release - the new version of the Zune. Since Apple already dominates that market, Microsoft qualifies as a follower - how are they approaching the introduction of a new product to compete with an 800 lb. gorilla?