For illustrative purposes let us imagine the following scenario: company X launches onto the market without benefiting from an accountancy service, be it internal or external. One can genuinely expect that to be a short lived venture, as risk was overlooked.  
ISO 26262 summarizes experience on software, hardware and system level.
Before diving into difficult topics as Random Fault, Common Failure Cause, Fault Tolerance and so on, let us keep in sight items such as: 
•    '' What is an Item?" , in ISO 26262 context, part 3;
•    Let us consider an engineer creating an architecture for a DC-DC converter following a simple logic, he/she creates an architecture : housing, PCB, MCU, Power-Bridge, Transformer, screws. Here are some relevant questions: has the System Engineer mapped Functions to Forms? Have the system boundaries been defined underlining function  representing requirements under safety context? On which use case the boundary diagram was defined, in order to create the corresponding test case ? Indeed, the more use cases the system has, the more boundary diagrams are required ( mapping functions to forms).
•     Taking a look into ISO26262 architecture diagram, from a top level perspective, it is easy to deduct the necessity of System Functional Safety Engineer