How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? […]
Requirements: Knowledge and Understanding
[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. […]
You Are Creating Bugs In Your Software
No matter how good your quality process is, you are introducing bugs. This article reviews the places where bugs are introduced in the software development process (from stakeholders to users), and reviews ways to address those bugs.
Avoid the Abilene Paradox
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 […]
Elicitation Techniques for Processes, Rules, and Requirements
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). […]
10th International Business Rules Forum
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 […]
Business Rules Hidden in Use Cases
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 […]
Analysis Paralysis and Agile Development
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 […]
Requirements Details – How Much is Enough?
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 […]