Outsourcing design is common in most industries; from simple sub-components to the full system.  In both cases the process by which the handoff between companies happens is critical.

It starts before you start (pre-project work)

Before the first model is exchanged, before the first requirement is written the two companies need to agree on  the following items

1. What materials are delivered
   1. Models, protected models?
   2. Data dictionary?
   3. Test models, test cases?
   4. Generated code?
   5. Requirements?
   6. Interface control document (ICD)?
   7. …
2. How are the materials delivered?
   1. Using Simulink Projects?
   2. Binaries?
   3. …
3. What level of model customization is enabled?
   1. Parameter tunning?
   2. variant tuning?
   3. …
4. How will the requirements be validated?
   1. Requirements tracking through traceability matrix?
   2. Requirements based testing?
   3. …

Regardless of what is specified the information that is required needs to be clearly defined.

Stages of development

An additional factor to consider is the stage of the development.  The materials that are handed over during the initial versus final stages of development will be different.  Normally during the early stages of development, the level of compliance will be lower.  As the development matures the rigor for compliance increases.

Recommendations for delivery

The following are recommendations for three stages of a “Company-to-Company” project.  The stages I will look at are “Initial specification”, “functional review” and “final delivery”

Initial specification

In the initial specification phase, the Requesting Company (RC) is providing requirements to the Providing Company (PC).  At a minimum, they should provide the following information.

1. Functional requirement document: A formal document describing how the software should perform
2. Required level of testing for acceptance: A description of the level, or class, of testing to be performed.  This may include some existing acceptance tests.
3. Interface control document (ICD):  Description of the software interface, including I/O, rates and tolerances
4. “Real-world data”:  Any specification sheets for the unit under design and or any existing performance data from the unit

Functional review

In most cases, the functional review stage is an iterative process with the Providing Company providing updates to the Requesting Company.

At a minimum, the providing company should provide the following artifacts

1. Simulatable model:  The model could be delivered in a protected mode, keeping the PC intellectual property protected.
2. Requirements traceability report:  A report on the current status of requirements implementation.  Note: at this stage, the not all of the requirements may have been implemented.
3. Verification results:  Related to the requirements report the verification results demonstrate the compliance with the requirements.  Note: at this stage, not all of the tests may have been implemented or in a passing stage.
4. Change requests: During the functional reviews the PC should provide change and clarification requests

Depending on what was decided in the pre-work phase the providing company may provide the test environment and test cases.

In response to these artifacts, the requesting company should provide, at a minimum, the following documents.

1. Change request response: The requesting company should respond with approval or clarifying information.
2. Change request: The requesting company should also formally provide any requests to the

Final Deliverable

With the final deliverables, the providing company should provide the same materials as in functional reviews.  The difference is that in the final review requirements traceability and verification results should be completed.  Any requirements that could not be met should have been addressed in the final functional review change request.

Final thoughts

The process of handing off artifacts between companies in the Model-Based Design environment is nearly identical to that of the traditional text-based environment.  The primary difference is that MBD enables the simulation of the model enabling the requesting company to easily verify the requirements.

Likewise, the specification of which artifacts, and in what format, will be exchanged in the pre-work phase is critical to the success of work between companies.