Guadagni:
- Capacità di distinguere requisiti funzionali e non funzionali e di scrivere espressioni di requisiti chiare e misurabili con il supporto dell'intelligenza artificiale
- Capacità di utilizzare l'intelligenza artificiale con istruzioni strutturate per estrarre la storia dell'utente, i criteri di accettazione e il limite di portata dalle note dell'intervista
- Abituarsi a verificare che i requisiti generati dall’intelligenza artificiale non presentino ambiguità, contraddizioni e regole mancanti e confermarli con le parti interessate
L’analisi dei requisiti è il compito di definire in modo completo, chiaro e verificabile cosa dovrebbe fare un sistema. È una delle fasi in cui lo specialista MIS produce il massimo valore; perché qui l'errore cresce esponenzialmente alla fine del progetto. Esistono due tipi fondamentali di analisi dei requisiti. Il requisito funzionale descrive il lavoro che il sistema dovrebbe svolgere: "Il sistema dovrebbe inviare un'e-mail al cliente quando conferma l'ordine". I requisiti non funzionali descrivono come dovrebbe essere il sistema: qualità come prestazioni, sicurezza, usabilità e accessibilità. "La schermata del report dovrebbe aprirsi in meno di 2 secondi a carico medio" è un requisito non funzionale.
Un buon requisito ha tre caratteristiche: è chiaro (ha un’unica interpretazione), è misurabile (ha una soglia verificabile) ed è tracciabile (è chiaro da quale esigenza aziendale proviene). "Il sistema deve essere veloce" non soddisfa nessuno di questi; “veloce” è soggettivo, non può essere misurato, non può essere testato. In questa fase, l’intelligenza artificiale è un potente aiuto nella stesura dei requisiti e nel cogliere formulazioni ambigue; ma solo lo stakeholder decide quale regola aziendale è reale.
Storia dell'utente e criteri di accettazione
Un formato comune nella scrittura dei requisiti moderni è la storia dell'utente: "Come [ruolo], per [scopo], voglio [funzionalità]". Esempio: "Come rappresentante di vendita, desidero il calcolo degli sconti dallo schermo del cellulare in modo da poter fare preventivi rapidi sul campo." La storia è breve e orientata al business; Non impone una soluzione tecnica.
Ogni storia dovrebbe avere criteri di accettazione: condizioni verificabili che devono essere soddisfatte affinché la storia sia considerata "ok". Uno schema utilizzato frequentemente è il modello "Dato/Quando/Allora": "Dato: il cliente è nel segmento VIP. Quando: ordini superiori a 10.000 TL. Quindi: il sistema applica uno sconto del 5%". Questo modello elimina l’ambiguità perché collega chiaramente la condizione e il risultato atteso.
Suggerimento: quando scrivi una storia utente per l'intelligenza artificiale, assicurati di dire "genera almeno 2 criteri di accettazione nel formato Dato/Quando/Allora per ogni storia". Quando il modello è costretto a produrre parametri di riferimento, le lacune nascoste nei requisiti diventano visibili.
Passo dopo passo: estrazione dei requisiti assistita dall'intelligenza artificiale
Passaggio 1: raccogliere input grezzi. Registri delle chiamate, e-mail, screenshot esistenti, elenchi di reclami. Maggiore è l’input reale, minore è la fabbricazione.
Passaggio 2: estrai la prima serie di storie. Fornisci input grezzi all'intelligenza artificiale e chiedile di produrre bozze di storie utente. Questo passaggio non è un elenco completo, ma un primo passo.
Passaggio 3: aggiungi criteri di accettazione. Genera criteri dato/quando/allora per ogni storia. Una storia per la quale non è possibile produrre criteri significa in realtà che non è sufficientemente definita.
Passaggio 4: ricerca di contraddizioni e lacune. Chiedi all’AI “ci sono contraddizioni, duplicazioni o situazioni indefinite tra questi requisiti?” Chiedi e fai controllare. Filtra il risultato come un essere umano.
Passaggio 5: assegnare la priorità e confermare. Dare priorità alle storie con le parti interessate in base al valore aziendale e all'urgenza. La decisione prioritaria spetta alla business unit, non all’intelligenza artificiale.
Non dimenticare i requisiti non funzionali
La maggior parte dei progetti hanno difficoltà sul campo perché dimenticano quelli non funzionali mentre scrivono i requisiti funzionali. Un report può funzionare “correttamente”, ma se impiega 45 secondi per aprirsi, nessuno lo utilizzerà. La tabella seguente mostra i tipi di requisiti non funzionali comunemente trascurati ed esempi di scrittura misurabili.
Genere
cattiva espressione
espressione misurabile
Prestazioni
"Devi essere veloce"
"Risposta alla query < 2 secondi con carico medio"
accessibilità
"Tutti dovrebbero poterlo utilizzare"
"Conforme a WCAG 2.1 AA; navigazione completa tramite tastiera"
Sicurezza
"Dovrebbe essere sicuro"
"I dati personali sono crittografati quando sono inattivi; l'accesso è basato sui ruoli"
disponibilità
"Dovrebbe essere facile"
"Il nuovo utente completa l'ordine in 3 passaggi senza formazione"
Disponibilità/continuità
"Non dovrebbe schiantarsi"
"Tempo di attività mensile ≥ 99,5%"
Tre mini custodie: i numeri
Caso 1 – Il prezzo di un bisogno non misurabile. Lo schermo, sviluppato in una banca con il requisito che "lo schermo del report si aprisse rapidamente", si è aperto in 22 secondi sotto carico sul campo. Lo sviluppatore pensava di fornire la parola "veloce" nel suo ambiente (2 secondi). Se il requisito fosse stato scritto come "< 3 secondi nelle ore di punta, produttività effettiva", il problema sarebbe stato rilevato durante i test. La riqualificazione è costata 3 settimane e un costo aggiuntivo misurabile.
Caso 2: gap colto dai criteri di accettazione. Mentre scriveva i criteri di accettazione per la storia del "sistema applica lo sconto" in un progetto di e-commerce, lo stakeholder ha notato che ciò che accadrebbe se lo sconto fosse in conflitto con il coupon e lo sconto VIP non veniva affatto discusso. Una singola domanda Dato/Quando/Allora ha impedito l'errore del doppio sconto prima del go-live; Questo errore ha causato gravi perdite di entrate in progetti simili.
Caso 3: regola creata dall’IA. In un progetto HR, AI ha aggiunto la frase “la richiesta di ferie viene automaticamente approvata entro 24 ore” alla bozza dei requisiti. Durante la riunione non è stata discussa tale approvazione automatica; Il modello aveva inventato una regola che sembrava “ragionevole”. Accanto ad ogni requisito, l’esperto scrive “fonte: quale intervista/documento?” Aggiungendo la colonna, ha rimosso 4 frasi senza fonte.
Prompt debole / Prompt forte
Suggerimento debole:
Scrivi storie di utenti per questo progetto.
Suggerimento potente:
Il tuo ruolo: sei un analista aziendale MIS. Estrai le storie degli utenti dalla nota dell'intervista di seguito. Regole: - Formato: "Come [ruolo], per [scopo], voglio [funzionalità]". - Scrivi ALMENO 2 criteri di accettazione per ogni storia nel formato Dato/Quando/Allora. - Aggiungi una colonna "Fonte" accanto a ciascuna storia: da quale frase proviene? - Etichetta [INCERTO] qualsiasi regola che non sia chiara nella nota; adattamento.- Scrivere i requisiti non funzionali misurabili (prestazioni, sicurezza, accessibilità) in una sezione separata. Nota sull'intervista:[testo]
Il potente prompt applica contemporaneamente il formato della storia, i criteri di accettazione, la tracciabilità della fonte e i requisiti non funzionali; Ciò semplifica il controllo dell'output.
Quattro modelli copiabili
1) Chiarimento dei requisiti:
Esaminare il requisito di seguito. Contrassegna ogni affermazione vaga, incommensurabile o aperta a più di un'interpretazione e scrivi una domanda chiarificatrice per ciascuna. Non inventare la risposta. Requisito: [testo]
2) Scansione delle contraddizioni:
Nell'elenco dei requisiti riportato di seguito, trova gli elementi che si contraddicono tra loro, sono ripetitivi o lasciano lacune logiche. Segnala ogni risultato con i numeri degli articoli e una giustificazione di una frase. Elenco: [testo]
3) Generazione dei criteri di accettazione:
Scrivi almeno 4 criteri di accettazione per la seguente storia utente nel formato Dato/Quando/Allora, inclusi casi limite ed eccezione. Elenca anche i punti che rimangono poco chiari. Storia: [testo]
4) Schema dell'ambito:
Elaborare gli elementi "In ambito" e "Fuori ambito" come tabella a due colonne in base ai seguenti requisiti. Etichetta [CONFERMA RICHIESTA] per qualsiasi articolo di cui non sei sicuro. Requisiti: [testo]
Errori comuni
- Pensare che la soluzione sia una necessità. "Aggiungi un menu a discesa" è una soluzione, non un requisito. Il requisito dice "l'utente deve essere in grado di selezionare il paese dall'elenco definito"; Il team IT progetta la soluzione.
- Tralasciando quelli non funzionali. Scrivere semplicemente “cosa fare” e dimenticare “come essere” (velocità, sicurezza, accessibilità) è la scappatoia più comune e costosa.
- Usare aggettivi incommensurabili. Parole come "veloce, facile, sicuro, facile da usare" non sono valide senza una soglia.
- Non accorgendosi della regola che l’IA ha inventato. Il modello può aggiungere regole “ragionevoli” ma non realmente dette; Richiedi risorse per ogni esigenza.
- Lasciando la priorità all’IA. La prima cosa da fare è una decisione di valore aziendale; La business unit lo dà.
Attenzione: la frase più pericolosa nell'analisi dei requisiti è "questo lo sanno già tutti". Le ipotesi inespresse non entrano nella documentazione, non entrano mai nel codice ed emergono sul campo. Chiedi ad AI “cosa si presume ma non è scritto in questo requisito?” rende visibili questi presupposti nascosti.
In sintesi
L’analisi dei requisiti definisce cosa dovrebbe fare il sistema in modo chiaro, misurabile e tracciabile. I requisiti funzionali descrivono il lavoro, i requisiti non funzionali descrivono le qualità e quest'ultima viene spesso dimenticata. La storia dell'utente e i criteri di accettazione Dato/Quando/Allora sono strumenti potenti che eliminano l'incertezza. L’intelligenza artificiale accelera significativamente la produzione di storyboard, criteri di accettazione, rilevamento dei conflitti e domande di chiarimento; Tuttavia, la responsabilità della responsabilità umana è la correttezza delle regole aziendali, la portata e la decisione prioritaria, nonché la fonte di ogni frase. Non finalizzare alcun requisito privo di fonti e incommensurabile.
Compito dell'applicazione
Scrivi una richiesta commerciale di un paragrafo per un immaginario "sistema di appuntamenti online" (ad esempio, "I clienti dovrebbero essere in grado di fissare appuntamenti online, il personale dovrebbe essere in grado di vedere i calendari"). (1) Crea almeno 5 storie utente e 2 criteri di accettazione per ciascuna con un forte suggerimento da questa richiesta. (2) Trovare almeno 2 lacune nascoste nei criteri prodotti dal modello (ad esempio doppio appuntamento simultaneo, regola di cancellazione). (3) Includere almeno 3 requisiti non funzionali in forma misurabile. (4) Identificare almeno 3 elementi come "Fuori ambito". (5) Segna una regola che il modello potrebbe aver inventato e scrivi come la confermeresti.
lista di controllo
- [ ] Ho scritto separatamente i requisiti funzionali e non funzionali.
- [ ] Ogni requisito è chiaro, misurabile e verificabile.
- [ ] Ogni storia ha criteri di accettazione Dato/Quando/Allora.
- [ ] Posso risalire alla fonte (conversazione/documento) di ogni esigenza.
- [ ] Ho segnato le possibili regole che l'IA aveva inventato e le ho lasciate per conferma.
- [ ] Ho definito le priorità insieme alla business unit.