Theory
इसे Write Down कीजिए
एक working project जिसे कोई समझ, इस्तेमाल, या maintain नहीं कर सकता सिर्फ़ आधा finished है। Professional software documented है, और आपका final-year project भी होना चाहिए। Documentation record करता है system क्या करता है, यह कैसे built है, और इसे कैसे इस्तेमाल करें, तो project आपकी team, आपके evaluators, future maintainers, और इसके users के लिए sense बनाता है।
तीन documents सबसे ज़्यादा matter करते हैं: SRS (requirements), design document (structure), और user manual (इसे कैसे इस्तेमाल करें)। यह lesson हर एक cover करता है। इसका ज़्यादातर हिस्सा उन artifacts से draw करता है जो आप पहले से create कर चुके हैं, requirements, ER diagrams, wireframes, अब clear documents में gathered।
At a glance
| Document | यह क्या Record करता है | किसके लिए |
|---|---|---|
| SRS (Software Requirements Specification) | System को क्या करना चाहिए: functional और non-functional requirements | Team, evaluators, stakeholders |
| Design Document | यह कैसे structured है: HLD, LLD, ER diagram, DFD, architecture | Developers और maintainers |
| User Manual | System कैसे इस्तेमाल करें: features, steps, screenshots | End users |
Theory
तीन Documents
SRS (Software Requirements Specification) आपकी requirements का formal record है, वे functional और non-functional requirements जो आपने analyse कीं, written down और agreed। यह define करता है system को क्या करना चाहिए और वह reference है जिसके against सब कुछ build और test होता है।
Design document record करता है system कैसे structured है: आपका high-level और low-level design, ER diagram, data flow diagram, और architecture। यह design decisions capture करता है तो कोई भी system समझ सके, और बाद में maintain कर सके।
User manual end users के लिए है: system इस्तेमाल करने की clear instructions, इसके features, common tasks करने के steps, अक्सर screenshots के साथ। यह सुनिश्चित करता है लोग actually वह इस्तेमाल कर सकें जो आपने build किया। साथ में, ये तीनों आपके project का what, how, और how-to-use cover करते हैं।
Formula
जैसे आगे बढ़ें Document कीजिए, सिर्फ़ End में नहीं
एक practical warning: सारी documentation final week के लिए मत छोड़िए। End में memory से सब कुछ लिखना painful, rushed, और अक्सर inaccurate है (आप भूल जाते हैं decisions क्यों made हुए)।
इसके बजाय, जैसे आगे बढ़ें document कीजिए: आपने planning और design के दौरान पहले से requirements और design artifacts produce किए, तो इन्हें रास्ते में gather और refine करके SRS और design document बनाइए, और features build करते हुए user steps note कीजिए। Development के साथ-साथ लिखी documentation ज़्यादा accurate और कहीं कम stressful है, और इसका मतलब है आपकी report (अगला lesson) का बहुत सा हिस्सा पहले से done है। Documentation को building का हिस्सा समझिए, end में bolted-on एक chore नहीं।
Quiz
कौन सा project document record करता है system को क्या करना चाहिए, इसकी functional और non-functional requirements?
- User manual
- SRS (Software Requirements Specification)
- सिर्फ़ architecture diagram
- ऐसा कोई document नहीं है
Show the answer
SRS (Software Requirements Specification)
SRS (Software Requirements Specification) वह document है जो record करता है system को क्या करना चाहिए, इसकी functional और non-functional requirements, agreed और written down building और testing के reference की तरह। Option A, user manual, END USERS को बताता है system कैसे USE करें, requirements level पर यह क्या करना चाहिए नहीं। Option C, architecture diagram, DESIGN document का हिस्सा है (system कैसे structured है), requirements specification नहीं। Option D wrong है: SRS एक standard, important document है। तीनों याद रखिए: SRS (इसे क्या करना चाहिए), design document (यह कैसे structured है), user manual (इसे कैसे इस्तेमाल करें)।
Think first
जो Project पहले से काम करता है उसके लिए Documentation क्यों Matter करती है?
अगर system correctly run होता है, इसे document करने में effort क्यों बिताएँ? फिर tap कीजिए।
Show the answer
क्योंकि software जो आज काम करता है उसे अभी भी UNDERSTOOD, USED, MAINTAINED, और ASSESSED होना पड़ता है, और documentation ही है जो इन सबको possible बनाती है; इसके बिना, एक working system एक black box है जिसे सिर्फ़ इसके original builders (briefly) समझते हैं। हर audience consider कीजिए। MAINTAINERS के लिए (आपके future selves सहित, या जो भी project को आगे ले जाए), अकेला code शायद ही कभी reveal करता है WHY चीज़ें एक certain तरीके से की गईं या pieces कैसे fit होते हैं; design document और SRS intent और structure explain करते हैं, तो कोई bugs fix कर सकता है, features add कर सकता है, या system को adapt कर सकता है सब कुछ reverse-engineer किए बिना, और documentation के बिना, यहाँ तक original authors भी weeks के अंदर details भूल जाते हैं। USERS के लिए, एक working system जिसे वे operate करना figure out नहीं कर सकते उनके लिए useless है; user manual उस gap को bridge करता है तो लोग actually आपने जो build किया उससे value पा सकें। Development के दौरान आपकी TEAM के लिए, shared documents (requirements, design) हर किसी को क्या build हो रहा है और कैसे इस पर aligned रखते हैं, वह miscommunication रोकते हुए जो group projects को derail करती है। और EVALUATORS के लिए, documentation आपके project को judge करने का एक major हिस्सा है (indeed evaluation scheme इसके लिए marks allocate करता है): clear documents demonstrate करते हैं आपने problem समझी, thoughtfully design किया, और अपना काम professionally communicate कर सकते हैं, जो exactly वह competence है जो एक final-year project दिखानी चाहिए। एक professional-habit dimension भी है: industry में, undocumented software एक liability है, और clear documentation produce करने की ability एक valued, expected skill है। तो documentation एक finished system पर tacked-on busywork नहीं है; यह वह है जो एक running program को एक comprehensible, usable, maintainable, और credible piece of engineering में बदल देता है। एक system जो काम करता है पर undocumented है fragile और opaque है; good documentation वाला same system trustworthy और lasting है। यही वजह है यहाँ तक एक working project भी documented होना चाहिए, और यही वजह है इसे अच्छी तरह करना project को अच्छी तरह करने का हिस्सा है। Documentation ही है जो working software को हर किसी के लिए understandable और usable बनाता है जिसे इसकी ज़रूरत है।
Summary
Key takeaways
- Documentation record करता है system क्या करता है, यह कैसे built है, और इसे कैसे इस्तेमाल करें, project को understandable, maintainable, और assessable बनाते हुए।
- SRS (Software Requirements Specification) requirements record करता है, functional और non-functional, जो system को meet करनी चाहिए।
- Design document structure record करता है: HLD, LLD, ER diagram, DFD, और architecture।
- User manual end users को system इस्तेमाल करने की clear instructions देता है (features, steps, screenshots)।
- साथ में ये what (SRS), how (design), और how-to-use (user manual) cover करते हैं।
- जैसे आगे बढ़ें document कीजिए, वे artifacts gather और refine करते हुए जो आप पहले से produce कर चुके हैं, end में memory से सब कुछ लिखने की बजाय।
- Memory hook: requirements के लिए SRS, structure के लिए design document, users के लिए user manual, documented software usable और maintainable है।