How does requirements gathering change when development is continuous?
For Agile teams, continuous requirements gathering will be very familiar. The changes an agile team will likely make as it transitions to continuous delivery or continuous development are in many ways more of the same: iterations become shorter, the scope of each project decreases, and requirements grow more flexible.
The difference in continuous development is that communication, modeling and design discussions occur continuously and not only in scheduled meetings. Teams don't need to sit in a circle, holding hands and singing "Kumbaya." But they must be comfortable asking questions, bringing up ideas and discussing them in the group -- repeatedly, if necessary. Talking among the team is important. It doesn't matter if it happens in person or via IM, email or teleconferencing. What's important is that it happens.
Many teams use a white board to draw out design ideas; while others may use modeling or flowchart techniques, depending on the size and complexity of the change or its implications to other parts of an existing application. The important part is that the team decides on the mode of communication they implement best. The right tool is the one that works best for that particular mix of people.
It is also essential to an Agile team's success that requirements be documented. They can be part of a user story or any other type of document. The purpose is to save ideas and track what the code does, continuously. Team members change and business priorities change, so it's imperative that design decisions are documented continuously, as well.
Generally, complex changes should be broken down into smaller pieces. Smaller pieces are easier to manage, and that's the secret to continuous success. Continuous development doesn't remove the responsibility of defining requirements, but it requires they be gathered continuously as features are designed.