With any software system, there "should be" ample documentation to describe the system, its requirements, design, security, etc. I say "should be," because documentation is usually only as good as the sponsor or project leader demands it to be. If expectations of quality and maintainability are high, the quality of the documentation should also be high.
If the system is half-assed, or there are no expectations for quality, or no one is checking up on documentation, it should be readily apparent.
If I was on the House Committee investigating this failure, I would tell Sebelius to bring all the HealthCare.gov documentation.
My point is, reading through, and understanding a well-documented system can take several months alone. They can't just expect a team to come to Washington for a week, tweak a few lines of code, and then be on their way.
Also, if it isn’t tested (and this one obviously was not) it isn’t documented. Documentation is the low man on the totem pole.
BTW, I’m a Lead Business Systems Analyst. Some of our work involves documenting legacy systems that have been working well for a while without it.
i.e. I’d like to see them ask Sebelius to bring the documentation just to see the position she fell in when she fainted.