Theory
તે લખીને document કરો
Working project જેને કોઈ સમજી, વાપરી અથવા maintain ન કરી શકે તે માત્ર half finished છે. Professional software documented હોય છે અને final-year project પણ એવો જ હોવો જોઈએ. Documentation system શું કરે છે, કેવી રીતે build થયું છે અને કેવી રીતે વાપરવું તે record કરે છે. તેથી team, evaluators, future maintainers અને users projectને સમજી શકે છે.
ત્રણ documents સૌથી મહત્વપૂર્ણ છે: SRS (requirements), design document (structure) અને user manual (use કરવાની રીત). આ lesson દરેક document સમજાવે છે. Requirements, ER diagrams અને wireframes જેવા પહેલાં બનાવેલા artifacts હવે clear documentsમાં ગોઠવવામાં આવે છે.
At a glance
| Document | What it records | For whom |
|---|---|---|
| SRS (Software Requirements Specification) | Systemએ શું કરવું જોઈએ: functional અને non-functional requirements | Team, evaluators અને stakeholders |
| Design document | System કેવી રીતે 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 છે. તેમાં analysed અને agreed functional તથા non-functional requirements લખાય છે. તે systemએ શું કરવું જોઈએ તે define કરે છે અને building તથા testing માટે reference બને છે.
Design document systemની structure કેવી છે તે record કરે છે: high-level design, low-level design, ER diagram, data flow diagram અને architecture. તે design decisions capture કરે છે જેથી કોઈ પણ વ્યક્તિ system સમજી અને પછી maintain કરી શકે.
User manual end users માટે છે. તેમાં systemની features, common tasks કરવાની steps અને ઘણીવાર screenshots સાથે clear instructions હોય છે. તે ખાતરી કરે છે કે તમે બનાવેલું system લોકો વાસ્તવમાં વાપરી શકે. ત્રણેય સાથે મળીને what, how અને how-to-use cover કરે છે.
Formula
Development સાથે document કરો, અંતે નહીં
બધી documentation final week સુધી ન મુલતવી રાખો. અંતે memory પરથી બધું લખવું painful, rushed અને ઘણીવાર inaccurate બને છે, કારણ કે design decisions શા માટે લીધા તે ભૂલી જાઓ છો.
તેના બદલે as you go document કરો. Planning અને design દરમિયાન બનાવેલા requirements અને diagramsને SRS તથા design documentમાં ધીમે ધીમે gather અને refine કરો. Features build કરતી વખતે user steps note કરો. Development સાથે લખાયેલી documentation વધુ accurate અને ઓછી stressful હોય છે. Reportનો મોટો ભાગ પણ પહેલેથી તૈયાર થઈ જાય છે. Documentationને અંતે લગાડેલું chore નહીં, પરંતુ building processનો ભાગ માનો.
Quiz
Systemએ શું કરવું જોઈએ, એટલે કે functional અને non-functional requirements, કયા documentમાં record થાય છે?
- User manual
- SRS (Software Requirements Specification)
- માત્ર architecture diagram
- આવો કોઈ document નથી
Show the answer
SRS (Software Requirements Specification)
SRS (Software Requirements Specification) systemએ શું કરવું જોઈએ તે functional અને non-functional requirements તરીકે record કરે છે. તે building અને testing માટે agreed reference છે. User manual END USERSને system કેવી રીતે USE કરવું તે કહે છે; requirements શું હોવી જોઈએ તે નહીં. Architecture diagram design documentનો ભાગ છે અને system કેવી રીતે structured છે તે બતાવે છે. યાદ રાખો: SRS = what it must do, design document = how it is structured, user manual = how to use it.
Think first
Project already works તો documentation શા માટે જરૂરી છે?
System correctly ચાલે છે, તો તેને document કરવા માટે extra effort શા માટે કરવો? પછી tap.
Show the answer
કારણ કે working softwareને પણ UNDERSTOOD, USED, MAINTAINED અને ASSESSED થવું પડે છે. Documentation વગર working system black box બની જાય છે, જેને શરૂઆતના builders સિવાય કોઈ સરળતાથી સમજી શકતું નથી.
Maintainers માટે code હંમેશા decisionsનું WHY અથવા components કેવી રીતે fit થાય છે તે બતાવતું નથી. SRS અને design document intent તથા structure સમજાવે છે, જેથી bugs fix, features add અથવા system adapt કરી શકાય. થોડા અઠવાડિયામાં original authors પણ details ભૂલી શકે છે.
Users માટે system working હોવા છતાં તે કેવી રીતે operate કરવું સમજાતું ન હોય તો system useless બની શકે છે. User manual આ gap દૂર કરે છે. Team માટે shared requirements અને design documents alignment રાખે છે અને group-project miscommunication ઘટાડે છે.
Evaluators માટે documentation project assessmentનો મહત્વનો ભાગ છે. Clear documents બતાવે છે કે તમે problem સમજી, thoughtful design કર્યું અને professional રીતે work communicate કરી શકો છો. Industryમાં undocumented software liability છે; clear documentation એક expected professional skill છે.
તેથી documentation busywork નથી. તે running programને comprehensible, usable, maintainable અને credible engineeringમાં ફેરવે છે. Working પરંતુ undocumented system fragile અને opaque છે; સારી documentationવાળું system trustworthy અને lasting બને છે.
Summary
Key takeaways
- Documentation system શું કરે છે, કેવી રીતે build થયું છે અને કેવી રીતે વાપરવું તે record કરે છે.
- SRS functional અને non-functional requirements record કરે છે.
- Design document HLD, LLD, ER diagram, DFD અને architecture જેવી structure બતાવે છે.
- User manual end usersને features, steps અને screenshots દ્વારા system વાપરવા સમજાવે છે.
- ત્રણ documents મળીને what (SRS), how (design) અને how-to-use (user manual) cover કરે છે.
- Documentation development સાથે લખો; અંતે memory પરથી બધું લખવાનું ટાળો.
- Memory hook: SRS requirements માટે, design document structure માટે અને user manual users માટે; documented software usable અને maintainable બને છે.