Real-Time Animator and Requirements Traceability - Using Event-B for Critical Device Software Systems - page 79

5.1.1 Structure of This Chapter

This chapter is organised as follows. Section 5.2 presents motivations behind this
work. Section 5.3 presents basic definition of traceability and Sect. 5.4 presents
related work. Section 5.5 presents basic details about animation and their benefits
and limitations. Section 5.6 presents the functional architecture which enables the
animation of a proved specification with a real-time data set. The functional archi-
tecture is then illustrated in Sect. 5.7 for applications and case studies. Section 5.8
presents limitations of this tool and finally Sect. 5.8 summarises the chapter.

5.2 Motivation

To discover the real requirements, discover errors in the early stage of the system
development and design a quality system, we need to look beyond the system itself,
and into the human activities that it will support. For example, medical systems are
mainly used by doctors, physicians, medical practitioners and patients in a more
convenient ways for their own purpose. The medical device manufacturing compa-
nies are providing safe, secure and profitable services to stakeholders. Such human
activities may be complex due to several involvements of many people with different
types of conflicts of interests. In this situation, it is hard to handle any problem and
to reach final agreement among the stakeholders. Requirements engineering tech-
niques offer ways to handle complex problems by decomposing into simple ones,
so that we can understand them better. Complexity of a system classifies it into a spe-
cific class of problems known as wicked problems [ 45 ]. This term was introduced
by Rittel and Webber [ 45 ] for problems that have the following characteristics:

• There is no proper definition of the problem—such as each stakeholders have

their own definition of the same problem.

• Wicked problems have no stopping rule—each solution is likely to extend into a

new set of problems, and the problem is never likely to be solved entirely.

• Solutions are not exactly in the form of right or wrong, but it provides for better

or worse solutions.

• There is no any fixed standard for a particular solution. Solution results are de-

pended on the judgement of various stakeholders according to their needs.

• For wicked problems, there is no any fixed enumerable solutions. The solutions

are discovered during problem analysis.

• Every wicked problem is unique and considered as sufficiently complex and dif-

ferent from others.

•

Every wicked problem is a symptom of another problem, which makes difficult
to choose an appropriate level of abstraction for describing the problem.

• The designer has no 'right' to be wrong. In other words, designers are liable for

the consequences of the actions they generate.