| > - It is driven entirely by formal requirements and specifications Can you explain why this is a bad thing? I've found that formal requirements and specifications are almost always good unless they're just vague (in which case: they're not really formal) > - These requirements are approved by "the customer," which is a set of people completely independent from "the actual users." Well, yes. That is indeed a problem. > - A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance. I've found that very very few people actively request people to say "your UI sucks". Instead, they want "constructive criticism" and/or "describe why it sucks!". Which, is sort've fair. But it gets to be extremely tiring to explain why the UX doesn't "just suck" but is fundamentally flawed. > - The developers often pat themselves on the back for meeting the requirements. Nothing wrong with that either. > - The customer has to accept the software and foist it on the users, because it meets the requirements. The customer has to accept the software because that's how contracts are done. But they don't have to foist it on the users. They just want to show that they've been able to deliver on their promise of a software solution. > - The competition is entirely about who gets the contract to build the software, and not for which software is actually the best. Well that's quite a problem. |
I have been in various projects for government and enterprises (non military, mostly medical and banking fields) with formal requirements and some without. I can say that those without always had better GUI and people using them liked it better. I think that one major reason is that most people can't really imagine application without actually using it. Only once they are using it they can give you useful feedback (as in this is important, this isn't, make that action default etc.)
Another reason is that people that are not using it are writing requirements. For instance in a lot of medical applications, people who will write specs and requirements are Business managers or doctors (or both), but not radiology technicians and nurses that will actually use the software. So they have no idea of day to day workflow - just desired outcome. So software will suck 100% if based only on their requirements (in my personal experience).