The complete English academic notes follow the Ukrainian source, retaining the original argument, engineering examples, terminology, diagrams, tasks and editorial qualifications. The original transcripts remain available separately in Ukrainian.

Lecture 05. Proposals, Standards and Commercial Models

Chronology: 16 September 2026 · fifth session. Primary source: the complete transcript. Focus: turn a pre-sales vision into a controlled collection of engineering assumptions, regulatory references, resources and commercial risks.

1. Our position in the lifecycle

The session begins by revisiting the sequence used as the course's teaching model:

Lead
 ↓
RFI
 ↓
RFC (Request for Clarification — course terminology)
 ↓
Proposal
 ↘
  RFQ / commercial estimate

In real procurement, the sequence may differ; some deliverables may run in parallel or have different names. What matters is not bureaucratic ordering, but the logic: understand the task first, then articulate an approach, and then estimate resources and risks transparently.

2. Why an embedded proposal quickly encounters standards

For systems interacting with the physical world, customer expectations often cover much more than functions:

safety;
security;
EMC, electrical and mechanical constraints;
quality processes;
traceability;
production and market requirements;
verification evidence.

A proposal therefore needs a reference basis: the regulatory, process and engineering documents affecting the solution.

3. Three levels of guidance: framework → standard → guideline / practice

The lecture proposes a helpful teaching hierarchy:

PROCESS / ASSESSMENT FRAMEWORK
            ↓
        STANDARDS
            ↓
 GUIDELINES / RULE SETS / PRACTICES
            ↓
     PROJECT IMPLEMENTATION

This must not be mistaken for a universal legal hierarchy, since particular documents can have different legal or contractual status. It remains a useful way of organizing technical reasoning.

Framework / process model

Mostly answers the questions “Which processes should exist, and how is their capability assessed?”

Example: Automotive SPICE.

Standard

Defines requirements, principles, work products or criteria for a particular domain.

Guideline / coding or design rule set

Helps translate high-level requirements into concrete engineering rules. Examples include MISRA C/C++, MAAB style guidelines and internal project rules, but the reasons for applying them must always be stated.

4. Editorial clarification — Automotive SPICE capability levels

The transcript mentioned a model with seven levels. The capability scale in Automotive SPICE PAM 4.0 actually runs from Level 0 through Level 5:

Level	Name
0	Incomplete
1	Performed
2	Managed
3	Established
4	Predictable
5	Innovating

Official VDA QMC PAM 4.0: https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf

It is also important that Automotive SPICE is a process assessment model, not a certificate that automatically authorizes the holder to develop systems of a particular complexity class.

5. Editorial clarification — standards and CE marking

In the spoken lecture, standards were identified too strongly with laws and CE marking with “ISO certification”.

For the European Union, the more accurate model is:

applicable EU legislation = mandatory legal requirements
             ↓
harmonised standards = usually voluntary route to presumption of conformity
             ↓
conformity assessment + technical documentation + declaration
             ↓
CE marking, where required by applicable law

In other words:

European standards are generally voluntary technical specifications unless legislation makes a specific requirement mandatory;
harmonised standards often provide a presumption of conformity, although alternative technical solutions may be acceptable;
CE marking is not a universal quality certificate and does not always involve a third party;
first determine exactly which legislation applies to the particular product.

Official EU resources:

6. Functional safety classification: do not mix domains and standards

HARA and ASIL reappear in the lecture as an example of risk classification determining the rigor of engineering activities.

Editorial clarification

Under ISO 26262, automotive ASIL is classified using Severity, Exposure and Controllability. QM and ASIL A–D must not be treated as a universal scale that applies without adaptation to every industry.

ISO 26262-3: https://www.iso.org/standard/68385.html

Similarly, rules such as “prohibit dynamic memory” or “keep 70% of memory unused” may be project-specific or domain-specific guidelines, but should not be presented as universally explicit ISO 26262 requirements without a precise reference.

7. A proposal must show architecture, implementation and V&V

The customer must be able to see not only what we will build but how we will demonstrate that the result satisfies the need.

Architecture

high-level decomposition;
major interfaces;
external dependencies;
key constraints;
alternatives and trade-offs.

Implementation

technologies and tools;
planned workstreams;
build and manufacturing route;
integration strategy;
feasibility checks or a PoC when needed.

Verification & Validation

reviews and static analysis;
unit tests;
integration tests;
bench, HIL and real-hardware tests;
regression and performance tests;
acceptance and validation evidence.

Do not mechanically insert every testing technique into each proposal. The V&V strategy must derive from product risks, requirements and the applicable process or reference basis.

8. Resources are not only people

An embedded-project estimate includes at least four resource layers:

Layer	Examples
People	architect, firmware, hardware, mechanics, QA, safety and security, manager
Materials	components, PCBs, mechanical parts, harnesses, fixtures
External services	fabrication, assembly, laboratories, certification or conformity-assessment work
Time / dependencies	lead times, shipment, customs, redesign cycles and waiting for samples

Consequently, the Gantt chart and critical path of an embedded project frequently depend on things that cannot be accelerated merely by adding another software engineer.

9. Time & Materials and Fixed Price: what really changes

The lecture compares two basic commercial models.

Time & Materials

The customer pays for actual engagement at agreed rates and, as provided by the contract, material and external-service expenses. This model works well with uncertain scope, discovery, research, R&D and frequent changes.

Fixed Price

The provider commits to completing a defined scope under agreed price and contractual conditions. This requires much clearer scope, acceptance criteria, assumptions and change control.

Editorial clarification — risk allocation

It is incorrect to claim categorically that “all risks are the customer's under T&M” or “all risks are the vendor's under Fixed Price”. Legal, safety, IP, liability, warranty, schedule and commercial risks are allocated by the contract.

A simplified comparison:

Risk	T&M	Fixed Price
Scope uncertainty	easier to absorb through reprioritization	risky without a change request
Provider's effort overrun	more often billable when the work is authorized	more often reduces the provider's margin
Customer budget predictability	lower	higher for frozen scope
Need for clear acceptance criteria	important	critical
Legal / liability risk	depends on the contract	depends on the contract

10. When Fixed Price makes sense

In the logic of the lecture, Fixed Price becomes realistic when:

the problem and scope are well understood;
requirements are sufficiently stable;
the provider has done comparable work before;
acceptance criteria are clear;
dependencies and customer responsibilities are documented;
a change-management process exists;
uncertainty has been reflected in contingency and margin.

If these conditions do not hold, T&M or a phased engagement model is often more transparent.

11. Estimates must be traceable

A proper estimate does not begin with “I think it will take three months”. It begins with decomposition.

scope / assumptions
      ↓
workstreams / WBS
      ↓
roles + effort
      ↓
materials + external services
      ↓
dependencies / lead times
      ↓
risk / contingency
      ↓
commercial estimate

Every significant number needs an explanation: where it came from and which factors would change it.

12. Review questions

Why does a proposal need a reference basis?
How does a process assessment model differ from a product safety standard?
What capability levels are defined in Automotive SPICE 4.0?
Why should CE marking not be called merely “ISO certification”?
What benefit can a harmonised standard provide in the EU?
Which three parameters underpin automotive HARA/ASIL classification?
What is the principal commercial difference between T&M and Fixed Price?
Why cannot legal and liability risks be inferred from the pricing model alone?
Which non-human resources belong in an embedded-project estimate?
What makes an estimate traceable?

13. Session diagram

client need
   ↓
reference basis
   ├─ process/framework
   ├─ standards / legislation
   └─ guidelines / project rules
   ↓
architecture + implementation + V&V
   ↓
resources + timeline + risks
   ↓
T&M / FP / hybrid commercial model
   ↓
Proposal that can be negotiated

14. Transition to 22 September 2026

An approved proposal leads to another major transition: a contact must become a contract, and the contract must become a delivery team and requirements. The next session starts the journey from a signed agreement through staffing, product discovery, business analysis, user stories and system requirements to the first architecture visualization.

Verified references

Automotive SPICE PAM 4.0: https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf
ISO 26262-3:2018: https://www.iso.org/standard/68385.html
EU standards overview: https://europa.eu/youreurope/business/product-rules-compliance/general-product-compliance/standards-in-europe/index_en.htm
EU conformity assessment: https://europa.eu/youreurope/business/product-rules-compliance/general-product-compliance/conformity-assessment/index_en.htm
CE marking: https://europa.eu/youreurope/business/product-rules-compliance/general-product-compliance/ce-marking/index_en.htm

Proposal, Standards and Commercial Model

Key ideas

Know document status

CE is conformity, not a generic certificate

T&M ≠ client owns all risk

Estimate must be traceable

Practical takeaway

06 — From Contract to Requirements and First Architecture

Full lecture notes