Archive of Requirements gathering Articles

Prioritization can be hard, especially when we’re dealing with a lot of variables. Peter Abilla, at shmula.com takes a fairly esoteric tool (interrelation digraphs) and applies it as a prioritization tool. Opthamologists have learned that they can’t show us a bunch of blurry images and have us tell them which one looks the best, and then prescribe a corrective lense. They have to ask us “Is it better like this? Or better like this?” Peter’s approach does the same thing, but with a quantitative edge.

The Monty Python troupe helps us remember five (no, three sir!) things about software requirements. And now for something completely different…

Finding the right balance when defining requirements can be hard. On one side, we want to avoid an inadequate system - “Don’t prevent my success by excluding features I might want”. On the other side, we want to avoid cost-overruns, delayed schedules, and negative-ROI features. This can be a hard line to walk.

What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.

How many people should be involved in requirements elicitation? A question from one of our readers via email.
Hi Scott, in the last months I faced the issue of managing the requirement elicitation phase in an Identity Management project. I have a very simple question. In your opinion how many people should do the [...]

Gathering requirements isn’t like asking kids what they want for their birthday. We aren’t giving our customers carte blanche, we are trying to identify the valuable requirements - things that solve problems and achieve value in a significant way.
Needs and Wants
Our customers usually know what they want. There’s a debate about if customers [...]

Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline - and we can apply it to any form of project-status. In this article, we will apply it to documenting business processes.
Thanks [...]

Estimating the gathering of requirements is hard. Not as hard as scheduling innovation, but easier than estimating implementation effort. One step in gathering requirements is often the documentation of the “as-is” process - how things exist today. We provide a framework for building those estimates - making the job a little bit easier.

Brainstorming can be a simultaneously fun and effective technique for identifying software features or requirements. We’ve written previously about how to facilitate a brainstorming session and how to leverage the results. Timothy Johnson shares another way to use the results effectively. His way is more fun, and maybe just as effective.

All process improvements are not created equal. How should we select which processes (or process steps) to improve? How do we approach this for a really large migration project? Start with understanding the potential for improvement and then narrow it down from there.