Archive of Requirements gathering Articles

An excellent article by Jonathan Babcock raises a thought provoking idea. When gathering requirements, we can end up with requirements that no one actually wants, because everyone thought someone else wanted it. This is apparently known as the Abilene Paradox, a term coined by Jerry Harvey. We can apply our insights into stakeholders and traceability to prevent it.

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?

The 10th International Business Rules Forum is coming up fast in October 2007. Scott Sehlhorst and James Taylor will be presenting Getting it Right. Rules and Requirements in Software on Thursday at the conference. The articles on rules and requirements that he and I have been publishing on our blogs for the last few months are leading to this presentation. The IBRF has graciously offered a 10% registration discount code to readers of Tyner Blain. Read on to get it.

Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside use cases.

How do you prevent analysis paralysis? That’s the question Barbara opens up for discussion on the Business Analyst Blog. The answer is somewhat simple. You stop as soon as you believe you have something that reasonably covers the goals (or use cases) that you are trying to address. When you have requirement completeness, you move on. This answer is both naive and enlightened- especially when you consider the benefits of an agile development process.

What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail - for any given product or project, and any given team. The reason we write requirements is so that they can be read. Understanding the readers is the key to determining which details to include in the requirements.

We’ve written in the past about why it is important to gather and manage requirements. In short, you avoid some costly mistakes, and fix others before they become too expensive. We’ve also started exploring how business requirements and business rules live and play together. But why should we bother to separate business rules from requirements? One reason is to increase your company’s agility.

We had a great interview with James Taylor a couple weeks ago, where we talked about his new book, Smart (Enough) Systems.

James is an expert on decision management systems. I spent the late 1990s working on “rules-centric” software systems that allowed us to isolate rules and manage them seperately from other software requirements.

Traditional structured requirements approaches focus on the gathering and management of software requirements, but they gloss over the gathering and management of business rules.

James and I are exploring the best ways to bring these two points of view together.

With a definition of the important use cases for our agile project, we can move to the logical next step - which is what exactly?

Prototyping.

We proposed a strategy for developing use cases as part of an agile development methodology last week. In this article, we will look in more detail at that proposal, and also look at a specific way to apply agile techniques to the development of the use cases. What we propose is essentially incremental development of use cases, and starting what comes next as soon as you can.