## 4 The System Proposal: An Introduction
### ABCDE Method: User Stories and Use Case Diagram  
In the following, the user stories used to define the requirements of the system proposal are listed:  
* Owners, engineers, architects, installation companies, construction companies, qualified certifiers and managers or managers of specific municipal offices contribute to produce files for a given building/DID;
* Appropriate IoT devices, located in strategic points and equipped with suitable RFID readers, take useful data from the RFID tags that detect and associate such data to the building and therefore to a specific DID;
* Appropriate IoT devices, located in strategic points collect useful data and associate such data to the building and therefore to a specific DID, to track workers, equipment and materials on site;
* Appropriate IoT devices, located in strategic points collect useful data to prepare maintenance actions or other facility management activities during the life cycle of a building;
* The certifications are drawn up using information extracted both from the BIM files and from the data taken from the IoT devices;
* All data/files belonging to a building are stored in a database/wallet off-chain. Hence the system manages the storage in clear text of files in off-chain mode using appropriate databases/structure data;
* Some data/files hashes belonging to a building are stored on-chain;* The hashes of the notarised files are stored on-chain performing a notarization-only function. In this way we have a timestamping of data by identifiable entities with asymmetric keys. Some files must be notarised but only some are certified;
* The hashes of the certified files are stored on-chain, in the Blockchain, with the proofs that prove their validity. In this way a file becomes a verifiable file;
* All the potential verifiers can verify the validity of the files/certifications since they are permanent, cryptographically verifiable, decentralized and \"solvable\";
* A process of multiple authorized signatories allows the storage of some files only after having reached a precise number of signatures, hence multiple approval;
* The system must improve, enhance the management of the information flow between offices and locations where the property is located, and/or between these and all the nodes that make up the building chain that revolves around a given property. To this end, friendly dashboards are opportunely prearranged to allow users access to all system functions;
* The system includes analysis software and visualization dashboards. All the information collected is processed to obtain valuable information in the context of decision making, with the possibility of obtaining a centralized and immediate consultation view of the entire building.  
From the user stories we extracted some use cases (see Figure 3) and the different classes that make up the system, that are shown in an UML (unified model language) class diagram in Figure 4, and described as follows.  
* _Creator/Admin_: the one who deploys the contracts and the external system;
* _Entity_: class representing the natural person, legal person or thing that is below a DID;
* _DID_: class representing stakeholders and construction products;
* _Information Management Platform_: class representing the Information Management Platform that allows all stakeholders to access and manage information relating to a DID;
* _IoT Device_: class representing IoT devices owned by a DID;
* _Notarized File_: It contains information used to prove who is behind the entity that has created this file;
* _Verifiable File_: This type of file is issued by an entity certified and contain information used to prove attributes or properties issued by this entity. This file is accepted as true. In the SSI models there are both data self certifications and 3 rd party data certifications.