This is kind of related to my previous post, but I believe it is rather a separate problem/question. I am seeking to improve the process of project development & system design at work. The way I see it, at one specific level, the architecture model serve as the "how" the requirements (what) can be achieved. However, when breaking down the requirements on the next lower level, that serves also as a "how" the upper requirement can be fulfilled. Thus, both architecture model of level N as well as requirements of level N+1 can really overlap in their roles.
When writing the requirements of lower levels, one might need to look not only at the requirements above but also to the existing architecture model, to understand what requirements the modules should have. On the other hand, if we say he should only derive his requirements from the requirements above (thus not looking at the existing architecture model), he might write something that contradicts the existing model from the level above, as he is also providing details on how to fulfill the system requirement.
The main decomposition flow can be depicted as below:
where the Requirements are usually needed in the end for documentation & validation/tracing purposes (besides of course helping the understanding & development of the model/system). And the Architect Model is very useful for the understanding of the whole model as one piece in multiple levels, that contain time diagrams, block diagrams, behavior diagrams and so on. Within on model, one can go from very upper levels into deeper levels by navigating into the blocks and seeing its inside implementation.
Now the question would be what is the best practice to make this break down. For example, to achieve Architecture model of level 1, there are these two ways:
where red flow means one could create a design model from the upper requirements and give further this model to the architect of the level below and this architect would then define further the black boxes from the upper level, i.e. how their insides can be developed to it achieves the I/O black box behavior from the upper layer. However, one could also decompose the requirements into the Level 1 Requirements and even derive some other requirements from the already existing model from the upper level. This input would then tell the architect how to develop the model further in this level.
Now comes the problem: if one focus more on the architectural model, most requirements can be modelled (thus satisfied by model specification) and given further to next layers, so they refine the diagrams, and only a few of the requirements (that cannot be modelled) would then be decomposed further or would be tested (verified), leading to this path:
On the other hand, one could focus on the requirements and mostly decompose the requirements further and modelling just a few diagrams in a higher level, making the models between layers kind of independent:
which I personally find a bad approach since I would prefer one big concise complete model instead of layer-independent models
A mixed solution is also possible, like the second picture, where Level 1 model and requirements are both derived from above, which I suppose is the best approach, where the architect/modeler from Level 1 takes both the "black boxes" from upper layer model as well as Level 0 requirements as input to model its layer. The question then becomes, how strong each "flow" should be. For example, if the blue flow is very small (not deriving many Level 1 requirements from existing Level 0 Model), then the input for Level 1 model/architecture is mostly existing Level 1 Requirements and Level 0 Model, which can lead to inconsistency, depending how Level 0 requirements were decomposed and how Level 0 Architecture was designed. If this blue flow is however strong (many Level 1constraints/requirements are derived from Level 0 model), then the Level 1 architect becomes more independent from Level 0 model when designing Level 1 model with consistency, but you create somehow redundancy of information (what is already at the Level 0 model will be translated into text form to the Level 1 requirements). I personally prefer this approach but it has being criticized due to this redundancy at my company.
So are there any kind of best practice on how to weight these flows on the best form with consistency but also not big overhead? Or any rule of thumb on how much should I derive Level 1 requirements from existing Level 0 model? Any help or even other suggestions of design flow is much appreciated.
