Does anybody face the issue with Design Validation and related overheads?

When we deliver a Solution we have a lot of so-called Streams (usually 3-8, average 5). Each Stream is responsible for its functional Module (e.g. Asset Management, CRM, Billing etc.) and prepares Technical Design for it.

The issue is that the functionality across the Streams is very interconnected and there are a lot of End-to-End Scenarios, which are not explicitly documented.

The approach we use to validate all this stuff is a manual cross-stream review, which is really very time consuming and error prone. Furthermore, as up to a human factor, it is physically impossible to do such validation, and we find out about gaps only during the last testing Phase (End-to-End one) when everything is already implemented (yes, we are waterfall). And you know what the cost of such gaps is...

How do you solve this issue? Special tools, techniques, methodologies etc.?


I think something that will help you a lot is using TDD at the integration levels.

Before starting to write any given module, define the module interface with other modules and define the integration tests that will be run to ensure that modules will work together based on the requirements. The module interface should be designed to be as stable as possible, and changes require a cross-team discussion. If a team changes the interface without telling anyone it will fail the integration tests. You should set up CI to build the modules and run these integration tests continuously.

On top of that, you should have automated acceptance and functional tests that test the system end-to-end in CI.

With both of these tests running continuously, it's more clear the direction that the system needs to go, and each module's team must ensure that they implement their contracts correctly.

  • 1
    The issue is on the higher level. Technically Modules are integrated by the time we start the Project as they all are part of the Product. The issues arise on the business level. As for E2E test - it's possible to automate only around 60% of the scenarios. The reason is the same - complicated business level scenarios. And again - using this approach will show us gaps only after the solutions is implemented. But I'm asking about early identification of the gaps before coding. Jul 18 '17 at 20:45
  • Writing automated acceptance tests will still cover your case then. Define what a successful system looks like and it will help all your teams meet the requirements.
    – Samuel
    Jul 18 '17 at 20:48

Found some suggestions here:

  • Informal Review [my comment: has the same issues described in the Question above]
  • Requirements Inspection [my comment: has the same issues described in the Question above]
  • Prototyping [my comment: very hard to cover complicated E2E Scenarios using this approach]
  • Requirements Testing [my comment: I believe this partially can solve the issue]
  • What is "requirements testing?" Note that this information probably belongs in your question, not in an answer. Jul 18 '17 at 21:29
  • You can read about the "Requirements Testing" by following the link. The Question states the issue. And the comment above provides one of the possible answers. I would not mix them. Jul 19 '17 at 6:22
  • Ah, that kind of requirements testing. Requirements that are not accompanied by an unambiguous acceptance test are not requirements at all; they are wishes. Jul 19 '17 at 14:34
  • So, since you've answered your own question, does that mean we're done? What should we do with the information you have provided here? Jul 19 '17 at 14:41
  • I would mark it as a Solution then. :) I still would like to hear different opinions based on one's experience. And I am interested the most if there is a 100% solution at all or shall I put up with it and each time just wait for defects identified in the Testing Phase. Jul 19 '17 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.