I always say "people don't have requirements, they have problems they want solved". IMO too many people in software get hung up thinking "requirements" means some kind of detailed design document. You're gonna wait a long time for someone with a problem to tell you how to solve it...
Yes! But often they have a hard time expressing it in terms of a problem, but instead think of a way to solve it, and present that to you. This is bad both because you as the developer don't know what they really want to do, but also because, being inexperienced at software design, their proposed solution is usually not very good.
So often I find the first step is to back up from their proposed solution, by gently probing what their reasoning is, then once the problem is better defined, only then going forward again sketching out a solution.
I always get people wanting another "email when this happens". When I dig bit more into the details, a confirm page on save is a far better solution.
I find the worst are semi technical managers who have been promoted too early, as they come up with junior level programer type solutions and think they are being helpful working out that for you.
This is a prime example of where the writer is stuck in a pre-Agile world. (This was 15 years ago, and most of his hands on work was well before then) If one follows and believes in the Waterfall method, tightening requirements is the most important thing to ensuring that the original goals are met. Modern software engineering has realized that changing requirements are a reality, and forcing sign-offs doesn't help as much as a flexible process.
This was the agile party line, but nothing in agile development helps with the core problem of changing requirements. If you design/code a solution to one set of problems using an underlying set of assumptions and when someone shows up and changes those assumptions it doesn't matter if your using an agile process or a heavyweight waterfall process. The only difference is going to be in the amount of time it takes to iterate the design and tear the existing product apart and rebuild it with the new set of assumptions.
The real savings with "agile" methodologies is the understanding that the code is the documentation. This doesn't free you from having requirements or design documents, it just allows you to spend less time on that part of the process. For any sufficiently complex project not having block diagrams of how everything fits together, and basic documentation of subsystem interfaces just means you waste a ton of time reading the detailed implementation before you can understand how the system works.
In other words its the same problem you have with heavyweight processes. If you have to read 500 pages of design documents to understand how to integrate your routine, that is the same has having to read 50,000 lines of code to understand how to integrate a piece of code.
I think we're going the same direction. The investment is less before you have to change. If you spend 6 months gathering requirements that are obsolete (or wrong for unanticipated reasons) before they're finished, you've lost 6 months. Working in an iterative process ("Is this what you want?", "No, how about this?", "Or this?") reflects the reality that requirements change sometimes for external reasons, and sometimes because people don't know what you want.
Agile also shouldn't be an excuse not to document. My (perhaps not fully informed) view is that it's more about iteration.
Agile/scrum makes a valiant attempt with "user stories", but these frequently end up being precise specifications for the wing feathers of the actually desired magical flying unicorn pony.
So I have a database, 4 years on from the initial design, a relationship between two central tables goes from one-to-many to many-to-many (I asked at the time and was promised it wouldn't happen).
Neither Agile nor Waterfall are going to save me from a pain in the arse of a change that affects a lot of the application.
4 years on, neither will save you. That's an issue of trading off short term schedules for long term flexibility. (Not an absolute right or wrong)
Agile could have helped uncover the need earlier, or enabled the project to react to it mid-project. Post production changes don't seem better or worse served by either.
"Agile could have helped uncover the need earlier, or enabled the project to react to it mid-project."
The project is an in house database tracking the samples and pretty much everything else for a DNA sequencing centre. The (sequencing) tech changes fairly rapidly and database migrations are frequent. It is constantly mid-project.
If I asked three and a half years ago and was promised, "no it won't ever happen", how would "agile" have helped uncover it earlier? Would a load of unit tests written before have made a difference? A stand up meeting every morning? A scrum master? Sorry, that's just bullshit.
It came up when it came up, a couple of weeks back. For the time being the workflow in the organisation will have to workaround. Its not a common case, and its really not worth the effort at the moment.
For the record I don't do TDD, Scrum type Agile. I do follow a lot of the principles in the agile manifesto, I have to. I do what works for me and the organisation, and blindly following methodology wouldn't.
"Modern software engineering has realized that changing requirements are a reality, and forcing sign-offs doesn't help as much as a flexible process."
a "flexible process" sounds great. However, the reality is that when you allow flexibility, the project rarely ever gets completed on time or within budget..which also seems to be the main requirements for a business.
