"Getting the Requirements Right Up Front"

Brian Marick posted this to the Agile-Testing Yahoo Group Today. I thought it was interesting … 1. It’s the job of the team to be able to respond well to requirements they didn’t anticipate. That will allow the business to adapt more quickly to a business environment that won’t stand still. 2. Something like 50 […]

Read More

Three days in Indy?

I will be in Indianapolis on Thursday, March 22nd, Presenting Rethinking Process Improvement at a meeting of the Indianapolis Quality Assurance Association (IQAA), with a one-day workshop on software requirements the day following. We’re value-pricing the workshop to make it affordable – $250 for a one-day class – about the price that a corporate IT […]

Read More

Requirements Methodology

If you listen to James Bach enough, you will eventually hear the idea that every practitioner should be able to articulate his strategy and methodology – preferably quickly – and defend it’s reasoning. Bach is generally talking about testing, but I’d like to talk about my philosophy on requirements for a bit. Now, I view […]

Read More

The Requirements Problem

Software Requirements are hard. Ok, let’s do some critical thinking on that. Why are requirements hard? In my honest opinion, the skill set to do requirements is a combination of writing skills, an understanding of the problem domain, and an understanding of technology. To paraphrase Jerry Weinberg, it’s not that you have to analyze requirements […]

Read More