Mga Solusyon sa Paningin


Suporta
Magrehistro
Mag-login
Simulan ang Libreng Pagsubok

Ang Mga Dapat at Hindi dapat gawin para sa Mga Kinakailangan sa Pagsulat

Ang Mga Dapat at Hindi dapat gawin para sa Mga Kinakailangan sa Pagsulat

Talaan ng nilalaman

Kung ikaw ay tulad ng karamihan sa mga tao, malamang na hindi ka nasisiyahan sa pagsusulat ng mga kinakailangan. Hindi ito ang pinakakapana-panabik na bagay sa mundo, ngunit ito ay isang kritikal na bahagi ng pagbuo ng produkto. Ang isang mas mahusay na dokumento ng mga kinakailangan ay makakapagtipid sa iyong organisasyon ng malaking halaga na may malinaw na komunikasyon sa pagitan ng developer at mga stakeholder ng produkto. Ito, sa turn, ay sumasalamin sa buong organisasyon, kabilang ang higit na transparency, mas kaunting rework, at pinahusay na produktibo.

Habang ang bawat organisasyon ay may iba't ibang mga kinakailangan at pamamaraan, ang mga batayan para sa mga kinakailangan sa pagsulat ay nananatiling pareho. Sa artikulong ito, magbabahagi kami ng ilang tip na makakatulong sa iyo na mapahusay ang iyong mga kinakailangan sa pagsusulat ng mga kasanayan at tulungan kang magsulat ng malinaw at malulutong na Mga Detalye ng Kinakailangan.

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 ibig sabihin ng "Mga Pinakamahusay na Kasanayan" sa Pamamahala ng Mga Kinakailangan?

Ito ay kawili-wili sa akin na ang lahat ay nagsasalita tungkol sa pagnanais ng pagsasanay sa "pinakamahusay na kasanayan". Ang terminong ito ay kadalasang ginagamit upang ilarawan ang uri ng pagkonsulta na maaari rin naming ibigay. Ano ba talaga ang ibig sabihin nito? Naniniwala ako na lahat tayo ay nasanay sa alamat na ang pinakamahuhusay na kagawian ay maaaring maging batayan para sa pagsasanay ng mga indibidwal. Ang mga pinakamahusay na kasanayan ay hindi sinanay, sila ay nakaranas.

Kung ihahambing natin ang pinakamahusay na diskarte sa kasanayan sa kalikasan, alam natin na hindi lamang ito ang pinakamalakas kundi ang pinaka-prolific species na nabubuhay. Iyan ang isa sa mga dahilan kung bakit napakahirap baguhin ang mga proseso sa isang organisasyon. Pag-isipan iyon sandali. Ang pinakamalakas at pinaka-prolific ay malamang na naglalarawan sa karamihan ng mga indibidwal na mayroon ka sa halos anumang grupo sa iyong organisasyon. Paulit-ulit ko itong nakita sa larangan ng System Engineering. Ang pinakamalakas at pinaka-prolific na mga inhinyero ay madalas na ginagawa ang kanilang trabaho sa loob ng maraming taon at may partikular na paraan kung paano nila ginagawa ang trabahong ito. Ang pagtatanong sa kanila na sumubok ng mga bagong pamamaraan at kasangkapan ay kadalasang walang saysay, dahil hindi nila alam kung paano nito mapapabuti ang kahanga-hangang trabaho na kanilang ginagawa. Ang kanilang pagsasanay ay magpapatuloy kung patuloy tayong magsusulong ng isang diskarte sa pinakamahusay na kasanayan sa kanila.

Mga Hamon sa Pagsusulat ng Mga Kinakailangan

Mayroong iba't ibang mga hamon na kinakaharap ng mga tao kapag nagsusulat ng mga kinakailangan.

Kawawang Papel – Sa ilang mga organisasyon, ang dokumentasyon ng mga proseso ay alinman sa wala o hindi hanggang sa par. Sa kasong ito, ang pagkolekta ng mga kinakailangan ay nagiging isang dalawang-hakbang na proseso: unang i-reverse engineering ang kasalukuyang proseso, at pagkatapos ay pagtukoy sa mga lugar na nangangailangan ng pagpapabuti at pag-optimize. Upang kumpirmahin na ang mga kinakailangan ay fleshed out at tumpak, ito ay susi upang matukoy ang mga pangunahing stakeholder at mga eksperto sa paksa, direktang nakikipag-ugnayan sa kanila. Ang pagguhit ng mga mapa ng proseso ng negosyo at pagpapakita ng mga daloy ng trabaho ay dalawang mahusay na paraan upang gawin ito. Nakakatulong ito sa pag-aalis ng mga maling pagpapalagay habang nagbibigay din ng kumpletong larawan. Ang pagguhit ng mga mapa ng proseso at pagpapakita ng mga proseso ay dalawang kapaki-pakinabang na diskarte para sa layuning ito.

Mga Salungat na Kinakailangan – Kapag ang mga stakeholder ay may iba't ibang priyoridad para sa kanilang mga layunin sa negosyo, humahantong ito sa mga kinakailangan na sumasalungat sa isa't isa. Sa mga ganitong kaso, ang responsibilidad ng isang business analyst ay idokumento ang lahat ng mga kinakailangan nang detalyado, tukuyin kung aling mga kahilingan ang sumasalungat sa isa't isa, at bigyang-daan ang mga stakeholder ng pagkakataon na magpasya kung ano ang uunahin.

Hindi ka makakagawa ng mga desisyon nang hindi naririnig ang input ng mga stakeholder, at bilang isang business analyst, maaari kang magkaroon ng ilang ideya tungkol sa kung ano ang dapat unahin. Mahalaga pa rin na marinig ang pananaw ng mga stakeholder. Ang pagse-set up ng poll ay maaaring isa sa mga paraan upang makakuha ng kalinawan sa kung ano ang pinakamahalaga sa karamihan ng mga stakeholder.

Unavailability ng User Input – Maaaring mag-ambag ang ilang dahilan sa hindi pagiging available ng mga end user, at bawat isa ay nangangailangan ng sarili nitong resolusyon. Halimbawa, kung minsan ang mga end user ay sobrang abala sa kanilang pang-araw-araw na gawain na hindi nila gustong makibahagi sa mga aktibidad sa pangangalap ng mga kinakailangan.

Sa ganitong mga kaso, ang pinakamahusay na magagawa ng isang business analyst ay limitahan ang bilang at haba ng mga pakikipag-ugnayan. Bago ang pulong, ang paggawa ng maraming pananaliksik hangga't maaari ay makakatulong upang gawing mas organisado at nagbibigay-kaalaman ang talakayan. Ito ay halos tulad ng paggawa ng pangangalap ng mga kinakailangan sa mga sesyon ng pagpapatunay ng mga kinakailangan. pagtukoy sa mga focus group at pagtukoy sa mga pinakaangkop na end-user para sa bawat grupo

Pagtuon sa Interface Sa halip na Karanasan – Maraming stakeholder at end-user ang may malinaw na pananaw kung paano dapat lumabas ang bagong solusyon, ngunit hindi nila alam kung ano ang dapat nitong gawin. Ang user interface ng anumang system ay mahalaga, ngunit hindi ito dapat tukuyin o makagambala sa functionality.

Dapat laging tandaan ng mga business analyst na panatilihing hiwalay ang disenyo at functional na mga kinakailangan sa kanilang dokumentasyon. Sa pamamagitan ng paggamit ng mas pangkalahatang mga tool gaya ng mga diagram, kwento ng user, o low-fi na prototype sa halip na mga draft ng disenyo, maaari nilang mapanatili ang pagtuon sa mga functional na aspeto ng pangangalap ng kinakailangan.

Mga Input ng Stakeholder – Kapag sinubukan ng mga stakeholder o end-user na sabihin sa mga designer kung paano dapat gumana ang system sa halip na kung ano ang dapat gawin ng system, maaari itong humantong sa mga suboptimal na disenyo. Upang maiwasan ito, patunayan ang bawat potensyal na 'maling kinakailangan' sa pamamagitan ng pagtatanong ng 'bakit?' hanggang sa makarating ka sa tunay na problema na kailangang lutasin.

Isyu sa Komunikasyon – Kabilang sa mga isyu na maaaring humantong sa miscommunication sa pagitan ng isang business analyst at iba pang mga partido ay ang mga hadlang sa wika, mga maling pagpapalagay, hindi sapat na ipinaliwanag na bokabularyo, at labis na paggamit ng mga teknikal na termino.

Ang perpektong diskarte upang maiwasan ang problemang ito ay ang madalas na pakikipag-ugnayan at bumuo ng dalawang-daan na pag-uusap. Idokumento ang mga pangangailangan na iyong natuklasan at isumite ang mga ito para sa peer review at pagpuna sa iba't ibang mga espesyalista sa paksa, lumikha ng isang glossary ng jargon at double-check na lugar.

10 Mga Dapat Gawin at Hindi Dapat Sa Pagsusulat ng Mga Kinakailangan:

Gawin ang #1. Paisa-isa – Ang bawat kinakailangan 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.

Huwag #1. Pag-usapan ang "Ano" Hindi "Paano" – Ang focus ay dapat sa kung ano ang gagawin ng system, hindi kung paano ito ginagawa. Bukod pa rito, iwasang masyadong malalim ang pagsasaliksik sa mga paksa ng disenyo gaya ng mga pangalan ng field, programming language object, at software object. Kung nakita mo ang iyong sarili na tinatalakay ang mga paksang ito sa Dokumento ng Pagtutukoy ng Mga Kinakailangan, bumalik sa isang hakbang – malamang na nangangahulugan ito na nagiging masyadong partikular ka.

Gawin ang #2. Traceability – Ang kakayahang masubaybayan sa pamamahala ng proyekto ay tumutukoy sa pagtiyak na ang mga kinakailangan ay nakaugnay sa iba pang mga bahagi sa proyekto. Nagbibigay-daan ito sa mga project manager, developer, at stakeholder na subaybayan ang buong lifecycle ng isang kinakailangan mula simula hanggang katapusan sa lahat ng direksyon pati na rin sa iba pang bahagi ng system. Kung maayos mong pinamamahalaan ang traceability, maiiwasan mo ang code na hindi tumutugma sa anumang kinakailangan ('stray' code), at matiyak na ang bawat test case ay sumasaklaw ng kahit isang kinakailangan. Magagawa mong masubaybayan ang mga kinakailangan sa pamamagitan ng pag-label sa kanila ng isang natatanging identifier at pagbibigay ng impormasyon tungkol sa kanilang pinagmulan sa isang sentral na repository na maa-access ng lahat ng miyembro ng team.

Huwag #2. Walang Mga Pagbubukod – Ang isang kinakailangan ay hindi dapat magkaroon ng escape clause. Halimbawa, "Dapat matukoy ng system ang bilang ng mga pagtatangka sa pag-log in, maliban kung malinaw na naipasok ng user ang isang maling username".

Gawin ang #3. Magagawa – Tiyakin na ang badyet at timeline ng proyekto ay magagawa, kasama ang mga magagamit na mapagkukunan. Kung masusuportahan ng kundisyong ito ang kinakailangan, posible na magpatuloy sa plano.

Huwag #3. Say No sa "let-out" Clauses – Subukang lumayo sa mga salitang binibitawan tulad ng ngunit, maliban, at kung kinakailangan lamang.

Gawin ang #4. Hindi pagbabago – Panatilihin ang pare-parehong antas ng detalye. Halimbawa, para sa mga kinakailangan ng user, isang end-user ang dapat maging paksa ng bawat pangungusap. Katulad nito, para sa mga kinakailangan ng system, isang sistema ang dapat na paksa ng bawat pangungusap.

Huwag #4. Walang mga pagdadaglat – Ang bawat pangangailangan ay dapat na isang buong pangungusap na walang anumang acronym o jargon.

Gawin ang #5. Aktibong Boses – Palaging sumulat sa isang aktibong boses, siguraduhing isa sa mga aktor ang paksa ng bawat pangungusap.

Huwag #5. Huwag Maging Malabo – Huwag gumamit ng Ambiguousterms tulad ng tantiya, atbp., at higit pang mga terminong katulad niyan sa dokumento ng mga kinakailangan. Siguraduhing ipaliwanag ang mga kinakailangan sa paraang naiintindihan ng lahat ng kasangkot ang mga ito nang tama. Ang mga hindi malinaw na pahayag ay maaaring humantong sa mga maling interpretasyon at maaaring magdulot ng mga salungatan sa pagitan ng iba't ibang stakeholder.

Gawin ang #6. Paksa at panaguri – Para sa bawat pangangailangan, dapat mayroong isang paksa (user/system) at isang panaguri (inilaan na resulta, aksyon, o kundisyon).

Huwag #6. Ang mga haka-haka ay maaaring magdulot ng pinsala - Huwag hulaan; huwag gumawa ng mga listahan ng mga feature na wala sa tanong. Ang pagsasabi na gusto mo ng isang system na pangasiwaan ang lahat ng hindi inaasahang kabiguan ay purong pantasya dahil walang sistema ang magiging 100 porsiyento kung ano ang gusto mo. Iwasan ang pagdoble at magkasalungat na mga pahayag.

Gawin ang #7. Mapapatunayan – Ang isa pang bagay na dapat tandaan kapag nag-oorganisa ng mga kinakailangan ay dapat silang palaging masusubok. Nangangahulugan ito na kailangang posible na i-verify na natutugunan ng system ang kinakailangan na pinag-uusapan. Ito rin ay nagli-link sa aming susunod na punto - ang kakayahang masubaybayan. Kung ang isang kinakailangan ay puno ng hindi malinaw na mga termino, magiging mas mahirap na pag-aralan at i-verify kung talagang natutugunan ng system ang mga pamantayang ito sa Performance-wise. Samakatuwid, hangga't maaari, maghangad ng kalinawan at katumpakan sa iyong wika upang ang pagtitipon ng Mga Kinakailangan ay hindi isang hindi malinaw na proseso.

Huwag #7. Iwasan ang mga Opsyon – Huwag mag-alok ng mga ideya o opsyon. Maaari mong makita ang mga ito sa anumang pahayag na kinabibilangan ng mga pariralang maaaring, maaaring, maaari, o nararapat.

Gawin ang #8. Tamang – Tiyaking kumpleto ang bawat pangungusap at wasto ang gramatika na may wastong paksa, pandiwa, at panaguri.

Huwag #8. Huwag Mag-usap sa Hinaharap na Panahon – Huwag sumangguni sa isang pa-tutukoy na pangangailangan. Ang iyong layunin ay gawing kaaya-ayang basahin ang dokumento hangga't maaari.

Gawin ang #9. Pokus – Magtatag ng pokus sa pamamagitan ng pag-aalis ng mga rambling, overlong mga parirala, at mga sanggunian sa mga hindi napapanahong papel.

Huwag #9. Ano ang Dapat Gamitin At Saan? – Dapat gamitin ang “Dapat” kung saan nakasaad ang mga kinakailangan, dapat gamitin ang “Will” upang kumatawan sa mga pahayag ng mga katotohanan; & "Dapat" upang kumatawan sa isang layunin na makakamit.

Gawin ang #10. Ang Organised Paperwork ay gumagawa ng Wonders – Panatilihing organisado ang mga kinakailangan sa isang lugar upang mapahusay ang pagiging madaling mabasa ng iyong dokumento at maiwasan ang pag-aaksaya ng oras sa pag-cross-referencing sa maraming mapagkukunan.

Huwag #10. Huwag Gumamit ng Mga Hindi Alam na Tuntunin – Huwag gumamit ng mga hindi kilalang termino tulad ng “user-friendly, versatile, at robust” na maaaring lumikha ng mga problema kapag sinusubukang tukuyin ang mga test case. Ang mga salitang ito ay kadalasang may iba't ibang kahulugan para sa iba't ibang tao.

Mga Kinakailangan sa Visure ALM Platform

Ang Visure ay isa sa mga pinakapinagkakatiwalaang platform ng pamamahala ng lifecycle ng application na dalubhasa 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.

Konklusyon

Ang pagtutukoy ng mga kinakailangan ay isang kritikal na proseso sa pagbuo ng software, ngunit maaari itong maging mahirap na magsulat ng mahusay na mga kinakailangan. Ang 20 tip na ibinigay namin ay dapat makatulong sa iyo na magsulat ng mas mahusay na mga kinakailangan, na ginagawang mas maayos ang proseso para sa lahat ng kasangkot. Kung gusto mong dalhin ang iyong mga kinakailangan sa pagsulat sa susunod na antas, isaalang-alang ang paggamit ng tool tulad ng Visure Requirements ALM Platform. Kahilingan a libreng 30-araw na pagsubok ngayon at tingnan kung paano makakatulong sa iyo ang aming platform na i-streamline ang iyong mga kinakailangan sa pangangalap at mga proseso ng pamamahala.

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.