Reality Check

Blog archive
Frustrated computer user set poor requirements. Here's how to avoid the same trap.

This week the Las Vegas Review-Journal carried a story about a man who signed up for Affordable Care Act insurance via the Nevada health care exchange, paid several premiums but later discovered (after a heart attack) that the exchange failed to send his selection on to the insurer. He is now stuck with a $407,000 medical bill. 

The man also “received nothing to confirm he had insurance,”  according to the story. Elsewhere, a Florida woman who was unable to disenroll from ACA insurance was quoted as saying, "I was blown away that they had not thought forward enough to realize that people are going to disenroll."  Confirmation is a basic requirement for any transaction system. If people enroll in a system, it is a basic requirement that they be able to disenroll. 

Most of the public’s attention until now has focused on the front-end of creating an ACA account: qualifying for assistance, comparing plans and selecting a plan. The failures noted above have to do with the back-end of the system, where a lack of proper requirements definition is hampering the system.

My personal experience using confirms this. 

I recently created an account, shopped for plans and completed an application on  After selecting the plans I wished to enroll in, the website told me I was finished and to remember to pay my first premium.  And then – nothing. I never received any information or notification confirming my selection or keeping me up to date on the status of my application. 

If we compare this process to ordering a product on, as the President did after the site’s launch, this would be like placing an order on and then receiving no confirmation of the order, no status information on when it was shipped and no tracking information.  So, as the deadline approached, I took the only reasonable course of action: I went to the insurance company’s site and re-applied myself. 

About a week later, I received a confirmation letter and bill to pay my first premium for the policy I selected on  So, like the Florida woman, I had two insurance policies as the result  of a blatant lack of forethought in defining the requirements for the exchange. (Unlike the Florida woman, I was able to then cancel the policy on

Why all this poorly engineered software for a marketplace – a type of software system commonly available from thousands of online vendors?  Where is the concept of operations that envisioned a marketplace in accordance with the President’s comparison of buying a “plane ticket on Kayak or a TV on Amazon”?  Where is the functional requirements document or set of agile user stories that walks through all the obvious use cases from start to finish and includes notification of the consumer on the back-end of the process?

If you think this is obvious and these tools clearly must exist, think again. I recently ran across an article that quoted a government CIO as saying that,  “the onus of requirements at inception also ends up creating a surfeit of software features.”  

To me, such a statement is shocking, sends the wrong message to government agencies and flies in the face of the many documented failures of related to the basic problem of capturing functional requirements. 

So, if you agree that such features are basic and should have been captured as functional requirements, we are left with two questions for government organizations: Is a requirements definition part of your systems development lifecycle?  And, if so, what is the “right” amount and level of detail for requirements specification? 

The right amount of requirements definition starts with a minimal requirement for all software development projects and then is further defined based on tailoring the level of detail to the scope of the system.  This is where project managers focus on the end user and define the expected behavior of the system for all key use cases.  This is done in agile via user stories.  Again, these types of requirements should be mandatory and non-negotiable. 

Unfortunately, this is also precisely where and the Nevada exchange failed.

The second part of determining the right amount of requirements definition is in the tailoring.  I am a big fan of tailoring the amount of rigor (and documentation) in a process to the scope and complexity of the system being built.  The smaller the scope, the less rigor required. 

Tailoring requirements definition calls for asking two additional questions. First, how are you partitioning development of your system? And second, how experimental or innovative is your system?  The answers to these two questions will determine how much effort you need to exert in deriving technical requirements from functional requirements.  In general, requirements tell you what should be done, and your design tells you how you are going to do it. 

Suffice it to say, that “the onus of requirements at inception” does NOT necessarily lead to a surfeit of features. In the case of the health care marketplaces, if done properly, this process will ensure that key end-user features are not neglected or omitted. 

In the end, it is the service to the citizen that is paramount.

Michael C. Daconta ([email protected] or @mdaconta) is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.

Posted by Michael C. Daconta on Mar 26, 2014 at 1:36 PM


  • Defense
    Soldiers from the Old Guard test the second iteration of the Integrated Visual Augmentation System (IVAS) capability set during an exercise at Fort Belvoir, VA in Fall 2019. Photo by Courtney Bacon

    IVAS and the future of defense acquisition

    The Army’s Integrated Visual Augmentation System has been in the works for years, but the potentially multibillion deal could mark a paradigm shift in how the Defense Department buys and leverages technology.

  • Cybersecurity
    Deputy Secretary of Homeland Security Alejandro Mayorkas  (U.S. Coast Guard photo by Petty Officer 3rd Class Lora Ratliff)

    Mayorkas announces cyber 'sprints' on ransomware, ICS, workforce

    The Homeland Security secretary announced a series of focused efforts to address issues around ransomware, critical infrastructure and the agency's workforce that will all be launched in the coming weeks.

Stay Connected