The Case of Healthcare.gov

Last Sunday, returning from the great 3rd Global Conference on Transparency Research held at HEC, Paris, I heard for the first time about  the Healthcare.gov case.

I was reading  the French newspaper JDD, when a news story caught my attention:
"De l'autre, Cheryl Campbell, dont la société CGI Federal a reçu près de 200 millions de
dollars (145 millions d'euros) pour développer et veiller au bon
fonctionnement du site. "Nous n'avons pas bénéficié d'assez de temps
pour tester le site, a-t-elle accusé. Seulement deux semaines.""

http://www.lejdd.fr/International/USA/Obamacare-tourne-t-il-au-fiasco-635832

I did laugh.

After the trip I went on to look at Slate; and look what it says: "Everyone at the
hearing, contractors and representatives alike, seemed ignorant of what
is demanded by this sort of testing, with the exception of Jerry
McNerney, D-Calif., a mathematics Ph.D. and ex-programmer. He asked
about such specifications for integrations. Campbell said, “There were
use-cases and things of that sort,” evidently unfamiliar with what
specifications are (hint: not use-cases). Slavitt said, “We believe we
received appropriate specifications.”"

http://www.slate.com/articles/technology/bitwise/2013/10/healthcare_gov_problems_house_committee_hearing_is_a_spectacle_of_tech_illiteracy.2.html

No comments.

But there is more: "On his Friday call, Zients differentiated between
healthcare.gov’s “scale” issues and its “functionality” issues. I
believe this marks the first time that the administration has admitted
that healthcare.gov’s problems went far beyond the site being
overloaded. Zients said that account creation had now been fixed, with
more than 90 percent of users now able to create accounts. But only 30
percent have been able to complete an actual insurance application. And
that’s not even to say that the application is correct, owing to reports
of children getting listed as multiple spouses and the like."

http://www.slate.com/articles/technology/bitwise/2013/10/healthcare_gov_tech_surge_the_uninsured_are_now_unpaid_alpha_testers_for.html

I will comment about these paragraphs, soon.  They are good examples of the lack of proper Requirements Engineering.

Parnas on Requirements Engineering

A must read article from David Parnas on the CACM of Jun/11 tackles the problem of lack of discipline in performing proper Software Engineering.

I am quoting below some of the important remarks, but go ahead and read the full article (here).

“Software development suffers from an infirmity best called Premature
Termination; the symptoms are that developers begin to do something
useful but stop too soon. The result is something that is not only
not very useful, but often harmful.“

“Nowhere is premature termination more evident than in
the field sometimes called "Requirements Engineering" (RE).”

“Programmers are chosen for their ability to design good algorithms and data structures as well as their knowledge of specific programming languages and
support environments. They should not be expected to understand the needs
and characteristics of the future users. Often, a programmer makes incorrect
guesses about the detailed requirements and, consequently, extensive
revisions are required (either before deployment or after users complain).”

“Such lists are a good start but considerable work must be done before one
has resolved the conflicts and ambiguity in such a list to produce a
complete and precise software requirements document, one that tells the
programmers what they must build to satisfy the agreed wishes. It isn't
wrong to produce a wish list but it is wrong to hand it over to the
programmers as a requirements document.”

The Risks of Stopping Too Soon
David Lorge Parnas Communications of the ACM
Vol. 54 No. 6, Pages 31-33

Requirements Engineering´s Roots

I am honored to be among the first researchers to be involved in the Requirements Engineering area. We were involved in the first RE conference as well as on the starting of IFIP W.G. 2.9.

I have recovered, and made available, a literature survey on Requirements. This survey, "A Survey on Requirements Analysis", preceded my Ph.D. thesis. The document contributed to the amalgamation of the different sources that shaped the area. I was one of the first to stress the problem of using the phrase “analysis” to denote the semantics of building requirements. The survey was popular at some point of time, as to be listed on Amazon.

The text is a collection of around 200 bibliography entries, which are summarized and briefly commented.

During the preparation for a talk I gave at Professor John Mylopoulos´s Festschrift I needed to recollect his importance to Requirements Engineering, and as such I went to reread the report. From there it was clear the importance of Mylopoulos to the area, specially because of the book “On Conceptual Modeling, Perspectives from Artificial Intelligence, Databases, and Programming Languages”. Coming back to the Survey I came to the conclusion that it would be a good idea to make it available.

Systems Analysis versus Requirements Engineering

I have been teaching and preaching that the
phrase "systems analysis" is not a proper term for the task of
building requirements. In reality it causes a lot of
misunderstandings for young professionals.

In fact, the phrase "systems analysis" was used since, in the past,
reverse engineering an "existing system" or "old system" was the
popular way to gain insight about the Universe of Discourse.

Check some of the arguments in a brief summary of a panel
at WER 04.

Traceability

Well we all know how important requirements traceability is for software engineering.

I just found a curious example of traceability that has a lot to do with business processes and how the financial market does operate. I came to it from watching a video on foreclosures from ABC news.

The written material is here. It is an example of the lack of a proper process for keeping traceability. A side effect: for some people, it is becoming a possible relief, or at least a way of postponing losing their homes.

Brainstorming

When teaching about requirements elicitation, I do speak of brainstorming as one of the ways of conducting a meeting. Meetings are one of the key techniques for conducting requirements elicitation.

I have recently conducted a web survey on brainstorm and found some interesting posts. I am sharing what I have found:

1. An article at the The Heart of Innovation.
2. A trade press article that is easy to ready.
3. Donald Clark introduction to the topic.
4. A vendor description of the technique.
5. Last, but not least: a chapter of a book where you can find a real example of the use of brainstorming. Of the notes cited above, this one is the only one that describes how brainstorming did solve a real problem.

Is text-mining a good way to elicit requirements?

Yes, it is.

A landmark work on this topic is AbstFinder. Several other strategies exist. Original documents from the Universe of Discourse are information sources to be used in eliciting requirements. They are of fundamental importance.

However, we must be careful when and how to use text-mining. Way back a simple text-mining strategy was commonly used by some OO practicioners: underlining words in a given text, usually a requirements document in natural language written by clients.
Such strategy is not the best choice.

See what Mitchell Lubars, Colin Potts, and Charles Richter wrote in a 1993 ICSE paper.

"Some protagonists of OOA advocate a bottom-up
strategy in which the analys tunderlines or highlights all
the noun phrases in the source material[Rum91].
This produces a list of candidate objects that must then
be pruned according to certain guidelines. This strategy
is sensible for small problems: objects are likely to be
referred to by noun phrases; making the list requires
little judgement and is almost trivial: and object-oriented
methods make many useful recommendations to help the
analyst prune the list.

However,these tasks become overwhelming for problems
of the size we faced. Listing the noun phrases in a
500-page requirements document is a daunting task
of questionable value. A long, unorganized list is
not a good starting point for the next stages of analysis."

The Never Ending Story

Recently, Claudia Capelli called my attention to an IEEE Software Article with the title "Nurturing Requirements". The article was written by Dave Thomas and Andy Hunt who call themselves "T h e P r a g m a t i c P r o g r a m m e r s". The short article can be found here.

Claudia, who is working towards her Ph. D., liked the way the article points out to the fact that requirements are in constant change. The article is straight to the point.

Foster, bring up, nourish requirements. Is that the right way? I believe it is. Remember: requirements are a never ending story.

Is it ok to conclude the article with the sentence: "So, while you’re reading the rest of this issue about requirements and process, remember one thing. Requirements aren’t engineered; they’re nurtured."?

It is not! Despite the fact that requirements will evolve as " a complex, multi loop
multilevel feedback system" (using M. Lehman words), requirements elicitation, modeling and analyis must be done the proper way.

Which is this proper way? Answer: use a requirements engineering process. What is the catch? The catch is on using a proper process, which must be tuned to the case at hand.

Requirements evolution, or better software evolution has been a research topic dear to me for almost 10 years. We have introduced the concept of a requirements baseline which is in constant change, but is also the base for the required software.

By the way: if the title reminds you of something, probably it is the movie, or its originator´s book.