Câștiguri:
- Abilitatea de a distinge cerințele funcționale și nefuncționale și de a scrie expresii clare, măsurabile cu cerințele cu sprijinul inteligenței artificiale
- Abilitatea de a utiliza inteligența artificială cu solicitări structurate pentru a extrage povestea utilizatorului, criteriile de acceptare și limita de aplicare din notele de interviu
- Obișnuința de a verifica cerințele generate de IA pentru ambiguitate, contradicție și reguli care lipsesc și să le confirme cu părțile interesate
Analiza cerințelor este sarcina de a defini într-un mod complet, clar și verificabil ceea ce ar trebui să facă un sistem. Este una dintre etapele în care specialistul MIS produce cea mai mare valoare; pentru că aici o greșeală crește exponențial la finalul proiectului. Există două tipuri de bază de analiză a cerințelor. Cerința funcțională descrie munca pe care ar trebui să o facă sistemul: „Sistemul ar trebui să e-mail clientului atunci când confirmă comanda.” Cerința nefuncțională descrie modul în care ar trebui să fie sistemul: calități precum performanța, securitatea, capacitatea de utilizare și accesibilitatea. „Ecranul de raport ar trebui să se deschidă în mai puțin de 2 secunde la încărcare medie” este o cerință nefuncțională.
O cerință bună are trei caracteristici: este clară (are o singură interpretare), este măsurabilă (are un prag testabil) și este trasabilă (este clar din ce nevoie de afaceri provine). „Sistemul trebuie să fie rapid” nu îndeplinește niciuna dintre acestea; „rapid” este subiectiv, nu poate fi măsurat, nu poate fi testat. În această etapă, IA este un ajutor puternic în elaborarea cerințelor și pentru a prinde cuvinte ambigue; dar numai partea interesată decide care regulă de afaceri este reală.
Povestea utilizatorului și criteriile de acceptare
Un format comun în scrierea cerințelor moderne este povestea utilizatorului: „Ca [rol], pentru [scop], vreau [funcție]”. Exemplu: „În calitate de reprezentant de vânzări, vreau calcularea reducerii de pe ecranul mobil, astfel încât să pot face cotații rapide pe teren”. Povestea este scurtă și orientată spre afaceri; Nu impune o soluție tehnică.
Fiecare poveste ar trebui să aibă criterii de acceptare: condiții testabile care trebuie îndeplinite pentru ca povestea să fie considerată „ok”. Un model folosit frecvent este modelul „Given/When/Then”: „Given: clientul este în segmentul VIP. Când: comenzi peste 10.000 TL. Apoi: sistemul aplică o reducere de 5%. Acest model elimină ambiguitatea, deoarece conectează în mod clar starea și rezultatul așteptat.
Sfat: atunci când scrieți o poveste de utilizator pentru inteligența artificială, asigurați-vă că spuneți „generați cel puțin 2 criterii de acceptare în formatul Dat/Când/Atunci pentru fiecare poveste”. Atunci când modelul este forțat să producă repere, lacunele ascunse în cerință devin vizibile.
Pas cu pas: Extragerea cerințelor asistată de AI
Pasul 1 - Colectați intrare brută. Jurnalele de apeluri, e-mailurile, capturile de ecran existente, listele de reclamații. Cu cât este mai multă intrare reală, cu atât mai puțină fabricație.
Pasul 2 — Extrageți primul set de povești. Oferiți informații brute inteligenței artificiale și puneți-o să producă schițe de poveste pentru utilizator. Acest pas nu este o listă completă, ci un prim pas.
Pasul 3 — Adăugați criterii de acceptare. Generați criterii Given/When/Then pentru fiecare poveste. O poveste pentru care nu se pot produce criterii înseamnă de fapt că nu este suficient de definită.
Pasul 4 — Scanarea pentru contradicții și lacune. Întrebați AI „există contradicții, dublări sau situații nedefinite între aceste cerințe?” Întrebați și verificați. Filtrați rezultatul ca om.
Pasul 5 — Prioritizează și confirmă. Prioritizează poveștile cu părțile interesate pe baza valorii afacerii și a urgenței. Decizia de prioritate aparține unității de afaceri, nu AI.
Nu uitați de cerințele nefuncționale
Majoritatea proiectelor au dificultăți în domeniu pentru că le uită pe cele nefuncționale în timp ce scriu cerințele funcționale. Un raport poate funcționa „corect”, dar dacă este nevoie de 45 de secunde pentru a se deschide, nimeni nu îl va folosi. Următorul tabel prezintă tipuri de cerințe nefuncționale neglijate în mod obișnuit și exemple de scriere măsurabile.
Gen
proasta expresie
expresie măsurabilă
Performanță
„Trebuie să fie rapid”
„Răspunsul la interogare < 2 secunde la încărcare medie”
accesibilitate
„Toată lumea ar trebui să-l poată folosi”
„Compatibil cu WCAG 2.1 AA; navigare completă de la tastatură”
Securitate
„Ar trebui să fie în siguranță”
„Datele personale sunt criptate în repaus; accesul se bazează pe rol”
disponibilitate
„Ar trebui să fie ușor”
„Utilizatorul nou finalizează comanda în 3 pași fără instruire”
Disponibilitate/continuitate
„Nu ar trebui să se prăbușească”
„Timp de funcționare lunar ≥ 99,5%”
Trei mini carcase: după cifre
Cazul 1 — Prețul unei nevoi nemăsurabile. Ecranul, care a fost dezvoltat într-o bancă cu cerința ca „ecranul de raport să se deschidă rapid”, s-a deschis în 22 de secunde sub sarcină de câmp. Dezvoltatorul a crezut că furnizează cuvântul „rapid” în mediul său (2 secunde). Dacă cerința ar fi fost scrisă ca „< 3 sec la ora de vârf, debit real”, problema ar fi fost surprinsă în timpul testării. Reamenajarea a costat 3 săptămâni și cost suplimentar măsurabil.
Cazul 2 — Decalajul capturat de criteriile de acceptare. În timp ce scria criteriile de acceptare pentru povestea „sistemul aplică reduceri” într-un proiect de comerț electronic, partea interesată a observat că nu s-a discutat deloc ce s-ar întâmpla dacă reducerea ar fi în conflict cu cuponul și reducerea VIP. O singură întrebare Given/When/Then a prevenit eroarea dublei reduceri înainte de lansare; Această eroare a cauzat pierderi serioase de venituri în proiecte similare.
Cazul 3 – Regula creată de AI. Într-un proiect de resurse umane, AI a adăugat propoziția „cererea de concediu este aprobată automat în 24 de ore” în proiectul de cerințe. Nu s-a discutat o astfel de aprobare automată în ședință; Modelul inventase o regulă care părea „rezonabilă”. Lângă fiecare cerință, expertul scrie „sursa: ce interviu/document?” Adăugând rubrica, a eliminat 4 propoziții fără sursă.
Solicitare slabă / Solicitare puternică
Prompt slab:
Scrieți poveștile utilizatorilor pentru acest proiect.
Solicitare puternică:
Rolul dvs.: Sunteți analist de afaceri MIS. Extrageți poveștile utilizatorilor din nota de interviu de mai jos. Reguli:- Format: „Ca [rol], pentru [scop], vreau [funcție].”- Scrieți CEL MĂRUM 2 criterii de acceptare pentru fiecare poveste în formatul dat/când/atunci. în notă; montaj.- Scrieți cerințe nefuncționale măsurabile (performanță, securitate, accesibilitate) într-o secțiune separată. Notă interviu:[text]
Un prompt puternic impune formatul poveștii, criteriile de acceptare, trasabilitatea sursei și cerințele nefuncționale simultan; Acest lucru facilitează controlul ieșirii.
Patru șabloane copiabile
1) Clarificarea cerințelor:
Examinați cerința de mai jos. Marcați fiecare afirmație care este vagă, incomensurabilă sau deschisă pentru mai multe interpretări și scrieți o întrebare clarificatoare pentru fiecare. Nu inventa răspunsul. Cerință: [text]
2) Scanarea contradicțiilor:
În lista de cerințe de mai jos, găsiți elemente care se contrazic între ele, sunt repetitive sau lasă lacune logice. Raportați fiecare constatare cu numerele articolului și o justificare cu o singură propoziție. Lista: [text]
3) Generarea criteriilor de acceptare:
Scrieți cel puțin 4 criterii de acceptare pentru următoarea poveste de utilizator în format Given/When/Then, inclusiv cazuri limită și excepție. De asemenea, enumerați orice puncte care rămân neclare. Povestea: [text]
4) Descrierea domeniului de aplicare:
Redactați articolele „În domeniul de aplicare” și „În afara domeniului de aplicare” ca un tabel cu două coloane, în conformitate cu următoarele cerințe. Etichetați [CONFIRMARE NECESARĂ] pentru orice articol de care nu sunteți sigur. Cerințe: [text]
Greșeli comune
- Gândirea că soluția este o nevoie. „Adăugați un meniu derulant” este o soluție, nu o cerință. Cerința spune „utilizatorul trebuie să poată selecta țara din lista definită”; Echipa IT proiectează soluția.
- Sari peste cele nefunctionale. Pur și simplu scrieți „ce trebuie să faceți” și uitați „cum să fiți” (viteză, securitate, accesibilitate) este cea mai comună și mai scumpă lacună.
- Folosind adjective incomensurabile. Cuvinte precum „rapid, ușor, sigur, ușor de utilizat” sunt invalide fără un prag.
- Neobservând regula pe care a inventat-o AI. Modelul poate adăuga reguli „rezonabile”, dar nu chiar rostite; Cere resurse pentru fiecare nevoie.
- Lăsând prioritizarea în seama AI. Ceea ce trebuie făcut mai întâi este o decizie de valoare de afaceri; Unitatea de afaceri dă asta.
Atenție: cea mai periculoasă propoziție din analiza cerințelor este „toată lumea știe deja acest lucru”. Ipotezele nespuse nu fac parte din documentație, nu se introduc niciodată în cod și apar pe teren. Întrebați AI „ce se presupune, dar nu este scris în această cerință?” face vizibile aceste presupuneri ascunse.
În concluzie
Analiza cerințelor definește ce ar trebui să facă sistemul într-un mod clar, măsurabil și urmăribil. Cerințele funcționale descriu postul, cerințele nefuncționale descriu calitățile, iar acestea din urmă sunt adesea uitate. Povestea utilizatorului și criteriile de acceptare Given/When/Then sunt instrumente puternice care elimină incertitudinea. Inteligența artificială accelerează semnificativ producția de storyboard-uri, criteriile de acceptare, detectarea conflictelor și clarificarea întrebărilor; Cu toate acestea, corectitudinea regulii de afaceri, domeniul de aplicare și decizia de prioritate și sursa fiecărei propoziții sunt responsabilitatea omului. Nu finalizați nicio cerință care nu este sursă și nemăsurabilă.
Sarcina de aplicare
Scrieți o cerere de afaceri de un paragraf pentru un „sistem de programare online” imaginar (de exemplu, „Clienții ar trebui să poată face programări online, personalul ar trebui să poată vedea calendare”). (1) Creați cel puțin 5 povești de utilizator și 2 criterii de acceptare pentru fiecare cu o solicitare puternică din această solicitare. (2) Găsiți cel puțin 2 lacune ascunse în criteriile produse de model (de exemplu, numire dublă în același timp, regula de anulare). (3) Includeți cel puțin 3 cerințe nefuncționale într-o formă măsurabilă. (4) Identificați cel puțin 3 elemente ca „În afara domeniului de aplicare”. (5) Marcați o regulă pe care modelul ar fi putut-o fi inventat și scrieți cum ați confirma-o.
lista de verificare
- [ ] Am scris separat cerințele funcționale și nefuncționale.
- [ ] Fiecare cerință este clară, măsurabilă și testabilă.
- [ ] Fiecare poveste are criterii de acceptare Dat/Când/Atunci.
- [ ] Pot urmări sursa (conversația/documentul) fiecărei cerințe.
- [ ] Am marcat posibilele reguli pe care AI le-a alcătuit și le-am lăsat pentru confirmare.
- [ ] Am făcut prioritizarea împreună cu unitatea de afaceri.