într-un proces de dezvoltare a produsului, unul dintre aspectele vitale ale succesului oricărui proiect este obținerea corectă a cerințelor. Și multe proiecte nu reușesc, deoarece părțile interesate nu reușesc să înțeleagă diferența dintre cerințele de afaceri vs cerințele funcționale.
succesul final și eșecul oricărui proiect depind de calitatea cerințelor. Deși este rar spus atât de simplu, majoritatea proiectelor software eșuează din cauza unui accent mai mic pus pe gestionarea cerințelor.
în septembrie 1999, NASA și-a pierdut 125 de milioane de dolari Mars Climate Orbiter când a încercat să intre pe orbită, la doar 100 de kilometri prea aproape de Marte. Misiunea a eșuat din cauza gestionării deficitare a cerințelor: nu s-a discutat mai devreme în etapă dacă ‘software-ul de navigație’ necesită unități metrice sau unități imperiale.
rezultatul: Specificații incompatibile; sistemul de control al atitudinii a fost specificat folosind unități imperiale, dar software-ul său de navigație a folosit unități metrice.
astfel, obținerea cerințelor corecte și utilizarea lor în cea mai mare măsură este esențială pentru succesul unui proiect.
în domeniul dezvoltării de produse software, importanța și relevanța cuvântului ‘cerințe’ crește odată cu popularitatea crescândă a metodologiilor de dezvoltare software agile. Chiar și unul dintre punctele menționate în Manifestul agil explică metodologia ca fiind una care apreciază:
„software de lucru peste documentație cuprinzătoare”
obținerea corectă a cerințelor este critică, indiferent dacă lucrați în metodologia Agile sau Waterfall.
- Business vs cerințe funcționale – definiție și tipurile sale
- care sunt cerințele de afaceri
- exemplu de cerințe de afaceri
- Business Requirements Document (BRD)
- documentul cerințelor de afaceri exemplu – de ce Chrysler PT Cruiser a fost etichetat ‘Hero to Zero’
- Sfaturi pentru scrierea unui șablon de Document cerințe de afaceri (BRD)
- care sunt cerințele funcționale
- cerințe funcționale exemplu
- soluția pe care Net Solutions a livrat-o
- document cerințe funcționale
- Sfaturi pentru scrierea unui șablon de document cu cerințe funcționale (FRD)
- cerințe de afaceri vs cerințe funcționale: provocări cheie în scrierea unui Document
- ce sunt cerințele nefuncționale?
- cerințe de afaceri vs cerințe funcționale – concluzie
Business vs cerințe funcționale – definiție și tipurile sale
înainte de a săpa mai adânc în cerințele de afaceri vs cerințe funcționale să ne uităm la definiția și tipurile.
potrivit Institutului Internațional de analiză a afacerilor, o cerință este:
- o condiție sau capacitatea necesară de o parte interesată pentru a rezolva o problemă sau atinge un obiectiv.
- o condiție sau capacitate care trebuie să fie îndeplinite sau posedat de un sistem sau o componentă de sistem pentru a satisface un contract, standard, caietul de sarcini, sau alte documente impuse în mod oficial.
- o reprezentare documentată a unei condiții sau capacități ca în (1) sau (2)
pe baza domeniului problematic si a metodologiei cu care lucreaza un Business Analyst (BA), sunt urmatoarele cerinte, dintre care cele mai importante sunt: cerinte de business si cerinte functionale.
în acest blog, vom explora diferența dintre cerințele de afaceri și cerințele funcționale. Este imperativ să înțelegem diferența, astfel încât să oferim afacerii o soluție ideală care să se ocupe cu adevărat de problemă.
care sunt cerințele de afaceri
de ce are nevoie un client de o aplicație?
aceste informații pot părea inutile pentru mulți, deoarece clientul este gata să vă plătească pentru a construi o aplicație. Deci, de ce ar trebui să conteze pentru tine pentru a obține motivele?
Ei bine, dacă sunteți pasionați de construirea de produse de calitate și de furnizarea de experiențe fără probleme clienților dvs., atunci ar trebui să vă pese de ‘whys’ la fel de mult ca și de ‘whats’ și ‘hows.’
și când începi să te concentrezi pe partea ‘de ce’ a unui proiect, înseamnă că ai grijă de cerințele afacerii.
vă respectăm confidențialitatea. Informațiile dvs. sunt în siguranță.
cerințele de afaceri pentru dezvoltarea de software ciclul de viață se ocupă de cerințele sau dorințele la nivel înalt ale unei organizații, ceea ce permite afacerii să își atingă obiectivele finale, viziunea și obiectivele.
de obicei descriu ce ar trebui să facă un sistem sau o soluție. Ele dau amploarea unei nevoi de afaceri sau a unei probleme care ar trebui abordată de un anumit proiect sau sarcină.
exemplu de cerințe de afaceri
ParcelKiosk este unul dintre clienții noștri care ne-au abordat pentru a obține o aplicație web proiectată și dezvoltată pentru a oferi clienților servicii de livrare mai bune a coletelor. Pe măsură ce ne-au abordat, am început discuția cu un parametru important: analiza nevoilor afacerii.
care credeți că ar putea fi cerința de afaceri pentru acest serviciu de aplicații web de livrare de colete?
s-ar putea veni cu un parametru important ca securitatea. Cu toate acestea, chiar dacă securitatea este un factor vital, nu este o cerință de afaceri. Tu nu construi un serviciu ca ParcelKiosk fără securitate în minte, dar crearea de servicii doar de dragul de a oferi securitate—nu este scopul final.
ce zici de conectarea unei game de servicii de curierat și clienți?
acest lucru are un sens mai bun ca cerință de afaceri în comparație cu securitatea, deoarece descrie ce va face serviciul. Cu toate acestea, acesta este motivul pentru construirea serviciului web sau este într-adevăr o funcție a serviciului?
iată câteva motive posibile (cerințe de afaceri) pentru a construi ParcelKiosk:
- oferiți o soluție mai inteligentă pentru măsurarea, selectarea și expedierea coletelor
- oferiți capabilități de urmărire și gestionare a serviciilor de livrare și preluare a acestora
- livrare la timp și feedback-ul clienților
vedeți diferența dintre conectarea unei game de servicii de curierat și clienți sau securitate și cerințele reale de afaceri?
următoarele puncte pot fi notate aici w. R. T cerințele de afaceri:
- cerințele de afaceri sunt întotdeauna scrise din punctul de vedere al clientului.
- sunt cerințe largi de sistem la nivel înalt, dar orientate spre detalii.
- nu sunt obiective organizaționale, ci ajută o organizație să-și atingă obiectivele. Prin îndeplinirea acestor cerințe de afaceri, organizația își atinge obiectivele generale.
este destul de clar acum că cerințele de afaceri explică ‘de ce’ parte a unui proiect: ‘de ce’ un anumit proiect trebuie să fie construit, adică. ce beneficii își propune organizația prin îndeplinirea unui proiect specific.
Business Requirements Document (BRD)
un Document Business Requirements descrie nevoile de afaceri la nivel înalt. Publicul țintă principal al unui BRD este clientul și utilizatorii. Cerințele de afaceri sunt documentate în BRD. Un document de cerințe de afaceri bine scris ajută la atingerea obiectivului dorit de a construi un produs de succes în termenul prevăzut.
are următoarele elemente:
- viziunea proiectului
- obiectivele proiectului
- contextul sau Contextul Proiectului
- domeniul de aplicare al proiectului
- Identificarea părților interesate
- cerințe detaliate de afaceri
- domeniul de aplicare al soluției
- constrângerile proiectului: Perioada de timp, costul proiectului și resursele disponibile
documentul cerințelor de afaceri exemplu – de ce Chrysler PT Cruiser a fost etichetat ‘Hero to Zero’
grupul Chrysler nu s-a concentrat prea mult pe BRD și a continuat producția PT Cruiser, rezultând multe dureri de cap pentru organizație. Să aruncăm o privire la modul în care documentul cerințelor lor de afaceri a eșuat:
- Identificarea părților interesate: grupul Chrysler a identificat majoritatea părților interesate destul de bine. Erau la bord cu vânzătorii și echipa de producție a PT Cruiser. Cu toate acestea, cele două părți interesate importante pe care le-au ratat au inclus clientul final care achiziționează vehiculul și dealerii care vând crucișătorul.
- constrângeri de proiect: Chrysler a făcut o treabă bună atunci când a venit la părțile interesate de nivel superior care furnizează și supraveghează construcția. Cu toate acestea, ceea ce au ratat a fost interogarea cronologiei producției, răspunsul la întrebările clienților sau ale dealerilor, cum ar fi prețul, disponibilitatea modelului și cererea.
să presupunem că BRD-ul Chrysler a inclus toate cerințele părților interesate, aceste întârzieri neprevăzute în livrarea produsului (obiectivul de a livra mașini către reprezentanță până în 2001) ar fi putut fi influențate cu mult înainte de producție, iar nevoile utilizatorilor finali ar fi fost justificate.
Sfaturi pentru scrierea unui șablon de Document cerințe de afaceri (BRD)
acum, că aveți o înțelegere de bază a ceea ce ar trebui să realizeze un BRD, puteți urma sfaturile menționate mai jos pentru a vă asigura că scrie un document restante cerințele de afaceri.
- practică cerințe puternice provocarea
- folosiți un limbaj simplu fără voce pasivă și jargon
- proiecte anterioare de cercetare
- validați documentația
- integrați imagini
care sunt cerințele funcționale
cerințe funcționale, după cum sugerează și numele, descrieți funcționalitățile software-ului sau ale un produs. Acestea sunt funcțiile pe care sistemul trebuie să le îndeplinească pentru a îndeplini cerințele de afaceri.
acestea includ detalii tehnice, calcule, manipularea și prelucrarea datelor și alte funcționalități particulare care caracterizează ceea ce ar trebui să realizeze un cadru.
dacă nu aveți cerințe funcționale clare pentru a înțelege tehnicitatea proiectului, atunci în timpul proiectului, nu veți putea răspunde dacă deciziile luate de echipele de dezvoltare/proiectare/testare sunt corecte.
„eșecul de a scrie o spec este cel mai mare risc inutil singur luați într-un proiect software.”~Joel Spolsky
dacă un detaliu funcțional este aliniat greșit la obiectivele de afaceri, ar putea duce la eșecul proiectului.
cerințe funcționale exemplu
unul dintre marii jucători FMCG a abordat Net Solutions pentru un proiect de dezvoltare a aplicațiilor mobile care ar putea îmbunătăți eficiența în lanțul lor de aprovizionare.
acest gigant FMCG a început un proiect în 2001, care vizează împuternicirea femeilor din mediul rural prin generarea de oportunități pentru ca acestea să vândă produse și să câștige un trai.
clientul a dorit ca echipa noastră de proiect să își refacă aplicația mobilă existentă într-un mod care să automatizeze lanțul de aprovizionare și procesul de comandă prin aducerea femeilor și distribuitorilor din mediul rural pe o singură platformă digitală.
au urmărit să îmbunătățească rata de adopție, permițând digital antreprenorilor și rezolvând fricțiunile din călătoria existentă a clienților (toate acestea sunt cerințe de afaceri).
când vine vorba de cerințele funcționale, am început să discutăm caracteristicile aplicației necesare cu clientul, care au fost:
- integrarea cu furnizori terți
- actualizări de stoc în timp real
- plasarea comenzilor
clientul a presupus că aceste caracteristici ar fi suficiente pentru a rezolva fricțiunea din călătoria curentă a clientului, îmbunătățind astfel rata de adoptare.
cu toate acestea, în timp ce discutam cerințele funcționale cu clientul nostru, ne-am dat seama că, dacă nu identificăm fricțiunile din călătoria unui client existent și măsurăm nivelurile de alfabetizare digitală pentru noii utilizatori de aplicații, dezvoltarea unei aplicații ar fi inutilă.
soluția pe care Net Solutions a livrat-o
am aplicat abordarea Design Thinking și am efectuat cercetări etnografice pentru a evalua disponibilitatea digitală a antreprenorilor și pentru a înțelege lacunele din călătoria utilizatorilor aplicației existente.
am petrecut o zi cu toate părțile interesate pentru a identifica în continuare problemele lor.
folosind abordarea de gândire de proiectare, am fost capabili să dau seama ce caracteristici ar trebui să meargă în noua aplicație. Mai mult decât atât, această abordare a făcut clientul nostru să înțeleagă că cel mai bun mod de a merge mai departe cu managementul de proiect este de a-l realiza într-o manieră etapizată.
rezultatul:
cercetarea etnografică și cartografierea călătoriei în cadrul metodologiei noastre de gândire a designului ne – au ajutat să construim o nouă aplicație cu caracteristici proiectate și validate de părțile interesate care o vor folosi în cele din urmă-făcându-l unul dintre exemplele de cerințe funcționale notabile.
următoarele puncte pot fi notate aici w. R. T cerințe funcționale:
- cerințele funcționale sunt întotdeauna scrise din punctul de vedere al sistemului și al părților interesate.
- specificațiile cerințelor funcționale sunt mult mai detaliate.
- prin îndeplinirea cerințelor funcționale se dezvoltă o soluție eficientă, care satisface nevoile și obiectivele de afaceri ale clientului.
prin urmare, cerințele funcționale explică partea ‘cum’ a unui proiect, adică cerințele software și modul în care soluția va putea satisface nevoile organizației.
document cerințe funcționale
documentul Cerințe funcționale prezintă funcțiile necesare pentru a atinge nevoile de afaceri. Aceste funcții sunt documentate în documentul privind cerințele funcționale (FRD) sau în documentul privind specificațiile privind cerințele funcționale (FRS).
un FRD bine scris descrie fiecare flux de proces pentru fiecare activitate, interconectând dependențele.
FRD conține următoarele elemente:
- Scopul proiectului
- domeniul de aplicare al proiectului
- cerințe funcționale detaliate
- ipoteze/constrângeri
- reprezentarea cerințelor funcționale folosind arhitectura informațională
Sfaturi pentru scrierea unui șablon de document cu cerințe funcționale (FRD)
crearea unui document care funcționalitățile tehnice care sunt necesare pentru livrarea cu succes a unui software/produs este la fel ca scrierea unui mesaj tuturor membrilor echipei implicate despre sarcinile tehnice pe care doriți să le îndeplinească.
următoarele sfaturi vă vor ajuta să scrieți un Document eficient privind cerințele funcționale:
- verificați faptele
- utilizați un limbaj simplu
- adăugați ilustrații sau diagrame
- respectați intervalele de timp
cerințe de afaceri vs cerințe funcționale: provocări cheie în scrierea unui Document
este o mare provocare să scrieți cerințe de afaceri și funcționale „bune” sau „valide”. Cele mai frecvente provocări întâlnite în timpul construirii acestor documente de cerințe includ:
- o înțelegere incompletă a cerinței, nereușind să ceară clarificări.
- interpretare incorectă a cerinței; aplicarea filtrelor personale informațiilor care modifică intenția.
- scrierea despre implementare (cum) în loc de cerințe (ce).
- deciziile de punere în aplicare ar trebui amânate până la un punct cât mai târziu posibil în procesul de solicitare a cerințelor.
- folosind structura propoziție incorectă.
- importanța evaluării cerințelor de calitate în dezvoltarea de produse software.
ce sunt cerințele nefuncționale?
cerințele nefuncționale definesc și specifică funcționarea sistemului. Cu toate acestea, nu afectează funcționalitatea sistemului așa cum sugerează și numele. Prin urmare, sistemul poate continua să funcționeze chiar dacă cerințele sale nefuncționale nu sunt îndeplinite. Motivul pentru care cerințele nefuncționale sunt esențiale se datorează utilizabilității lor și deoarece ajută la determinarea factorilor care afectează experiența utilizatorului.
ceea ce diferențiază cerințele funcționale și nefuncționale este că, în timp ce prima decide caracteristicile produsului și cerințele utilizatorilor, cea de-a doua se concentrează pe proprietățile produsului și așteptările utilizatorilor.
cerințe de afaceri vs cerințe funcționale – concluzie
din comparația de mai sus, este clar că cerințele sunt coloana vertebrală a fiecărei afaceri. Atât cerințele de afaceri, cât și cele funcționale formează fundamentul unei analize eficiente a afacerii. Cerințele de afaceri explică „de ce „și” CE „ale unui proiect, iar cerințele funcționale explică” cum ” a proiectului.
o revizuire periodică și o analiză comparativă a cerințelor funcționale (dezvoltate) cu cerințele de afaceri asigură succesul general al unui proiect. Iată o declarație finală care vă va ajuta să distingeți clar cerințele de afaceri de cerințele funcționale – punctul de plecare al oricărei analize de afaceri este să înțelegeți cerințele de afaceri (ce și de ce) ale clientului și să le transformați în cerințe funcționale (cum).