Systems engineering — V-model, requirements traceability: Visual walkthrough

3.6.26 · D2 · Physics › Spacecraft Structures & Systems Engineering › Systems engineering — V-model, requirements traceability

Shuru karne se pehle, teen chhote symbols aayenge. Aao inhe abhi plain words mein naam de dete hain, taaki baad mein koi surprise na ho.

Yeh page parent topic ka visual companion hai. Agar koi word unfamiliar lage, toh prerequisite hai Systems Engineering Fundamentals.

Step 1 — Ek sentence se shuru karo, ekdum upar

KYA. Hum ek akeli mission sentence likhte hain aur use ek khaali page ke bilkul upar rakh dete hain. Abhi kuch neeche nahi.

KYU. Spacecraft engineering mein har cheez mission kis liye hai uss tak trace honi chahiye. Agar hum parts se shuru karein, toh ho sakta hai hum khoobsurat hardware banayein jo galat kaam kare. Sentence se shuru karne se guarantee hoti hai ki poore tree ki ek hi root hai — yeh root hai Concept of Operations (ConOps) jo parent note ne pehle list ki thi.

PICTURE. Figure mein, ekdum upar wala ek blue box hi humara poora starting point hai. Uske neeche ki khaali jagah woh sab kuch hai jo hum abhi tak decide nahi kiya.

Label $M_{1}$ bas ek name tag hai — letter $M$ yaad dilata hai "mission", number $1$ kehta hai "pehli wali". Abhi koi maths nahi, bas ek handle jise hum baad mein point kar sakein.

Step 2 — Poochhte hain "poore spacecraft ko kya karna hai?"

KYA. Hum ek level neeche utarte hain aur mission sentence ko ek system requirement mein translate karte hain: kuch aisa jo poora spacecraft, ek object ke taur par, guarantee kare.

KYU. Mission sentence ("10 m resolution") ground se dekha gaya result hai. System requirement wohi idea hai jo built spacecraft ki ek promise ke roop mein re-phrase kiya gaya hai. Hum "mission chahta hai..." se "spacecraft shall..." ki taraf ja rahe hain. Yeh V ke left arm ki pehli seedhi hai.

PICTURE. Figure mein blue box ke neeche ek green box hai, jo ek neeche ki taraf arrow se juda hai. Woh arrow hamara pehla $\Rightarrow$ ("breaks down into") hai. Dhyan do box ek step neeche aur top se zyada door hai — neeche matlab kam abstract, zyada concrete.

$M_{1} \Rightarrow S_{1}$

$M_{1}$ — Step 1 ki mission sentence (jo cheez hum chahte hain).
$\Rightarrow$ — hamara mota arrow, padho "breaks down into". Hum ne abhi ise earn kiya: yeh abstract wish se concrete promise ki taraf point karta hai.
$S_{1}$ — system-level requirement. $S$ for "system", poora spacecraft ek box ki tarah: "the camera shall achieve 10 m ground sample distance."

Yahan Requirements Derivation rehti hai — ek wish ko ek testable "shall" statement mein badalna.

Step 3 — System requirement ko subsystems mein split karo

KYA. Hum $S_{1}$ ko kai chhoti requirements mein todte hain, ek har us subsystem ke liye jo use achieve karne mein madad karta hai.

KYU. Koi ek team "the spacecraft" nahi banati. Alag-alag specialists optics, orbit control, structure banate hain. Toh hum ek badi promise ke pieces har subsystem ko allocate karte hain. Yeh allocation left arm ka dil hai — aur har split ek aur $\Rightarrow$ hai.

PICTURE. Green box ab teen yellow boxes mein fan out ho jaata hai. Har fan-line ek flow-down arrow hai. Yeh V ka chaudaapan hai jo abstraction girne par khulta hai.

$S_{1} \Rightarrow {R_{1}, R_{2}, R_{3}}$

$S_{1}$ — Step 2 se system promise (10 m resolution).
$\Rightarrow$ — "breaks down into", wahi mota arrow.
${\dots}$ — curly braces matlab "in cheezon ka set", yaani ek bundle jo hum saath consider karte hain.
$R_{1}$ — "focal length shall be 2 m" (optics subsystem).
$R_{2}$ — "orbit altitude shall be 500 km" (propulsion / orbit subsystem).
$R_{3}$ — "detector pitch shall be 5 μm" (electronics subsystem).

Ye sab $S_{1}$ ke children hain. Do subsystems ke beech ki boundary Interface Control Document mein likhi jaati hai taaki teams agree karein ki kaunsa team kya own karta hai.

Step 4 — "AND" kyun, "OR" kyun nahi? Serial-chain picture

KYA. Hum claim karte hain ki spacecraft $S_{1}$ tab hi meet karta hai jab $R_{1}, R_{2}, R_{3}$ mein se har ek meet ho. "Kuch" nahi, "zyaadatar" nahi — sab.

KYU. Ek spacecraft ek serial chain hai: light optics se guzarti hai, phir detector se sample hoti hai, jabki orbit distance set karta hai. Koi bhi link todo aur 10 m result chala jaata hai. Koi "backup path" nahi hai. Toh sahi connector hai AND, jise hum bade $⋀$ symbol se likhte hain.

PICTURE. Figure teen requirements ko ek chain ki teen links ke roop mein draw karta hai jo $S_{1}$ label wala ek weight khich rahi hain. Koi bhi link todo (red broken link) aur weight gir jaata hai. Yahi "AND" ka matlab hai: sab links zaroori.

$⋀_{i = 1}^{3} R_{i} \equiv R_{1} \land R_{2} \land R_{3}$

$⋀_{i = 1}^{3}$ — bada "AND": " $i$ ko $1$ se $3$ tak run karte hue, AND ke saath combine karo".
$R_{i}$ — $i$ -wein subsystem requirement (hamare set ka generic member).
$\equiv$ — "bilkul same hai" (definition-style equals).
$\land$ — do facts ke beech chhota "AND". $R_{1} \land R_{2}$ tab hi true hai jab dono true hon.

Step 5 — Logic loop close karo: central result

KYA. Hum ab poori promise state karte hain: agar saare children true hain, toh parent zaroor true ho jaata hai.

KYU. Yeh ek achi flow-down ka payoff hai. Hum sirf yeh umeed nahi karte ki pieces add up ho jaayenge — hum split is tarah design karte hain ki har child meet karna parent ko logically guarantee kare. Jab yeh true hota hai, children verify karna kaafi hai; humein kabhi directly abstract parent test nahi karna.

PICTURE. Step 4 ki chain ko dobaara draw kiya gaya hai jisme saare teen links intact aur green hain — weight $S_{1}$ thamai hui hai. Ek arrow jis par $⟹$ likha hai "sab links hold" se " $S_{1}$ satisfied" ki taraf point karta hai.

$(⋀_{i = 1}^{n} R_{i}) ⟹ R_{sys}$

$⋀_{i = 1}^{n} R_{i}$ — "saari $n$ subsystem requirements ek saath true" (yahan $n = 3$ , par kisi bhi count ke liye kaam karta hai).
$⟹$ — patla double arrow, "logically forces". $\Rightarrow$ (split karne ka ek design action) ke unlike, yeh ek truth statement hai: left true hone se right zaroor true hoti hai.
$R_{sys}$ — system requirement, hamara $S_{1}$ , generically likha.

Steps 3 aur 5 ko milane se parent note ka central result ek line mein milta hai:

$R_{sys} \Rightarrow {R_{1}, \dots, R_{n}} such that ⋀_{i = 1}^{n} R_{i} ⟹ R_{sys}$

Sab kuch earn karte hue ise zor se padho: "system requirement ek set of children mein break down hoti hai, is tarah choose ki gayi ki saare children ek saath true hone se system requirement zaroor true ho jaaye."

Step 6 — Page ko ulta karo: verification, design ka mirror hai

KYA. Hum neeche jaate design tree ko reflect karte hain aur ek upar jaata verification tree banate hain. Left side ka har design box right side par ek partner test box paata hai, same height par.

KYU. Humne top-down design kiya (abstract → concrete). Hum us order mein verify nahi kar sakte — parts exist hone tak "10 m resolution" test nahi ho sakti. Toh hum bottom-up build aur test karte hain: pehle har part, phir combined subsystems, phir poora. Same abstraction level par test karna jahan humne requirement likhi hai, yahi V ko neatly close karta hai. Yeh right arm Spacecraft Integration and Testing ka domain hai.

PICTURE. Dono arms letter V banate hain. Horizontal dashed lines har left box ko uske right partner se connect karti hain — woh dashes traceability links hain. Component req ↔ component test; subsystem req ↔ subsystem test; system req ↔ system test.

$R_{i} verified by V_{i}$

$R_{i}$ — left arm par ek requirement.
$verified by$ — horizontal traceability line: "yeh requirement check hoti hai...".
$V_{i}$ — verification evidence (ek test result, ek analysis) bilkul $R_{i}$ ke saamne.

Step 7 — Degenerate cases: jab saaf-suthri V toot jaati hai

KYA. Hum woh corner cases check karte hain jo clean formula ne chupke maan liye the.

KYU. Contract kehta hai reader kabhi unshown scenario mein na aaye. AND-logic result kuch assumptions par tika hai; yeh rahe jo tab hota hai jab woh fail ho jaayein.

PICTURE. Teen mini-panels: (a) ek missing child — ek aisi link jo kabhi draw hi nahi hui, toh $S_{1}$ paper par "satisfied" ho sakti hai par orbit mein fail ho jaati hai; (b) ek orphan requirement — ek box jiska kisi test se koi line nahi, toh yeh kabhi verify nahi hoti; (c) ek changed parent — $M_{1}$ edit hua, aur red ripple dikhata hai har downstream box jo re-check hona chahiye.

Case (a) — incomplete flow-down. Agar children actually $S_{1}$ cover nahi karte, toh $⋀ R_{i} ⟹ R_{sys}$ false hai chahe humne likh diya ho. Maths utni hi achi hai jitna split. Cure: ek coverage review jo har child ko parent ke against check kare.
Case (b) — orphan / dangling requirement. Koi requirement jiska koi test link nahi ( $R_{i}$ jiska koi $V_{i}$ nahi) unverifiable hai. Matrix mein uska "Test Result" cell khaali hai — ek instant red flag. Cure: har requirement ko kam se kam ek verification se trace karna chahiye.
Case (c) — parent badal jaaye. Agar $M_{1}$ "5 m resolution" ban jaaye, toh mote arrows humein exactly batate hain kaunse $R_{i}$ , designs aur tests revisit karne hain. Yeh backward walk impact analysis hai aur isliye Configuration Management poore tree ko freeze aur version-control karta hai — ek box badlo, aur traceability links fallout list kar dete hain.

Ek-picture summary

Upar sab kuch ek V mein compress karke: blue mission root, fat $\Rightarrow$ arrows ke saath girta design arm, neeche AND-chain, uthta verification arm, aur dashed traceability rungs jo dono sides close karte hain — beech mein central logic line print karke.

Recall Feynman retelling — plain words mein kaho

Hum ek sentence se shuru karte hain: "image Earth at 10 metres." Woh sentence upar baithti hai. Hum poochhte hain "poore spacecraft ko kya karna chahiye?" aur use ek system promise ke roop mein likhte hain — yeh ek step neeche aur ek mota arrow hai. Phir hum poochhte hain "kaunsi teams woh promise nibhane mein madad karti hain?" aur use chhoti requirements ke bundle mein split karte hain, ek har subsystem ke liye — aur mote arrows fan out karte hain. Ab key idea: spacecraft ek chain hai, isliye humein har chhoti requirement ek saath true chahiye — yeh bada "AND" hai. Aur hum split is tarah dhyan se karte hain ki saare children true parent ko actually force karein true hone ke liye — woh patla logic arrow hai. Abhi tak hum sirf neeche gaye aur design kiya. Prove karne ke liye, hum page ko ulta palatke upar jaate hain: har part test karo, phir har subsystem, phir poora spacecraft, har level ko us same height par likhi requirement ke against check karte hue. Horizontal dashed rungs har requirement ko uske test se jodte hain — yeh traceability hai, aur yahi humein "agar mission badla, kya re-check karna hai?" ka turant jawab deta hai. Saaf-suthra picture teen taraikon se toot sakta hai: koi child jo likhna bhool gaye, koi requirement jiska koi test nahi, ya koi parent jo badal gaya — aur wahi links jo V banaate hain, unhe hi hum chalke theek karte hain.

Quick self-checks:

Kaunsa arrow "breaks down into" ka matlab rakhta hai aur kaunsa "logically forces" ka?

\Rightarrow

breaks down into (ek design action);

⟹

logically forces (ek truth statement).

Subsystems ke across AND kyun, OR kyun nahi?

Spacecraft ek serial chain hai — ek failed link mission kho deta hai, toh har requirement simultaneously hold karni chahiye.

Ek requirement box ka kisi bhi test se koi dashed line nahi. Kya gadbad hai?

Yeh ek orphan / unverifiable requirement hai — kuch prove nahi karta ki yeh meet hui.

Agar mission

M_{1}

badal jaaye, hum kaise dhoondhte hain kya re-check karna hai?

Traceability links ko backward walk karo (impact analysis); Configuration Management versions track karta hai.