Systems design and systems test
New product development is the most complex context for any organization developing products. To make completely new products is about to get the understanding how the new parts, where many or all of them are novel to us, will integrate together to a coherent and cohesive whole, novel as well. To reduce this complexity means that we need to acquire new knowledge. This can be knowledge that we know that we can reach after a few tries, or when the complexity is very high, we do not when, or even if, we can acquire the knowledge. If we refer to the Cynefin™ Framework by Dave Snowden, the former means a Complicated and the latter means a Complex context.
By doing the systems test cases and the systems test environment already from start, means that we are forcing ourselves to acquire the requirements on our system first. This means both the functional and the non-functional requirements, but where the focus especially is on the non-functional requirements, that is setting up the backend parts of the systems architecture. To first set the systems test, like performance tests, for our system and then iteratively develop the systems design, means a test-driven systems design, that is the heart of TDSD, no matter domain.
In the case of a Complicated context, it may only need a few iterations until we have full knowledge about our solution, since we our building our solution on knowledge and experiences of our old products and their systems design. In a Complicated context, our experts can guide us after each iteration (like a prototype), to be able to fulfil the requirements of the product.
But, in the case of a Complex context, it may need several iterations until we have acquired the knowledge (or not) about our solution, and not until then, can we be sure that our resulting architecture artifact, from our systems design, will do the job. For the Complex context, we will use the concept of a system skeleton, with mocked sub-systems, so we can have early systems tests of the non-functional requirements. When we have acquired enough new knowledge about our system, we have reduced the complexity enough, meaning that we can continue as in the case of a Complicated context.
Depending on the size and complexity of the product, we may also need to do sub-system architectures in the same way as above, which can result in intertwined iterations between the system and sub-system levels.
For a deep-dive into systems design and systems test, how to make the implementation and what to think about, see here.