സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് പ്രക്രിയ

Read Time:23 Minute

ലല്ലു ആന്തൂര്‍

സോഫ്റ്റ്‌വെയർ നിർമ്മാണത്തിലേക്കുള്ള ഒരു എത്തിനോട്ടമായിരുന്നു കഴിഞ്ഞ ലേഖനം. സോഫ്റ്റ് വെയര്‍ കമ്പനികള്‍ അതിലെ ഓരോ ഘട്ടവും എങ്ങിനെയാണ് കൈകാര്യം ചെയ്യുന്നതെന്ന് ഇനി വിശദമായി നോക്കാം. ഒരു സോഫ്റ്റ്‌വെയർ നിർമാണം തുടങ്ങുന്നതിനു ചില മുന്നൊരുക്കങ്ങളൊക്കെ ആവശ്യമുണ്ട്. നിർമിക്കാൻ പോവുന്ന സോഫ്റ്റ്‌വെയർ വാങ്ങാൻ ആളുകൾ ഉണ്ടാവുമോ, വാങ്ങുന്നവർക്ക് അത് പ്രയോജനകരമാവുമോ (desirability), ഈ സോഫ്റ്റ്‌വെയർ വിൽക്കുന്നത് വഴി ലാഭം ഉണ്ടാക്കാൻ സാധിക്കുമോ (viability),എന്നൊക്കെയാവും കമ്പിനി ചിന്തിക്കുക. (ഒരു കമ്പനിയെ സംബന്ധിച്ചിടത്തോളം ലാഭമാണല്ലോ പ്രധാന മാനദണ്ഡം). ഒപ്പം ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ നിർമിക്കാൻ ആവശ്യമായ സാങ്കേതികവിദ്യകൾ ലഭ്യമാണോ(feasibility), തുടങ്ങിയ കാര്യങ്ങളിൽ ഒരു പ്രാഥമിക നിഗമനം കൂടി ആവശ്യമാണ്. അതുപോലെ തന്നെ ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ നിർമിക്കാൻ പ്രാപ്തരായ ആളുകൾ കമ്പനിയിൽ ഇപ്പോൾ ജോലി ചെയ്യുന്നുണ്ടോ, ഇനി അഥവാ ഇല്ലെങ്കിൽ അത്തരക്കാരെ ജോലിക്ക് എടുക്കാൻ ഉള്ള ബജറ്റ് ഉണ്ടോ, തുടങ്ങിയ കാര്യങ്ങളും ഈ ഘട്ടത്തിൽ വിലയിരുത്തപ്പെടും. ഈ ഒരു നിഗമനത്തിന്റെ പുറത്താണ് സോഫ്റ്റ്‌വെയർ നിർമിക്കാൻ ഉള്ള തീരുമാനം ഒരു കമ്പനി കൈക്കൊള്ളുന്നത്. ഈ പ്രക്രിയയെ feasibility study എന്ന് പറയുന്നു. feasibility study നടത്തി ഒരു സോഫ്റ്റ്‌വെയർ നിർമിക്കാൻ തീരുമാനിച്ചാൽ പിന്നീട് ഒരു തിരിഞ്ഞുനോട്ടം പൊതുവെ ഉണ്ടാവാറില്ല.

നമുക്ക് സൂപ്പർ മാർക്കറ്റുകളുടെ കാര്യം എടുക്കാം. എന്തൊക്കെ രീതിയിലുള്ള രേഖകളാണ് ഒരു സൂപ്പർ മാർക്കറ്റിൽ സൂക്ഷിക്കുക? സ്റ്റോക്ക് വരുമ്പോൾ അതിനെ സ്റ്റോക്ക് രജിസ്റ്ററിൽ രേഖപ്പെടുത്തണം. ഓരോ ഉപഭോക്താക്കളും സാധനം വാങ്ങുമ്പോൾ അതിന്റെ ബില്ല് തയ്യാറാക്കി നൽകണം. പണം വാങ്ങി ബാക്കി നൽകണം. അതാതു ദിവസത്തെ വരുമാനം രജിസ്റ്ററിൽ രേഖപ്പെടുത്തണം. എല്ലാ ദിവസവും/മാസവും ഇതിനെ സ്റ്റോക്കുമായി താരതമ്യപ്പെടുത്തി വരവ് ചിലവ് കണക്ക് തിട്ടപ്പെടുത്തണം. ഏതെങ്കിലും സാധനം സ്റ്റോക്ക് തീരാനാവുമ്പോൾ വീണ്ടും ഓർഡർ ചെയ്യണം. ഇതെല്ലം തന്നെ വളരെ വിഷമകരമായ കാര്യങ്ങളാണ്. ബില്ല് തയ്യാറാക്കാൻ എല്ലാ സാധനങ്ങളുടെയും വില പാക്കറ്റ് നോക്കി എഴുതി അളവനുസരിച്ച് ഗുണിച്ച് വില കണ്ടുപിടിക്കണം. പിന്നീട് എല്ലാം കൂട്ടി ആകെ തുക കണ്ടുപിടിക്കണം. സ്റ്റോക്ക് വരുമ്പോൾ ഓരോ സാധനവും എണ്ണി തിട്ടപ്പെടുത്തി രജിസ്റ്ററിൽ രേഖപ്പെടുത്തി വയ്ക്കണം. ഇവയിൽ ഏതിലെങ്കിലും ഒരു തെറ്റ് പറ്റിയാൽ തിരുത്താനും വളരെ ബുദ്ധിമുട്ടാണ്. അതുമാത്രമല്ല, ഒരു വെള്ളപ്പൊക്കമോ തീപിടുത്തമോ വന്നാൽ ഇവയെല്ലാം നഷ്ടമാവുകയും ചെയ്യും. അല്ലെങ്കിൽ സ്റ്റോർ റൂമിൽ ഇരുന്നു എലിയോ പാറ്റയോ തിന്നു തീർക്കും.

ഇത്തരം പ്രശ്നങ്ങൾക്കൊക്കെ ഒരു പരിഹാരം ഉണ്ടാക്കാൻ ഒരു സോഫ്ട്‍വെയറിന്റെ സഹായം തേടുന്നതിലൂടെ സാധിക്കും. എന്ന് മാത്രമല്ല മുമ്പത്തേക്കാൾ എളുപ്പത്തിൽ, വേഗത്തിൽ, കൃത്യതയോടെ പണികൾ ചെയ്യാൻ സാധിക്കും. സൂപ്പർമാർക്കറ്റിന്റെ പ്രവർത്തനം മൊത്തത്തിൽ കൂടുതൽ കാര്യക്ഷമമാക്കാൻ സഹായിക്കുന്ന ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ മിക്ക സൂപ്പര്മാര്ക്കറ്റും വാങ്ങും എന്നും ഏതാണ്ട് ഉറപ്പാണ്. ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ നിർമിക്കുന്നതിന് പ്രസക്തി ഉണ്ടോ, അവ വിൽക്കപെടുമോ തുടങ്ങിയ ചോദ്യങ്ങൾക്കു അനുകൂലമായ ഒരു ഉത്തരം ലഭിച്ചാൽ സോഫ്റ്റ്‌വെയർ നിർമാണത്തിന്റെ അടുത്ത ഘട്ടത്തിലേക്ക് നീങ്ങാം.

പിന്നീട് ആരംഭിക്കുന്ന സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിങ് പ്രക്രിയയിലെ ഘട്ടമാണ് റിക്വയർമെന്റ് അനാലിസിസ്. ഒരു സോഫ്റ്റ്‌വെയറിൽ എന്തൊക്കെ സവിശേഷതകൾ (features) ഉണ്ടായിരിക്കണം എന്നുള്ള തീരുമാനം എടുക്കുന്ന ഘട്ടമാണ് ഇത്. സൂപ്പർ മാർക്കറ്റിന്റെ കാര്യം നോക്കിയാൽ വരവും ചിലവും രേഖപ്പെടുത്തി വെക്കണം എന്ന സിംപിൾ ആയ സംഗതി അല്ലെ ഇവിടെ ആവശ്യമുള്ളൂ എന്നാകും പലരും ചിന്തിക്കുക. എന്നാൽ സത്യത്തിൽ അതത്ര സിംപിൾ അല്ല. വരവും ചിലവും കണക്കാക്കണം എന്നാലോചിക്കുമ്പോൾ ഒരു സോഫ്ട്‍വെയർ എൻജിനീയറുടെ മനസ്സിൽ അതിനു അനുബന്ധമായി ഒരു പാട് ചോദ്യങ്ങൾ ഉയരും. വരവ് എങ്ങിനെ കണക്കാക്കും? ചിലവ് എങ്ങിനെ കണക്കാക്കും? ഒരു ബില്ല് തയാറാക്കുമ്പോൾ അതിൽ എന്തൊക്കെ കാര്യങ്ങൾ ഏതു രീതിയിൽ കാണിക്കണം? അതിലെ നികുതി കണക്കാക്കുന്നത് എങ്ങിനെയാണ്? ഒരാൾ സാധനം വാങ്ങിയാൽ ഏതൊക്കെ രീതിയിൽ പണം നൽകും? പണമായിട്ട് മാത്രമാണോ അതോ ക്രെഡിറ്റ്/ഡെബിറ്റ് കാർഡുകൾ സ്വീകരിക്കാമോ? പേ-ടി എം, ഗൂഗിൾ പേ തുടങ്ങിയവ ഉപയോഗിച്ച് പണമടക്കമോ? ഇത്തരത്തിൽ നൂറുകണക്കിന് ചോദ്യങ്ങളുടെ ഉത്തരം ലഭിച്ചാലേ ഫലപ്രദമായ ഒരു സോഫ്റ്റ്‌വെയർ നമ്മൾക്ക് നിർമിക്കാൻ സാധിക്കൂ. തീർന്നില്ല, ഇത്തരം വിവരങ്ങൾ എങ്ങിനെ എവിടെ സ്റ്റോർ ചെയ്യണം, ഒരു വെള്ളപ്പൊക്കമോ , അഗ്നിബാധയോ വന്നാൽ ഈ വിവരങ്ങൾ എങ്ങിനെ സുരക്ഷിതമായി മാറ്റിവയ്ക്കാം, ആരൊക്കെയാണ് ഈ സോഫ്റ്റ്‌വെയർ ദിവസേന ഉപയോഗിക്കാൻ പോവുന്നത്, അവരുടെ ആവശ്യങ്ങൾ എന്തൊക്കെയാണ്, ഏതൊക്കെ പ്രക്രിയകളാണ് കൂടുതൽ തവണ ചെയ്യുന്നത് എന്ന് തുടങ്ങി ഏതു രാജ്യത്തിൻറെ നിയമാവലിയാണ് പാലിക്കേണ്ടത് എന്നത് വരെയുള്ള അനവധി ചോദ്യങ്ങൾക്കു ഉത്തരം ലഭിക്കേണ്ടതായുണ്ട്.

ഈ ചോദ്യങ്ങളുടെ ഒന്നും ഉത്തരം ഇതുണ്ടാക്കാൻ ഇരിക്കുന്ന സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയർമാർക്ക് അറിയണം എന്നില്ല. ഇതിന്റെ ഒക്കെ ഉത്തരം കൃത്യമായി അറിയുന്നവർക്കാകട്ടെ ഒരു സോഫ്റ്റ്‌വെയർ ഉണ്ടാക്കാൻ സാധിക്കാറുമില്ല. അതുകൊണ്ടു തന്നെ ഈ രണ്ടുകൂട്ടരും തമ്മിലുള്ള ഒരു ആശയവിനിമയം ആണ് അടുത്ത ഘട്ടം. അതിനു പല വഴികൾ തേടാം. നേരിട്ടുള്ള കൂടിക്കാഴ്ചയോ സർവേയോ അങ്ങനെ പലതും. ഇതും അത്ര എളുപ്പമുള്ള സംഗതി ആണെന്ന് ധരിക്കേണ്ട. ഒരുപാടു ആൾക്കാരെ ഇതിനായി ബന്ധപ്പെടേണ്ടി വരും. വരവ് ചിലവ് കണക്കുകൾ, ഇടപാടുകൾ തുടങ്ങിയവയെക്കുറിച്ച് ഒരു സൂപ്പർ മാർക്കറ്റിലെ അക്കൗണ്ടന്റിനാണ് നല്ല ധാരണ ഉണ്ടാവുക. എന്നാൽ ദൈനംദിന കാര്യങ്ങളെക്കുറിച്ച് നന്നായി അറിയുക ഒരുപക്ഷേ മാനേജർക്കോ ബില്ലിങ് വിഭാഗത്തിലെ ജോലിക്കാർക്കോ ആവും. അതുപോലെ തന്നെ ഇവരുടെ ഓരോരുത്തരും കൈകാര്യം ചെയ്യേണ്ട കാര്യങ്ങളും അവർക്കു ആവശ്യമായ വിവരങ്ങളും വ്യത്യസ്തമായിരിക്കും. അതുകൊണ്ടു തന്നെ ഇവരൊരുത്തരുടേയും ആവശ്യങ്ങൾ പ്രത്യേകം ചോദിച്ചറിയേണ്ടതായുണ്ട്. ഉപഭോക്താവിന്റെ ആവശ്യകതയുടെ സൂഷ്മാംശങ്ങൾ വരെ സോഫ്റ്റ്‌വെയർ നിർമിക്കാൻ ഇരിക്കുന്നവർക്ക് ബോധ്യമാകുക എന്നതാണ് പ്രധാനം.

ഒരു സോഫ്റ്റ്‌വെയറിന്റെ requirements നെ പൊതുവെ 4 തലങ്ങളായാണ് തിരിക്കാറുള്ളത്. സോഫ്റ്റ്‌വെയറിന്റെ സുപ്രധാനമായ സവിശേഷതകളെ theme അല്ലെങ്കിൽ initiative എന്നാണ് പറയാറുള്ളത്. നമ്മുടെ ബില്ലിംഗ് സോഫ്റ്റ്‌വെയർ എടുത്താൽ, അതിലെ വരവ് ചിലവ് കണക്ക് സൂക്ഷിക്കാനും ബില്ല് തയ്യാറാക്കാനും ഉള്ള കഴിവിനെ ഒരു initiative ആയി കണക്കാക്കാം. ഇത്തരം ഒരു initiative ഒറ്റയടിക്ക് അനായാസം നിർമിക്കുക അസാധ്യമാണ്. ആഴ്ചകളോ മാസങ്ങളോ എടുത്ത് മാത്രമേ ഇത്തരം ഒരു സംവിധാനം പൂർണമായി നിർമിക്കാൻ സാധിക്കുകയുള്ളു. അതുകൊണ്ടുതന്നെ അതിനെ ചെറു ഘടകങ്ങളായി തിരിക്കും. ഇത്തരം ഘടകങ്ങളെ epic എന്നാണ് വിളിക്കാറുള്ളത്. ഇത്തരം epic കൾ വ്യാപ്തിയിൽ initiative കളേക്കാൾ ചെറുതാണെങ്കിലും ഇവയും പൂർത്തീകരിക്കാൻ രണ്ടോ മൂന്നോ ആഴ്ചകൾ വേണ്ടിവരും. ഉദാഹരണത്തിന് വരവ് ചിലവ് കണക്കുകൾ സൂക്ഷിക്കാനുള്ള സംവിധാനത്തെ ഒരു epic ആയി കരുതാം. അതുകൊണ്ടുതന്നെ ഇത്തരം epic കളെ വീണ്ടും വിഭജിച്ച് user story കളാക്കി മാറ്റും. ഒരു user story കൂടിപ്പോയാൽ ഒരാഴ്ചയ്ക്കുള്ളിൽ തീർക്കാൻ പറ്റുന്നതായിരിക്കും. ഉദാഹരണത്തിന് സ്റ്റോക്ക് വരുമ്പോൾ സാധനങ്ങളുടെ വിവരങ്ങൾ രേഖപ്പെടുത്താനും അളവുകൾ പുനഃക്രമീകരിക്കാനുമുള്ള കഴിവിനെ ഒരു user story ആയി കരുതാം. ഒരു സോഫ്റ്റ്‌വെയർ എൻജിനീയറെ സംബന്ധിച്ചിടത്തോളം ഒരു user story പോലും വലിയ ഒരു കടമ്പയാണ്. അതിനാൽ user story കളെ വീണ്ടും വിഭജിച്ച് task കളും sub-taskകളുമായിആയി തിരിക്കും. ഇത്തരം task കളും sub-task കളും പൂർത്തിയാക്കാൻ ഒന്നോ രണ്ടോ ദിവസം മതിയാവും. Task ഉം sub-task ഉം ആയുള്ള വിഭജനം വരെ തുടക്കത്തിൽ തന്നെ ചെയ്യുക അസാധ്യമാണ്. റിക്വയർമെന്റ് അനാലിസിസ് കഴിയുമ്പോൾ പൊതുവെ initiative കൾ വളരെ വ്യക്തമായി നിർവചിക്കാനാവും. ചില epic കളും നിർവചിക്കാനായേക്കാം. ബാക്കി ഉള്ള വിഭജനം ഇനിയങ്ങോട്ടുള്ള ഓരോരോ ഘട്ടങ്ങളിലായാണ് നടക്കുക. ഒരു ഉദാഹരണം നമുക്ക് ഇവിടെ കാണാം.

ഈ രീതിയിൽ ജോലി വിഭജിക്കുന്നതിനു രണ്ടുകാരണങ്ങളാണ് ഉള്ളത്. ഒന്ന്, അത് ജോലിയുടെ അളവ് അറിയാനും ക്രമീകരിക്കാനും സഹായിക്കുന്നു. രണ്ട്, ഇത്തരം ഘടകങ്ങൾക്ക് മുൻഗണന നൽകാനും പ്രാധാന്യം കൂടുതലുള്ളവ ആദ്യം ചെയ്യാനും സഹായിക്കുന്നു. ഇവ രണ്ടും ഒരു സോഫ്റ്റ്‌വെയർ കമ്പനിയെ സംബന്ധിച്ചിടത്തോളം വളരെ പ്രാധാന്യമുള്ള വിവരങ്ങളാണ്. ജോലിയുടെ വ്യാപ്തിയും ആളുകളുടെ എണ്ണവും കണക്കിലെടുത്ത് സോഫ്റ്റ്‌വെയർ എപ്പോൾ പൂർത്തിയാക്കാൻ സാധിക്കും എന്ന് അനുമാനിക്കാവുന്നതാണ്. അപ്രതീക്ഷിതമായ എന്തെങ്കിലും തടസങ്ങൾ നേരിട്ടാൽ ഏത് രീതിയിൽ അതിനെ തരണം ചെയ്യാം എന്നും ഇത് ഉപയോഗിച്ച് കണക്കുകൂട്ടാം. അടിസ്ഥാനപരമായ ആവശ്യങ്ങൾ നിറവേറ്റാൻ സാധിക്കുന്ന ഒരു സോഫ്റ്റ്‌വെയർ വളരെ നേരത്തെ നിർമിക്കാനും ഇതുവഴി സാധിക്കുന്നു. MVP (Minimum Viable Product) എന്നാണ് ഇത് അറിയപ്പെടുന്നത്. നിർമിക്കാൻ ഉദ്ദേശിക്കുന്ന സോഫ്റ്റ്‌വെയറിന്റെ ആദ്യ രൂപമായി MVP യെ കണക്കാക്കാം. ഉദാഹരണത്തിന്, വരവ് ചിലവ് കണക്കുകൾ സൂക്ഷിക്കാനും ബില്ല് തയ്യാറാക്കാനും സാധിച്ചാൽ അതൊരു എംവിപി ആണ്. ക്രെഡിറ്റ്/ഡെബിറ്റ് കാർഡോ ഗൂഗിൾ പേയോ ഉപയോഗിക്കാനുള്ള സംവിധാനം ഇല്ലെങ്കിലും സോഫ്റ്റ്‌വെയർ ഫലപ്രദമായി ഉപയോഗിക്കാം. എന്നാൽ ഇവ ഉണ്ടെങ്കിൽ കുറച്ചുകൂടി സൗകര്യപ്രദമാവും എന്ന് മാത്രം.

ഈ രീതിയിൽ സോഫ്റ്റ്‌വെയർ സവിശേഷതകളെ ക്രോഡീകരിച്ച് സൂക്ഷിക്കാനുള്ള നിരവധി സോഫ്റ്റ്‌വെയറുകൾ ഇന്ന് ലഭ്യമാണ്. മൈക്രോസോഫ്റ്റിന്റെ GitHub, അറ്റ്‌ലേഷ്യന്റെ Jira, Aha!, Trello തുടങ്ങി ധാരാളം ഉദാഹരണങ്ങൾ. ഈ സോഫ്റ്റ്‌വെയറുകളിൽ എല്ലാം തന്നെ മുകളിൽ പറഞ്ഞ രീതിയിലുള്ള ക്രമീകരണങ്ങൾ വളരെ നിഷ്പ്രയാസം ചെയ്യാവുന്നതാണ്. ഈ സോഫ്റ്റ്‌വെയറുകളുടെ ഒരു പ്രത്യേകത ഇത് ഒരു collaboration platform ആണെന്നുള്ളതാണ്. ഏതെങ്കിലും task കളിൽ സംശയം തോന്നുന്ന പക്ഷം ചോദിക്കുവാനും മറ്റു സഹപ്രവർത്തകരിൽനിന്നും ഉത്തരം ലഭിക്കുവാനും ഉള്ള സംവിധാനങ്ങൾ ഈ സോഫ്റ്റ്‌വെയറിൽ ഉണ്ട്. ഇത്തരത്തിലുള്ള സോഫ്റ്റ്‌വെയറുകളുടെ മറ്റൊരു പ്രത്യേകത എന്ന് പറയുന്നത് ജോലി പ്ലാൻ ചെയ്യാനുള്ള കഴിവാണ്. ഏത് task ആരാണ് ചെയ്യുന്നത്, അതിനു എത്ര സമയം വേണമെന്നാണ് കണക്കാക്കിയത്, എത്ര സമയത്തിനുള്ളിലാണ് അത് പൂർത്തീകരിച്ചത്, ഏതൊക്കെ user story പൂർത്തിയായി, തുടങ്ങി നിരവധി കാര്യങ്ങൾ അനായാസമായി ഇവയിൽ രേഖപ്പെടുത്താം. ഒരുപാടുപേർ ചേർന്ന് ഒരു സോഫ്റ്റ്‌വെയറിനായി പ്രവർത്തിക്കുമ്പോൾ ഇത്തരം collaboration platform കൾ ഏറെ പ്രയോജനകരമാണ്.

നമ്മുടെ മൂന്നാമത്തെയും അവസാനത്തേയും പ്രശ്നമാണ് ഉപയോക്താക്കളെ സോഫ്റ്റ്‌വെയർ സവിശേഷതകളുമായി ബന്ധിപ്പിക്കുക എന്നത്. ഇതിനായി പ്രധാനമായും ചെയ്യുന്നത് ഉപഭോക്താക്കളുടെ സ്ഥാപനങ്ങളിലുള്ള വിവിധ സ്ഥാനങ്ങൾക്ക് (മാനേജർ, അക്കൗണ്ടന്റ്, മുതലായവ) തത്തുല്യമായ രീതിയിൽ സാങ്കല്പിക കഥാപാത്രങ്ങളെ നിർമിക്കുക എന്നതാണ്. ഇത്തരം സാങ്കല്പിക കഥാപാത്രങ്ങൾക്ക് ഓരോ പദവി നൽകുകയും അവരുടെ ജോലി പൂർത്തിയാക്കാൻ വേണ്ട കാര്യങ്ങൾ അവരുടെ പേരിനു നേരെ രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു. ഇത്തരം പദവികളെ persona എന്ന് പറയുന്നു. ഒരു ഉപയോക്താവ് തന്റെ ദൈനംദിന ജോലിയിൽ ഒരു സോഫ്റ്റ്‌വെയർ എങ്ങിനെ ഉപയോഗിക്കുന്നു എന്ന് സൂചിപ്പിക്കാനും ഇത്തരം persona കൾ സഹായിക്കുന്നു. ഈ രേഖ പിന്നീട് സോഫ്റ്റ്‌വെയർ ടെസ്റ്റ് ചെയ്യുമ്പോൾ ഓരോ persona യുടെയും ആവശ്യകതകൾ പൂർത്തീകരിക്കപ്പെട്ടോ എന്ന് ഉറപ്പുവരുത്താൻ ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, ബില്ല് തയ്യാറാക്കുന്ന ഒരാൾക്ക് സാധനങ്ങളുടെ പേരും അളവും രേഖപ്പെടുത്തി ബില്ല് തയ്യാറാക്കാനുള്ള സംവിധാനമാവും പ്രധാനമായും വേണ്ടത്. അതിനെ “ബില്ലിങ് സ്റ്റാഫ്” എന്ന persona യുമായി ബന്ധിപ്പിക്കും. എന്നാൽ ഒരു മാനേജർക്ക് ഓരോ ദിവസത്തേയും വിറ്റുവരവ് കണക്ക് അറിയുന്നതിലാവും താല്പര്യം. അതിനെ “മാനേജർ” എന്ന persona യുമായും ബന്ധിപ്പിക്കാം.

നമ്മൾ ഇതുവരെ സംസാരിച്ചത് ഒരു ഉപഭോക്താവിന്റെ ആവശ്യതകളെക്കുറിച്ചാണ് (customer requirements അഥവാ functional requirements). എന്നാൽ ഇതല്ലാതെ മറ്റു പല ആവശ്യകതകളും ഈ ഒരു ഘട്ടത്തിൽ പരിശോധിക്കപെടുന്നു. അതിലെ പ്രമുഖമായ ഒന്നാണ് performance requirements. ഈ സോഫ്റ്റ്‌വെയർ പ്രവർത്തിക്കുന്നതിന്റെ ഒരു ചട്ടക്കൂടാണ് performance requirements . സോഫ്റ്റ്‌വെയറിന്റെ പ്രവർത്തനത്തിന് എത്രത്തോളം വിഭവങ്ങൾ (resources) ഉപയോഗിക്കാനാവും, എത്ര സമയത്തിനുള്ളിൽ സോഫ്റ്റ്‌വെയർ കാര്യങ്ങൾ ചെയ്യണം തുടങ്ങിയ കാര്യങ്ങളാണ് ഇവിടെ പ്രതിപാദിക്കുന്നത്. ഒരു ബില്ല് തയ്യാറാക്കാൻ അര മണിക്കൂർ സമയം വേണം എന്ന് ഒരു സോഫ്റ്റ്‌വെയർ പറഞ്ഞാൽ അത്തരം ഒരു സോഫ്റ്റ്‌വെയർ തികച്ചും അപ്രായോഗികമാണ്. അതുപോലെ തന്നെ സോഫ്റ്റ്‌വെയറിനു പ്രവർത്തിക്കാൻ സൂപ്പർ കമ്പ്യൂട്ടർ വേണം എന്ന് പറഞ്ഞാൽ അതും അപ്രായോഗികം തന്നെ.

Performance പോലെ പ്രാധാന്യമുള്ള മറ്റു ചില റിക്വയർമെന്റുകളും ഉണ്ട്. അതിൽ മുന്നിട്ടു നിൽക്കുന്നതാണ് സുരക്ഷിതത്വം (security). നമ്മുടെ സോഫ്റ്റ്‌വെയറിൽ സൂക്ഷിച്ചിരിക്കുന്ന വിവരങ്ങൾ എത്രത്തോളം സുരക്ഷിതമാക്കാൻ പറ്റും എന്നുള്ള കാര്യങ്ങളാണ് ഇവിടെ നോക്കുന്നത്. ഒരു തടസവും കൂടാതെ ആർക്കു വേണമെങ്കിലും വരവ് ചിലവ് കണക്കുകൾ മാറ്റം വരുത്താൻ പറ്റുമെങ്കിൽ കൃത്രിമം കാണിക്കാൻ വളരെ എളുപ്പമാവും. അതുപോലെ മറ്റുള്ളവർക്ക് (പ്രത്യേകിച്ചും വിദ്വേഷക്കാരായ ഹാക്കർമാർക്ക്) തടയില്ലാത്ത രീതിയിൽ വിവരങ്ങൾ കാണാനും കൈകാര്യം ചെയ്യാനും സാധിക്കുമെങ്കിൽ നമ്മുടെ കച്ചവടം പൂട്ടിക്കാനും എളുപ്പമാവും. അപ്പോൾ ഒരു സോഫ്റ്റ്‌വെയർ നിർമിക്കുമ്പോൾ ഇത്തരം വിവര ചോർച്ചകൾ ഉണ്ടാവുന്നില്ല എന്നും ഉറപ്പുവരുത്തേണ്ടതുണ്ട്. അതുപോലെ തന്നെ പ്രാധാന്യമുള്ള മറ്റൊരു വിഷയമാണ് scalability. ഉപയോഗിക്കുന്നവരുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച് പ്രവർത്തനത്തിൽ അധഃപതനം ഉണ്ടാവാതിരിക്കാനുള്ള ക്ഷമതയും സോഫ്റ്റ്‌വെയറിനു വേണം. സൂപ്പർ മാർക്കറ്റ് വിപുലീകരിച്ച് ബില്ലിങ് കൗണ്ടറുകളുടെ എണ്ണം കൂടിയാൽ സോഫ്റ്റ്‌വെയർ മാറ്റി എഴുതേണ്ട ആവശ്യം ഉണ്ടാവരുത്. ഉപയോഗത്തിന്റെ തോത് (scale) അനുസരിച്ച് പ്രവർത്തന സ്വഭാവത്തിൽ വ്യതിയാനം വരാതിരിക്കാനുള്ള സോഫ്റ്റ്‌വെയറിന്റെ കഴിവിനെയാണ് scalability എന്ന് പറയുന്നത്. ഇത്തരം റിക്വയർമെന്റുകൾ എല്ലാം തന്നെ സോഫ്റ്റ്‌വെയർ ഡിസൈനിനെ സ്വാധീനിക്കുന്നു എന്നുള്ളതാണ് ഇതിലെ ശ്രദ്ധേയമായ മറ്റൊരു കാര്യം.

Performance, security, scalability തുടങ്ങിയ റിക്വയർമെന്റുകളെ പൊതുവായി non-functional requirements എന്നാണ് പറയാറുള്ളത്. ഇങ്ങനെ എല്ലാവിധ ആവശ്യങ്ങളും ചിട്ടയായി ക്രമീകരിച്ചിരിക്കുന്ന രേഖയെയാണ് software requirement specification എന്ന് പറയുന്നത്. പണ്ടുകാലങ്ങളിൽ ഇത്തരം രേഖകൾ അച്ചടിച്ച് സൂക്ഷിക്കുക പതിവായിരുന്നു. എന്നാൽ ഇപ്പോൾ എല്ലാം Aha!, Jira മുതലായ സോഫ്റ്റ്‌വെയറുകളിലാണ് സൂക്ഷിക്കാറുള്ളത്.

ഇത്തരത്തിൽ software requirement specification തയ്യാറായിക്കഴിഞ്ഞാൽ അടുത്ത ഘട്ടം അതിനെ ഏത് രീതിയിൽ ഒരു സോഫ്റ്റ്‌വെയർ ആക്കി മാറ്റാം എന്നുള്ളതാണ്. സോഫ്റ്റ്‌വെയർ ഡിസൈൻ എങ്ങിനെ രൂപപ്പെടുത്തുന്നു എന്ന് നമുക്ക് അടുത്ത ലേഖനത്തിൽ വായിക്കാം.

വിവരങ്ങൾ കൂടുതൽ ആഴത്തിൽ അറിയുവാൻ താൽപര്യപ്പെടുന്ന വായനക്കാർക്കായി ഒരു സാമ്പിൾ GitHub പ്രൊജക്റ്റ് ഈ ലേഖന പരമ്പരയുടെ ഭാഗമായി തയ്യാറാക്കിയിട്ടുണ്ട്. ഓരോ ലേഖനത്തിലും പ്രതിപാദിക്കുന്ന കാര്യങ്ങൾ അതാത് ലേഖനത്തിൽ നൽകിയിരിക്കുന്ന ലിങ്കുകൾ വഴി നേരിട്ട് കണ്ടു മനസിലാക്കാം. 100% കൃത്യതയാർന്ന സമ്പൂർണ്ണമായ ഒരു പ്രൊജക്റ്റ് നടത്തിക്കൊണ്ടുപോവാൻ ഉള്ള പ്രായോഗികവും നിയമപരവും ആയ ബുദ്ധിമുട്ടുകൾ കാരണം ഇതിനെ ഒരു ലഘുസൂചകമായി മാത്രം കാണണം എന്ന് അപേക്ഷ. ഈ ലിങ്കിൽ ഈ പ്രോജക്ടിനായുള്ള persona കളും മറ്റു റിക്വയർമെന്റുകളും നിങ്ങൾക്ക് കാണാം.

Requirement analysis നേപ്പറ്റി കൂടുതൽ അറിയുവാൻ ഈ ലിങ്കുകൾ സന്ദർശിക്കുക.