Systems engineering — V-model, requirements traceability: Question bank

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

Shuru karne se pehle, chalte hain dekhte hain woh do structures jinpe neeche ke har sawaal tike hain, aur shorthand ko pakka kar lete hain taaki kabhi guess na karna pade.

V-model as a picture (figure s01). Ise ek choda "V" letter ki tarah padho. Left arm pe upar se neeche char teal nodes hain: ConOps (the mission), phir System requirements, phir Subsystem requirements, phir Component design — neeche jaate jaate abstraction kam hoti hai. Right arm pe neeche se upar char orange nodes hain: Component testing, Subsystem integration & test, System integration & test, aur sabse upar Validation. Sab se neeche ke point pe dono arms "build / implement" pe milte hain. Dashed plum arrows flat rungs hain: har ek left-arm requirement ko right-arm test se jodhta hai jo use same height pe close karta hai, yaani same abstraction level pe.

Figure — Systems engineering — V-model, requirements traceability

A traceability chain as a picture (figure s02). Top row mein paanch coloured discs hain jo left-se-right solid arrows se jude hain: Mission objective → Requirement → Design item → Test → Result (PASS). Woh unbroken row captioned hai "mission provably met". Bottom row mein wahi paanch discs hain, lekin "Design item" aur "Test" ke beech ka arrow ek dotted line se replace ho gaya hai jisme orange cross hai — ek missing link — aur row captioned hai "mission unproven". Is picture ka poora message yeh hai: koi bhi ek link todo aur tum prove nahi kar sakte ki mission meet hua.

Definition Is page pe use hone wala shorthand (ek baar yahan spelled out)

BOL = Beginning-of-Life — spacecraft ka orbit mein bilkul pehla din, kuch bhi degrade hone se pehle. Solar cells yahan sabse strong hote hain.
EOL = End-of-Life — woh aakhri din jab spacecraft ko abhi bhi apne requirements meet karne chahiye (jaise 15 saal baad), jab radiation ne cells ko degrade kar diya ho. Requirements EOL pe judge hote hain kyunki woh worst case hai.
PMAD = Power Management And Distribution — woh boxes aur wiring jo arrays/battery se raw power lekar har load tak deliver karte hain. Yeh imperfect hai, toh raaste mein kuch percent power heat ke roop mein lose hoti hai.
EMI = Electromagnetic Interference — unwanted electrical noise jo ek box doosre mein radiate karta hai (wires ke through ya air ke through), jo sirf tab appear hoti hai jab parts ek saath wired hote hain.
ICD = Interface Control Document — ek single authoritative document jo ek interface (connector, voltage, data format) ki ek agreed definition pin karta hai taaki dono sides same values pe trace karein. Dekho Interface Control Documents.
Symbol $⟹$ (jo $\Rightarrow$ bhi likha jaata hai) padhta hai "logically implies": " $X ⟹ Y$ " ka matlab hai jab bhi $X$ true ho, $Y$ bhi true hona chahiye. Symbol $\land$ padhta hai "and": $X \land Y$ tabhi true hai jab dono $X$ aur $Y$ true hoon.
Symbol $⋀_{i = 1}^{n}$ bas "and" symbol $\land$ hai jo kai items pe chain ki tarah lagta hai: $⋀_{i = 1}^{n} R_{i}$ exactly $R_{1} \land R_{2} \land \dots \land R_{n}$ hai — har ek $n$ items true hona chahiye.

True or false — justify

V-model ka right arm usi abstraction level pe verify karta hai jahan left arm ne specify kiya.

True — ek component requirement ko ek component test se check kiya jaata hai, ek system requirement ko system-level test se. "V" ke dashed plum rungs (figure s01) wahi matching levels hain; yahi is shape ka poora point hai.

Agar har subsystem apna test pass kar le, toh system requirement automatically verified ho jaati hai.

False in general — subsystem tests pass karna flow-down logic ko tabhi verify karta hai jab flow-down complete aur correct thi. Integration effects (interfaces, EMI — electromagnetic interference, thermal coupling) phir bhi system ko tod sakti hain, isliye V-model ek alag system-level test rung rakhta hai.

Verification aur validation ek hi activity ke do naam hain.

False — verification check karta hai ki requirement meet hui (sahi banaya); validation check karta hai ki mission meet hua (sahi cheez banayi). Tum har verification test pass kar sakte ho aur phir bhi validation fail ho sakta hai agar requirements khud hi galat theen.

Koi requirement jiska koi test linked nahi hai, use "met" consider kiya ja sakta hai agar design sahi lagta ho.

False — koi verification evidence na hone se traceability chain (figure s02 mein dotted, crossed link) toot jaati hai, toh completeness claim nahi ki ja sakti. "Sahi lagta hai" ek opinion hai; test result evidence hota hai.

Flow-down logical conjunction (AND) use karta hai kyunki spacecraft subsystems ek serial chain banate hain.

True — agar koi bhi ek subsystem apni allocated requirement fail kare toh mission fail ho sakta hai, isliye sab

R_{1} \land R_{2} \land \dots \land R_{n}

hold karne chahiye taaki

R_{sys}

imply ho.

Traceability sirf auditors aur paperwork ke liye useful hai.

False — iski sabse badi engineering value impact analysis hai: jab ek requirement change hoti hai toh tum instantly dekh sakte ho ki kaun se designs aur tests revisit karne hain (dekho Configuration Management).

"Analysis" hamesha "Test" se inferior verification method hai.

False — test hardware ke liye sabse credible hai, lekin kuch requirements (15-year radiation dose, worst-case orbit) physically test nahi ki ja sakti aur analysis ya simulation se verify karni padti hain. Method requirement ke hisaab se choose ki jaati hai.

"V" ka bottom woh jagah hai jahan requirements likhi jaati hain.

False — bottom implementation/build hai (sabse kam abstraction, sabse detailed design). Requirements left arm pe neeche jaate waqt likhi jaati hain aur right arm pe upar jaate waqt close out hoti hain.

Spot the error

"Humne component test pass kar liya, toh time bachane ke liye subsystem test skip kar sakte hain."

Error — component tests sirf prove karte hain ki har part isolation mein kaam karta hai; subsystem test ek alag V-model rung hai jo un parts ke beech interface aur integration faults pakadta hai. Ise skip karna ek unverified level chhod deta hai.

"BOL (Beginning-of-Life) output 840 W hai aur requirement 600 W EOL (End-of-Life) pe hai, toh hamare paas 240 W margin hai."

Error — numbers alag conditions pe hain, isliye unhe directly subtract nahi kar sakte. Margin EOL pe judge hona chahiye: ~15 saal ki degradation ke baad array apne 840 W BOL figure se kam deliver karta hai (parent note mein, lagbhag 840 W BOL degrade hokar EOL pe kaafi kam ho jaata hai), aur sirf woh degraded EOL number 600 W requirement se compare hona chahiye.

"M3 verified hai kyunki SS3.1 aur SS3.2 pass ho gaye."

Error — M3 SS3.1, SS3.2 aur SS3.3 mein flow down hoti hai. Conjunction ka matlab hai teeno pass hone chahiye; SS3.3 (radiators) ko chhod dena chain ko incomplete chhod deta hai aur M3 unproven rehti hai.

"Traceability ka matlab bas har requirement ko ek unique ID dena hai."

Error — unique IDs step one hain; traceability ke liye links chahiye (parent-child flow-down, requirement→design→test→result). IDs bina links ke kuch bhi trace nahi karte (dekho Requirements Derivation).

"Camera lab mein kaam karta hai, toh validation complete hai."

Error — bench pe ek working camera ek subsystem ka verification hai, validation nahi. Validation poochhta hai ki kya integrated spacecraft apne mission environment mein ConOps — Concept of Operations achieve karta hai (jaise orbit se 10 m resolution).

"Interface sirf ek subsystem ki requirements mein appear hone ki zaroorat hai."

Error — interface ke do sides hote hain; dono subsystems ko same agreed values reference karni chahiye, yahi exactly wajah hai ki ek Interface Control Document (ICD — ek single document jo interface ki ek authoritative definition pin karta hai) exist karta hai.

Why questions

Same abstraction level pe verify kyun karte hain jahan requirement specify ki, instead of end mein sab kuch test karne ke?

Kyunki apne level pe fault pakadna kaafi sasta hai aur cause pinpoint karta hai; ek single end-of-line test batata hai ki kuch fail hua lekin kya, nahi — aur late pakde gaye integration mistakes fix karne mein sabse zyada expensive hain.

Requirements flow-down

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

kyon demand karta hai — matlab

R_{1} \land R_{2} \land \dots \land R_{n}

, yaani sab child requirements milke logically parent imply karte hain — rather than just "koi

R_{i}

Kyunki subsystems ek serial mission chain hain — ek unmet allocation mission ko duba sakta hai — isliye sab child requirements ka conjunction (har ek true) parent ko logically guarantee karna chahiye.

Solar array ko End-of-Life (EOL) required number ki bajaye Beginning-of-Life (BOL) pe size kyun karte hain?

Kyunki radiation har saal cells ko degrade karta hai; tum BOL headroom build karte ho taaki degradation ke baad (EOL condition) array load requirement se zyada deliver kare. BOL pe exactly EOL pe design karna zero margin chhod deta.

Traceability matrix kyun rakhte hain jab engineers design "jaante" hain?

Kyunki human memory auditable ya transferable nahi hai, aur change pe impact analysis ke liye machine-checkable links chahiye; matrix tribal knowledge ko evidence mein convert karta hai (ties into Risk Management in Spacecraft Design).

Validation right arm ke top pe kyun hai, ConOps ke opposite?

Kyunki ConOps left pe highest abstraction pe baitha hai, isliye uska matching verification — actual mission ke against validation — right pe highest integration level pe hona chahiye.

Distribution losses (the <5% PMAD, Power Management And Distribution, loss) ko explicitly requirement ke roop mein kyun budget karte hain instead of ignore karne ke?

Kyunki loads ko deliver hone wali power hamesha generate hone wali power se kam hoti hai; agar losses trace aur allocate nahi ki gayi, toh flow-down silently under-deliver karega aur system requirement fail hogi (dekho Interface Control Documents jahan yeh budgets rehte hain).

Edge cases

Ek requirement sirf uss test se verify ho sakti hai jo launch se pehle physically run karna impossible hai (jaise 15-year dose). Kya hota hai?

Verification method Test se Analysis/Simulation mein switch ho jaata hai — requirement phir bhi verified hai, bas alag, appropriate evidence type ke saath. Rung kabhi simply khali nahi chhodi jaati.

Ek subsystem zero margin ke saath pass karta hai (exactly apna number meet karta hai). Kya yeh acceptable hai?

Technically yeh requirement meet karta hai, lekin zero margin ka matlab hai ki koi bhi modelling error, degradation, ya measurement uncertainty ise failure ki taraf dhakelta hai; achhi practice ise risk item flag karta hai even though box PASS kehta hai.

Ek mission requirement tab change hoti hai jab saare tests already PASS hain. Traceability kya batata hai?

Changed requirement se neeche links follow karo: har child requirement, design item, aur test jo isse touch karta hai examine karna hoga aur possibly re-run karna hoga — yahi impact analysis hai, aur isliye links, sirf IDs nahi, matter karte hain.

Do subsystems ek hi interface value ka ownership claim karte hain, aur woh agree nahi karte. Kya toota, aur fix kahan hai?

Interface do jagah define hua ek ki bajaye; fix ek single authoritative ICD (Interface Control Document) hai jise dono subsystems trace karte hain, taaki exactly ek true value ho.

Ek requirement likhi gayi hai jisme koi design element aur koi test link nahi karta. Kya spacecraft complete hai?

Nahi — ek orphan requirement matlab completeness unproven hai; ya toh requirement genuinely unmet hai, ya stale hai aur formally Configuration Management ke under remove karni chahiye. Silence evidence nahi hai.

Har verification test pass ho jaata hai, phir bhi orbit mein spacecraft apna kaam karne mein fail ho jaata hai. Kaun sa discipline fail hua?

Validation — verification ne confirm kiya ki humne requirements ke hisaab se banaya, lekin requirements khud hi real mission need capture nahi kar paayein, toh humne galat cheez sahi se banayi (dekho Verification vs Validation).

Ek component test pass hota hai, lekin wahi component apne neighbours ke saath integrate hone ke baad fail ho jaata hai. V-model ka kaun sa rung ise pakda, aur neeche wala kyun nahi pakad sakta tha?

Subsystem integration rung ne pakda, kyunki interactions (shared power, heat, EMI — electromagnetic interference, mechanical fit) sirf tabhi exist karte hain jab parts combine hote hain — isolated component test ke paas expose karne ke liye koi neighbours nahi the.

Recall Quick self-check

Ek rung, ek condition, ek chain — har ek ko zyoor se bolo. "V" ka ek horizontal rung kya link karta hai? ::: Left pe ek requirement level ko right pe uski matching verification level se. Verification vs validation paanch paanch words mein? ::: Built the thing right / built the right thing. Traceability chain valid kab hoti hai? ::: Jab mission objective se requirement, design, aur test se result tak links ka ek unbroken set ho.