Project Reporting

It is a dedicated projection in arKItect SEA to identify objects information or their relations with other objects that don't respect the modelling rules defined by the very users.

It allows you to correct the identified faulty objects directly in the database, fix wrong allocation or interface.

Access to project reporting

Go to projection "Reporting" as shown below:

Update the reports information by launching the script "Update reporting" in Project Tools:

Reports structure

In the generated reports, there are 2 different groups the generic reports for all type of SEA projects and the DEAME specific reports (reports beginning with "DEAME -").

As you can see in the image below, reports are structured by DEAME systems.

Under each system report, it is organized by faulty objects types and by severity.

 

NOTE:

Under each leaf objects report, you will find the problematic object. For Example "Error - True requirements without description - ELECTRIC DRIVE" will list all Electric Drive true requirements that have an empty attribute desc.

If there is no error for a report, report will not be generated.

The idea is to correct at least all reports of "Error" and "Warning" severity and empty them.

Local reporting

You have to note that this method to update reporting is a Local run : Launch the reporting only on your computer, a refresh or reopening of the project will remove these objects (not saved on the server). It is the fastest way to generate reporting and you don't create reports on other users arKItect session.

See more information to run reporting at Project Reporting.

Report list

All the Reports are associated with a severity with the following meaning :

Error - K1Cannot launch scripts and not usable
Warning - K3Scripts launch but with error
Information - K4No impact on scripts

Terminology

a. True Requirement

True requirements are those with the following characteristics:

  1. Their requirement type is "Functional requirement"
  2. They can only be "leaf" requirements (requirements at the bottom of the tree, with no children).

b. Structure Requirement

Structure requirements are divided in 2 categories:

  1. High level requirements: They are structure requirements that are not exported as chapters in scripts.
  2. Title requirements: They are structure requirements that are exported as chapters in scripts.

c. Mirror Tree

In DEAME logic, mirror requirements represent a duplicate from the Functional tree. Each function from the Functional tree in the view “3.1. Define functional architecture” contains a mirror requirement in the view “2.1 Define requirements”.

The mirror requirements can only be of “High level” type, with leaf requirements allocated to the lowest requirements in the tree, that can only be “true” requirements.

d. Breakdown Tree

The Breakdown tree is distinguished because its systems (first level requirements of the tree) contain the word "Breakdown" at the end of the name.

It contains "System concept" requirements, that receive refines from other systems (internal or external) or stakeholders. In the breakdown tree, true requirements better precise the System concept requirements.

e. System

The DEAME rules determine that a system is any of the following:

f. Severity

The severity of each report is set to a default value specified in Reporting severity DEAME.xlsx. It allows the user to prioritize which Report to solve first.

The severity value allowed are :

g. Generate a Reporting for a specific Project

If you want to have a Reporting on a specific scope, you need to activate the Variant of your project before updating the Reporting. You can do it locally if you want to avoid blocking other users from an access to this functiuon on other project.

h. Reporting indicator

To have an overview of how many errors/Warnings/Info are reported on your project, it is possible to generate an Excel file with a Summary of all issues per System.