Requirements — SMART (Specific, Measurable, Achievable, Relevant, Testable): Question bank

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

Poora page teen ideas par tika hai — neeche ka figure inhe visual banata hai shuru karne se pehle.

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

Performance vs process — ek requirement ko constraint karna chahiye ki product kya achieve karta hai, na ki engineers kya karte hain.
Verifiable — kisi ko ek test/analysis/inspection/demonstration ki taraf point karna hoga jo pass ya fail bolta ho. (Verification and Validation = ek requirement ke meet hone ko prove karne ka discipline (verification) aur yeh prove karna ki woh sahi requirement thi (validation).)
Traceable — har child requirement isliye exist karti hai kyunki kisi parent ko uski zarurat hai. (Ek Requirements Traceability Matrix simply ek table hai jo har requirement ko uske parent objective aur verification method se link karti hai — neeche ki tasveer dekhein.)

Do abbreviations baar baar aati hain; yahan ek baar, plain words mein:

TRL — Technology Readiness Level: technology ki maturity ke liye ek 1–9 scale, jahan 1 hai "sirf ek idea" aur 9 hai "successfully fly ho chuka hai"; roughly TRL 6 ka matlab hai "relevant environment mein demonstrated."
FMEA — Failure Modes and Effects Analysis: ek systematic table jo batata hai ki har part kaise fail ho sakta hai aur agar ho gaya toh mission par kya asar padega.

Verification "V" jiska kai answers mein reference hai, kuch aisa dikhta hai:

True or false — justify

"The satellite bus mass shall be ≤ 150 kg" ek acchi requirement hai sirf isliye kyunki isme "shall" word use hua hai.

False — "shall" sirf yeh signal karta hai ki yeh ek binding requirement hai; acchhaai number, unit aur clear scope (bus, payload nahi) se aati hai. Akela verb kuch verify nahi karta.

Ek requirement Measurable ho sakti hai bina Testable hue.

Practice mein False — agar aap ek number aur unit laga sakte hain toh aapne almost always define kar diya hai ki kya measure karna hai, lekin ek requirement tab hi Testable hoti hai jab ek method (test/analysis/inspection/demo) woh number produce kar sake. Measurable metric hai; Testable usse obtain karne ka zariya hai.

"The structure shall be robust" Specific hai kyunki "robust" clearly strong maanta hai.

False — "robust" mein koi number nahi, koi axis nahi, koi load case nahi, isliye do engineers alag-alag structures ki kalpana karte hain. Specific ka matlab hai interpretation ki koi gunjaaish nahi, jo "robust" uss mein fail ho jaata hai kyunki yahi invite karta hai.

Ek Achievable requirement woh hoti hai jo sasti ho.

False — Achievable ka matlab hai current/near-term tech, budget AUR schedule ke saath feasible, physics violate kiye bina. Cost iska ek pehlu hai; ek requirement affordable ho sakti hai phir bhi physically impossible ho, ya mahagi ho phir bhi bilkul achievable ho.

Jo requirement kisi mission objective se trace hoti hai woh automatically Testable hoti hai.

False — Relevance aur Testability independent axes hain. "Shall be reliable" ek mission se khoobsurti se trace ho sakti hai aur phir bhi untestable reh sakti hai kyunki "reliable" ka koi pass/fail metric nahi hai.

Kisi number mein "± 5%" add karne se requirement hamesha better ho jaati hai.

False — tolerance tabhi help karta hai jab woh real manufacturing/degradation physics ko reflect kare. Ek meaningless ya contradictory tolerance (jaise sensor se bhi tighter) sirf unverifiable requirements banata hai.

Do requirements jo same parameter ko alag values se constrain karti hain, theek hain jab tak dono SMART hain.

False — har ek individually SMART ho sakti hai, lekin saath mein woh inconsistent hain, jo ek system-level defect hai jise pakadne ke liye Requirements Traceability Matrix exist karta hai. SMART zaruri hai, sufficient nahi.

Agar koi requirement Test ki jagah Analysis se verify hoti hai, toh woh sach mein Testable nahi hai.

False — Testable ka matlab hai char methods mein se kisi ek se verifiable: Test, Analysis, Inspection, Demonstration. Analysis (jaise FEA ya thermal model) ek legitimate verification path hai, jab full-scale test impractical ho tab choose kiya jaata hai.

Spot the error

"The propulsion system shall be designed to survive vibration." — kaunsa SMART criterion toot ta hai?

Testable (aur Specific) — "designed to" ek process requirement hai jo engineer ki activity describe karta hai, na ki koi performance outcome jise aap pass/fail kar sakein. Fix: vibration spectrum state karein jise system survive karega, shaker test se verify hoga.

"The solar array shall generate 2.5 kW." — kya missing hai?

Measurability context — koi operator direction theek hai (minimum implied), lekin koi conditions nahi hain: life mein kis point par, sun angle kya, distance kya, temperature kya? Power sab par depend karti hai, isliye conditions ke bina number unfalsifiable hai.

"The GPS receiver shall provide accurate position." — kaun se do letters fail hote hain?

Measurable aur Testable — "accurate" koi number nahi hai. Replace karein "±3 m (3σ) integrated over 10 s" se taaki ek test comparable value produce kar sake.

"The battery shall last a long time." — Measurable ke aage, kaunsi gehra problem chhupi hai?

Yeh Relevant-traceable bhi nahi hai jaise likha gaya hai — "a long time" chhupaata hai ki kaunsi mission need hai (eclipse survival? end-of-life margin?). Parent objective ke bina aap sahi number bhi nahi chun sakte.

"The thermal control shall keep the payload cool." — galti kya hai aur fix kya hai?

"Cool" measurable nahi hai aur "keep" process-flavoured hai. Fix: "shall maintain payload baseplate temperature between −20°C and +40°C during all mission phases, verified by thermal-vacuum test and thermal model." (Verification and Validation woh proof deta hai.)

Ek subsystem requirement likhi jaati hai jisme koi mission objective point nahi karti. Kaunsa SMART letter fail hota hai aur kya karna chahiye?

Relevant fail hota hai — ek orphan requirement sirf cost aur complexity badhata hai bina kisi faide ke. Ya toh trace mein uska sach wala parent dhoondho ya use cut karo.

"The structure shall withstand 8g." — load statement mein kya incomplete hai?

Axis (axial vs lateral) missing hai, yeh clear nahi ki quasi-static hai ya dynamic, aur qualification margin missing hai. Ek complete version har axis, load type, aur test factor specify karta hai (jaise 1.25× design limit).

Why questions

SMART kyun insist karta hai ki requirements falsifiable hon na ki sirf well-intentioned?

Kyunki dozens of teams parallel mein build karte hain; sirf ek pass/fail statement integration ko confirm karne deta hai ki har piece sahi hai. Ek unfalsifiable requirement na succeed ho sakti hai na fail, isliye yeh kuch protect nahi karti.

"Achievable" ko specifically TRL (1–9 technology maturity scale) ke against kyun check kiya jaata hai?

TRL "kya hum isse bana sakte hain?" ko ek measurable maturity scale mein badal deta hai; roughly TRL 6 (relevant environment mein demonstrated) maangna objective evidence deta hai ki tech program ke andar feasible hai, na sirf hoped for.

Ek Measurable requirement mein sirf number nahi, units kyun hone chahiye?

Har physical law dimensioned quantities ko relate karta hai, isliye akela number ambiguous hai — "2.5" watts ho sakta hai ya kilowatts. Units number ko physical meaning dete hain aur directly dimensional analysis se follow karte hain.

Framework Relevant ko baaki chaar criteria se alag kyun rakhta hai?

Baaki chaar poochhte hain "kya yeh ek acchi requirement hai?"; Relevant poochhta hai "kya yeh requirement exist karni chahiye?" Ek bilkul Specific/Measurable/Achievable/Testable requirement jo kisi mission need ko serve nahi karti, pure waste hai.

Hum power output test kyun karte hain lekin re-entry heating analyse kyun karte hain?

Aap Test se verify karte hain jo directly aur safely measure kiya ja sake (simulated sun ke neeche array output), aur Analysis se jo full scale par impractical ya dangerous ho (re-entry). Method physical domain ke baad aata hai, preference ke nahi.

Outcome constrain karna design process constrain karne se preferred kyun hai?

Outcome requirements engineers ko target meet karne ka sabse accha tarika freely choose karne deti hain aur delivered hardware par verifiable rehti hain; process requirements ("shall be designed to…") method lock karte hain phir bhi product par test nahi ho sakti.

Edge cases

Kya kisi requirement mein zero tolerance ho sakta hai (koi exact "=" bina ± ke)?

Tabhi jab measurement meaningfully woh value hit kar sake — zyadatar physical quantities ko band chahiye kyunki manufacturing aur instruments mein spread hota hai. Ek sach wala "=" usually counts ya discrete states mein hota hai (jaise "shall have = 4 thrusters"), continuous physical values mein nahi.

Ek requirement day one par trivially meet ho jaati hai aur huge margin ke saath hamesha meet rehti hai. Kya yeh phir bhi useful hai?

Marginally — yeh testable hai lekin non-binding ho sakti hai, matlab isse kabhi koi design decision drive nahi hua. Aise requirements ko relax ya cut karne ke candidate hain taaki yeh bina kisi faide ke trace aur verification cost add karna band karein.

Mission ke end-of-life boundary par kya hota hai jo conditions ko essential banata hai?

Performance degrade hoti hai (radiation solar output kaat ta hai, batteries fade hoti hain), isliye "≥ 2.5 kW" tabhi falsifiable hai jab aap EOL vs BOL state karein. Wahi hardware beginning-of-life par pass aur end-of-life par fail ho sakta hai bina kisi error ke — condition decide karti hai ki aapka matlab kya tha.

Ek requirement physically possible hai lekin ek small sat ke liye 8 million kg propellant maangti hai. SMART verdict?

Yeh Achievable fail karta hai, physics nahi — Tsiolkovsky Rocket Equation ise allow karta hai, lekin budget, mass aur schedule reality forbid karte hain. Achievable program se bounded hai, sirf nature ke laws se nahi.

Kya "the software shall never crash" Testable hai?

Nahi — infinite inputs par "never" unverifiable hai; aap sab cases exhaust nahi kar sakte. Ise bounded, demonstrable behaviour ki tarah recast karein: "shall recover to a safe mode within 5 s of any single fault, verified by fault-injection test." (Ek FMEA — failure modes aur unke mission effects ki table — aapko bataata hai ki kaun se faults inject karne hain.)

Do subsystems same signal reference karte hain lekin alag voltages assume karte hain. Kaunsi SMART property kuch nahi pakad payi, aur kaunsa document pakadna chahiye?

SMART har requirement ko isolation mein check karta hai aur dono ko pass kar sakta hai; inconsistency ek interface defect hai jo Interface Control Document (ICD) se belong karta hai, Systems Engineering V-Model integration side se enforce hota hai.

Recall Quick self-test

Ek colleague likhta hai "the antenna shall be light and steerable." Har SMART letter naam batao jo yeh violate karta hai. ::: Specific (light? steerable kitna?), Measurable (koi numbers/units nahi), aur Testable (koi pass/fail nahi), jabki Relevant unclear hai kyunki parent need unstated hai. Kaunsa verification method ek dimensional tolerance requirement ke liye fit hai? ::: Inspection — ek coordinate-measuring measurement directly tolerance band ke against pass/fail deta hai.