FMEA

The FMEA is done on the “first zoom level” of the architecture,

The relevant elements are annotated by oval labels, see also the diagram legend.

Fault Model

The following analysis is based on this generic fault model for activity diagrams:

Element Type

Error ID

Generic Error Description

Data storage

DS1

Stored data changed before read operation

DS2

New data not stored / keeps old data / stuck at specific value

Data flow

DF1

Transferred data changed

DF2

Transferred data lost

DF3

Data stored at / read from wrong location in data store

DF4

Data transferred to wrong data store

Processing

PR1

Calculates wrong results

PR2

Processing is skipped

PR3

Processing too slow/fast

Control flow

CF1

Control flow stops

CF2

Control flow proceeds to wrong process

If more than one error is identified for the same element with the same error ID, a counter is added, e.g. PR1.1, PR1.2, etc.

In the following sections, references to files are shown which end with _spec.rb. These files are test files which can be found in the spec folder of the Dim tool, e.g. <Dim root>/spec/options_spec.rb.

Generalized Errors

The following errors are analyzed generically and not on architectural element level.

Error ID

General Error Description

Measures

DF1, DF2, DF3

Data is corrupted or lost during file access or wrong files are accessed.

This tool runs without network access or memory queues. It is assumed that underlying layers like Ruby or the OS are qualified. Potential issues with data are analyzed in “Data storage” and “Processing” elements.

DF4

Every data store type exists only once in the system, e.g. “Input files” cannot be stored in “Exit code”.

Trying to do something like this will lead to a program exception. Dim will terminate with an exit code != 0.

PR3

Dim has no strict timing constraints and has no concurrently running threads, so it cannot run too fast. However, a too slow execution might frustrate the user, so that the user removes the mandatory check on the code review tool.

It’s mentioned in the integration guideline of Dim that the verifier from the code review tool is mandatory and must not be removed or skipped.

CF1

A complete stop of the control flow is usually no problem for a tool which runs offline and not on the target hardware. Dim is used for verifying changes on a code review tool. A stopped or terminated Dim check due to timeout must not lead to a merged commit.

It’s mentioned in the integration guideline of Dim that the verifier from the code review tool must exit successfully, otherwise the commit must be rejected.

CF2

This is a very generic problem and can lead to random errors.

The likelihood is reduced to a minimum by intensive unit tests. To ensure that enough unit tests are written, the code coverage is 100%.

Command Line Workflow

This analysis is done on the Fig. 11 with the Use Cases in mind.

Element ID

Error ID

Specific Error Description

Measures

References

p1

PR1

Incorrectly treated command line arguments will lead to unpredictable behaviour.

In most cases wrong command line arguments will lead to an error, which means Dim terminates with an exit code != 0. In many cases the user will recognize if Dim is doing unexpected steps like formatting instead of exporting, or using a different export output format. Reviews are mandatory. Tested by unit tests.

options_spec.rb,
Integration Guide Verifier,
Integration Guide Export

PR2

No options are set, Dim is not executing the intended steps.

Dim requires some arguments to be set. If not written into the options data store, the program will raise an exception when trying to access the options data store which leads to an exit code != 0.

Workflow Execute Subcommand

p2

PR1.1

Files are loaded incorrectly, not loaded completely or wrong files are loaded.

In most cases syntax and consistency checks within the loader will recognize the errors and Dim will terminate with exit code != 0. Otherwise the data store data will get incorrect data. This can often be recognized by the user or latest by the reviewer in a code review tool. Reviews are mandatory. Tested by unit tests.

loader_spec.rb,
requirement_spec.rb,
consistency_spec.rb,
Integration Guide Verifier,
Integration Guide Export

PR1.2

Files do not exist.

If files do not exist, Dim will terminate with an exit code != 0. Tested by unit test.

loader_spec.rb

PR2

If loading is skipped, no requirements are available for subsequent steps.

This is recognized by the user or latest by the reviewer in a code review tool, e.g. getting empty export files.

Integration Guide Verifier,
Integration Guide Export

p3

PR1.1

The formatter changes the Input files incorrectly or writes incorrect Separately stored formatted input files.

In most cases this is recognized by the user or latest by the reviewer in a code review tool. Reviews are mandatory. Tested by unit tests.

format_spec.rb,
Integration Guide Verifier

PR1.2

The exporter produces wrong files or writes them to a wrong location.

In most cases this is recognized by the user or latest by the reviewer in a code review tool. In a verifier, subsequent steps will fail. Reviews are mandatory. Tested by unit tests.

export_spec.rb,
Integration Guide Verifier,
Integration Guide Export

PR1.3

The built-in stats are incorrect.

In most cases this is recognized by the user by doing sanity checks. Statistics reviews are mandatory. Tested by unit tests.

stats_spec.rb,
Integration Guide Statistics

PR2.1

The formatter does not write the output correctly or the format options are not processed correctly.

In most cases this is recognized by the user or latest by the reviewer in a code review tool. Reviews are mandatory. Tested by unit tests.

format_spec.rb,
Integration Guide Verifier

PR2.2

The exporter does not write to Exported files.

Non-existing Exported Files will lead to an error in the verifier. Reviews are mandatory. Tested by unit tests.

export_spec.rb,
Integration Guide Verifier,
Integration Guide Export

PR2.3

The built-in stats are not printed to the console.

Recognized by the user. Statistics reviews are mandatory. Tested by unit tests.

stats_spec.rb,
Integration Guide Statistics

p4

PR1

The exit code is set to a value != 0.

An exit code != 0 indicates an error. A verifier will reject the commit. In almost every unit test the exit code is checked.

Integration Guide Verifier

PR2

The exit code is not set explicitly. A value != 0 is used by the underlying Ruby or OS framework.

An exit code != 0 indicates an error. A verifier will reject the commit. In almost every unit test the exit code is checked.

Integration Guide Verifier

p5

PR1

The exit code is set to 0.

In almost every unit test the exit code is checked.

See unit tests.

PR2

The exit code is not set explicitly. 0 is used by the underlying Ruby or OS framework.

In almost every unit test the exit code is checked.

See unit tests.

s1

DS1

Wrong command line arguments used.

same as p1/PR1

n/a

DS2

n/a, only read access

n/a

n/a

s2

DS1

n/a, only write access

n/a

n/a

DS2

Error messages are not visible on console.

The user might miss the information what went wrong, but the exit code != 0 indicates that something went wrong. A verifer will reject the commit.

Integration Guide Verifier

DS2

n/a, only read access

n/a

n/a

s4

DS1

n/a, only write access

n/a

n/a

DS2

Wrong exit code used.

same as p4/PR2 and p5/PR2

n/a

s5

DS1

Corrupted data leads to incorrect output of Dim.

same as p3/PR1.1 to p3/PR1.3

n/a

DS2

Requirements are not available for subsequent steps or data is incomplete.

In most cases this is recognized by the user or in a review. Reviews are mandatory. Tested by unit tests.

export_spec.rb
format_spec.rb,
Integration Guide Verifier,
Integration Guide Export,
Integration Guide Statistics

s6

DS1

Wrong options used.

same as p1/PR1

n/a

DS2

Command line arguments are ignored.

same as p1/PR2

n/a

s7

DS1

Wrong requirements data is loaded.

same as p2/PR1.1

n/a

DS2

Input files are not formatted.

When files cannot be written to the file system, an exception will be raised, which leads to an exit code != 0. A verifier will reject unformatted files.

Integration Guide Verifier

s8

DS1

n/a, only write access

n/a

n/a

DS2

Separately stored formatted input files not written or stay untouched.

When files cannot be written to the file system, an exception will be raised. Beside that, these files are only used for previewing the formatting without touching the Input files. Changes are not committed, therefore there is no risk.

n/a

s9

DS1

n/a, only write access.

n/a

n/a

DS2

Exported files are not written or stay untouched.

When files cannot be written to the file system, an exception will be raised, which leads to an exit code != 0. A verifier will reject the commit. Export reviews are mandatory.

Integration Guide Verifier,
Integration Guide Export

Scripting Workflow

This analysis is done on the Fig. 18 with the Use Cases in mind.

The basic idea (loading, processing, writing) is the same as in the Command Line Workflow. Therefore references to the analysis of that workflow are added here to avoid unnecessary duplication.

Element ID

Error ID

Specific Error Description

Measures

References

q1

PR1.1

Files are loaded incorrectly or not loaded completely.

In most cases syntax and consistency checks within the loader will recognize the errors and Dim will terminate with exit code != 0. Otherwise the data store data will get incorrect data. This can be recognized by the user or latest by the reviewer in a code review tool. Reviews are mandatory. Tested by unit tests.

loader_spec.rb,
requirement_spec.rb,
consistency_spec.rb,
Integration Guide Verifier,
Integration Guide Export

PR1.2

Wrong files loaded.

In almost every case random files are neither syntactically correct nor consistent which will lead to loading errors. In most of the remaining cases the wrong data is recognized by a mandatory review. Tested by unit tests.

loader_spec.rb,
consistency_spec.rb,
requirement_spec.rb,
Integration Guide Verifier,
Integration Guide Scripting

PR2

If loading is skipped, no requirements are available for subsequent steps.

This is recognized by the user or latest by the reviewer in a code review tool, e.g. getting empty export files.

Integration Guide Verifier,
Integration Guide Export

q2

PR1

The formatter changes the the Input files incorrectly.

In most cases this is recognized by the user or latest by the reviewer in a code review tools. Reviews are mandatory. Tested by unit tests.

format_spec.rb,
Integration Guide Verifier

PR2

The formatter does not write to Input files.

In most cases this is recognized by the user or latest by the reviewer in a code review tool. Reviews are mandatory. Tested by unit tests.

export_spec.rb,
Integration Guide Verifier,
Integration Guide Export

q3

PR1

Requirements are not proceseed as intended, statistics are incorrect.

It is mandatory to review scripts and their outcome to ensure correctness. Inconsistent and syntactically incorrect data written to Input files is recognized by the verifier in the version control system. Reviews are mandatory. Tested by unit tests.

loader_spec.rb,
consistency_spec.rb,
requirement_spec.rb,
Integration Guide Verifier,
Integration Guide Scripting

PR2

Requirements are not processed, statistics are not created.

It is mandatory to review scripts and their outcome to ensure correctness.

Integration Guide Scripting

t1

DS1

Wrong requirements data is loaded.

same as q1/PR1

n/a

DS2

Input files are not updated as intended by the script.

same as q3/PR2

n/a

t2

DS1

Corrupted data leads to incorrect output of the script.

same as q3/PR1

n/a

DS2

Requirements are not available for subsequent steps or data is incomplete.

same as q3/PR2

n/a