A look back at the best from a year ago.

A first look at Outside-in Software Development, available tomorrow (or pre-order tonight on Amazon.com). At the time of this writing, the book is #29 on the Hot New Releases list - and you can get it for just over a third off the price if you pre-order now. Take a look at an overview of the book and our first impressions - then give the book a bump and let the wisdom of crowds take over.

We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently - and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.

There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.

A look back at the best from a year ago.

You’ve written a project plan. Your team is ready to start. Here’s the bad news - you’re going to fail. But why? How can you avoid failure?

It isn’t just about finding customers anymore. You have to build fans. Take a look at the dynamics of word of mouth marketing and how they can cause your product to succeed. This article includes tips and references for helping you move through each stage in the cycle of fans, maximizing opportunities for word of mouth marketing for your products.

A look back at the best from a year ago.

Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?

Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea - it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.

A look back at the best from a year ago.