May 06 2012

Octo Barnett’s Classic Comments on the DoD requirements process

Published by at 9:01 am under history of computers,VistA

If I had to name the folks who had the most influence on my career development, I would have to name Dr. Octo Barnett, director of the Massachusetts General Hospital Laboratory of Computer Science.  Out of his laboratory came the MUMPS computer language, designed specifically for medical information processing,

Here is his 1984 paper 1984 Octo Barnett responds to MITRE report on DoD methodology that takes DoD to task for the way they try to define a hospital information based on the requirements process.   Some tidbits from his paper (I’ll do a full write up later):

He stresses adaptability, flexibility, user involvement, robustness…

In some cases… the requirements are nothing more than vague wish lists… it is even more difficult to understand how DoD could systematically evaluate to what extent the delivered system fulfilled the requirements”

When I worked on the original CHCS proposal effort at SAIC, I had to demonstrate how the software conformed to list of about 150 requirements.  One requirement was that the system should recover from a power failure within 30 minutes, which was a really crucial thing in a hospital.  Another was that the system should be able to ring a bell on the line printer.  (Line printers were a throwback to the batch processing days of old; the requirements also defined card punch procedures, even though we weren’t using cards any more.

The day of reckoning came, and we had DoD, GAO, congressional staffers, and my own management looking over my shoulder as we worked our way through the requirements.  I sweat blood making sure we met the 30 min recovery time requirement, and everyone accepted the demonstrations without any questions or concerns.   We moved on to the bell on the line printer requirement.  I sent a bell code to the printer, but nothing happened.  I tried again, still no bell sound.  Eyebrows were raised; the room went silent as it looked like I might fail this requirement – which was as significant as showing that the system could recover from a power failure.

It was nearly lunch time, so I suggested everyone come back after lunch while we called Digital and asked the Maynard engineers what was going on.  I think we solved the problem by plugging the printer into a different port.  Everyone came back from lunch, I rang the bell, all breathed a sigh of relief, and we were off for the other 148 other requirements for the day.  It was kind of we were all in a puppet show, going through the motions, with no one understanding what was going on.

The more I read the DoD requirements, the more I find that the “emperor has no clothes,”

He goes on to talk about “gold plated” DoD requirements, while explaining the the DHCP system is just a simple beginning.  The question is whether the system can evolve.

The fundamental principle of the VA strategy is that the user community must have an important role in the shaping of their information system, and must have an important role in the evolution of the system over time.  The TRIMIS strategy ignores this user involvement and makes an assumption that the vendor can supply the information system in a well-wrapped package that can easily be fitted into the hospital operations.   I believe that the highest priority should be given to testing these two different strategies in the DOD environment….. what we do know is that this strategy has been associated with an impressive set of functioning medical information subsystems on a very limited budget and with much greater user involvement that appears possible with totally vendor created information systems.

Unfortunately, this parallel test never happened.  While DoD accepted the DHCP software (or was forced to accept by the financial realities of the bidding process), they rejected the idea of user involvement, open source (public domain) software, and shared development with the VA.  This was due to intedepartmental turf wars as well ideological chasms between DoD’s “waterfall” requirements-based design vs. VA’s evolutionary design, starting with “good enough” and moving forward in response to user involvement.






Comments Off on Octo Barnett’s Classic Comments on the DoD requirements process

Comments are closed at this time.

Creative Commons License
Images by Tom Munnecke is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.
Based on a work at
Permissions beyond the scope of this license may be available at