To keep track of the quality tests that need to be performed in a project, briefing models can be extended with a test or verification model. Requirements are then linked to one or more tests. Specific information, such as the type of test (e.g. a visual inspection, simulation or document review), when it should take place (e.g. during the concept design or developed design), who is responsible (e.g. the design team or an external expert) and the tests outcome (e.g. pass or fail) can be entered for each test. For the client, the development of a test plan is a way to ensure that requirements are not ignored or overlooked in the design process, pushing the design team to deliver proof that requirements are being met. For the design team, systematic testing can be seen as a form of clash control between their design proposals and the clients requirements, tracing possible problems before moving on to the next design phase. Theoretically, all requirements can be related to such tests. However, the test plan should not result in an overload of additional work in the project. A test plan shouldThis page is focus on those design aspects that have a large impact on the budget and that are difficult to correct further down the line.Meeting room Acoustic comfort intentionally Reverberation time: 0.6 sec left blankPhase: design developmentResponsible actor: design team Test acoustic comfort Method: simulation Outcome: pass/failTests and requirementsThe example above shows a simple example of how a requirement can be linked to a test object that indicates what kind of test it is and when it should take place. 138