Theory
क्या आप यह कर सकते हैं, और इसे exactly क्या करना चाहिए?
हाथ में एक clear problem के साथ, अगले दो questions आते हैं, और इन्हें सही करना ज़्यादातर project disasters रोकता है। पहला: क्या यह project अपने time, skills, और resources से realistically हो सकता है? यही feasibility study है। दूसरा: system को exactly क्या करना चाहिए? यही requirement analysis है।
इन्हें skip करना classic student trap की तरफ़ ले जाता है, एक over-ambitious project जो half-built time से बाहर हो जाता है, या एक project जहाँ team ने कभी agree नहीं किया वे क्या build कर रहे हैं। यह lesson दोनों checks cover करता है, तो आप किसी achievable चीज़ को commit करते हैं और start करने से पहले exactly जानते हैं 'done' का क्या मतलब है।
Theory
Feasibility: क्या यह Realistic है?
एक feasibility study पूछती है क्या project actually deliver हो सकता है, इसमें महीने invest करने से पहले। Common angles:
Technical: क्या यह available technology और आपकी skills से build हो सकता है? Operational: क्या यह practice में काम करेगा और actually इस्तेमाल होगा? Economic: क्या cost benefit के worth है, और affordable है? Schedule: क्या यह available time (एक semester) में complete हो सकता है?
एक student project के लिए, time और skill feasibility सबसे ज़्यादा matter करते हैं। Honest question है: क्या HAM, अपनी current abilities के साथ, अपने पास मौजूद semester में THIS finish कर सकते हैं? अगर जवाब नहीं है, इसे किसी ऐसी चीज़ तक scope down कीजिए जिसे आप complete और polish कर सकें। एक finished, modest project हर बार एक ambitious unfinished से बेहतर है।
Theory
Requirements: Functional और Non-Functional
Requirement analysis define करता है system को क्या करना चाहिए, इतनी detail में कि everyone agree करे और आप इसके against build और test कर सकें। Requirements दो kinds में split होती हैं।
Functional requirements specific features या behaviours हैं: 'system एक student को एक event के लिए register करने देगा', 'एक organiser attendee list देख सकेगा'। ये describe करते हैं system क्या करता है।
Non-functional requirements qualities हैं: performance ('एक page 2 seconds के अंदर load होता है'), security ('passwords securely stored हैं'), usability, reliability। ये describe करते हैं यह इसे कितनी अच्छी तरह करता है।
Good requirements team से clear, specific, और agreed होती हैं। ये आपकी build करने की checklist और testing की criteria बनती हैं।
Quiz
इनमें से कौन सी एक non-functional requirement है (एक functional वाली की बजाय)?
- System एक student को एक event के लिए register करने देगा
- System हर request को 2 seconds के अंदर respond करेगा और passwords securely store करेगा
- System एक organiser को attendee list देखने देगा
- System registration पर एक confirmation email भेजेगा
Show the answer
System हर request को 2 seconds के अंदर respond करेगा और passwords securely store करेगा
Non-functional requirements QUALITIES describe करती हैं, system कितनी अच्छी तरह perform करता है, specific features की बजाय। Option B (2 seconds के अंदर respond करना, passwords securely store करना) performance और security के बारे में है, जो qualities हैं, तो यह non-functional है। Options A, C, और D सभी specific FEATURES या behaviours describe करते हैं जो system को करने हैं (एक event के लिए register करना, attendees देखना, एक confirmation email भेजना), जो functional requirements हैं। Distinction: functional requirements बताती हैं system WHAT करता है; non-functional requirements बताती हैं यह HOW WELL करता है (speed, security, usability, reliability)। दोनों matter करती हैं, और दोनों आपके requirement analysis में belong करती हैं।
Think first
एक Project को Realistically Scope करना Hardest, और Most Important, Planning Skill क्यों है?
इतने सारे student projects scope पर क्यों fail होते हैं, और honest feasibility इतनी matter क्यों करती है? फिर tap कीजिए।
Show the answer
क्योंकि ambition easy है और finishing hard है, तो failed student projects का सबसे common cause है available time में realistically complete हो सकने से MORE लेना, और honest feasibility, deliberately उस चीज़ तक scope down करना जो आप actually deliver कर सकें, यही है जो उस failure को रोकता है। एक grand project plan करना genuinely tempting है: बहुत सारे features, cutting-edge technology, panel को wow करने के लिए कुछ। पर एक semester short है, आपकी skills अभी भी develop हो रही हैं, और real development हमेशा expected से ज़्यादा time लेता है (bugs, integration problems, learning curves, life)। तो एक over-scoped project core features half-built के साथ और कुछ भी polished के बिना time से बाहर हो जाता है, जो evaluators और users को immediately unfinished दिखता है, और जो deeply demoralising है। Counter-intuitive truth यह है कि एक SMALL, COMPLETE, well-executed project एक large, broken वाले से कहीं ज़्यादा impressive और valuable है: यह demonstrate करता है कि आप कुछ real define, plan, build, test, और finish कर सकते हैं, जो actual skill है जो assessed हो रही है। Honest feasibility वहाँ पहुँचने का तरीका है: realistically पूछकर 'क्या HAM अपने पास मौजूद time में THIS finish कर सकते हैं?', और अगर नहीं, तो scope तब तक cut करते हुए जब तक answer yes न हो, features की एक core set choose करते हुए जो आप अच्छी तरह build कर सकें बजाय एक wish-list के जिसे आप नहीं कर सकते। यह hard इसलिए है क्योंकि इसके लिए आपकी खुद की ambition resist करनी पड़ती है और limits admit करने पड़ते हैं, जो less के लिए settle करने जैसा लगता है। पर experienced developers जानते हैं reality तक scope करना maturity का mark है, weakness का नहीं: यही difference है एक project के ship होने और एक के collapse होने के बीच। आप हमेशा extra features को 'future scope' की तरह note कर सकते हैं ambition दिखाने के लिए जबकि अपना actual build achievable रखते हुए। तो एक honest feasibility check से driven realistic scoping ही वह planning skill है जो सबसे ज़्यादा determine करती है क्या आपका project succeed करता है, exactly इसलिए क्योंकि default human tendency over-promise करने की है। Finish करने के लिए scope कीजिए, और आप finish करेंगे, जो high aim करने और short गिरने से बेहतर है। Small और done big और broken से बेहतर है।
Summary
Key takeaways
- Problem define करने के बाद, feasibility check कीजिए (क्या यह हो सकता है?) और requirements analyse कीजिए (इसे क्या करना चाहिए?)।
- एक feasibility study assess करती है project realistic है या नहीं: technical, operational, economic, और schedule feasibility।
- एक student project के लिए, time और skill feasibility सबसे ज़्यादा matter करते हैं; semester में finish हो सकने वाली चीज़ तक scope down कीजिए।
- Requirement analysis define करता है system को क्या करना चाहिए, इतना clearly कि इसके against build और test हो सके।
- Functional requirements specific features/behaviours हैं (system क्या करता है); non-functional requirements qualities हैं (कितनी अच्छी तरह: performance, security, usability)।
- Good requirements clear, specific, और agreed होती हैं; ये आपकी build checklist और test criteria बनती हैं।
- Memory hook: check कीजिए यह feasible है (क्या हम इसे finish कर सकते हैं?), फिर functional (what) और non-functional (how well) requirements define कीजिए।