Ano ang Detalye ng Mga Kinakailangan: Kahulugan, Pinakamahusay na Mga Tool at Teknik | Gabay
Ang pagtutukoy ng mga kinakailangan ay isang mahalagang bahagi ng proseso ng Requirements Engineering. Ito ang ikatlong yugto, pagkatapos ng Pagkuha at Pagsusuri ng Mga Kinakailangan. Ang layunin ay lumikha ng isang dokumento, o Detalye ng Mga Kinakailangan, na may kaukulang antas ng detalye. Ang dokumentong ito ay naglalaman ng lahat ng mga kinakailangan na ipapataw sa disenyo at pag-verify ng produkto. Maglalaman din ito ng iba pang nauugnay na impormasyong kinakailangan para sa disenyo, pagpapatunay, at pagpapanatili ng produkto.
Ano ang Pagtukoy sa Mga Kinakailangan?
Ang pagtutukoy ng kinakailangan, na kilala rin bilang dokumentasyon, ay isang proseso ng pagsusulat ng lahat ng mga kinakailangan ng system at user sa anyo ng isang dokumento. Ang mga kinakailangang ito ay dapat na malinaw, kumpleto, komprehensibo, at pare-pareho.
Sa panahon ng aktibidad sa pagkuha, tinitipon namin ang lahat ng mga kinakailangan mula sa iba't ibang mga mapagkukunan. Sa panahon ng pagsusuri at mga aktibidad sa negosasyon, sinusuri at nauunawaan namin ang mga kinakailangang iyon. Ngayon, dapat tayong maghanda ng isang pormal na dokumento na nagpapaliwanag sa mga kinakailangang iyon. Iyon ay kung ano ang pagtutukoy ng kinakailangan. Upang maging tumpak, ito ay ang proseso ng pagdodokumento ng lahat ng mga pangangailangan ng user at system at mga hadlang sa isang malinaw at tumpak na paraan.
Ano ang isang System Requirement?
Ang mga kinakailangan ng system ay maaaring tawaging pinalawak na bersyon ng mga kinakailangan ng gumagamit. Ang mga kinakailangan ng system ay nagsisilbing punto ng pagsisimula para sa anumang bagong disenyo ng system. Ang mga kinakailangang ito ay isang detalyadong paglalarawan ng mga kinakailangan ng user na dapat matugunan ng system.
Ano ang Kinakailangan ng Gumagamit?
Ang pangangailangan ng user ay isang kumbinasyon ng functional at non-functional na mga kinakailangan. Ang mga kinakailangan ng user na ito ay dapat na idinisenyo sa paraang madaling maunawaan ng mga user na walang anumang uri ng teknikal na kaalaman. Samakatuwid, dapat silang isulat sa natural na wika gamit ang mga simpleng talahanayan, anyo, at diagram. Gayundin, siguraduhin na ang dokumento ay walang mga detalye sa disenyo ng system, software, o mga pormal na notasyon.
Ano ang Functional at Non-Functional na Kinakailangan?
Ang mga functional na kinakailangan, gaya ng ipinahihiwatig ng pangalan, ay naglalarawan sa mga function ng system na idinisenyo. Ito ay isang paglalarawan ng kung ano ang magiging system at kung paano ito gagana upang matugunan ang mga pangangailangan ng gumagamit. Nagbibigay ang mga ito ng malinaw na paglalarawan kung paano dapat tumugon ang system sa isang partikular na command, mga feature, at kung ano ang inaasahan ng mga user.
Ipinapaliwanag ng mga di-functional na kinakailangan ang mga limitasyon at mga hadlang ng system na ididisenyo. Ang mga kinakailangang ito ay walang anumang epekto sa functionality ng application. Higit pa rito, mayroong isang karaniwang kasanayan ng sub-classifying ang non-functional na mga kinakailangan sa iba't ibang mga kategorya tulad ng
- User Interface
- kahusayan
- Katiwasayan
- pagganap
- pagpapanatili
- Pamantayan
Ang sub-classifying sa mga non-functional na kinakailangan ay isang magandang kasanayan. Nakakatulong ito kapag gumagawa ng checklist ng mga kinakailangan na dapat matugunan sa system na idinisenyo.
Ang mga di-functional na kinakailangan ay kasinghalaga ng functional na mga kinakailangan. Kung tinukoy ng mga functional na kinakailangan kung ano ang dapat gawin ng isang system, inilalarawan ng mga hindi gumaganang kinakailangan kung paano ito gagawin ng system. Halimbawa, ang bagong application ay magbibigay sa amin ng panghuling listahan ng lahat ng konektadong user. Iyon ay bahagi ng mga kinakailangan sa pagganap. Kung sinasabi ng kinakailangan na ang system ay gagana lamang sa isang Windows at isang Linux system, iyon ay magiging bahagi ng hindi gumaganang mga kinakailangan.
Ang tanging pagkakaiba sa pagitan ng dalawa ay ang sistema ay hindi maaaring gumana nang hindi natutugunan ang lahat ng mga kinakailangan sa pagganap. Sa kabilang banda, ibibigay sa iyo ng system ang ninanais na resulta kahit na hindi nito natutugunan ang mga di-functional na kinakailangan.
Ano ang Mga Benepisyo ng Pagkakaroon ng Detalye ng Mga Kinakailangan?
Maraming benepisyo ang pagkakaroon ng specification ng mga kinakailangan. Ang ilan sa mga ito ay nakalista sa ibaba:
- Tumutulong upang matiyak na ang lahat ng mga stakeholder ay may isang karaniwang pag-unawa sa sistema na bubuuin. Iniiwasan nito ang anumang hindi pagkakaunawaan sa mga susunod na yugto ng pag-unlad.
- Nagsisilbing reference point para sa lahat ng stakeholder sa panahon ng proseso ng development.
- Tumutulong upang matukoy ang anumang mga puwang sa mga kinakailangan sa isang maagang yugto.
- Binabawasan ang kabuuang gastos at oras ng pagpapaunlad dahil iniiwasan nito ang muling paggawa dahil sa mga pagbabago sa mga kinakailangan.
Mga pamantayan para sa mga kinakailangan sa pagsulat?
Ang EARS ay magiging isang epektibong pamamaraan dito. Ito ay kumakatawan sa Easy Approach to Requirements Syntax. Sa pamamaraang ito, nagsusulat kami ng malinaw, maigsi, at naiintindihan na wika. Pinapabuti nito ang buong mga kinakailangan sa engineering workflow at pinapasimple ang trabaho sa pamamagitan ng paggawa ng mga bagay na medyo madaling maunawaan.
Upang makamit ito, narito ang ilang mga prinsipyo na dapat isaisip habang isinusulat ang mga kinakailangan. Kasama nila ang:
- Ang bawat pangangailangan ay dapat na nasa anyo ng isang kumpletong pangungusap. Walang bullet, acronym, abbreviation, o buzzwords ang dapat gamitin. Subukang gumawa ng maikli, direkta, at kumpletong mga pangungusap.
- Siguraduhin na ang bawat pangangailangan ay may wastong simuno, panaguri, at pandiwa. Ang paksa ay ang uri ng gumagamit o ang sistema na pinag-uusapan natin. Ang panaguri ay ang mga kundisyon o aksyon o ninanais na resulta na inaasahan namin. Dapat tayong gumamit ng mga salitang tulad ng 'ay', 'kalooban', at 'dapat' upang ipahayag ang ilang uri ng pangangailangan, at mga salitang tulad ng 'maaaring' upang ipahayag ang opsyonal sa kinakailangan.
- Ang bawat kinakailangan ay dapat na mahusay na ipaliwanag ang huling resulta na gusto namin mula sa system.
- Gayundin, dapat ilarawan ng kinakailangan ang kalidad na inaasahan namin mula sa system. Nakakatulong ito kapag sinusukat natin ang resulta at tingnan kung naipapatupad nang maayos o hindi ang kinakailangan.
Mga Uri ng Mga Detalye ng Kinakailangan:
Mayroong maraming mga uri ng mga pagtutukoy ng kinakailangan. Kasama sa mga ito ang Mga Pagtutukoy ng Kinakailangan sa Pag-andar (FRS), Pagtutukoy ng Kinakailangan sa Pagganap (PRS), Pagtutukoy ng Kinakailangan sa Pag-configure (CRF), Pagtutukoy ng Kinakailangan sa Negosyo (BRS), Pagtutukoy ng Reliability Requirement (RRF), Pagtutukoy ng Kinakailangan sa Pagkatugma (CRF), at Pagtutukoy ng Kinakailangan sa Software (SRS). ).
Mga Detalye ng Kinakailangan sa Paggana: Ang functional requirement specification (FRS) ay isang dokumentong kumukuha ng mga function na dapat gawin ng isang system. Kabilang dito ang lahat ng functionality, lugar, mga hakbang sa seguridad, at iba pang nauugnay na impormasyon. Sa madaling salita, ang FRS ay isang dokumento na naglalaman ng lahat ng dapat gawin ng isang partikular na sistema.
Mga Detalye ng Kinakailangan sa Pagganap: Ang performance requirement specification (PRS) ay isang dokumentong kumukuha ng lahat ng aspetong nauugnay sa performance ng isang system. Kabilang dito ang oras ng pagtugon, throughput ng data, kahusayan, scalability, atbp. Sa pangkalahatan, ang anumang bagay na maaaring ma-quantify at mapahusay ay nasa ilalim ng kategorya ng PRS.
Detalye ng Kinakailangan sa Mga Configuration: Ang configuration requirement specification (CRS) ay isang dokumentong kumukuha ng lahat ng impormasyong nauugnay sa configuration ng isang system. Kabilang dito ang mga detalye gaya ng mga sinusuportahang platform, mga dependency sa software/hardware, mga minimum na kinakailangan sa system, atbp.
Mga Detalye ng Kinakailangan sa Negosyo: Ang business requirement specification (BRS) ay isang dokumentong kumukuha ng lahat ng aspetong nauugnay sa negosyo ng isang system. Kabilang dito ang mga feature gaya ng pamamahala ng user, seguridad, integridad ng data, atbp. Karaniwang, anumang bagay na nakakaapekto sa mga pagpapatakbo ng negosyo ng isang system ay nasa ilalim ng kategoryang BRS.
Mga Detalye ng Reliability Requirements: Ang reliability requirement specification (RRF) ay isang dokumentong kumukuha ng lahat ng impormasyong nauugnay sa pagiging maaasahan ng isang system. Kabilang dito ang mga aspeto tulad ng uptime, oras ng pagbawi, mga rate ng error, atbp.
Mga Detalye ng Kinakailangan sa Pagkatugma: Ang compatibility requirement specification (CRF) ay isang dokumentong kumukuha ng lahat ng impormasyong nauugnay sa compatibility ng isang system. Kabilang dito ang mga aspeto gaya ng mga sinusuportahang platform, mga dependency sa software/hardware, mga minimum na kinakailangan sa system, atbp.
Mga Detalye ng Kinakailangan sa Software: Ang software requirement specification (SRS) ay isang dokumentong kumukuha ng lahat ng aspetong nauugnay sa software ng isang system. Kabilang dito ang mga aspeto tulad ng functionality, performance, scalability, atbp. Karaniwan, ang anumang bagay na nakakaapekto sa mga pagpapatakbo ng software ng isang system ay nasa ilalim ng kategoryang SRS.
Detalye ng Kinakailangan sa Software Kumpara sa Detalye ng Kinakailangan sa Negosyo:
Minsan pinaghahalo ng mga tao ang mga konsepto ng software at mga detalye ng kinakailangan sa negosyo. Actually, magkaiba silang dalawa.
Ang pangunahing pagkakaiba sa pagitan ng pagtutukoy ng kinakailangan ng software at pagtutukoy ng kinakailangan sa negosyo ay nakukuha ng una ang lahat ng impormasyong nauugnay sa software habang kinukuha ng huli ang lahat ng impormasyong nauugnay sa negosyo.
| Detalye ng Mga Kinakailangan sa Negosyo (BRS) | Software Requirements Specification (SRS) |
|---|---|
| Ito ay isang pormal na dokumento na naglalarawan sa iba't ibang mga kinakailangan na ibinigay ng kliyente/mga stakeholder. | Tinutukoy nito ang functional at non-functional na mga kinakailangan na naroroon sa software. |
| Ito ay nagmula sa mga kinakailangan at pakikipag-ugnayan ng kliyente. | Ito ay hango sa Business Requirements Specification (BRS). |
| Ito ay nilikha ng isang analyst ng negosyo. | Ito ay nilikha ng isang system analyst o isang system architect o isang business analyst. |
| Inilalarawan nito ang mga functional na detalye ng software sa napakataas na antas. | Inilalarawan nito ang parehong teknikal at functional na mga detalye ng software din sa isang mataas na antas. |
| Nakikitungo ito sa mga kinakailangan sa negosyo. | Nakikitungo ito sa mga mapagkukunan na ibinibigay ng kumpanya. |
| Tinutukoy nito ang mga pangangailangan ng customer. Ang dokumento ay ginagamit mula sa simula hanggang sa katapusan ng proyekto. | Inilalarawan nito kung paano gumagana ang negosyo kapag ginagamit ang software o application. |
| Hindi kasama ang mga table at use case. | Kasama ang mga table at use case. |
Mga Katangian ng isang Dokumento ng Pagtutukoy ng Mga Kinakailangan sa Software:
- tumpak – Ang layunin ng isang dokumento ng SRS ay maging simple upang maunawaan. Walang dapat na hindi malinaw, kaya walang mga pagtatalo sa pagitan ng mga stakeholder.
- Maaaring sukatin – Ang mga kinakailangan sa iyong SRS na dokumento ay dapat na masusukat, samakatuwid ang tapos na produkto ay maaaring ma-validate at ma-certify laban sa mga kinakailangan.
- Matapos – Ang dokumento ng SRS ay dapat magsama ng sapat na impormasyon para sa iyong development team at mga tester upang makumpleto ang produkto at matiyak na natutugunan nito ang mga kinakailangan ng user nang walang mga bug.
- Magagawa – Ang mga kinakailangan ay dapat sumasalamin sa aktwal na estado ng mga gawain, kabilang ang gastos, timeline, at teknolohiya. Hindi sila dapat nakadepende sa mga pagsulong ng teknolohiya sa hinaharap.
- Nababaluktot – Dahil maaaring magbago ang mga pangyayari sa lugar ng trabaho, ang iyong dokumento sa SRS ay dapat na sapat na naaangkop upang matugunan ang mga pagbabago. Huwag magsama ng labis na materyal sa ilang seksyon na kailangang i-update tuwing may shift.
- Mapapatunayan – Ang bawat isa sa pangkat ng pagbuo ay dapat magkaroon ng access sa dokumento upang maisangguni nila ito nang madalas hangga't kinakailangan. Dahil ang mga kinakailangan ay dapat na malinaw, ang mga miyembro ng koponan ay hindi nais ng karagdagang impormasyon. Dapat silang lahat ay naa-access sa dokumento ng SRS.
- Pare-pareho – Dapat magkatugma ang mga kinakailangan. Dapat ay walang kontradiksyon sa pagitan ng mga bahagi ng iyong dokumentong kinakailangan. Ang dokumento ay dapat na maayos na nakaayos, at ang terminolohiya ay ginagamit sa parehong paraan sa kabuuan.
- Walang Mga Limitasyon sa Pagpapatupad – Sa pangkalahatan, ang isang SRS na dokumento ay dapat sapat na detalyado upang magawa ang trabaho ngunit hindi masyadong tiyak na huminto ito sa pag-unlad. Maraming development ang nakabatay sa mga third-party na serbisyo na walang kontrol sa mga developer.
- tama – Ang mga kinakailangan na tinukoy sa mga dokumento ay dapat na napaka-tumpak upang maiwasan ang anumang uri ng kalituhan. Hindi sila dapat magkaroon ng anumang mga butas, kalabuan, subjectivity, superlatibo, o paghahambing.
Mahahalagang Bahagi ng isang SRS:
Ang mga pangunahing seksyon ng isang detalye ng mga kinakailangan ng software ay:
- Mga Driver ng Negosyo – Ang mga dahilan kung bakit naghahanap ang customer na bumuo ng isang sistema ay inilarawan sa seksyong ito. Kasama pa sa seksyong ito ang mga problemang kinakaharap ng customer sa kasalukuyang system at ang mga pagkakataong ibibigay ng bagong system.
- Model ng Negosyo – Ang modelo ng negosyo na kinakailangang suportahan ng system ay tinalakay sa seksyong ito. Kasama pa rito ang iba't ibang detalye tulad ng konteksto ng organisasyon at negosyo, mga pangunahing function ng negosyo, at mga diagram ng daloy ng proseso ng system.
- Mga Kinakailangan sa Functional at System – Ang seksyong ito ay karaniwang nagdedetalye ng mga kinakailangan na nakaayos sa isang hierarchical na istraktura. Ang mga kinakailangan sa pagganap ay nasa pinakamataas na antas at ang mga detalyadong kinakailangan ng system ay nakalista bilang mga sub-item.
- Mga Kaso ng Paggamit ng System – Binubuo ang seksyong ito ng isang diagram ng kaso ng paggamit ng Unified Modeling Language (UML) na nagpapaliwanag sa lahat ng pangunahing panlabas na entity na makikipag-ugnayan sa system at sa iba't ibang mga kaso ng paggamit na kailangan nilang gawin.
- Mga Kahilingan sa Teknikal – Tinatalakay ng seksyong ito ang lahat ng hindi gumaganang mga kinakailangan na bumubuo sa teknikal na kapaligiran at ang mga teknikal na limitasyon kung saan gagana ang software.
- Mga Katangian ng System – Sa seksyong ito, ang maraming katangian ng system ay tinukoy tulad ng pagiging maaasahan, kakayahang magamit, seguridad, scalability, availability, at maintainability.
- Mga Limitasyon at Pagpapalagay – Inilalarawan ng seksyong ito ang lahat ng limitasyong ipinataw sa disenyo ng system mula sa pananaw ng customer. Ang iba't ibang mga pagpapalagay ng pangkat ng engineering tungkol sa kung ano ang aasahan sa panahon ng pag-unlad ay tinalakay din dito.
- Pamantayan sa Pagtanggap – Ang mga detalye sa lahat ng kundisyon na dapat matugunan bago ibigay ang system sa mga huling customer ay tinatalakay sa seksyong ito.
Istraktura ng isang SRS:
1. Panimula -
Ipinapaliwanag ng panimula ang kahulugan ng SRS sa pangkalahatan, ang saklaw nito para sa iyong koponan, at ang istraktura nito.
1.1. Layunin
Dito, ipaliwanag ang layunin at istraktura ng dokumentasyon ng software ng SRS: ang mga uri ng mga kinakailangan na tutugunan, pati na rin ang mga tauhan na gagamit nito.
Panatilihing maikli ang seksyong ito: sapat na ang 1-2 talata.
1.2. Sinasadyang Madla
Magagawa mong malalim at ipaliwanag kung paano gagana ang mga stakeholder at team sa SRS, pati na rin ang pakikilahok sa pagbuo nito. Ito ay karaniwang mga may-ari ng produkto, mamumuhunan, analyst ng negosyo, developer, minsan tester, at tauhan ng operasyon. Ang buong istraktura ay tinutukoy ng iyong diskarte sa pagbuo ng software at ang setup ng organisasyon ng koponan.
1.3. Naipalabas na Paggamit
Ilarawan kung aling mga sitwasyon ang gagamitin ng iyong koponan sa SRS. Kadalasan, ginagamit ito sa mga sumusunod na kaso:
- pagdidisenyo at brainstorming ng mga bagong feature
- pagpaplano ng tagal ng proyekto, mga sprint, pagtatantya ng mga gastos
- pagsusuri ng mga panganib
- pagsubaybay at pagsukat ng tagumpay ng pangkat
- magkasalungat na sitwasyon kapag ang mga kasangkot na partido ay may iba't ibang pananaw sa isang mahusay na naisakatuparan na produkto.
1.4. Saklaw
Sinasaklaw ng bahaging ito ang saklaw ng produkto, kaya kakailanganin mong magbigay ng mabilis na pangkalahatang-ideya ng system – ang pangunahing layunin, function, at posisyon nito. Maihahambing ito sa kung paano mo ipapaliwanag ang isang produkto sa isang pulong ng stakeholder maliban na ito ay pinahihintulutan na magsaliksik nang mas malalim sa mga teknikal na detalye.
Ang seksyong ito ay kailangang ilarawan:
- Lahat ng uri ng user na inaasahang makikipag-ugnayan sa system
- Lahat ng mahahalagang bahagi ng arkitektura
1.5 Mga Kahulugan at Acronym
Ang mga bahaging nabanggit sa itaas ay bumubuo ng isang kahulugan. Nagbibigay ang mga kahulugan ng impormasyon tungkol sa function, mga pinagbabatayan na teknolohiya, target na personas, mga entidad ng negosyo (mga user, kliyente, middlemen), at mga stakeholder. Maaari kang gumamit ng acronym upang isulat ang iyong SRS nang mas mabilis kung pipiliin mong gawin ito. Mababasa ang dokumento hangga't kasama ito sa talahanayan ng mga kahulugan.
Sa kabuuan ng iyong dokumento, ang koponan ay madalas na gumagamit ng ilang mga salita. Ang pag-aalis ng anumang potensyal na hindi pagkakaunawaan, pagbibigay-daan sa mga bagong developer na mag-onboard, at paglutas ng mga magkasalungat na sitwasyon ay magiging mas madali kung lilinawin mo ang kahulugan ng mga salitang ito.
2. Pangkalahatang Paglalarawan
Sa ikalawang bahagi, inilalarawan mo ang mga pangunahing tampok ng produkto, mga target na user, at saklaw ng system sa mga mambabasa. Ang paglalarawang ito ay tumutuon lamang sa mga pangunahing tampok at arkitektura ng software nang hindi kumukuha ng mga detalye tungkol sa mga add-on at koneksyon.
2.1 Pangangailangan ng Gumagamit
Ang bahaging ito ay isang bagay na mapagpipilian, kaya pinipili ng ilang organisasyon na huwag isama ito sa kanilang dokumentasyon ng SRS engineering. Naniniwala kami na mas mabuting ilista ang mga problemang gusto mong lutasin sa iyong functionality ngayon. Ito ay darating sa madaling gamiting sa ibang pagkakataon habang brainstorming at pagsubaybay function. Maaari kang bumalik sa seksyong ito anumang oras sa panahon ng proseso ng pagbuo ng produkto at tingnan kung ang koponan ng karanasan ng gumagamit ay hindi nalalayo sa nilalayong landas.
Ang mga pangangailangan ay tumutukoy sa mga isyu na magagawang lutasin ng mga user gamit ang system. Maaari mong hatiin ang mga pangangailangang ito sa mga subcategory kung haharapin mo ang isang napaka-segment na audience. Subukang huwag pumunta sa mga detalye tungkol sa mga pangangailangan ng bawat user. Kailangan mong mag-iwan ng ilang puwang para sa interpretasyon, kung sakaling ang isang problema ay lumabas na mas makabuluhan kaysa sa una mong naisip.
2.2 Mga Assumption at Dependencies
Ang mga pagpapalagay ay ang mga pagpapalagay ng koponan tungkol sa produkto at mga kakayahan nito na magiging tama sa 99% ng mga sitwasyon. Natural lang na ipagpalagay, halimbawa, na ang isang platform na tumutulong sa mga driver na mag-navigate sa gabi ay gagamitin sa karamihan sa nighttime mode.
Ano ang kahalagahan ng mga pagpapalagay? Nagbibigay-daan sa iyo ang mga ito na tumutok muna sa pinakamahahalagang feature ng app. Ang pagpapalagay na ito ay tumutulong sa pag-unawa na ang mga taga-disenyo ay dapat bumuo ng isang interface na angkop para sa paningin sa dilim para sa isang katulong sa pagmamaneho sa gabi. Ang ilang mga gumagamit ay maaaring tiyak na buksan ang application sa araw, ngunit ito ay isang mahabang shot, kaya hindi mo kailangang isama ang mga kaugnay na elemento sa prototype kaagad.
3. Mga Tampok at Kinakailangan ng System
Sinasaklaw ng bahaging ito ang mga tampok ng produkto at pamantayan sa pagpapatupad nang detalyado. Dahil tinutugunan ng nakaraang dalawang seksyon ang produkto sa kabuuan, makakahanap ka ng mas kumpletong paglalarawan dito.
3.1 Mga Kinakailangan sa Paggana
Ang mga kinakailangan sa paggana ay nakasaad sa isang listahan ng mga function na isasagawa sa isang system. Ang mga pamantayang ito ay nababahala sa "ano ang malilikha?" sa halip na "paano," at "kailan."
Nagsisimula ang mga kinakailangan sa paggana sa pamamagitan ng paglalarawan sa kinakailangang paggana batay sa kung gaano ito kahalaga sa application. Kung gusto mong magtrabaho muna, maaari kang magsimula sa disenyo, ngunit dapat kang pumunta sa pag-unlad. Ang mga kinakailangan sa paggana ay hindi masyadong detalyado tungkol sa mga stack ng teknolohiya dahil maaaring magbago ang mga ito habang umuusad ang proyekto. Sa halip na tumutok sa panloob na lohika, ang mga kinakailangan sa paggana ay nakatuon sa paggana ng end-user.
3.2 Mga Kinakailangang Panlabas na Interface
Ang mga functional na kinakailangan ay isang mahalagang bahagi ng isang detalye ng mga kinakailangan ng system. Para masakop ang lahat ng kinakailangang feature ng system, kakailanganin mo ng 4-5 na pahina ng impormasyon. Pinaghiwa-hiwalay sila ng ilang mga koponan ayon sa mga tema upang gawing mas madaling basahin ang dokumento.
Karaniwan, tinutukoy ang mga bahagi ng disenyo ng SRS bilang hiwalay sa backend at lohika ng negosyo. Makatuwiran ito dahil ang mga designer sa halip na mga developer ang humahawak sa karamihan ng lugar na ito, ngunit din dahil dito magsisimula ang proseso ng pagbuo ng produkto.
Depende sa proyekto, ang mga kinakailangan sa panlabas na interface ay maaaring binubuo ng apat na uri:
- Interface ng gumagamit
- Interface ng software
- Interface ng Hardware
- Interface Communication
Inilalarawan ng mga kinakailangan sa panlabas na interface ang mga elemento ng page na makikita ng end client. Maaari nilang isama ang listahan ng mga page, mga elemento ng disenyo, mga pangunahing tema ng istilo, kahit na mga artistikong elemento, at higit pa kung mahalaga ang mga ito sa produkto.
3.3 Mga Kinakailangan sa System
Ang mga kinakailangan sa system ng produkto ay nagsasaad ng mga kondisyon kung saan ito maaaring gamitin. Karaniwang nauugnay ang mga ito sa mga detalye at tampok ng hardware. Ang mga kinakailangan sa hardware ng SRS ay kadalasang tinutukoy ng minimal at pinakamaraming hanay, pati na rin ang pinakamainam na limitasyon ng pagganap ng produkto.
Ang paggawa ng mga kinakailangan sa system bago magsimulang lumikha ng isang produkto ay maaaring mukhang mahirap, ngunit ito ay mahalaga. Dapat sumunod ang mga developer sa mga kinakailangan sa hardware upang hindi na nila kailangang i-restart ang proyekto sa ibang pagkakataon. Ang mga mobile app (na may maraming variable na dapat isaalang-alang) at mga application na nangangailangan ng mataas na reaktibidad (mga laro, anumang produkto na may VR/AR, o IoT) ay partikular na mahina.
3.4 Mga Non-Functional na Kinakailangan
Para sa maraming organisasyon, ang bahaging ito ng isang SRS ang pinakamahirap. Kung tinutugunan ng mga kinakailangan sa pagganap ang tanong kung ano ang gagawin, tinutukoy ng mga pamantayang hindi gumagana kung paano. Itinatag nila ang mga pamantayan ayon sa kung gaano kaepektibo ang sistema ay dapat gumana. Ang mga limitasyon para sa pagganap, seguridad, at kakayahang magamit ay lahat ay kasama sa lugar na ito.
Ang tunay na halaga ay kung bakit mahirap tukuyin ang hindi gumaganang mga kinakailangan. Ang pagtukoy sa mga pariralang tulad ng "concurrency" o "portability" ay mahirap dahil maaaring may iba't ibang interpretasyon ang mga ito para sa lahat ng partidong kasangkot. Bilang resulta, itinataguyod namin ang pagbibigay ng puntos sa bawat hindi gumaganang kinakailangan. Maaari mong bisitahin muli ang iyong mga kinakailangan sa proyekto anumang oras upang makita kung ang kasalukuyang sistema ay nakakatugon sa mga paunang inaasahan.
Mga Kinakailangan sa Visure ALM Platform:
Ang Visure ay isa sa mga pinagkakatiwalaang platform ng pamamahala ng lifecycle ng application na nagdadalubhasa sa pamamahala ng mga kinakailangan para sa mga organisasyon sa lahat ng laki sa buong mundo. Kabilang sa mga pangunahing kasosyo ng Visure ang mga kumpanyang kritikal sa negosyo at kritikal sa kaligtasan. Sumasama ang kumpanya sa buong proseso ng Pamamahala ng Lifecycle ng Application kabilang ang pamamahala sa peligro, pagsubaybay sa isyu at depekto, pamamahala sa traceability, pamamahala sa pagbabago, at iba't ibang bahagi tulad ng pagsusuri sa kalidad, pag-bersyon ng mga kinakailangan, at mahusay na pag-uulat.
Kung naghahanap ka ng tool sa pamamahala ng mga kinakailangan na tutulong sa iyo sa parehong mga kinakailangan sa functional at non-functional, tingnan ang Mga Kinakailangan sa Visure. Sa platform na ito, madali kang makakagawa, makakapamahala at masusubaybayan ang lahat ng mga kinakailangan ng iyong proyekto sa isang lugar.
Paghihinuha:
Ang detalye ng mga kinakailangan ay isang dokumento na nagbabalangkas sa mga partikular na pangangailangan ng isang proyekto o sistema. Ang mga detalye ng mga kinakailangan ay mahalaga dahil ito ay nagsisilbing pundasyon para sa lahat ng hinaharap na gawain sa proyekto. Ang software requirements specification (SRS) ay iba kaysa sa business requirements specification (BRS), bagama't magkaugnay ang mga ito. Nakatuon ang SRS sa kung ano ang dapat gawin ng system, habang ang BRS ay nakatuon sa kung bakit kailangan ang system at kung paano ito gagamitin. Maaaring mag-iba ang istruktura ng isang dokumento ng mga kinakailangan sa software, ngunit dapat palaging may kasamang mga seksyon sa layunin, saklaw, function, feature, hadlang, pagpapalagay, at dependencies. Mga Kinakailangan sa Visure Ang ALM Platform ay tumutulong sa iyo na lumikha at pamahalaan ang iyong SRS nang madali. Humiling ng libreng 30-araw na pagsubok sa Visure Requirements ALM Platform upang makita kung paano makakatulong ang aming tool sa iyong mga proyekto na tumakbo nang mas maayos.
