Lecture 06. From Contract to Requirements and the First Architecture

Chronology: 22 September 2026 · sixth session. Primary source: the complete transcript. Transition: pre-sales ends and the student teams' roles begin shifting from sales and engagement to systems engineering.

1. When a lead becomes a client in this course model

The lecture establishes a clear educational boundary: as long as the process concerns meetings, RFIs, RFQs, RFCs and proposals, it remains a lead or opportunity. Once the legal documents and commercial starting point are agreed, the client/project relationship begins.

Editorial clarification 01

In real CRM, accounting and contracting processes, lead, opportunity, prospect, customer and client may have different boundaries. Likewise, a contract need not be signed by a C-level executive: signing authority is defined by the individual company. In this course, “signed agreement → client” is a useful teaching model, not a universal legal definition.

2. Project start lead time must already be sold in the proposal

A signed contract does not instantly create a team. Hardware, firmware and systems roles can require lengthy hiring and onboarding. Before a project starts, therefore, document:

• the earliest start date;
• staffing assumptions;
• which people are already available;
• which roles must still be recruited or allocated;
• dependencies on customer access, hardware, accounts and documents;
• what happens if these prerequisites are late.

Practical principle: do not promise a Monday start on Thursday if the team does not yet exist.

3. Form the core team during pre-sales

Continuity is best provided by people who have already studied the problem statement during pre-sales:

• architect / systems engineer;
• technical lead or leads;
• engineering / delivery manager;
• domain experts.

These roles form the core. The team then scales to match the actual scope.

pre-sale core
     ↓
contract
     ↓
core team retained
     +
newly staffed specialists
     ↓
delivery team

4. An important reality: discovery after signing may change the picture

The lecture describes situations where the customer withholds part of the context before signing or uses the pre-sales task to evaluate capabilities. Consequently, the first actual delivery input may be different from the early problem statement.

The right response is neither to take offence nor to start implementing an outdated proposal: re-establish the actual scope, assumptions and gaps.

This is another reason for traceability and change control.

5. Teaching case: a robot for automated PCB testing

The customer input in the lecture is deliberately given as a long, partly structured spoken description. The system concept includes:

• a ready-made six-degree-of-freedom robot manipulator;
• a custom end effector;
• three methods for interacting with objects: electromagnetic pickup, mechanical gripper and contact test matrix;
• automatic tool selection and orientation;
• control and computing;
• computer vision;
• network communication;
• ROS 2 integration;
• reporting and cloud storage;
• operation in proximity to people.

The case is not about selecting a particular robot brand. It shows how to derive an engineering structure from a customer's spoken description.

6. Business analysis: decompose first, do not invent requirements

The business analyst or systems analyst should not start by immediately “inventing requirements”. First, decompose the input into logical domains and components.

An example of the decomposition from the lecture:

Customer statement
      ↓
1. Robot manipulator
2. End effector
3. Sensor / vision subsystem
4. Control subsystem
5. Communication
6. Functional safety
7. Test / reporting / cloud

This creates a map on which to ask questions and identify missing information.

7. From chapters to user stories

After decomposition, the lecture introduces user stories as a way to describe the system from the viewpoint of an actor or role.

The conventional form is:

As a <role>
I want <capability>
so that <value / outcome>

An example close to the lecture:

As an operator, I want to select and activate the required end-effector tool so that the robot can manipulate different object types without manual reconfiguration.

Editorial clarification 02 — actor versus component

At times in the transcript, a component or control subsystem is described as the “user”. This can be a useful modelling device when identifying interactions; however, in the traditional agile sense a user story usually captures the needs of an actor or stakeholder. Component behaviors should later be formalized through system, software, hardware or interface requirements.

8. From user need to engineering requirements

The course constructs the following traceability chain:

Customer need / speech
      ↓
Business decomposition
      ↓
User stories / stakeholder needs
      ↓
System requirements
      ↓
HW / SW / FW / Mechanical / Interface requirements
      ↓
Architecture / component description
      ↓
Implementation
      ↓
Verification & Validation

This is the central engineering idea of the session: every lower level should explain which higher-level need it fulfils.

9. What makes a good requirement?

The lecture establishes several important rules that must be retained.

Atomic

One requirement states one verifiable need, rather than combining multiple unrelated conditions in a long sentence.

Unambiguous

Avoid terms such as “sufficient”, “fast”, “convenient” or “reliable” unless they are quantified or tied to an acceptance criterion.

Testable / verifiable

It should be clear how to demonstrate compliance.

Identifiable and traceable

Each requirement needs an identifier, revision or change history, and a connection to the parent need or requirement and to verification evidence.

Consistent

The complete requirement set should contain no hidden contradictions.

Example

Weak wording:

Robot shall position the tool very accurately.

Better wording:

SYS-POS-001: The robot shall position the active tool center point within ±0.2 mm of the commanded Cartesian position under the defined test load.

The test conditions, reference frame and measurement method still need to be defined; that is exactly how a requirement becomes professionally usable.

10. System requirements versus component requirements

The lecture correctly distinguishes the following levels:

System requirement

Describes the behavior or property of the whole system or an interaction between major components.

Hardware / software / firmware / mechanical requirement

Allocates part of the system behavior to a specific engineering domain or component.

Example:

SYS-COM-001
Robot controller and end-effector controller shall exchange command/status data through the defined system network.

        ↓ allocation

HW-COM-...
SW-COM-...
IF-COM-...

11. Editorial clarification — ROS 2, YOLO and safety

The case mentions ROS 2, YOLO, camera, LiDAR and RADAR as possible solution elements. These should not be transformed into requirements simply because someone mentioned them during discovery.

• ROS 2 is a technology or platform decision: define the interaction and deployment requirement first, and choose a solution later.
• YOLO is a family of object-detection models, not automatically the best classifier or PCB inspection method.
• LiDAR, RADAR and cameras are possible sensing technologies, not universal answers to functional-safety questions.
• Robot-cell safety architecture must derive from risk assessment, operating modes and applicable standards; the sensor type follows the analysis rather than serving as a starting assumption.

This is an essential discipline in requirements engineering: do not confuse the need with a premature solution.

12. The first architecture sketch

When system requirements and the main components begin to emerge, the first topology or architecture visualization can be drafted.

The educational case diagram:

                    Supervisory / Test Computer
                       │        │        │
                       │        │        └── Reports / storage
                       │        └────────── Vision / perception
                       │
                    System network
                  ┌────┴───────────┐
                  │                │
          Robot Controller   End-Effector Controller
                  │                │
          Robot Manipulator   Tool rotation / gripper /
                              magnet / contact matrix
                  └──────── mechanical coupling ───────┘

This is not detailed architecture yet. Its purpose is to make gaps visible: interfaces, ownership, power, timing, safety boundaries, data flow and physical coupling.

13. The V-model is traceability, not a decorative letter V

In the lecture, requirements lead toward implementation and then back toward verification.

Needs                    Validation
  ↓                         ↑
System requirements     System test
  ↓                         ↑
Component requirements  Integration test
  ↓                         ↑
Design / architecture   Unit/component verification
  ↓                         ↑
       Implementation

The point is that test evidence must correspond to the level of the requirement being verified.

14. Team practical assignment

At the end of the session, the first substantial practical scenario is defined. Teams are expected to behave like small service companies.

For the next stage they must:

1. form their teams;
2. assign initial roles in engagement or business, technical leadership and management;
3. develop a company identity;
4. prepare business cards and digital contact details;
5. prepare a public-facing story or landing materials;
6. act as though they are leaving for an industry conference tomorrow;
7. approach the lecturer as a prospective lead and secure a follow-up;
8. then work through meetings → RFI/RFQ/RFC → proposal → decomposition → requirements.

Thus the first assessment track tests not one isolated topic, but the entire journey covered since 1 September.

15. Review questions

1. Why must staffing lead time be shown before the contractual start?
2. What should you do when the actual scope after signing differs from the pre-sales picture?
3. Why does business analysis start with decomposition rather than requirements?
4. How do stakeholder needs, user stories and system requirements differ?
5. What makes a requirement atomic?
6. Why is a requirement weak if no verification method is identified?
7. Why should a named technology not automatically become a requirement?
8. What should the first architecture diagram reveal?
9. How does the V-model connect requirements to test evidence?
10. Which deliverables should each student “company” prepare before its first practical session?

16. Forecast for the next one or two sessions — as of 22 September 2026

Likely Session 07 — practical lead-generation / initial-meeting simulation

The homework already suggests the next step: teams present their “companies”, conduct an initial encounter, seek a follow-up and record discovery questions. Expected deliverables include a company one-pager, role map, contact card or QR code, two or three cases or capability statements, and a list of questions for the lead.

Likely Session 08 — from follow-up to RFI/proposal and requirements baseline

After simulating the lead funnel, the natural progression is a specific customer case: receive an RFI or problem statement, answer it, establish assumptions and open questions, develop a high-level proposal and construct the first traceability chain from need to system and allocated requirements.

Important: this is a forecast, not a frozen claim about what actually took place. Once a new recording is uploaded, the actual session is added as new content; this forecast is not rewritten.

Verified references

• ROS 2 documentation: https://docs.ros.org/en/jazzy/
• AUTOSAR Classic Platform (example of layered architecture): https://www.autosar.org/standards/classic-platform
• ISO 26262-3:2018 (example of formal concept and HARA discipline in automotive): https://www.iso.org/standard/68385.html