Clinical Definition: Deficient or deformed requirements through lack of exposure to the light of reason in analysis and review during early lifecycle.
Symptoms: Missing or incomplete requirements; other requirements may be stunted, deformed or fragile. If untreated, the sufferer may go on to suffer Ambiguities and/or Assumption.
Cause: It is well documented that Requirements Rickets is caused by lack of exposure to requirements analysis and review process during the early life of the software project. Left untreated, the project objectives become distorted.
Case Studies:
Project W carefully defined the requirements of what was to happen in response to a specific condition but omitted to state what was to happen when the condition was not met. The project presented with uncontrolled error conditions which were rectified by grafting in an error trap. Although functional, surgical correction was inelegant and costly.
Project H had requirements which mandated a "user-friendly" interface but did not define "user-friendly" in the context of the target user. The project assumed a level of competence not possessed by the end user resulting in an unusable software product.

Clinical Definition: Ambiguity is inherent in all natural languages and overcome by contextual clues; in projects, ambiguity causes problems where tight definitions are required.
Symptoms: Imprecise use of language provides variety, mystery and humour to works of fiction and everyday life, but causes dizziness, nausea and confusion in software documentation. If diagnosed early, it can be cured and treatment is often easy and relatively painless. If left untreated, projects may suffer a lingering decline and slow and painful death. The ghost of the project often returns to haunt members.
Cause: Wording allows different readers to interpret the same requirement in different ways. Each may be unaware that there is an alternative interpretation of the same wording. Each assumes that their interpretation is the correct one.
Case Studies:
Actual cases are many and varied and range from minor confusion to complete misunderstanding of the system's objectives.
The plain English statement "If A is true, and B is true, or C is true then do D" was presented. It had been interpreted by different readers to mean either "If (A is true, and B is true) or C is true, then do D" or "If A is true, and (B is true or C is true), then do D" . In such cases, the use of mathematical notation may cure ambiguitis.
An attack of "assumption" often accompanies ambiguitis.
Related Conditions: Implementation Labyrinthitis ("spaghetti code") is a specific disease causing muddled and impenetrable design and code; staminitis is a condition causing loss of enthusiasm and reduced stamina coupled with a tendency to become distracted or sidetracked into trivial items.

Clinical Definition: A wasting disease causing wasted time due to hazarding guesses at the meaning of requirements.
Symptoms: See Ambiguitis; where the ambiguitis is due to multiple assumptions as to the meaning of requirements, a differential diagnosis may be made. Project documentation may be congested with "it is assumed" statements. There may be an overgrowth of the "assumptions and exclusions" region of documentation.
Cause: Associated with ambiguitis and also with a lack of contextual information accompanying requirements. May have a metabolic element as many cases relate to poor flow of information between requirements authority and implementation authority.
Case Studies:
Project C present to a consultant with severe congestion of "we shall assume" in the software requirements. These were traced back to unstable systems requirements. The "we shall assumes" had been allowed to take root even after the source document had been stabilised. The condition was stabilised, with difficulty, by a transfusion of baselined system requirements. All descendants of the software requirements had to be traced and treated and huge cost. It is possible to innoculate against assumption by raising a risk against poor system requirements.

Clinical Description: Design (and sometimes requirements) full of holes, making it liable to crumble or collapse when implemented.
Symptoms: Gaps, holes and mismatches in the design such that it is riddled with holes like a sponge or Swiss cheese. As the design grows, the holes also grow, but this is not apparent at a casual glance and sometimes not until the system cannot crumbles under strain. Entire interfaces may be missing because it is unclear where in the design they should appear.
Cause: Design detail (and often requirements) have "slipped through the cracks" and not noticed until implementation or test.
Case Studies:
Project Beta presented with "design holes big enough to drive a double-decker London bus through" due to poor team co-ordination and lack of peer review; the design collapsed entirely when scrutinised.
Project Hotel presented with "spongy design" (i.e. Design Porosis) traceable to requirements rickets or requirements porosis (requirement full of holes).

Clinical Definition: Degenerative condition of the system, descending into unpredictability, irretrievable madness and death.
Symptoms: The system becomes more and more unpredictable and erratic over time; attempts to remedy the situation further de-stabilize it.
Cause: An add-on disease. Attempts to modify an poorly designed or poorly understood system causes problems in other areas. These proliferate, affecting more and more areas until the system enters terminal collapse.
Case Studies:
Project M was an evolving system where code mods were fed back into the design. Over time, additions/changes to the software caused it to act in an unpredictable manner. Patches and undocumented fixes led to "spaghetti code" syndrome. The system and the design became a hotch-potch of mismatched modules.
Similar Conditions: Implementation Labyrinthitis ("classical spaghetti code") is a specific disease causing muddled and impenetrable design and code; if caught early it can be prevented.

Clinical Definition: Hardening of source code, making it very difficult to correct or upgrade without breaking some other existing capability. In advanced cases the code has completely ossified.
Symptoms: Maintaining one function causes others to fail.
Cause: Code is poorly designed, unstructured, poorly commented and hard to maintain. Code infested with global variables.
Case Studies:
These conditions are common in old legacy systems and unresolved cases of Implementation Labyrinthitis. They require aggressive therapy or intensive care to prolong life expectancies. Life support for seriously sclerotic or ossified legacy systems should be turned off (or euthanasia applied) and replaced by better designed and maintainable systems.
Project J presented with the early stages of Source Code Sclerosis which they wished to resolve before the code became ossified. Investigation showed that the hard-to-maintain code was caused by inexperienced software staff. Aggressive and expensive excision and replacement of the affected parts by a skilled practitioner resolved the immediate problem. Training was administered as a preventative measure.

Clinical Definition: Rampant deficiency of source document references in project documents.
Symptoms: Project documents lack references (citations) to source documents so that requirements cannot be traced back. Spurious requirements may appear spontaneously. Important information is hidden in unreferenced source documents. Content is repeated across several documents and over the course of time becomes inconsistent due to the update process. Scratching about for information may cause the documentation set to fall apart.
Cause: Attempts to make project documents into standalone artefacts rather than referencing out to source works; over time the source works may evolve but project documents do not keep pace.
Case Studies:
Document A, derived from 6 source documents was designed to be self-contained. 6 months later, document B, derived from document A was found to be inconsistent with the original source documents due to a process called "Chinese whispers". With no references cited in document A, the author of document B had been unable to cross-check for errors. As a result of this information hiding, the software did not fully meet requirements.
In another case, 3 man days were spent in tracing back to root documents due to lack of references within a top level software project document.

Clinical Definition: Unclear, clouded or missing items in project vision, not to be confused with the self-explanatory conditions of Project Myopia (short-sightedness) or Project Tunnel Vision.
Symptoms: Unclear, clouded or missing objectives; frequently diagnosed in development, support and maintenance reports, plans or guidelines. There are no clear statements of objectives and no vision of where things are headed. Progress is slow as afflicted projects must fumble their way forwards.
Cause: Poor documentation with no explanatory or context information. Posthumous Documentation Syndrome ("we'll document it later")
Case Studies:
Project A, a Maintenance Contract, presented with symptoms of Document Cataracts. Unable to see the way ahead, the project had gone round in circles and made no forward progress. Upon investigation, it was found that the original project had been hastily documented after delivery in order to meet urgent timescales. With no clear view of the system's aims, the project became mired in technical detail and were unable to see their way out.

Clinical Definition: Requirements defect or high level design defect propagates to multiple implementation defects at lower levels in a "cascade effect".
Symptoms: Multiple defects in low level design or code are traced to a single overlooked defect in the high level documentation; in some cases the original defect had been excised but the secondary effects were still present and continued to grow. As growth and spread continues, it consumes schedules and budgets and ultimate kills the project unless dramatic surgery is performed to locate and treat all affected areas.
Cause: Failure to fully treat the original defect and to locate and treat any secondary defects still in an early stage of development.
Case Studies:
Project O presented with its schedule and budget almost entirely eaten away before coding was complete. Investigation showed Content Cancers due to an uncorrected documentation error in a high level design document.
Another project, "PZ", presented with a particularly malignant form of Content Cancer caused by production of unnecessary documentation.
Related Conditions: A very specialised form of Content Cancer is known as Feature Creep and may be slowed, or even halted, by ensuring a separate budget allocation is raised against each creeping feature not in the original estimate.

Clinical Definition: Leakage of requirements out of software project objectives.
Symptoms: Occurs from design stage onwards, usually when timescales and budgets become an issue. Requirements are leaked out of the initial version with the intention of transfusing them in as part of a later version. Design and test effort may also be shed.
Cause: Overruns in early project stages e.g. over-complex solutions, unrealistic expectations, poorly understood requirement resulting in slippage at later stages; radical life-saving treatment is needed to save the project. Requirements are leaked left, right and centre in order to meet timescales.
Case Studies:
A project known to researchers as Ms B presented with symptoms of overrun and insufficient budget for completion. In order to meet project schedule objectives, a radical requirementectomy was performed to remove expendable functionality. Failure to tie off the connective areas resulted in slow haemorrhaging of software requirements into hardware implementation.
Related Conditions: Functionality Amputation, Requirementectomy.