Fil Salustri's Design Site

Site Tools


System Validation

System validation is the last step of a system design process stage, intended to make sure everything is ready to proceed to concept design.

What is system validation?

System validation is a final check of all aspects of a system design, done in prelude to proceeding to concept design. In the real world, it represents a process gate at which a project can be either approved by all stakeholders, or cancelled before more work is done (thus saving development costs on a project that would otherwise be “doomed to failure”).

In academic settings, it is a major opportunity to verify that the system design is as good as it can be. Remember that the sooner errors are caught in a design process, the easier they are to fix.

How do we validate systems?

There are generally three ways to validate a system design. It should be obvious which of the three is appropriate only at the end of the design process.

  • Simulation and test: Your team would build, run, and evaluate simulations of the product, to ensure that it is behaving as you expect and want it to behave.
  • Validation with all stakeholders: You present your systems design to your management and your client, offering them the opportunity of critiquing and commenting on it.
  • Consistency checks: Your team would carefully review the systems diagrams and interface specifications to ensure that consistency exists between them and the PRS.

Simulation and Test

There are a variety of software packages that allow you to analyze the systems level behaviour of your product, without defining the actual shape, materials, and geometry of the product. These systems let you define the interfaces – the expected behaviours – of the major product components, and investigate how the product reacts to various inputs.

While this may seem of relatively little use, it is in fact a vital aspect of the product development process. This is because it is unlikely that a design team will be able to predict all the possible dynamic response interactions of the product's systems. The team could wait until a prototype is available and conduct actual tests on physical specimens, but this would require a lot of detail design to be carried out without any guarantee at all that the system will work. A systems level analysis is important because it is a concept-prover; it indicates that the principles of your design solution are sound. This gives you the confidence to continue the product's development. In other words, it lowers the risk that you've mis-designed the product.

Of course, you confidence in these systems level analyses is lower than that for real physical component and system tests, but they still provide valuable information about product performance early in the overall development process, when errors can be caught and fixed much more easily and cheaply than if they're discovered in later development stages.

Two important kinds of analysis that you can perform are complexity analysis and FMEA.

Validation with all Stakeholders

While not as “scientific” as simulating and testing, validating you systems design with all stakeholders is also very important. This kind of validation usually involves presenting an overview of the design, of estimates of product cost and performance, and – perhaps most importantly – of how much work is left to get the design into production. In essence, you need to convince your client and your bosses that the project is worth pursuing, that the risk of developing the product is outweighed by the benefits to the company (and all other stakeholders) once the product is on the market.

Consistency Checks

Given the nature of the courses you are taking, it is not reasonable to expect students to do simulation and test as well as stakeholder validation. There just aren't the resources and time to do so. Also, there are other courses which focus on the details of validation.

If you can check with some typical users of your intended design and review the systems architecture, then you should do so. This may be as simple as finding one or two friends or family members who might be prospective users, and talk them through the architecture, noting any comments or issues they have. However, this may not always be possible.

So, for design courses, consistency checks are the only real type of validations that can be done. This is done by comparing the system to the requirements.

Go through each of your requirements, and make sure that the interfaces between system elements are consistent with the requirements. For instance, it would be a problem if you have requirements that your product uses electricity and that it will be used in North America and Europe, yet your architecture specifies power at only 120V and 60Hz. Fix any discrepancies that you find.

This validation step can be documented by indicating, for instance, which requirements and which scenarios have been checked and found suitable for each system block diagram. Documentation is essential, but the form of that documentation can be as brief as a point-form list with short sentence justifications as your team thinks is necessary.

From an academic point of view, you want to convince the reader/grader that you have in fact attempted to validate the architecture, and that as far as you can describe, the architecture is consistent with the content of the PRS.


There are no explicit deliverables for this step of system design.

If you have validated your system design properly, then it will be correct. If you didn't, then there will be errors in it. Your ability to validate a system architecture is determined by the quality of the architecture itself.

You may, however, include optional documentation highlighting briefly how your system architecture addresses identified shortcomings of reference products you reviewed in your situation scan. If these points are made elsewhere in your reports, do not repeat them here. Repetition and redundant information are considered significant errors and are to be avoided unless absolutely necessary.


Because of coevolution, systems validation is not really ever complete until the design itself is complete. This means that at any given stage of the process, only some systems validation can be done. This isn't a problem, so long as everything is validated by the end of the project.

One validates a system with respect to available information about the design to that point. If issues arise that cannot be validated at that point, then it is essential to note them for followup later in the design process.

design/systems_validation.txt · Last modified: 2021.05.27 18:39 by Fil Salustri