Appendix IV-Brainstorming summary

The cinegram design process involved a  brainstorming [1] session which took ca. 90 minutes and involved 6 service engineers of the oil system group, and one consultant who was formerly a manager at Rolls Royce and is a seasoned troubleshooting specialist. In a first silent phase of ca. 15 minutes, service engineers articulated ideas on cards. The rest of the time these ideas were discussed and elaborated. The designer continued to record the main ideas on cards which were sorted with the other cards.

The  session started in response to the following prompt by the designer:

A list of the main issues is presented below. Quotes are from the cards distributed before the session. The following topics seem to encapsulate the main requirements:

• Direct access. One of the most unanimous results was the requirement for direct and immediate access (‘Ready accessibility’, ‘available on mainframe to user - access rapid’). The need for direct access is also implicit in all requirements for integration across different systems .
• Integration. Statements indicated both a need for integration within systems (‘animation of AOHE + FOHE operation’, ‘component location on engine’), and integration across systems (‘'multiple' ETG presentation … system combines oil system ETG with airflow/ pressure/ temperature ETG to provide easy cross reference’, ‘Tech Pubs cross reference[IPC] …'clicking' around system schematic allows access to IPC information (P/No's, ATA ref, drawing of e.g. pipe fittings etc.)’; ‘link into IPC’; ‘linked to a SB [service bulletin] database’). A third type of integration is the inclusion of mathematical simulation models (‘Maths model link (thinking graphics)’). Integration with the paper world was also mentioned (‘print a picture or sequence for explaining in a fax?’; ‘primarily used in search mode but also useful for prints’).
• Dynamics and state changes. There were a range of different entries which I group under this heading, for example, fault simulation (‘trigger faults actively’; ‘What if? This doesn't open or opens too slow’; ‘failure representation’); varying values of parameters throughout the flight cycle (‘access P, T, F in flight cycle’); and displays of causal and physical connections (‘sequence of events [this rotates, pushes this, opens this]’)
• Equipment history. There were many statements indicating the need for comparison across different modification standards (‘Would show different mod standards, i.e. a computerised series of general assy drawings’; ‘The animation could show the effects on the oil system of different combinations of modification standards…it could show the effects of previous defects as we become aware of a new problem’ )
• Confluent data display. This related to the confluence of content dimensions in the graphic display, for example, the embedding of numerical data or references in illustrations (‘display of data on animation’; ‘show series of mod standards of general assy drawings’; ‘data through power range’)
• Resource validity. There were several warnings that numerical values derived from simulations had to be treated s approximate rather than conclusive (‘-Data accuracy problems?’; ‘*data accuracy risk*’, ‘displayed data correct?’, ‘Qualify data - not take as read’)

The list attempts to reflect the ranking of requirements. This ranking, however, is not based on a quantitative measure (e.g., based on the number of times a particular requirement was mentioned in the brainstorming cards); instead, is based on the perceived importance of topics in the group discussion following the written part of the brainstorming [2].

Footnotes to Appendix IV-Brainstorming summary

[1] The procedure followed the brainstorming method described by Jones (1992/1970, p274).

[2] There are at least three reasons why a quantitative measure does not work: (1) Requirements are expressed differently by each member. Mapping the lexical items on the cards onto conceptual categories always involves choices which could be made differently; (2) A number of items express several requirements simultaneously; for example, a card carrying the inscription "Call up different ETGs (with pressures, temp, etc.) for varying flight conditions" points at structural integration ("different ETGs"), data access ("pressures, temp, etc.") and temporal integration ("varying flight conditions") at the same time; (3) Important requirements hardly mentioned on the cards forcefully emerged in the discussion. The need for quick access, for example, was actually not often put on the brainstorming cards, but was strongly emphasised by everyone in the following discussion once it surfaced as a topic. It seems that this requirement was so central that is was in fact transparent to people explicitly seeking to define desirable system properties.