Câștiguri:
- Capacitatea de a transforma cererile vagi de afaceri în cerințe software clare și testabile și povești ale utilizatorilor cu suport AI
- Abilitatea de a compara avantajele și dezavantajele proiectării sistemului, modelului de date și deciziilor arhitecturale într-un mod structurat cu AI
- Capacitatea de a valida în mod critic designul propus de IA în raport cu cerințele, scalabilitatea și constrângerile
Majoritatea proiectelor software eșuează nu din cauza codului prost, ci din cauza cerințelor neînțelese. O solicitare cu o singură propoziție precum „Permite utilizatorilor să descarce rapoarte” lasă în urmă zeci de întrebări fără răspuns: în ce format? Cine este responsabil? Câte înregistrări? Dacă e lent? Analiza cerințelor (traducerea unei cereri de afaceri în nevoi tehnice clare, testabile) și proiectarea software (construirea structurii pe hârtie pentru a satisface aceste nevoi) este etapa în care cele mai costisitoare greșeli sunt prevenite înainte de scrierea codului. În această unitate, vom învăța să folosim AI ca „partener de gândire” în această etapă: un partener care demitifică incertitudinea, sortează opțiunile, dar lasă decizia finală la latitudinea dvs.
AI produce două mari valori aici. În primul rând, pune întrebări pe care le omiteți; Aduce la suprafață ipoteze ascunse și cazuri marginale într-o cerere. În al doilea rând, prezintă rapid avantajele și dezavantajele unei decizii de proiectare. Dar acesta este pericolul: AI va oferi recomandări generice ca „cele mai bune practici” fără a vă cunoaște pe deplin contextul (buget, echipă, sistem existent, constrângere legală). Este datoria ta să filtrezi acest sfat împotriva propriului tău adevăr.
Concepte: Povestea utilizatorului: O propoziție scurtă care exprimă o nevoie sub forma „... ca, vreau să pot... pentru că...”. Criterii de acceptare: Condiții testabile care trebuie îndeplinite pentru ca un loc de muncă să fie considerat „terminat”. Cerință nefuncțională: cerințe legate de „cum se va comporta” mai degrabă decât de „ce va face”, cum ar fi viteza, securitatea, scalabilitatea.
De la cerere vagă la cerință testabilă
O cerință bună este măsurabilă și verificabilă. Nu „lasă sistemul să fie rapid”, ci „lasă rezultatele căutării să revină în 500 ms”. Iată o modalitate pas cu pas de a utiliza AI pentru a reduce incertitudinea:
- Dă cererea așa cum este și generează întrebarea. Cereți AI nu soluția, ci mai întâi „să enumerați orice neclar în această solicitare ca întrebare”.
- Tu dai raspunsurile. Numai tu cunoști contextul; Răspundeți la întrebările AI cu constrângerile dvs. reale de afaceri.
- Traduceți-l în povești ale utilizatorilor și criterii de acceptare. Traduceți nevoia clarificată în elemente testabile.
- Adăugați cazuri marginale și scenarii negative. „Rezultat gol”, „utilizator neautorizat”, „fișier prea mare” etc.
Prompt de extragere a ambiguității: „Vom traduce următoarea solicitare de afaceri într-o cerință software. Nu propuneți încă o soluție. În primul rând, extrageți TOATE ambiguitățile și ipotezele ascunse la care nu se răspunde în această solicitare ca o listă de întrebări. Grupați întrebările sub următoarele rubrici: domeniu de aplicare, utilizator/autoritate, volum de date, performanță, condiții de eroare, securitate.
Povestea utilizatorului + solicitarea criteriilor de acceptare: „Împărțiți următoarea nevoie clarificată în povești de utilizator care respectă principiile INVEST. Scrieți 3-5 criterii de acceptare testabile pentru fiecare poveste (în format dat-când-atunci). Adăugați cel puțin 2 scenarii negative (acces neautorizat, date goale). Nevoie: [scrieți necesitatea clarificată aici]"
Compararea deciziilor de proiectare cu AI
Designul este un compromis constant: viteză versus flexibilitate, simplitate versus scalabilitate? AI pune aceste compromisuri într-o foaie de calcul rapidă. De exemplu, pentru o funcție de „trimitere notificare”, puteți dezbate dacă să utilizați o abordare sincronă (trimitere la cerere) sau asincronă (în coadă, trimitere în fundal).
Prompt de comparare a designului: „Proiectez o funcție de „trimitere notificare prin e-mail utilizatorului”. Comparați cele două abordări: (A) livrare sincronă în timpul solicitării HTTP, (B) livrare asincronă în fundal, punând-o în coada de mesaje. Faceți un tabel pe următoarele axe: timp de așteptare a utilizatorului, toleranță la erori, complexitate, cost de infrastructură, dificultate în depanarea în propoziții care ar putea alege într-un final22. caz în care nu lua decizia pentru mine”.
axa
transmisie sincronă
Asincron (coadă)
Timp de așteptare al utilizatorului
Lung (se așteaptă expedierea)
Scurtă (se întoarce imediat)
Toleranță la erori
Scăzut (solicitarea explodează dacă trimiterea explodează)
Ridicat (reîncercați posibil)
complexitate
scăzută
Mediu-ridicat (infrastructură de coadă)
Costul infrastructurii
scăzută
Sunt necesare componente suplimentare
Unde se potrivește
Volum redus, aplicare simplă
Volum mare, livrare critică
Sfat: a-i spune AI „nu lua decizia pentru mine, arată-mi doar opțiunile și condițiile” te obligă să gândești și reduce riscul de a accepta orbește o sugestie. Cea mai bună decizie de proiectare este cea luată de persoana care vă cunoaște contextul (dvs).
Solicitare slabă / Solicitare puternică
SLAB: „Proiectează o bază de date pentru sistemul de comenzi”. (Rezultat: ce scară, ce relații, ce constrângeri nu sunt clare; o schemă generală, nerealistă.) PUTERNIC: „Sugerați un model de date schiță pentru un comerț electronic mic. Entități: client, comandă, produs, articol de comandă. Constrângeri: pot exista multe produse într-o comandă; prețul produsului se poate modifica în timp, dar prețul actual ar trebui păstrat; „Explică-i că ai luat decizia. Specificați cum ați rezolvat problema istoricului prețurilor. Dați-o ca o listă de entități și câmpuri, nu cod."
Diferența unui prompt puternic; scară (500 de comenzi pe zi), regula de afaceri (prețul trecut trebuie menținut) și formatul de ieșire dorit. O singură propoziție precum „Prețul trecut trebuie menținut” schimbă complet designul; Dacă nu specificați acest lucru, AI va produce o diagramă inexactă, dar cu aspect plauzibil.
Mini Carcase
Cazul 1 — Ipoteza ascunsă. O echipă codifică direct solicitarea „utilizatorul poate încărca fotografia de profil”. O altă echipă a întrebat AI despre incertitudine: „dimensiune maximă? formate permise? control neadecvat al conținutului? șterge fotografia veche?” Produce 8 întrebări de genul. Prima echipă află de problema în producție când fișierele de 20 MB umplu serverul; Cea de-a doua echipă o rezolvă în design.
Cazul 2 – Ipoteza de scară incorectă. AI propune un strat complex de stocare în cache pentru o caracteristică de raportare. Când inginerul subliniază că datele reale sunt doar 30 de rapoarte pe zi, AI simplifică sugestia. Nespecificarea scalei implică costul complexității inutile; specificarea economisește 2 săptămâni de muncă inutilă.
Cazul 3 – Decalajul criteriilor de acceptare. „Ce se întâmplă dacă plata eșuează?” Întrucât întrebarea nu a fost pusă niciodată, un sistem de comandă va marca în continuare comanda ca „confirmată” în cazul plății nereușite. Lista scenariilor negative generate de AI surprinde acest decalaj; Criteriile de acceptare pe 1 linie previne pierderea de bani reali.
Greșeli comune
- Trecerea cererii direct la cod. Codul scris înainte ca ambiguitatea să fie rezolvată rezolvă rapid problema greșită.
- Luând orbește „cea mai bună practică” generală a AI. Dacă nu specificați contextul dvs. (scale, buget, echipă) recomandarea nu va funcționa pentru dvs.
- Omiterea cerințelor nefuncționale. Dacă viteza, securitatea și scara nu sunt specificate, designul va fi incomplet.
- Mă gândesc doar la scenariul fericit. Scenariile negative, cum ar fi date goale, utilizator neautorizat, starea de eroare ar trebui incluse în proiect.
- Delegarea deciziei către AI. AI generează opțiuni; Tu decizi ce compromis se potrivește afacerii tale.
În concluzie
Analiza și proiectarea cerințelor este etapa în care sunt surprinse cele mai ieftine erori. Aici, AI generează întrebări care dezvăluie incertitudinea, elaborează poveștile utilizatorilor și criteriile de acceptare și prezintă compromisuri de proiectare. Dar numai tu cunoști contextul; Este datoria ta să filtrezi recomandările AI în funcție de scara, bugetul, echipă și constrângerile legale și să iei decizia finală. Disciplina „nu lua decizia pentru mine, arată-mi opțiunile” duce atât la un design mai bun, cât și la o învățare mai profundă.
Sarcina de aplicare
Alegeți o cerere de angajare cu o singură propoziție din contextul dvs. Mai întâi, aplicați promptul de ambiguitate AI și răspundeți la întrebări cu constrângerile dvs. reale. Apoi, traduceți nevoia clarificată în cel puțin 2 povești de utilizator și 3 criterii de acceptare pentru fiecare; Includeți cel puțin 1 scenariu negativ. În cele din urmă, creați un tabel de comparație pentru o decizie de proiectare (sincronă/asincronă, structură de tabel etc.) și scrieți propria decizie în 2 propoziții.
lista de verificare
- [ ] Am eliminat ambiguitățile ca întrebări înainte de a trece solicitarea în cod.
- [ ] Am dat contextul (scale, autoritate, performanță, constrângere legală) AI.
- [ ] Am împărțit poveștile utilizatorilor în criterii de acceptare testabile.
- [ ] Am adăugat cel puțin un scenariu dezavantaj/margine.
- [ ] Am evaluat decizia de proiectare cu tabelul de compromis.
- [ ] Am luat decizia finală pe baza contextului meu, nu am lăsat-o pe seama AI.