When analyzing let's say a single use case, how far should the decomposition of sub-systems go? Should system engineers stop at a high level BDD (Block Definition Diagram), or go one level inside (i.e a first level IBD Internal Block Diagram), or two levels, or as many levels as they can based on their experience, or learn enough about the subject so they can go as far as possible until there is no more decomposition possible?
Among the work products and the engineering data to handoff to the downstream engineers, there must be "Physical" ICD (Interface Control Documents), i.e. the specification of the physical connections/interfaces between sub-systems involved in that use case and the controls and data exchanged through those connections/interfaces. But the question still remains about how deep should the system engineering analysis go?
Taking a client/server example of a mobile app connected to a server, let's assume the use case is "Login". Here are three sunny day scenarios and a couple of rainy day scenarios of that use case:
User logs in using username and password
User logs in using fingerprint
User logs in using face recognition
Login fails due to incorrect password
Login fails due to unauthenticated certificate presented by the server
And here are four high-level high level sub-systems involved in this use case:
Client Mobile App
Certificate Authority (CA) – (mobile app needs to authenticate the server)
Requirements will need to be created by system engineers, providing more details, such as how many times the login can fail before doing something, or how much time the user has between entering the username and the password, or regarding the authentication of the server, etc. and then link them to model elements like the "Login" use case and the sub-systems mentioned above. Then system engineers may want to create a few sequence diagrams for the above scenarios, and define the physical interface between the mobile app and the backend server, something like TLS V1.2 connection via TCP/IP port number 4433 and the clear format and the content of the controls/data exchanged through that port; and so on. But would that be enough?
Please share your experience about when to stop.
The basic answer is the same as it is at the system level: stop before you start getting into internal design. For subsystems, that means as soon as you start designing internal parts, that's too far. Sequences for interactions between susysstems are surely within the appropriate range, as these are "above" or "outside" the specific focus of the internal subsystem design.
One exception (kind of) is the development of the deployment architecture. This specifies the responsibilities of the different engineering facets (software, electronics, mechanics, and so on) and the systems engineer has legitimate focus over system-level optimizations so that is part of the hand off process. But you shouldn't be specifying the design of the electronics, mechanics or software. Decomposing "until no more decomposition is possible" would be a terrible criterion to use.
I hope this helps.