Requirements — SMART (Specific, Measurable, Achievable, Relevant, Testable): Visual walkthrough

3.6.27 · D2 · Physics › Spacecraft Structures & Systems Engineering › Requirements — SMART (Specific, Measurable, Achievable, Rele

Intuition Hum actually kya derive kar rahe hain

Parent note tumhe SMART rules deta hai. Lekin rules akele ek aisi checklist jaisi lagti hain jo kisi ne tumhe memorise karwai ho. Yeh page kuch alag karta hai: hum ek raw human wish se shuru karte hain — "satellite ko lightweight banao" — aur dekhte hain ki yeh ek ek visible squeeze ke saath kaise transform hoti hai ek aisi sentence mein jo ek machinist build kar sake aur ek test engineer prove kar sake. Har SMART letter ek filter hai jisse wish guzarti hai. Akhir mein tumhe dikhega ki kyon ek requirement jo paanch filters survive karti hai woh falsifiable hoti hai — tum definitively pass ya fail prove kar sakte ho.

Isse ek funnel ki tarah socho: ek wide, fuzzy cloud of meaning upar se andar jaati hai; ek single sharp sentence neeche se baahar aati hai.

Yeh the SMART topic note ka visual companion hai. Pehle woh padho rules ke liye; yeh padho derivation feel karne ke liye.

Step 1 — Raw wish se shuru karo (the fuzzy cloud)

KYA: Hum sabse honest starting point se shuru karte hain: ek sentence jo ek insaan actually bol ke kehta. "The satellite shall be lightweight."

KYUN: Isse pehle ki hum appreciate karein ki SMART kyun help karta hai, hume woh bimari dekhni chahiye jo yeh theek karta hai. Aise wish ki koi edges nahi hoti. Agar main yeh paanch engineers ko doon, mujhe paanch alag satellites milenge. Hume ek tarika chahiye us ambiguity ko picture karne ka taaki hum jaanein ki har SMART filter exactly kya remove kar raha hai.

PICTURE: Figure wish ko ek soft cloud ke roop mein dikhati hai. Cloud ke andar bahut saare chhote dots hain — har dot ek alag satellite hai jo koi honestly claim kar sakta hai ki woh "lightweight" words ko satisfy karta hai. Ek 40 kg cubesat wahan hai. Ek 900 kg bus bhi hai jisko uski team apni "class ke liye" light samajhti hai. Words mein se koi bhi kisi ko exclude nahi karta.

Figure — Requirements — SMART (Specific, Measurable, Achievable, Relevant, Testable)

Step 2 — Filter Specific: cheez ka naam lo (cloud ko aadha karo)

KYA: Hum sentence ko majboor karte hain ki woh exactly bataye ki kaunsa part constrained hai. "The satellite" nahi — bus structure. Payload nahi, fuel nahi, solar panels nahi.

KYUN: "Satellite" shabd ek saath sab kuch point kar raha tha, isliye har subsystem sochta tha ki requirement unke baare mein hai (ya kisi aur ke baare mein). Scope ka naam lena cloud ke har us dot ko hata deta hai jo ek alag component se belong karta hai. Yeh pehli real narrowing hai.

PICTURE: Step 1 ka cloud ek vertical line se slice hoti hai. "Wrong component" side par sab kuch (payload masses, fuel masses) grey ho jaata hai aur drop ho jaata hai. Jo bachta hai woh dots ki strip hai jo genuinely bus structure ke baare mein hain.

Step 3 — Filter Measurable: ek number, unit, operator, tolerance lagao (ek boundary pe collapse karo)

KYA: Hum fuzzy word "lightweight" ko un cheezon se replace karte hain jo kisi bhi physical constraint ko chahiye: ek value, ek unit, ek comparison operator, ek tolerance / measurement uncertainty, aur woh conditions jisme yeh lagoo hoti hai.

KYUN yeh aur kuch softer nahi? Kyunki physics sirf dimensioned quantities mein baat karta hai. Ek mass ek number times ek unit hoti hai — 150 akela kuch nahi kehta; 150 kg kuch kehta hai. Aur sentence ko ek gate (pass/fail) banane ke liye hume ek comparison operator chahiye jo ek line draw kare: ek taraf sab pass, doosri taraf sab fail. Yehi ise falsifiable banata hai.

Tolerance optional kyun nahi hai: har real measurement mein uncertainty hoti hai. Agar ek scale $150.0 kg \pm 0.3 kg$ read kare, toh exactly $150 kg$ wala part $149.7$ se $150.3$ tak kahin bhi read ho sakta hai. Stated tolerance ke bina, line ke bilkul upar baitha ek part undecidable hai — aur ek undecidable case falsifiable nahi hai. Isliye ek truly measurable requirement target value aur check ke aas paas measurement uncertainty band dono ko pin down karti hai.

PICTURE: Dots ki strip pe ek hard vertical wall $150 kg$ par girayi jaati hai. Wall ke aas paas ek thin fuzzy band hai — measurement uncertainty — jo dikhata hai ki band ke andar girane wale parts woh hain jinhe tumhara instrument cleanly call nahi kar sakta. Saaf taur se left (halke) wale dots green ho jaate hain — woh PASS hain. Saaf taur se right wale coral ho jaate hain — woh FAIL hain. Requirement ab ek mood nahi balki ek boundary hai.

Formula Measurable sentence ki anatomy

$the parameter m_{bus} operator: draws the pass/fail line \leq the value 150 the unit, gives the number meaning [kg] measurement tolerance (\pm 0.3 kg) the condition, when it applies at launch config$

$m_{bus}$ — woh measurable quantity. Tum iske neeche scale rakh sakte ho.
$\leq$ — iske bina tumhare paas ek fact hai, requirement nahi. Yeh gate hai.
$150$ — woh number jise value cross nahi karni chahiye.
$[kg]$ — ise hatao aur $150$ grams, pounds, ya newtons kuch bhi ho sakta hai. Units decoration nahi hain.
$(\pm 0.3 kg)$ — measurement/verification ki uncertainty. Yeh batata hai ki line ke kitna karib "call karne ke liye bahut karib" hai, isliye boundary ke paas wale part ka bhi ek defined verdict hota hai.
"at launch config" — mass change ho sakti hai (fuel burn hota hai), isliye hum pin down karte hain kab hum ise weighte hain.

Step 4 — Filter Achievable: check karo ki boundary reality ke andar hai

KYA: Ek sentence perfectly measurable ho sakta hai aur phir bhi impossible ho sakta hai. Achievable poochhta hai: kya jo line humne kheechi hai woh physics, technology, aur budget actually allow karte hain uske andar hai?

KYUN: Tum likh sakte ho " $Δ v = 50 km/s$ on chemical propulsion" — yeh specific aur measurable hai — lekin koi bhi engineering effort ise reach nahi kar sakti. Ek impossible jagah par boundary draw karna design cloud ko chhota nahi karta; yeh ise khaali kar deta hai, aur yeh tum ek saal barbaad karne ke baad discover karte ho. Isliye hum ek feasibility region overlay karte hain aur require karte hain ki boundary usse overlap kare.

PICTURE: Do vertical bands. Green feasible band wahan hai jahan real bus structures rehh sakti hain (given materials aur cost). Coral infeasible band physics/budget se pare hai. Hamara $150 kg$ wall green band ke andar land karna chahiye. Figure ek achhi requirement (line green mein) aur ek doomed wali (line coral mein) side by side dikhati hai.

Formula Kyun doomed propulsion example impossible hai — openly worked out

Tsiolkovsky rocket equation (Tsiolkovsky Rocket Equation) speed change $Δ v$ ko relate karta hai ki tum kitna mass throw away karte ho: $Δ v = v_{e}, exhaust speed I_{s p} g_{0} ln wet / dry mass ratio \frac{m _{0}}{m _{f}}$

$I_{s p}$ — specific impulse, seconds mein measure hota hai. Ise padho "ek unit-weight propellant kitne seconds tak ek unit of thrust produce kar sakta hai" — fuel ka efficiency score. Bada $I_{s p}$ matlab har kilogram propellant tumhe zyada speed change deta hai.
$g_{0} = 9.81 m/s^{2}$ — standard gravity, woh constant jo $I_{s p}$ ke seconds ko m/s mein real exhaust speed mein convert karta hai.
$v_{e} = I_{s p} g_{0}$ — exhaust speed: gas nozzle se kitni tez nikalti hai.
$m_{0}$ — wet mass (structure + saara propellant, ignition par); $m_{f}$ — dry mass (akela structure, tanks khaali).

Ek high-performance cryogenic chemical engine lo (liquid hydrogen / liquid oxygen, vacuum mein quoted) — yeh roughly chemical rocketry ki best offer hai, $I_{s p} \approx 450 s$ . Yeh ek specific, best-case figure hai, universal chemical constant nahi: storable propellants jaise hydrazine kaafi neeche baithe hain (~230 s), aur sea-level values vacuum se bhi neeche hain. Yeh best case use karte hue, $v_{e} = 450 \times 9.81 = 4414.5 m/s .$ $Δ v = 50000 m/s$ reach karne ke liye hume chahiye $\frac{m _{0}}{m _{f}} = e^{50000/4414.5} = e^{11.33} \approx 8.3 \times 1 0^{4} .$ $100 kg$ dry mass ke saath yeh 8 million kg se zyada propellant hai — jo bhi green band exist karti hai usse bahar. Measurable ✓, achievable ✗.

Ab achievable counterpart. Maan lo ek small-satellite mission ko kam se kam $Δ v$ of $500 m/s$ chahiye (orbit maintenance aur de-orbit ke liye enough). Hum likhte hain:

Ise rocket equation ke against check karo. Hydrazine (ek storable propellant, isliye bahut lower score) ka $I_{s p} \approx 230 s$ hai, isliye $v_{e} = 230 \times 9.81 = 2256.3 m/s$ . Mass ratio $= (50 + 10) /10 = 6$ : $Δ v = 2256.3 \times ln 6 = 2256.3 \times 1.7918 \approx 4043 m/s,$ jo comfortably $500 m/s$ target clear karta hai — isliye yeh line green band ke andar achhi tarah land karti hai. (Achievability Technology Readiness Levels (TRL) aur Mass Budget par lean karti hai.)

Step 5 — Filter Relevant: boundary ko upar kyun se connect karo

KYA: Ek measurable, achievable line bhi bekar ho sakti hai. Relevant demand karta hai ki requirement ek real mission objective tak chain mein trace kare. Agar ise cut karne se mission ko nuqsaan nahi hota, toh yeh exist nahi karni chahiye.

KYUN: Har requirement ko verify karne mein paise, mass, aur schedule lagta hai. Ek orphan requirement — jo kisi cheez se trace nahi hoti — pure cost hai, koi benefit nahi. Upar trace karna mission ko bhi protect karta hai: agar tum ek relevant requirement delete karo, toh objective visibly toot jaata hai.

PICTURE: Teen linked boxes ki ek vertical chain. Top: Mission objective. Middle: System requirement. Bottom: hamari subsystem requirement ( $150 kg$ bus). Green arrows upar point karte hain — "ki wajah se exist karta hai." Hum relevance test karte hain top box cover karke aur poochhte hain: kya neeche kisi cheez ka koi reason bacha hai? Agar nahi, toh cut karo.

Step 6 — Filter Testable: woh proof chuno jo loop close kare

KYA: Aakhri filter poochhta hai: hum ise kaise prove karenge? Har achhi requirement char verification methods mein se ek name karti hai (ya clearly permit karti hai). Poori tarah se spell out kiye gaye, yeh hain:

T = Test — real hardware/software exercise karo aur result measure karo (jaise ek panel par simulated sun shine karo aur watts padho).
A = Analysis — ek validated mathematical model ya simulation se prove karo jab full-scale test impractical ho (jaise re-entry heating).
I = Inspection — directly item ko dekho ya measure karo (jaise structure ko calibrated scale par rakho, gauge se dimension padho).
D = Demonstration — ek operational scenario run karo aur correct end-to-end behaviour observe karo (jaise complete command-and-response sequence).

KYUN: Ek boundary jise tum check nahi kar sakte woh ek boundary hai jise tum sirf hope karte ho ki met ho. Hope broken hardware ship karta hai. Method pehle se choose karna requirement ko checkable language mein phrase karne ke liye majboor karta hai aur check ke liye budget/schedule reserve karta hai.

PICTURE: Char methods char gates ki tarah hain, aur requirement ka domain decide karta hai kis gate se woh guzarti hai. Mass requirement → Inspection (ise scale par rakho). Power requirement → Test (simulated sun shine karo, watts measure karo). Re-entry heating requirement → Analysis (tum bench par full re-entry build nahi kar sakte). Complex operational sequence → Demonstration.

Step 7 — Degenerate cases (SMART kab fail hota hai)

KYA: Ek derivation tab tak complete nahi jab tak tum har woh tarika nahi dikhao jisme yeh toot sakta hai. Yeh paanch failure modes hain — ek per SMART letter, har ek ek filter hai jo khula chhoot gaya.

KYUN: Real requirement documents exactly inhi gaps par rot karte hain. Ek tooti hui requirement ki shape ko pehchanna good wale ko memorise karne se zyada useful hai.

PICTURE: Paanch mini-panels, ek broken filter har ek mein:

No S (vague scope): Step 2 wala slice kabhi nahi hota — "satellite shall be light," isliye har subsystem sochta hai yeh kisi aur ka number hai; cloud kabhi narrow nahi hota.
No M (fuzzy): Step 3 wali wall missing hai — har dot pass ho jaata hai, kuch fail nahi hota, unfalsifiable.
No A (impossible): Wall poori tarah coral band mein land karti hai — har dot fail ho jaata hai, empty design space.
No R (orphan): Step 5 ki trace chain mein top link toota hua hai — floating box, koi reason nahi.
No T (process not performance): "shall be designed to withstand loads" — koi gate nahi jisse guzarna ho, unverifiable.

Ek picture summary

Yeh poora walkthrough ek canvas par hai: fuzzy wish funnel mein upar se enter karti hai, har SMART letter ek narrowing ring hai, aur neeche se ek single sharp, falsifiable, verifiable sentence baahir aati hai. Yeh poori cheez Systems Engineering V-Model ke andar rehti hai — SMART woh tarika hai jisme V ke left arm (requirements) likhe jaate hain taaki right arm (verification) ise prove kar sake.

Recall Feynman retelling — plain words mein ek dost ko batao

Socho tum ek workshop mein ek wish chillate ho: "ise light banao!" Woh wish ek cloud hai — sau alag satellites sab "light" hone ka claim kar sakte hain, isliye koi nahi jaanta kya banana hai. SMART ek funnel hai jo cloud ko ek buildable sentence mein squeeze karta hai, ek squeeze per letter.

Specific sab kuch wrong part ke baare mein hatata hai — hum matlab bus structure se hai, fuel se nahi. Measurable survivors par ek hard wall girata hai — " $\leq 150$ kg, measured to $\pm 0.3$ kg" — isliye ab ek definite pass side aur fail side hai, aur line ke paas baitha ek part ka bhi defined verdict hota hai; tum ise weigh kar sakte ho aur jaan sakte ho. Achievable check karta hai ki wall fantasy land mein nahi hai: tum " $50$ km/s on chemical fuel" likh sakte ho, lekin best cryogenic engine ka rocket equation bhi kehta hai tumhe aath million kilogram propellant chahiye, isliye woh wall forbidden zone mein hai. Relevant poochhta hai ki woh wall wahan kyun hai — ise ek mission goal tak trace karna chahiye; agar tum ise delete karo aur kuch nahi toot-ta, woh dead weight tha. Testable pick karta hai kaise tum ise prove karoge — ise Test karo, Analyse karo, Inspect karo, ya Demonstrate karo — kyunki ek limit jise tum check nahi kar sakte woh sirf ek wish hai jo ek number pehne hua hai.

Paanch filters pass karo aur tumhe ek sentence milta hai jo falsifiable hai: ek experiment, ek clean pass-or-fail, koi arguments nahi. Woh single sentence contract hai jo tumhe kya chahiye aur jo banta hai ke beech mein hai.

Reveal check:

"The satellite shall be lightweight" falsifiable kyun nahi hai?

Yeh koi number nahi kehta, isliye koi bhi measurement isse kabhi contradict nahi kar sakti — kuch ise false prove nahi kar sakta.

Kaun sa SMART letter wish ko pass/fail boundary mein turn karta hai?

Measurable — yeh value, unit, comparison operator, aur tolerance supply karta hai.

Ek measurable requirement tolerance kyun state karni chahiye?

Har measurement mein uncertainty hoti hai; tolerance ke bina line par baitha ek part undecidable hai, aur ek undecidable case falsifiable nahi hai.

Δ v = 50 km/s

on chemical propulsion Achievable kyun fail karta hai?

Best cryogenic engine bhi ek mass ratio

e^{11.33} \approx 83000

demand karta hai, yaani 100 kg dry mass ke liye ~8 million kg propellant — physical/budget reality se bahar.

T, A, I, D ke char letters kya stand karte hain?

Test, Analysis, Inspection, Demonstration — char verification methods.

"Shall be designed to withstand loads" untestable kyun hai?

Yeh design process constrain karta hai, koi measurable product performance nahi, isliye koi verification gate apply nahi hoti.