You could always go with a waterfall approach, but you're going to end up with a system that meets a lot of requirements, but doesn't deliver value.
7
2
22
It's stupid to follow the waterfall process. Period. Actually I'm not sure anyone ever really recommended it.
2
Replying to @ewolff @fmueller_bln
I can imagine it (or something like it) might make sense for, say, a nuclear power plant control system

Oct 2, 2021 · 8:07 AM UTC

3
1
Replying to @stilkov @ewolff @fmueller_bln
Id agree. If you know the requirements waterfall is fine. If you have no clue about the market like every startup, waterfall kills you.
1
2
Now it becomes philosophical. :) I think you cannot prove to know all requirements (also from UX) in advance without delivering and learning. You can only falsify your claims. But, in some contexts, this can be enough.
3
1
more replies
Replying to @stilkov @fmueller_bln
The original Royce paper recommended several iterations. He worked in air & space, not unlike nuclear. The paper is from 1970. It was wrongly cited as the paper that described waterfall for the first time.
4
4
Sure. I just wanted to point out that agile development’s “learning from trying out things in production” might not be the best choice for every context :)
4
2
more replies
Replying to @stilkov @ewolff @fmueller_bln
I would like to point out that software like that is subject to changing requirements, too. Albeit on longer timescales, there are changes to regulations, standards, workflows, processes, equipment etc.
1