Mga Solusyon sa Paningin


Suporta
Magrehistro
Mag-login
Simulan ang Libreng Pagsubok

Pagpapatibay ng EARS Notation para sa Requirements Engineering

Pagpapatibay ng EARS Notation para sa Requirements Engineering

Talaan ng nilalaman

pagpapakilala

Ang engineering ng mga kinakailangan ay isang kritikal na yugto sa pagbuo ng software na naglalagay ng pundasyon para sa buong proyekto. Ang tumpak at mahusay na tinukoy na mga kinakailangan ay mahalaga para sa paghahatid ng isang matagumpay na produkto ng software na nakakatugon sa mga pangangailangan ng mga gumagamit nito. Upang makamit ito, ang mga propesyonal sa software ay madalas na bumaling sa iba't ibang mga pamamaraan at mga notasyon, at ang isa sa gayong notasyon na nagiging popular ay ang EARS (Easy Approach to Requirements Syntax) notation. Sa artikulong ito, i-explore natin ang EARS notation, ang mga benepisyo nito, at kung bakit ang pag-adopt nito ay maaaring mapahusay ang mga kinakailangan sa proseso ng engineering.

Pag-unawa sa EARS Notation

Ano ang EARS?

Ang EARS, na nangangahulugang Easy Approach to Requirements Syntax, ay isang notasyon na idinisenyo upang mapadali ang pagkuha at dokumentasyon ng mga kinakailangan sa isang malinaw at maigsi na paraan. Binuo ito ng mga mananaliksik bilang tugon sa pagiging kumplikado at kalabuan na kadalasang nauugnay sa mga tradisyonal na pamamaraan ng dokumentasyon ng mga kinakailangan. Pinapasimple ng EARS ang proseso ng engineering ng mga kinakailangan sa pamamagitan ng pagbibigay ng structured na paraan upang ipahayag ang mga kinakailangan gamit ang natural na wika.

Pangunahing Elemento ng EARS

Ang notasyon ng EARS ay binubuo ng ilang mahahalagang elemento, na ginagawa itong isang maraming nalalaman at epektibong tool para sa mga kinakailangan sa engineering:

  • Mga Layunin: Sa kaibuturan ng EARS ay ang mga layunin, na kumakatawan sa mga layunin sa mataas na antas na dapat makamit ng software system. Ang mga layunin ay ipinahayag gamit ang natural na wika at nagsisilbing panimulang punto para sa pagtukoy ng mga kinakailangan.
  • Mga Softgoal: Ang mga softgoal ay hindi gumaganang mga kinakailangan o mga katangian ng kalidad na mahalaga para sa tagumpay ng proyekto ngunit maaaring hindi madaling masusukat. Kasama sa mga halimbawa ang usability, maintainability, at scalability.
  • Mga Gawain: Ang mga gawain ay kumakatawan sa mga tiyak na aksyon o aktibidad na kailangang isagawa upang makamit ang isang layunin. Ang mga ito ay madalas na inilalarawan sa isang verb-object na format, na ginagawang madaling maunawaan ang mga ito.
  • Operand: Ang mga operand ay ginagamit upang magbigay ng karagdagang impormasyon at mga hadlang na may kaugnayan sa mga gawain. Tumutulong ang mga ito na linawin kung paano dapat gawin ang isang gawain o sa ilalim ng anong mga kondisyon.
  • Domain Assumptions: Hinihikayat ng EARS ang dokumentasyon ng mga pagpapalagay tungkol sa domain kung saan gagana ang software. Ang mga pagpapalagay na ito ay nagbibigay ng konteksto at tumutulong na matiyak na ang mga kinakailangan ay naaayon sa mga totoong sitwasyon.

Mga Benepisyo ng Pag-ampon ng EARS Notation

Pinahusay na Kalinawan at Katumpakan

Ang isa sa mga pangunahing bentahe ng paggamit ng EARS notation ay ang pinahusay na kalinawan at katumpakan na dulot nito sa dokumentasyon ng mga kinakailangan. Sa pamamagitan ng pagbubuo ng mga kinakailangan bilang mga layunin, gawain, at softgoal, ginagawang mas madali ng EARS para sa mga stakeholder na maunawaan kung ano ang inaasahan mula sa software system. Binabawasan ng kalinawan na ito ang kalabuan at maling interpretasyon, na humahantong sa mas tumpak na mga kinakailangan.

Likas na Pagpapahayag ng Wika

Ginagamit ng EARS ang natural na wika, na ginagawa itong naa-access sa malawak na hanay ng mga stakeholder, kabilang ang mga hindi teknikal na miyembro ng team. Tinitiyak ng inclusivity na ito na ang lahat ng kasangkot sa proyekto ay makakapag-ambag at makakaunawa sa mga kinakailangan, sa pagpapaunlad ng pakikipagtulungan at isang nakabahaging pananaw.

Kakayahang umangkop at Kakayahan

Ang EARS ay isang flexible na notation na maaaring iayon upang umangkop sa mga partikular na pangangailangan ng isang proyekto. Gumagawa ka man ng isang sistemang kritikal sa kaligtasan o isang application na nakasentro sa gumagamit, maaaring tanggapin ng EARS ang iba't ibang uri ng mga kinakailangan. Ang kakayahang umangkop na ito ay ginagawa itong isang mahalagang tool para sa magkakaibang konteksto ng pagbuo ng software.

Traceability at Pamamahala ng Pagbabago

Ang kakayahang masubaybayan ay isang mahalagang aspeto ng mga kinakailangan sa engineering, na tinitiyak na ang bawat pangangailangan ay naka-link sa pinagmulan nito at maaaring masubaybayan sa buong development lifecycle. Ang EARS notation ay nagbibigay ng isang malinaw na istraktura para sa traceability, na ginagawang mas madaling pamahalaan ang mga pagbabago at masuri ang epekto ng mga pagbabago sa iba pang mga kinakailangan.

Pag-align sa Pinakamahuhusay na Kasanayan

Ang notasyon ng EARS ay umaayon sa pinakamahuhusay na kagawian sa engineering ng mga kinakailangan. Hinihikayat nito ang paghihiwalay ng mga kinakailangan sa functional at non-functional, itinataguyod ang paggamit ng malinaw na wika, at binibigyang-diin ang kahalagahan ng pagkuha ng mga pagpapalagay ng domain - na lahat ay nakakatulong sa mas matagumpay na mga proyekto ng software.

Ano ang INCOSE?

Ang INCOSE, o ang International Council on Systems Engineering, ay isang international not-for-profit membership organization na nagbibigay ng mga pamantayan at alituntunin upang matulungan ang mga organisasyon na lumikha ng mas mahusay na mga proseso ng system engineering. Ang INCOSE System Requirements Standard (SRS) ay naglalaman ng isang hanay ng mga panuntunan at pamantayan na idinisenyo upang tulungan ang mga organisasyon na suriin ang mga pahayag ng mga kinakailangan bago ito ipatupad. Ang SRS ay pinagtibay ng ilang malalaking korporasyon gayundin ng mga ahensya ng gobyerno sa buong mundo at maaaring magamit sa maraming iba't ibang industriya para sa iba't ibang aplikasyon. Mahalaga para sa mga stakeholder gaya ng mga software developer, business analyst, project manager, tester, IT department personnel, at iba pang miyembro ng team na magkaroon ng matibay na pag-unawa sa mga kinakailangang ito bago magsimulang magtrabaho sa anumang statement o proyekto ng kinakailangan ng system.

Sa huli, ang pagsulat ng magagandang kinakailangan ay nagsasangkot ng maingat na balanse sa pagitan ng pagiging detalyado at maigsi, pati na rin ang pagtiyak na ang kinakailangan ay masusubok at magagawa. Ang INCOSE SRS ay nag-aalok ng mga prinsipyo at mga alituntunin upang ang mga koponan ay makapagsulat ng magandang kalidad na mga kinakailangan at makatulong na matiyak na ang kanilang mga proyekto ay matagumpay. Makakatulong ito upang maiwasan ang mga magastos na error sa panahon ng pag-develop o pagkatapos ng pag-deploy, sa gayon ay tinutulungan ang mga organisasyon na lumikha ng mas mahusay na mga system sa mas maikling panahon.

Ano ang INCOSE Rules?

Ang mga Pahayag ng Kinakailangan ay sinusuri sa pamamagitan ng mga tuntunin ng INCOSE. Ang mga pamantayang ito ay tumutulong sa mga organisasyon na masuri ang pagiging posible at kalidad ng mga kinakailangan bago sila ipatupad. Kasama sa proseso ng pagsusuri ang apat na pangunahing pamantayan:

  • Malinaw - Ang nakasulat na mga kinakailangan ay dapat na malinaw, madaling basahin, at naiintindihan. Malinaw na tukuyin ang impormasyon gamit ang mga apirmatibong pangungusap na ipapalit sa pagitan ng mga aktor. Ang bawat pangangailangan ay dapat maglarawan ng malinaw na pamantayan sa tagumpay. Subukang gumamit ng simpleng bokabularyo at iwasan ang mga pagdadaglat. Halimbawa, "Makikita ng user ang Audit Log Report."
  • Atomic - Ang bawat pangangailangan ay dapat ituring bilang isang discrete test case. Ang mga pang-ugnay tulad ng at, o, at iba pa ay hindi dapat gamitin dahil maaari silang humantong sa pagkawala ng mga kinakailangan. Ito ay partikular na mahalaga dahil ang mga tuntuning tulad nito ay maaaring maging sanhi ng mga developer ng software at mga tagasubok na makaligtaan ang mga kinakailangan. Ang paghahati sa mga kumplikadong pangangailangan sa mas maliliit na bahagi hanggang sa masuri ang bawat isa nang hiwalay ay isang paraan upang maiwasang mangyari ito.
  • Hindi malabo – Ang hindi malinaw, hindi kumpleto, o magkasalungat na mga kinakailangan ay maaaring humantong sa mga pagkakamali at muling paggawa. Upang maiwasang mangyari ito, dapat na suriin ng bawat stakeholder ang mga kinakailangan bago ito ma-finalize. Makakatulong ito na matukoy ang anumang mga puwang nang maaga na maaaring matugunan.
  • Nabe-verify – Ang bawat isa sa development team ay dapat magkaroon ng access sa dokumento para ma-reference 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.
  • Kailangan – Ang bawat kinakailangan ay dapat magdokumento ng isang bagay na talagang kailangan ng mga user o isang bagay na kinakailangan upang matupad ang isang pamantayan o pangangailangan sa pagsasama dahil sa pagkakaroon ng panlabas na interface. Gayundin, mahalaga para sa bawat pangangailangan na magkaroon ng awtorisadong pinagmulan.
  • Independiyenteng Disenyo - Dapat tukuyin ng bawat kinakailangan kung ano ang kinakailangan, hindi kung paano ito ipapatupad. Dapat tukuyin ng mga kinakailangan ang mga katangian ng system na oobserbahan sa labas, hindi ang mga panloob na detalye.
  • Magagawa - Ang bawat kinakailangan ay dapat na teknikal na maipapatupad at dapat na ipatupad na isinasaalang-alang ang badyet, deadline, at iba pang mga paghihigpit na nakakaapekto sa proyekto. Dapat ipakita ng mga kinakailangan ang aktwal na kalagayan, kabilang ang gastos, timeline, at teknolohiya. Hindi sila dapat nakadepende sa mga pagsulong ng teknolohiya sa hinaharap.
  • Kumpleto – Ang dokumento ng mga kinakailangan 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.
  • Tama - Ang mga kinakailangan na tinukoy sa mga dokumento ay dapat na napaka-tumpak upang maiwasan ang anumang uri ng pagkalito. Hindi sila dapat magkaroon ng anumang mga butas, kalabuan, subjectivity, superlatibo, o paghahambing. Samakatuwid, Upang makapagsulat ng tamang mga kinakailangan, dapat tayong kumuha ng tamang impormasyon at wastong idokumento ang impormasyong nakalap.

Pag-ampon ng EARS sa Proseso ng Inhinyero ng Iyong Mga Kinakailangan

Para epektibong gamitin ang EARS notation sa iyong mga kinakailangan sa proseso ng engineering, isaalang-alang ang mga sumusunod na hakbang:

  • Pagsasanay at Pag-familiarization: Tiyaking pamilyar ang iyong koponan sa notasyon ng EARS. Magbigay ng pagsasanay at mga mapagkukunan upang matulungan silang maunawaan ang mga pangunahing elemento at prinsipyo.
  • Mga Template at Tool: Gumamit ng mga template at software tool na sumusuporta sa EARS notation. Maaaring i-streamline ng mga tool na ito ang proseso ng dokumentasyon ng mga kinakailangan at mapadali ang pakikipagtulungan sa mga miyembro ng team.
  • Mga Alituntunin at Pamantayan: Magtatag ng mga alituntunin at pamantayan para sa paggamit ng EARS sa loob ng iyong organisasyon. Tukuyin ang mga convention sa pagbibigay ng pangalan, istraktura ng dokumento, at pinakamahusay na kagawian upang mapanatili ang pagkakapare-pareho.
  • Pakikipagtulungan: Hikayatin ang pakikipagtulungan sa mga stakeholder, kabilang ang mga end-user, business analyst, at developer. Ang natural na diskarte sa wika ng EARS notation ay nagpapaunlad ng mas mahusay na komunikasyon at nakabahaging pag-unawa.
  • Pagsusuri at Pagpapatunay: Magpatupad ng proseso ng pagsusuri at pagpapatunay upang matiyak na ang mga kinakailangan na nakuha gamit ang EARS ay kumpleto, pare-pareho, at naaayon sa mga layunin ng proyekto.

Konklusyon

Ang pag-adopt ng EARS notation para sa mga kinakailangan sa engineering ay nag-aalok ng maraming benepisyo, kabilang ang pinahusay na kalinawan, natural na pagpapahayag ng wika, flexibility, traceability, at pagkakahanay sa pinakamahuhusay na kagawian. Sa pamamagitan ng pagtanggap sa EARS, mapapahusay ng mga software development team ang kanilang proseso ng dokumentasyon ng mga kinakailangan at mapataas ang posibilidad na makapaghatid ng mga matagumpay na proyekto ng software na nakakatugon sa mga pangangailangan at inaasahan ng user. Kung ikaw ay isang batikang engineer ng mga kinakailangan o bago sa larangan, ang pagsasaalang-alang sa EARS bilang isang opsyon sa notasyon ay isang hakbang patungo sa mas epektibo at mahusay na mga kinakailangan sa engineering.

Huwag kalimutang ibahagi ang post na ito!

tuktok

Pag-streamline ng mga Pangangailangan sa Pamamahala at Pagpapatunay

Hulyo 16th, 2024

10 am EST | 4 pm CET | 7 am PST

Louis Arduin

Louis Arduin

Senior Consultant, Visure Solutions

Thomas Dirsch

Senior Software Quality Consultant, Razorcat Development GmbH

Isang Pinagsanib na Diskarte sa Visure Solutions at Razorcat Development TESSY

Matutunan kung paano i-streamline ang pamamahala ng mga kinakailangan at pagpapatunay para sa pinakamahusay na mga resulta.