Understanding someone’s perspective on requirements requires that you appreciate the context in which they’ve formed that perspective. Not everyone is playing the same game on the same field.
Interrelation Digraphs As Prioritization Tool
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.
Monty Python and Software Requirements
The Monty Python troupe helps us remember five (no, three sir!) things about software requirements. And now for something completely different…
Don’t Prevent My Success
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.
Business Rules And Requirements
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 for Requirements Elicitation?
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 […]
Nice To Have
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 […]
Burndown Bullied Into Business Analysis
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 […]
Estimating the Effort of Documenting an As-Is Process
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.