ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 21
Abonament PDF

Cauza tuturor relelor în dezvoltarea soft…

Cluj Business Analysts
Mădălina Crișan, Business Analyst Monica Petraru, Product Manager Cătălin Anghel, Business Analyst



MANAGEMENT


Se presupune că ar fi proasta definire a cerințelor. Este riscant să se adopte o poziție radicală și să se izoleze cauza determinantă la una singură. Extragerea defectuoasă a cerințelor este însă cu siguranță una dintre ele. Din scurta mea experiență, în timpul extragerii cerințelor, în ciuda celor mai bune intenții, nu se face uz de o înțelegere sau diferențiere exactă între noțiunile de cerințe și design al soluției.

Nevoia și valoarea designului sunt incontestabile, dar in stadiile incipiente ale extragerii cerințelor, focusul ar trebui să fie îndreptat spre înțelegerea genezei cerinței pentru a putea genera cât mai multe opțiuni adecvate pentru sponsorii noștri. Riscurile de a nu face aceasta sunt multiple și se pot concretiza prin :

  • implementarea unei soluții specifice pentru o problema generală pe care nu suntem capabili să o surprindem și să o exprimăm;
  • pierderea interesului, a încrederii și a implicării persoanelor cu competență decizională în domeniul de specialitate,
  • confirmări false( urmând să suportăm consecințele mai târziu), sau mai rău,
  • efort de dezvoltare și costuri adiționale și în cele din urmă, eșecul proiectului.

În cele ce urmează, câteva argumente din perspectiva unui analist de business.

O definiție magică

BABOK definește extragerea cerințelor (noțiunea de "elicitation") ca: a scoate la suprafață, a scoate la lumină ceva latent sau potențial; a extrage sub formă de informație sau răspuns.
Conform IREB tehnicile de extragere a cerințelor îndeplinesc acel scop de a afla cerințele conștiente, inconștiente și subconștiente de la sponsori. Cuvinte precum : latent, potențial, conștient, inconștient și subconștient confirmă definiția latină a cuvântului: "a extrage prin șiretlic sau magie".Nu fără justificare.

În opinia mea, totul se leagă de faptul că sponsorii nu au o viziune riguroasă asupra domeniului și din acest motiv nu ne putem aștepta de la ei să fie în întregime conștienți de relația dintre problemă și domeniu. Noi ca analiști de business, modelăm domeniul de business, mai exact, creăm o reprezentare simplificată și abstractizată a domeniului respectiv, cu toate avantajele și capcanele pe care modelarea le implică. Nu este cu nimic mai puțin valoros sau adevărat ca modelarea domeniului de business și a problemei :

  • ghidează activitatea de extragere a cerințelor,
  • ajută la formularea întrebărilor și la descoperirea problemelor,
  • ajută la descoperirea inconsecvențelor, a cerințelor contradictorii și a disensiunilor dintre sponsori.

Dacă se ia în considerare o problemă exprimată prost, enunțată fără detalii, avansată prematur în etapa de analizare a soluției - atunci începem să înțelegem dificultățile cauzate în proiecte de cerințe slab definite.

Obiectul activității de extragere a cerințelor

Este vorba atât despre cerințe venite din partea sponsorilor, cât și cerințe legate de implementarea soluției.
Conform BABOK, cerința este : " (1) O condiție sau abilitate de care un sponsor are nevoie pentru a rezolva o problema, sau pentru a atinge un obiectiv; Există mai multe definiții, dar cuvinte ca "problemă", "oportunitate", sau "constrângere" (cu valoare potențială pentru sponsori) apar în mod recurent.
Designul pe de altă parte este o colecție de hotărâre cu referire la implementarea soluției.

Ușor de zis, greu de făcut, pentru că în mod aparent, nu ne pricepem prea bine la estimarea căror lucruri sunt de valoare pentru noi și în ce măsură. Mai mult decât atât, suntem predispuși să gândim în termeni de soluții, mai degrabă decât în termeni de probleme. Acest lucru este cauzat de ușurința de vizualizare. Acesta este motivul pentru care există dificultăți în găsirea demarcației dintre declararea/definirea problemei pe de o parte, respectiv definirea soluției pe de altă parte.

Bazându-se pe argumentul anterior, cerințele sunt "afirmații care traduc sau exprimă o nevoie și constrângerile și condițiile asociate acesteia".Iată că astfel putem diferenția între cerințele sponsorilor și cerințele legate de implementarea soluției. Modelul Conceptelor de Bază în Analiza de Business are o definiție clară pentru concepte cum sunt : schimbare, nevoie, soluție, valoare, părți interesate, și context. Modelul asociază aceste valori, după cum urmează:

  • Cerințe: nevoie, valoare, sponsori;
  • Design: soluție, nevoie, context;

Tragem concluzia că nu există nici o linie de demarcație precisă între cele două, întrucât acestea au în comun conceptul de "nevoie". Ceea ce este sigur însă, este că atunci când începem activitatea de extragere a cerințelor, ar trebui să fie clar care este obiectul ei. În faza de inițializare a unui proiect ar trebui să stabilească regulile privind granularitatea dincolo de care noțiunile constituie mai degrabă detalii de design decât cerințe de business, detalii asupra cărora sponsorul nu insistă să imprime o direcție sau să își impună autoritate decizională.

Exemplul ferestrei

Să luam în considerare o situație banală. Un exemplu prin care aleg să abdic de la trivialitatea și de la modul în care această situație este tratată aproape de fiecare dată. Un exemplu pe care am de gând să îl utilizez ca pe o hiperbolă, pentru a ilustra un punct de vedere.

Problema este reprezentată de imaginea de mai jos.

Pentru a o rezolva, am fi tentați să spunem ca trebuie să cumpărăm un geam termopan și dilema este rezolvată. Problema ar putea să fie formulată:
- relativ la estetică, confort sau sănătate ( vântul și ploaia ajunge în casă, iar mobilierul și parchetul sunt distruse), sau
- relativ la aspectul siguranței și a pierderii bunurilor materiale - expunerea la hoți.

Să consideram puțin și contextul. Dacă acest cadru de fereastră gol este montat într-o instituție de sănătate mintală? Dar dacă aceasta se află într-o anexă gospodărească aflată pe un câmp de la țară? Este soluția evidentă,cea mai potrivită pentru ambele situații?

În prima situație, ați fi cu siguranță interesați de siguranța și, de asemenea,de aspectul intimității. În acest caz, ar fi nevoie de sticlă nu doar izolatoare, ci și securizată, opacă. Pentru cadrul din mijlocul câmpului, s-ar putea să vrei doar să ai un adăpost temporar împotriva ploii - caz în care o folie mai rezistentă de plastic ar putea rezolva problema la fel de bine.

Tendințele naturii umane în timpul activității de extragere a cerințelor

Se pot folosi spre avantajul nostru, mai multe tendințe ale naturii umane în timpul etapei de extragere a cerințelor, dar nu și dacă avem:

  • așteptări subiective,
  • preconcepții,
  • dorință de auto-exprimare,
  • dacă exploatăm anxietatea vizavi de performanța a celui intervievat.

Sentimente, cum ar fi : dorința de a fi recunoscut sau apreciat, predispoziția la curiozitate sau bârfă, instinctul de a se plânge, și nu în ultimul rând - obiceiuri inerente legate de munca de zi cu zi : consilierea, predarea, corectarea, provocatoare - sunt toate pârghii foarte importante pe care le putem utiliza în timpul extragerii cerințelor .

Se poate adopta una dintre abordările evidente cum ar fi : exprimarea unui interes comun, flatarea, quid pro quo sau,cei cu experiență sau îndrăzneți, pot exploata cu precauțiile necesare așa numitele referințe oblice (comentarii făcute indirect, fie într-o lumină pozitivă sau negativă,care generează, fie reacții de apărare sau critică; utilitatea acestora din urma constă validarea percepției domeniului de specialitate). De asemenea, fără ca partenerul să sesizeze, analiștii de business pot insinua în timpul discursului - o declarație provocatoare sau pot adopta o poziție antitetică, ceea ce va determina oameni competenți în domeniu să dorească să corecteze
Observați răspunsul interlocutorului și în primul rând, reduceți amenințarea la adresa ego-ului. Nimănui nu îi place să fie arătat degetul în timp ce se află în lumina reflectorului. Pentru a fi mai câștigați pe termen lung, este mai bine sa ne comportăm mai degrabă ca un "complice" care înțelege provocările cuiva care trebuie să cunoască toate răspunsurile corecte și să evitam să cerem acele informații în mod nerespectuos, ca și cum ni se cuvin.

O combinație inspirată a tehnicilor de extragere a cerințelor

Una dintre tehnicile puse la dispoziție de către BABOK este interviul, care este definit ca o conversație care invită oamenii să-ți spună în mod voluntar lucruri fără a conștientiza neapărat că fac asta. Chiar dacă este o conversație planificată, și pare că este simplu, faptul că trebuie să te bazezi pe detalii pe care le primești în timpul interviului și respectiv pe predispozițiile psihologice - face din interviu un demers mai greu decât s-ar zice la o primă vedere.

Se spune "nu planifica, și de fapt planifici să dai greș"; de aceea este recomandat să se înceapă prin formularea întrebărilor relevante (deschise, ipotetice) și să se ia în considerare relația cu interlocutorul, și anume atitudinea față de schimbul de informații. După aceasta, în timpul interviului, ar trebui să reformulăm întrebările primite pentru a motiva împărtășirea informațiilor și respectiv pentru a valida înțelegerea răspunsurilor primite și proiecția domeniului de business creată in mintea noastră.
Există cuvinte cheie care pot fi utilizate pentru a menține atenția, și pentru a preveni ca informațiile importante să ne scape printre degete: DE CE - conduce la motivațiile profunde; CE - conduce la fapte, CUM - conduce la o discuție cu privire la proces, nu structură; POT - încurajează flexibilitate maximă. Alte întrebări utile sunt: Care anume este problema care trebuie rezolvată? Când apare problema? Ce generează problema? Ce situații sunt noi sau vechi? Cum este tratată problema acum? De ce există problema?

Așa-numitele întrebări "situaționale" merg un pas mai departe, mai exact - prin acestea se întreabă despre o situație într-un mod care se testează înțelegerea domeniului. În opinia mea, acest lucru ar echivala cu înlocuirea variabilelor într-o formulă matematică, cu valori numerice.

Cel mai important lucru pe care ar fi bine să îl facem în timpul etapei de extragere a cerințelor este nu să vorbim, ci să ascultăm, altfel riscămsugerăm în mod neintenționat răspunsurile celui intervievat. Atunci când punem întrebări, în primul rând trebuie să avem în vedere oportunitățile de abordat, problemele de rezolvat și constrângerile pe care trebuie să le respectăm.

La fel ca majoritatea oamenilor, s-ar putea să fiți de părere că acest lucru este mai mult sau mai puțin o perdea de fum și că nu ajuta la scrierea codului și avansarea proiectului.Să luăm în considerare că s-a enunțat cu succes problema care trebuie să fie rezolvată, opțiunile pe care le avem la dispoziție să abordăm soluția, precum și restricțiile necesare pentru a asigura conformitatea. S-a întocmit de asemenea, o diagramă context (și acum știm dacă avem de a face cu un cadru de fereastră aflat într-o anexă aflată pe un câmp de la țară sau într-o instituție de sănătate mintală).

În continuare vom aborda interfețele. Analiza interfețelor are scopul de a identifica legăturile dintre soluții și / sau componentele soluțiilor și de a defini modul în care acestea vor interacționa. Nu trebuie să uitam de interfețele aplicațiilor cu utilizatorii și nici despre interfețe cu dispozitive hardware externe sau de cele cu aplicații externe.

Pentru definirea interfețelor, este important să se precizeze tipul și scopul acestora. Apoi se continuă cu datele de intrare și ieșire, definirea regulilor de validare care guvernează datele de intrare și ieșire, respectiv cu identificarea evenimentelor care declanșează interacțiuni.

Există o dezbatere aprinsă cu privire la definirea cerințelor care ajută să clasăm acest subiect. Această dezbatere are schimburi de replici circulare, pentru a ajunge la concluzia viziunilor diferite ale grupurilor: ceea ce pentru un grup reprezintă cerința, pentru următorul grup, poate să reprezinte modul în care trebuie să rezolvăm problema, pe măsura ce trecem de la membri ai conducerii executive la "executanți".

Nu există o rețetă unică pentru a preveni haosul în ceea ce privește cerințele, dar sunt și idei utile precum: acordarea importanței cuvenite etapei de determinare, după care conștientizarea și enunțarea obiectivului și a obiectului activității dumneavoastră. După câteva runde de colectare a cerințelor, este recomandat ca treptat să facem trecerea spre proiectarea soluției, definirea opțiunilor pentru a rezolva problema - presupunând că s-a înțeles problema / oportunitatea de adresat și… nivelul de granularitate impus de grupul țintă al muncii de analiză.

Elicitarea cerinţelor - Best practices

Experienţa profesională acumulată de-a lungul timpului are o importanţă vitală în identificarea tehnicilor de elicitare corespunzătoare.

Dragi colegi, noi ca analişti de business, dorim să livrăm în final un "business analysis approach" de o calitate ridicată. Gradul de mulțumire a cliențilori este extrem de greu de apreciat, însă nu e un target imposibil de atins.

Prezentând într-o manieră coerentă şi punctuală situaţia, e firesc să ne întrebăm care sunt tacticile prin care vom obţine în final un client mulţumit? Doar prin aplicarea în practică a unor suite de tehnici de elicitare a cerințelor recomandate de către specialiştii din industrie.

Succesul sau eșecul de implementare a procesului soft depinde de calitatea specificaţiilor. Obținerea unor cerinţe clare, concrete şi punctuale depinde extrem de mult de metodele abordate în timpul fazei de colectare a cerinţelor.

Toate tehnicile disponibile dau rezultate, atâta timp cât sunt folosite în circumstanțele adecvate. Cu atât mai mult, tehnicile sunt complementare unele altora, prin faptul că limitările unei tehnici sunt adresate de cealaltă. În continuare, vă prezentăm câteva recomandări :

  1. Sesiuni de colaborare (workshops). Sunt modul standard de abordare a etapei de extragere a cerințelor.
    Avantaj : încurajează creativitatea și colaborarea între sponsori .
  2. Best practice :
    • Este ideal pentru situații în care sunt implicați numeroși sponsori autonomi.
    • Se poate ține sesiunea sub control prin afișarea agendei și a regulilor întâlnirii respective, păstrați evidența ideilor rezultate, a subiectelor care urmează sa fie abordate ulterior și a subiectelor care blochează avansarea.
    • Încercați să aveți o persoană care facilitează întâlnirea și o persoană care ia notițe.

Modele (data flow diagrams, state charts, UML)

Această tehnică are o vechime istorică care momentan joacă un rol în :

  • Facilitarea comunicării,
  • Identificarea detaliilor lipsă,
  • Organizarea informațiilor adunate prin intermediul altor tehnici de elicitare,
  • Descoperirea inconsecvențelor.

Best practice

  • Secvenţe de evenimente ordonate din punct de vedere cronologic utilizate pentru captarea interacţiunii dintre sisteme sau a oamenilor ce interacţionează cu sistemele.
  • Se recomandă crearea diagramelor DFD pe o tablă albă ca rezultat al colaborării, întrucât scopul acestora este acela de a crea un model mai bun al procesului, nefiind targetat ca documentaţie finală pentru client.
  • Construirea diagramelor DFD buttom - up având ca fundament de pornire analiza sistemelor iniţiale.
  • Utilizarea dicţionarelor de date ori de câte ori există mai multe grupuri de interese diverse şi autonome.

Dragi colegi, proiectele software analizate din perspectiva de business necesită abordări de elicitare a specificaţiilor ce se mulează pe cazuri reale şi pe constrângerile acestora. Noi, ca analişti de business avem nevoie de ghidare practică ce se articulează pe aplicarea bunelor practice aferente în faza de colectare a specificaţiilor.

Elicitarea cerinţelor - Provocări şi tendinţe viitoare

Înainte de a afla mai multe detalii utile legate de provocările şi tendințele viitoare ale procesului de elicitare, un analist de business experimentat ar trebui să aibă ca fundament de pornire imaginea întregului proces de colectare a cerinţelor.

Ce tehnici şi metode de elicitare să folosiţi în practică?

Se poate lua în calcul următorul exemplu: utilizarea mai multor tehnici de elicitare a specificaţiilor în proiecte caracterizate printr - o complexitate ridicată e posibil de aplicat în practică. Interviurile, tehnicile de prototyping şi interviurile, workshop - urile sunt combinate pentru a facilita procesul de colectare a specificaţiilor de pe acest tip de proiecte. Dacă se ia în calcul şi varianta echipelor virtuale distribuite geografic, în aceste circumstanţe este recomandată utilizarea technicilor de tip groupware (video conferinţe, cazuri de utilizare, sesiuni de brainstorming) ca un instrument adiacent procesului de management al cerinţelor. Acesta trebuie realizat extrem de punctual şi eficient. Nu trebuie omis faptul că technicile de elicitare au dezavantajele cât şi avantajele lor. Frumuseţea acestui proces constă în selectarea tehnicii corespunzătoare, iar această etapă presupune o înţelegere a audienţei business, cât şi a posibilităţilor avute la dispoziţie.

Alt argument important: alegerea tehnicilor de elicitare a specificaţiilor e dependentă de contextul proiectului şi este considerat un factor critic în livrarea cu succes a procesului de elicitare.

Factori importanţi:

  • Tehnica selectată e recomandată de metodologia abordată.
  • Tehnica aleasă e preferată de către analistul de business.
  • Orientarea către o anumită tehnică e guvernată de către simţul intuitive al analistului ca fiind "the best approach"- având în vedere circumstanţele date-

Elicitarea unor specificaţii clare este elaborată în parametri optimi dacă se va face apel la o suită de tehnici, nu doar la una singură - în majoritatea proiectelor, analiştii de business aduc în prim-plan utilizarea mai multor tehnici în funcţie de etapa SDLC - ului.

Sfaturi utile pentru facilitarea activităţilor zilnice:

  • Lipsa motivaţiei stakeholder-ilor de s se implica proactiv în procesul de elicitare a cerinţelor;
  • Lipsa abilităţilor de captare abstracte:
  • Stakeholder-i clasificaţi în functie de nivelul de management;
  • Disponibilitatea temporală slabă a părţilor implicate;
  • Complexitatea ridicată a business matter-ului.

Provocări

De-a lungul timpului s-au evidenţiat o serie de provocări şi trenduri posibile în domeniul elicitării cerinţelor.

Una dintre cele mai importante provocări este posibilitatea de implementare şi dezvoltare a unei strategii prin care să se reducă diferenţele existente dintre departamentele de cercetare şi industrie. Aceste diferenţe sunt definite la nivel de awareness, acceptanţă sau adaptare la nevoile de business. Totodată, conform experţiilor BA, aceste target - uri pot fi atinse doar prin setarea unor obiective concrete în practică şi printr-o eficientă promovare a metodelor corespunzătoare, astfel încât analiştii de business să le aplice cu uşurinţă şi confidenţă în munca lor zilnică.

Există probabilitatea ca analistul de business să se mai confrunte cu următoarele provocări:

  • Specificaţii conflictuale provenind de la stakeholder diferiţi;
  • Cerințe nerostite sau asumate;
  • Reticența părților interesate de a schimba / sprijini proiectarea unui nou produs.
  • Time management deficitar pentru stabilirea unor şedinţe de lucru cu toate grupurile de interese ale proiectului;
  • Aplicarea cu bună-ştiinţă a tehnicilor și metodelor de elicitare - creşte nivelul de obţinere în final al unui client mulțumit şi totodată asigurarea succesului proiectului;
  • Accesul limitat la părțile interesate de proiect;
  • Dispersarea geografică a stakeholder-ilor proiectului;
  • Priorităţi conflictuale;
  • Prea multe părți interesate sunt dornice de afirmarea unui efort participativ;

În AGILE

  • Există riscul ca programatorii să nu înţeleagă specificaţiile primite.
  • Echipa de implementare nu are cunoştiinţe ale domeniului business afferent.

Secretul evitării acestor situaţii mai mult sau mai puţin ortodoxe e unul extrem de simplu: ca analişti de business trebuie să ne motivăm continuu atât end user-ii, echipa de implementare,cât şi clienţii în vederea unei abordări colaborative, atât în planul comunicării şi spiritului de muncă în echipă. Un prim pas spre atingerea obiectelor menţionate în rândurile de mai sus constă în primul rând în selectarea metodelor optime de elicitare a specificaţiilor.

Tendinţe viitosre în elicitarea cerinţelor

În ciuda obținerii unei suite de succese și progrese în domeniul cerințelor, există totuşi încă unele probleme care așteaptă să fie luate în mod corespunzător, în considerare.

Potenţialele trăsături pe baza cărora se conturează viitoarele direcţii în domeniul elicitării specificaţiilor sunt listate în rândurile de mai jos:

  • Reducerea decalajului dintre teorie și practică, precum și practicanţi cu experienţă și novici;
  • Creșterea gradului de conștientizare și educație destinat celor interesaţi de acest domeniu, cât şi a părților interesate din industrie;
  • Dezvoltarea unor standarde pentru selecția tehnică și gestionarea impactului factorilor asupra procesului;
  • Modalități de colectare și reutilizare a cunoștințelor în ceea ce priveşte etapa de colectare a specificaţiilor business;
  • Integrarea și utilizarea tehnologiilor actuale;

Concluzii

Procesul de elicitare a cerinţelor, alegerea unei tehnici corespunzătoare depinde de o suită de factori, dintre care merită să îi amintim pe următorii: tipul proiectului soft ce se află in curs de implementare, stadiul în care se află proiectul sau domeniul business aferent.

Majoritatea abordărilor necesită atât un nivel ridicat de experienţă în domeniu, cât şi ani de experienţă profesională solidă.

Cu toate acestea, există o suită de tehnici ce se folosesc cu o frecvenţă mai mare. Acestea sunt: interviuri, workshop-uri în grup, tehnici de observare, setare de obiective strategice şi scenarii - ele sunt utilizate cu un succes răsunător în practică.

În cele din urmă, alegerea metodelor de elicitare a cerinţelor îi revine exclusiv analistului de business / inginerului de cerinţe, acesta luând decizia viabilă bazându-se pe mediul cultural, organizaţional sau pe constrângerile specifice domeniului de business.

Bibliografie

  1. A Guide to the Business Analysis Body of Knowledge(r) (Babok(r) Guide), by IIBA (Author), Kevin Brennan (Editor)
  2. Requirements Engineering, by Elizabeth Hull, Ken Jackson, Jeremy Dick
  3. Mastering the Requirements Process: Getting Requirements Right (3rd Edition), Suzanne Robertson, James Robertson
  4. Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant (Rocky Nook Computing), by Klaus Pohl , Chris Rupp
  5. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series),by Dean Leffingwell
  6. The Business Analyst"s Handbook, by Howard Podeswa
  7. Discovering Requirements: How to Specify Products and Services, by Ian Alexander, Ljerka Beus-Dukic
  8. OCEB Certification Guide: Business Process Management - Fundamental Level, by Tim Weilkiens , Christian Weiss , Andrea Grass
  9. Requirements by Collaboration: Workshops for Defining Needs, by Ellen Gottesdiener

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects