From 55ebba980cd2b427bc1fc5fc96784deb25f8c7eb Mon Sep 17 00:00:00 2001 From: Robin Date: Sat, 8 May 2010 11:06:40 +0100 Subject: [PATCH] after Friday meeting with Andrew Fish --- .../component_failure_modes_definition.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index 0205fc8..106be87 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/component_failure_modes_definition/component_failure_modes_definition.tex @@ -121,8 +121,8 @@ In terms of our UML model the symptom abstraction process takes a functional~gro and creates a new derived component from it. To do this it first creates a new set of failure modes, representing the fault behaviour -of the functional group. This is a human process and the analyst -will consider all the failure modes of the components in the functional +of the functional group. This is a human process and to do this the analyst +must consider all the failure modes of the components in the functional group. These new failure modes are derived from the functional group, we can therefore call these `derived~failure~modes'.