Systems engineering — V-model, requirements traceability: Worked examples

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

Kuch bhi compute karne se pehle, hum un do numbers par agree kar lete hain jo is puri page par baar baar use honge.

Definition Margin (aur requirement ke do flavours)

Pehle, wo do words jo is page ke har formula mein aate hain:

Capability = hardware actually jo deliver karta hai (measured ya predicted).
Requirement = spec mein likha hua number.

Margin yeh hai ki Capability, Requirement se kitni behtar hai — seedhe shabdon mein, "mujhe fail hone se pehle kitna room hai?" Do tarah ki requirements hoti hain, aur formula unke beech flip karta hai.

Floor requirement ( $\geq$ , jitna zyada utna behtar — jaise "kam se kam 600 W do"): $Margin_{\geq} = \frac{Capability - Requirement}{Requirement} \times 100%$

Ceiling requirement ( $\leq$ , jitna kam utna behtar — jaise "10 W/m² se zyada mat gawao"): $Margin_{\leq} = \frac{Requirement - Capability}{Requirement} \times 100%$

Dhyan do: ceiling ke liye hum numerator mein Requirement pehle rakhte hain, kyunki ab spec ko beat karne ka matlab below rehna hai. Dono cases mein positive = pass with room, negative = fail, zero = exactly meets with no cushion.

The scenario matrix

Is topic ka har problem in cells mein se ek hai. Neeche ka har worked example apne cell(s) ke saath tagged hai.

#	Case class	Kya mushkil banaata hai	Example
A	Saare children pass (happy path)	Confirm karo ki AND-rule loop close karta hai	Ex 1
B	Ek child fail → parent fail	Conjunction ek single FALSE par toot jaata hai	Ex 2
C	Zero / degenerate input	Ek budget term 0 hai (no eclipse, no loss)	Ex 3
D	Limiting / end-of-life	Value worst-case boundary tak drift karti hai	Ex 4
E	Negative margin (numbers ke saath fail)	Margin formula zero se neeche jaata hai	Ex 5
F	Exactly-zero margin (boundary)	Capability == Requirement exactly	Ex 6
G	Real-world word problem	Prose ko → traceability chain mein translate karo	Ex 7
H	Exam twist: unverifiable requirement	Requirement aise likhi jo test hi nahi ho sakti	Ex 8
I	Impact analysis (requirement changes)	Jab spec change ho toh links backward follow karo	Ex 9

Worked examples

Worked example Example 1 — Cell A: saare children pass (happy path)

Statement. System requirement S3: "Saare components survival limits ke andar rahenge." Yeh teen thermal children par flow down hota hai:

SS3.1 (MLI heat loss): required $\leq 10 W/m^{2}$ , measured $8 W/m^{2}$ .
SS3.2 (eclipse heater): required $\geq 50 W$ , measured $51 W$ .
SS3.3 (radiator): required $\geq 200 W$ , measured $205 W$ .

Kya S3 verified hai? Sabse buri (sabse chhoti) margin kya hai?

Forecast: Abhi guess karo — teeno apne numbers beat karte hain, toh S3 pass hona chahiye. Kaun sa child fail hone ke sabse kareeb hai?

Step 1 — Har child ko uski requirement ke khilaaf check karo.

SS3.1: kya $8 \leq 10$ hai? Haan ✓
SS3.2: kya $51 \geq 50$ hai? Haan ✓
SS3.3: kya $205 \geq 200$ hai? Haan ✓

Yeh step kyun? AND-rule ( $⋀$ ) S3 ko tab hi pass karne deta hai jab har child TRUE ho. Toh hum unhe ek ek karke test karte hain.

Step 2 — Sahi flavour se har margin compute karo. SS3.1 ek ceiling ( $\leq$ ) hai, toh hum $Margin_{\leq}$ use karte hain (Requirement pehle). SS3.2 aur SS3.3 floors ( $\geq$ ) hain, toh hum $Margin_{\geq}$ use karte hain (Capability pehle).

SS3.1 (ceiling): $\frac{10 - 8}{10} \times 100% = \frac{2}{10} \times 100% = 20%$
SS3.2 (floor): $\frac{51 - 50}{50} \times 100% = 2%$
SS3.3 (floor): $\frac{205 - 200}{200} \times 100% = 2.5%$

Yeh step kyun? $2%$ margin ke saath pass hona fragile hai — ek hot day aur yeh fail mein flip ho jaata hai. Margins batate hain ki pass kitna safe hai, sirf ki pass hua ya nahi. Sahi flavour use karne se number meaningful rehta hai (ek ceiling margin measure karta hai ki tum limit se kitna neeche ho).

Step 3 — Loop close karo. Saare children TRUE $\Rightarrow$ conjunction se, S3 verified hai. Sabse kamzor link SS3.2 hai $2%$ par.

Yeh step kyun? AND-rule parent ko tab hi guarantee karta hai jab har child individually confirm ho jaaye; sabse kamzor child ko naam dena ( $2%$ ) review board ko woh single number de deta hai jo S3 ko fail mein flip kar de — yahi Step 2 mein margins compute karne ka poora point hai.

Verify: Units: $W$ vs $W$ aur $W/m^{2}$ vs $W/m^{2}$ — consistent. $(10 - 8) /10 = 0.20 = 20%$ , $25%$ nahi — yeh ek common slip hai. Sanity: loop close hota hai aur thinnest margin identify karta hai, exactly wahi jo ek review board chahta hai.

Worked example Example 2 — Cell B: ek child fail, parent fail

Statement. Wahi teen children, lekin radiator ka retest ab sirf $195 W$ read karta hai (required $\geq 200 W$ ). SS3.1 aur SS3.2 ab bhi pass hain. Kya S3 verified hai?

Forecast: Teen mein se do pass hain. Kya "mostly passing" S3 verify karta hai? Padhne se pehle guess karo.

Step 1 — Failing child ko re-evaluate karo. SS3.3: kya $195 \geq 200$ hai? Nahi ✗.

Yeh step kyun? Conjunction $⋀$ maafi nahi deta: usse sab TRUE chahiye. Ek bhi FALSE poore AND ko FALSE bana deta hai.

Step 2 — AND-rule apply karo. $(SS3.1 = T) \land (SS3.2 = T) \land (SS3.3 = F) = F$ Isliye S3 verified NAHI hai, chahe do passes hon.

Step 3 — Negative margin compute karo. SS3.3 ek floor ( $\geq 200$ ) hai, toh $Margin_{\geq}$ use karo: $\frac{195 - 200}{200} \times 100% = - 2.5%$

Yeh step kyun? Margin ka sign tumhara headline hai: negative ⇒ tum $5 W$ short ho aur redesign (bada radiator) ya requirement renegotiate karni hogi.

Verify: $- 2.5%$ of $200 = - 5 W$ , $195 - 200$ shortfall se match karta hai. Sanity: do green boxes aur ek red box ka matlab hai parent red hai.

Worked example Example 3 — Cell C: zero / degenerate input

Statement. Ek spacecraft dawn–dusk sun-synchronous orbit mein kabhi eclipse enter nahi karta, toh eclipse duration $= 0$ . Battery child SS4.2 required tha "eclipse loads ke liye itna store karo." Average eclipse load $300 W$ , eclipse time $t_{ecl} = 0 h$ . SS4.2 ko kitni usable energy chahiye, aur requirement ka kya hota hai — aur kya hum margin quote bhi kar sakte hain?

Forecast: Koi eclipse nahi hai toh kya battery requirement poori tarah gayab ho jaati hai? Aur margin compute karne ki koshish karo toh kya hoga? Guess karo.

Step 1 — Zero plug in karo. Energy needed $= P \times t = 300 W \times 0 h = 0 Wh$ .

Yeh step kyun? Yeh assume karne se pehle ki term gayab ho gayi, hamesha test karo ki ek zero input formula ke saath kya karta hai. Yahan eclipse-survival requirement $0 Wh$ par collapse ho jaati hai.

Step 2 — Margin compute karne ki koshish karo (aur refuse karo). Requirement ab $0 Wh$ hai. Margin formula dega $\frac{Capability - 0}{0} \times 100% = \frac{something}{0} = undefined .$ Toh upar wale [!mistake] rule ke mutabiq, hum nahi report karte percentage. Hum SS4.2 (eclipse) ko "trivially satisfied by inspection" record karte hain — koi bhi non-negative battery capacity ek zero requirement ko meet karti hai.

Yeh step kyun? Division by zero ek badi margin nahi hai, yeh bilkul bhi defined margin nahi hai. "Infinite margin" report karna reviewer ko mislead karega; "trivially satisfied" honest aur auditable phrase hai.

Step 3 — Over-conclude mat karo. SS4.2 eclipse ke liye auto-pass hai, LEKIN ek real battery launch, safe-mode, aur load transients ke liye ab bhi chahiye — yeh alag requirements hain apne non-zero numbers aur real margins ke saath.

Yeh step kyun? Ek degenerate input ek derived requirement zero karta hai, component ke poore existence ka reason nahi. Traceability un requirements ko alag rows ke roop mein rakhti hai.

Verify: $300 \times 0 = 0 Wh$ . Units $W \cdot h = Wh$ . Sanity: zero requirement auto-pass aur documented hai, aur koi margin percentage quote nahi ki (denominator zero hai).

Worked example Example 4 — Cell D: limiting / end-of-life boundary

Statement. Solar array: beginning-of-life power $P_{BOL} = 1226 W$ , radiation degradation $d = 2.5%$ per year, mission $t = 15$ years. Requirement SS4.1: $P_{EOL} \geq 600 W$ . Verify karo.

Forecast: 15 saal ke decay ke baad, kya array $600 W$ clear karta hai? Ek number guess karo.

Step 1 — Decay model karo. Har saal power $(1 - d)$ se multiply hoti hai. $t$ saalon baad: $P_{EOL} = P_{BOL} (1 - d)^{t}$

Yeh step kyun? Degradation multiplicative hai (har saal ek fixed fraction lose hoti hai), toh yeh compound hoti hai — ek exponential $(1 - d)^{t}$ , seedha subtraction nahi. Hum power law use karte hain kyunki "har saal same percentage" exactly geometric decay define karta hai.

Step 2 — Limit evaluate karo. $P_{EOL} = 1226 \times (0.975)^{15} \approx 1226 \times 0.6853 \approx 840 W$

Yeh step kyun? Hum arithmetic sabse bure instant par karte hain — $t = 15$ , end of life — kyunki wahan exponential bottom out hota hai; agar number yahan $600 W$ clear karta hai, toh usne har pehle, zyada bright saal mein bhi clear kiya tha.

Step 3 — Compare aur margin. Yeh ek floor ( $\geq 600$ ) hai: $840 \geq 600$ ✓, margin $= \frac{840 - 600}{600} \times 100% = 40%$ .

Yeh step kyun? Floor margin "passes" ko "passes with $40%$ headroom" mein badalta hai, jo ki woh number hai jise ek review board SS4.1 — aur isliye S4 — ke safely met hone ka evidence record karta hai.

Figure padho. Neeche ka black curve $P_{BOL} (1 - d)^{t}$ hai; yeh black BOL dot ( $1226 W$ ) se start hota hai aur neeche sagg karta jaata hai jaise radiation cells khaati hai. Dashed black line $600 W$ requirement floor hai. Red EOL dot $t = 15$ par $\approx 840 W$ par baitha hai — dashed line se kaafi upar. Red dot aur dashed line ke beech ka vertical gap hi $40%$ margin hai: poora curve poore mission mein requirement ke upar rehta hai, toh array har instant par pass karta hai, sirf end mein nahi.

Figure 1 — Solar array power vs. orbit mein saal. Black curve: $P = P_{BOL} (1 - d)^{t}$ black BOL dot ( $1226 W$ ) se decay karta hua. Dashed black line: $600 W$ floor requirement. Red dot: $t = 15$ par end-of-life point, $\approx 840 W$ — dashed line se uski height $40%$ margin hai.

Verify: $ln (0.975) \times 15 \approx - 0.3797$ , $e^{- 0.3797} \approx 0.684$ , times $1226 \approx 839$ . Boundary passes.

Worked example Example 5 — Cell E: negative margin (numeric failure)

Statement. Ek sasta array cell $P_{BOL} = 780 W$ deta hai same $d = 2.5%/ yr$ , $t = 15$ ke saath. Requirement ab bhi $\geq 600 W$ hai. Kya SS4.1 pass hoga?

Forecast: BOL sirf $780$ hai; kya 15 saal ka decay isse $600$ ke neeche dhakel dega? Guess karo.

Step 1 — Same decay law. $P_{EOL} = 780 \times (0.975)^{15} \approx 780 \times 0.6853 \approx 535 W$ .

Yeh step kyun? Hum Example 4 ka identical geometric-decay law reuse karte hain kyunki physics (har saal fixed fractional loss) unchanged hai — sirf starting power alag hai.

Step 2 — Margin (floor $\geq 600$ ): $\frac{535 - 600}{600} \times 100% \approx - 10.8%$

Yeh step kyun? Sign verdict hai: negative ⇒ SS4.1 FAIL, aur flow-down se S4 (power) fail, aur koi bhi mission requirement jo S4 par depend karti hai ab risk mein hai.

Step 3 — Kya upar toot ta hai. Kyunki $⋀$ ko SS4.1 TRUE chahiye, aur yeh FALSE hai, S4 bhi FALSE hai. Fix options: bada array area, behtar cells (zyada BOL), ya chhota mission (chhota $t$ ).

Yeh step kyun? Failure ko upar trace karna program ko exactly batata hai kaun sa parent (S4) ab unmet hai, aur fixes enumerate karna ek red margin ko ek actionable design decision mein badalta hai.

Verify: $780 \times 0.6853 = 534.5 W < 600$ . $(- 65/600) = - 0.108$ . Fails as claimed.

Worked example Example 6 — Cell F: exactly-zero margin (the boundary)

Statement. Array exactly required EOL power deliver karta hai: capability $= 600 W$ , requirement $= 600 W$ . Pass ya fail?

Forecast: Requirement ke barabar — kya yeh pass hai?

Step 1 — Margin (floor $\geq 600$ ): $\frac{600 - 600}{600} \times 100% = 0%$

Yeh step kyun? Zero margin ka matlab hai "requirement kisi cushion ke bina meet ki." Mathematically $600 \geq 600$ TRUE hai, toh yeh spec ke letter ke hisaab se pass karta hai.

Step 2 — Engineering judgement. Real programs review mein positive margin (often $\geq 5 - 10%$ ) demand karte hain, kyunki measurement error akele ek $0%$ pass ko fail mein flip kar sakti hai.

Yeh step kyun? Math kehta hai pass; process kehta hai "unacceptably risky." Traceability isse pass with zero margin record karta hai aur waiver ke liye flag karta hai.

Verify: $600 - 600 = 0$ . Boundary case: logically passes, operationally flagged.

Worked example Example 7 — Cell G: real-world word problem

Statement. "Ek Earth-imaging satellite ko $500 km$ orbit se $10 m$ cross ke objects resolve karne chahiye. Uski camera focal length $2 m$ hai aur har detector pixel $6 μ m$ ka hai." Kya design resolution requirement meet karta hai? Traceability chain M1 → S1 → SS1.x banao.

Forecast: Guess karo ki kya $6 μ m$ pixels $10 m$ ground resolution ke liye chhote hain.

Step 1 — Tool dhoondo. Ground sample distance (GSD) — ground ka woh patch jise ek pixel dekhta hai — similar triangles se aata hai: pixel size $p$ ka focal length $f$ se jo ratio hai wahi GSD ka altitude $H$ se ratio hai. $\frac{GSD}{H} = \frac{p}{f} ⟹ GSD = \frac{p H}{f}$

Yeh step kyun? Hum similar triangles use karte hain kyunki lens ek scaled image banata hai: chhota triangle (pixel over focal length) aur bada triangle (ground patch over altitude) same shape share karte hain. Yahi woh geometry hai jo ratio $p / f$ encode karta hai.

Figure padho. Neeche ki picture mein lens black dot hai beech mein. Uske upar, chhota black triangle ka base = ek pixel ( $6 μ m$ ) aur height = focal length ( $2 m$ ) hai. Uske neeche, bada triangle ka base = red ground patch (wo GSD jo hum chahte hain) aur height = altitude ( $500 km$ ) hai. Dono triangles lens ke through mirror images hain, toh yeh similar hain — equal shape, alag size — yahi wajah hai ki ratios $p / f$ aur $GSD / H$ equal hain. Red base woh ek unknown hai jo hum solve karte hain.

Figure 2 — Pinhole/lens similar-triangles geometry. Black dot: lens. Upar chhota black triangle: base = ek pixel ( $6 μ m$ ), height = focal length ( $2 m$ ). Neeche bada triangle: height = altitude ( $500 km$ ), red base = ground sample distance (GSD) jo hum solve karte hain. Equal shapes ⇒ $p / f = GSD / H$ .

Step 2 — GSD compute karo (sab kuch metres mein: $p = 6 \times 1 0^{- 6} m$ , $H = 5 \times 1 0^{5} m$ , $f = 2 m$ ). $GSD = \frac{( 6 \times 1 0 ^{- 6} ) ( 5 \times 1 0 ^{5} )}{2} = \frac{3}{2} = 1.5 m$

Yeh step kyun? Multiply karne se pehle sab kuch ek unit (metres) mein convert karte hain, kyunki same fraction mein $μ m$ , $km$ aur $m$ mix karna GSD ko ek thousand ke factor se galat karne ka sabse common tarika hai.

Step 3 — Requirement se compare karo. Resolution ek ceiling hai ( $\leq 10 m$ : chhota GSD = sharper), toh $Margin_{\leq}$ use karo: $\frac{10 - 1.5}{10} \times 100% = 85%.$ $1.5 m \leq 10 m$ ✓ $85%$ margin ke saath — design PASS karta hai kaafi room ke saath.

Yeh step kyun? Resolution smaller-is-better hai, toh hume ceiling margin use karni hi chahiye (Requirement pehle) — floor formula yahan use karna misleading sign dega. Bada $85%$ margin kehta hai pixels zarorat se kahin zyada fine hain.

Step 4 — Traceability chain complete karo. $M1 (10 m resolution) \to S1 (camera GSD \leq 10 m) \to {SS1.1, SS1.2, SS1.3}$ jahan children hain SS1.1: focal length $f = 2 m$ , SS1.2: orbit altitude $H = 500 km$ , SS1.3: pixel pitch $p = 6 μ m$ . Teeno GSD formula mein feed hote hain; unka combined result ( $1.5 m \leq 10 m$ ) S1 satisfy karta hai, aur conjunction se $SS1.1 \land SS1.2 \land SS1.3 \Rightarrow S1$ verified $\Rightarrow$ M1 verified.

Yeh step kyun? Chain deliverable hai: yeh ek formula aur ek number ke saath prove karta hai ki top-level mission requirement M1 teen physical design choices se meet hoti hai, aur yahi hai jo ek review board audit karta hai.

Verify: $6 \times 1 0^{- 6} \times 5 \times 1 0^{5} = 3$ ; $3/2 = 1.5 m$ . Units: $m \cdot m / m = m$ ✓. Ceiling margin $(10 - 1.5) /10 = 0.85 = 85%$ ✓.

Worked example Example 8 — Cell H: exam twist — the unverifiable requirement

Statement. Ek draft spec padhta hai: SS7: "Spacecraft reliable hoga." Tumhara kaam: explain karo yeh verify kyun nahi ho sakta, aur isse rewrite karo taaki ho sake.

Forecast: Padhne se pehle guess karo ki kya problem hai — design mein hai ya wording mein?

Step 1 — Verifiability test karo. Ek achhi requirement measurable honi chahiye: isse ek quantity, ek value, aur ek method chahiye. "Reliable" mein kuch bhi nahi — test karne ke liye koi number nahi.

Yeh step kyun? V-model ke har right-arm activity mein ek number verify hota hai. Agar left arm koi number nahi deta, toh horizontal traceability line ke paas point karne ko kuch nahi. Dekho Verification vs Validation.

Step 2 — Rewrite karo. Vague adjective ko ek testable statement se replace karo:

"Spacecraft ek mission reliability $R \geq 0.90$ over 5 years achieve karega, fault-tree analysis se demonstrate kiya hua."

Ab iske paas ek metric ( $R$ ), ek value ( $0.90$ ), ek timeframe (5 yr) aur ek method (analysis) hai.

Yeh step kyun? Adjective ko metric+value+method mein badalna hi ek verification test ko requirement par latkane ka ek maatra tarika hai — warna yeh V-model ke right arm par kabhi close nahi ho sakta.

Step 3 — Numeric sanity. Agar design mein 3 independent critical strings hain, har ek ki reliability $0.966$ hai, toh series reliability hai $R = 0.96 6^{3} \approx 0.901 \geq 0.90 ✓$

Yeh step kyun? Serial systems multiply karte hain (AND-rule phir se, probability form mein): saari strings survive karni chahiye, toh unki probabilities multiply hoti hain — aur product ko newly-quantified floor clear karni chahiye.

Verify: $0.96 6^{3} = 0.9014 \geq 0.90$ . Rewritten requirement ab testable hai aur pass karta hai.

Worked example Example 9 — Cell I: impact analysis jab requirement change ho

Statement. Customer M3 "survive $- 4 0^{\circ} C$ " se "survive $- 5 0^{\circ} C$ " mein change karta hai. Traceability use karke, kaun se children re-examine karne padhenge, aur kya eclipse heater ab bhi kafi hai? Interior $+ 2 0^{\circ} C$ par hold kiya jaata hai; purana eclipse heater $51 W$ deliver karta tha (required $\geq 50 W$ ), aur eclipse heat loss interior-to-exterior temperature gap ke saath linearly scale hoti hai.

Forecast: Guess karo ki ek single top-level change kitne downstream items disturb karta hai — aur kya existing $51 W$ heater thande floor ko survive karta hai.

Step 1 — Links neeche follow karo. M3 → S3 → {SS3.1 MLI, SS3.2 heater, SS3.3 radiator}. Ek thanda survival floor heat retention ko stress karta hai, toh SS3.1 (MLI) aur SS3.2 (heater) impacted hain; SS3.3 (radiator, ek hot-case item) nahi.

Yeh step kyun? Impact analysis traceability hai jo backwards phir forwards chalti hai: changed parent se har child link walk karo aur poocho "kya yeh number changed value par depend karta hai?"

Step 2 — Heater need recompute karo. Eclipse heat loss $\propto$ temperature gap. Purana gap (interior $+ 20$ se exterior $- 40$ tak): $20 - (- 40) = 6 0^{\circ}$ , purana heater $50 W$ ke liye sized. Naya gap (interior $+ 20$ se exterior $- 50$ tak): $20 - (- 50) = 7 0^{\circ}$ . Required heater power gap ratio se scale karo: $P_{new} = 50 \times \frac{70}{60} \approx 58.3 W$

Yeh step kyun? Kyunki loss gap ke proportional hai, ek bada gap same interior temperature hold karne ke liye proportionally zyada heater power maangta hai — toh hum purani requirement ko $70/60$ se multiply karte hain.

Step 3 — Installed heater ko nai requirement ke khilaaf check karo. Installed capability ab bhi $51 W$ hai; nai requirement $58.3 W$ hai (ek floor, $\geq$ ): $\frac{51 - 58.3}{58.3} \times 100% \approx - 12.5%$ $51 < 58.3$ ⇒ SS3.2 ab FAIL karta hai. Heater resize karni hogi (bada heater) ya interior setpoint lower karna hoga.

Yeh step kyun? Negative margin alarm bell hai: requirement change ne ek pehle-passing child ko tod diya hai. Sirf do tests (MLI, heater) re-run karne padte hain, poora spacecraft nahi — yahi traceability ka payoff hai. Dekho Configuration Management aur Requirements Derivation.

Step 4 — Ripple report karo. Changed: M3. Impacted children: SS3.1, SS3.2 (SS3.3 untouched). Change ke baad failing child: SS3.2. Re-verification needed: sirf T-SS3.1-001 aur T-SS3.2-001.

Yeh step kyun? Exact ripple set document karna impact analysis ka auditable output hai — yeh configuration board ko precisely batata hai kya re-open karna hai aur kya frozen rakhna hai. Dekho Configuration Management.

Verify: $50 \times 70/60 = 58.33 W$ ; $51 < 58.33$ ; $(51 - 58.33) /58.33 = - 0.1257 \approx - 12.5%$ . Change sahi se exactly do thermal-retention children tak ripple karta hai.

Recall Quick self-check

AND-rule: ek child fail ho toh kya parent pass hoga? ::: Nahi — $⋀$ ko har child TRUE chahiye. Ek ceiling requirement (smaller-is-better) ke liye margin formula? ::: $(Req - Capability) / Req \times 100%$ . Jab requirement $0$ ho toh margin kya hoga? ::: Undefined — report karo "trivially satisfied by inspection," kabhi percentage nahi. Ek requirement kehti hai "shall be robust." Verifiable hai? ::: Nahi — koi metric/value/method nahi; ek number ke saath rewrite karo. Solar decay $(1 - d)^{t}$ : power kyun, subtraction kyun nahi? ::: Loss har saal ek fixed fraction hai, toh yeh compound hoti hai (geometric). Zero eclipse time ⇒ eclipse battery energy? ::: $P \times 0 = 0 Wh$ ; requirement auto-pass hoti hai lekin documented rehti hai. 500 km orbit se GSD formula? ::: $GSD = p H / f$ (similar triangles).

Related: Systems Engineering Fundamentals · Interface Control Documents · Spacecraft Integration and Testing · Risk Management in Spacecraft Design