This commit is contained in:
Robin 2010-06-05 10:36:45 +01:00
parent 3776001738
commit 09d4ebc3d1

View File

@ -207,7 +207,7 @@ Each `test case' is analysed.
The component failure modes are examined with respect to their effect on the functional~group.
The philosophy behind this analysis is, how will the functional~group react
to each of the test case conditions. The aim is to produce a set of failure modes from the perspective of the functional~group.
\paragraph{Symptom identification and collection}
\paragraph{Symptom identification}
When all `test~cases' have been analysed a second phase is applied.
%
This looks at the results of the `test~cases' as symptoms
@ -352,7 +352,7 @@ $$ FM(DC) = \{ SP1, SP2, fgfm_6 \} $$
Note that $fgfm_6$, while being a failure mode has not been grouped as a common symptom
has {\textbf not dissappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear in the derived component.
This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner, my advice to all nine year olds is its best to throw the brussell sprouts out of the dining~room window while the adults are not watching!}!
This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner, my advice to all nine year olds faced with this dilema, is its best to throw the brussell sprouts out of the dining~room window while the adults are not watching!}!
The process must not allow failure modes to be ignored or forgotten.
@ -400,7 +400,6 @@ model.
\clearpage
\section{A Formal Algorithmic Description of `Symptom Abstraction'}
The algorithm for {\em symptom abstraction} is described in