The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.
In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices
A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time. After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no. Let’s see this concept in practice in the “Requirements for My New Car”: a fable.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: