Firstly, I totally agree, this was far more a failure of design than operator.
Secondly, it wouldn't surprise me in the least if the design failure wasn't the fault of the software vendor. I work with fedgov groups regularly, and requirements & acquisitions can be very broken. It's even possible that the contracting office required it to be designed this way (I'm not kidding).
This is one of the reasons good product management is so important. There is an acute distinction between "Buyer Requirements" and "User Requirements", and if a requirement involves UI/UX, it really needs to be done by someone who knows how to design such things :)
One can only hope we learn from this, but I could see a possibility where this could make requirements even more rigid in the ways you've described. We need checks and balances that account for actual risk and a design process that can improve with feedback and testing.
It seems like some organizations are hamstrung into no-win scenarios.
One of the things FedGov has always struggled with is how to enact "checks and balances" that don't ultimately become /rigid requirements/. There are a lot of complicating issues in government acquisition, and political maneuvering can completely crater otherwise great ideas (this is true at companies, too, but I would argue is less prevalent).
It's worth noting that the National Defense Authorization Act of 2018 actually has a section devoted to piloting an Agile development & acquisition process for defense software systems to address a slew of issues, including the one we are discussing, here.
All of Subtitle H in the NDAA-2018 is relevant for people with an interest in how the FedGov handles software, but Section 873 specifically lays out the Agile Development initiative:
You stole the words I was to write. +1
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.