Quali sono alcune buone alternative ai casi d'uso quando il sistema non ha attori?

Gli "attori" possono essere ciò che vuoi che sia l'attore per trasmettere le informazioni che stai cercando di comunicare. Non c'è nulla che richiede ad un "attore" di essere una persona o anche una cosa tangibile. Un "attore" può semplicemente essere un concetto se trasmette le informazioni in modo efficace.

Il criterio più importante per identificare gli attori è ciò che innesca un'azione a livello di astrazione in cui si desidera definire i casi d'uso. Se il "trigger-er" può essere identificato, allora è un candidato legittimo per essere un "attore". Il "trigger-er" può essere una persona, può essere un sensore, può essere qualsiasi cosa, può anche essere il tempo. Ci sono persino casi in cui potresti non voler nemmeno essere molto specifico nell'identificare un attore per un caso d'uso perché potresti non sapere o potresti avere una moltitudine di opzioni tra cui scegliere.

La maggior parte delle persone ha la percezione errata che un "attore" debba essere qualcosa di esterno al sistema. Questo è assolutamente falso. Non esiste qualcosa che sia "esterno" al tuo sistema se deve interagire con il tuo sistema. OGNI "attore" in OGNI caso d'uso che io abbia mai progettato e implementato ha richiesto un'implementazione dell'interfaccia che rappresentasse l'attore. Solo perché un attore si presenta come esterno nel diagramma del caso d'uso, non significa che non dovrai scrivere codice / build hardware che implementa l'interfaccia per quell'utente. In altre parole, solo perché l'attore è modellato come esterno al sistema non significa che non facciano parte del sistema. In effetti, quasi certamente non vuoi che le interfacce per l'attore vengano descritte dai casi d'uso in quanto ciò tende a trasformare i tuoi casi d'uso in romanzi.

In sintesi, sostengo che la tua affermazione che non ci sono attori non è corretta. Invece, sembra solo così a causa del tuo fraintendimento dello scopo degli attori nel contesto dei casi d'uso. Identifica ciò che attiva le azioni nel tuo sistema, dai loro un nome significativo e rappresentativo e le probabilità sono piuttosto buone che faranno scelte abbastanza decenti per essere attori.

Il tuo sistema potrebbe svolgere le sue attività in modo autonomo, ma sarà comunque vero che tali attività vengono eseguite per raggiungere un obiettivo a vantaggio di qualcuno.

Se il tuo sistema non fornisce alcun vantaggio, nessuno lo userebbe / lo comprerebbe (tranne forse per curiosità). Se riesci ad articolare questi benefici e chi ne beneficia, allora è possibile scrivere storie di utenti. I casi d'uso sono meno adatti ai sistemi autonomi, perché i casi d'uso sono più focalizzati sull'interazione dell'utente.

Ad esempio, se hai un sistema per riscaldare la tua casa, allora una possibile user story potrebbe essere:

As a resident, I want the heating system to start heating my house if the actual temperature drops more than 1 degree below the desired temperature, so that I am comfortable in my house.

Qui c'è un chiaro vantaggio per l'utente (una casa constrongvole) e il sistema dovrebbe anche fornire quel vantaggio senza che l'utente debba intraprendere azioni esplicite.

I casi d'uso e le storie degli utenti sono un metodo per acquisire i requisiti. Esistono altri modi per catturare i requisiti, dalle dichiarazioni in stile "shall" a vari modelli tabulari o grafici. Entrare in tutte le opzioni su come ottenere, acquisire, analizzare e gestire i requisiti va oltre lo scopo di una singola risposta qui, quindi vorrei dare un'occhiata ad alcune altre domande su requisiti , o posso anche raccomandare di leggere Karl Wiegers e Joy Beatty's Requisiti software (3rd Edition) e Joy Beatty e Anthony Chen's Visual Models per i requisiti del software per ulteriori informazioni.

Per quanto riguarda Scrum, le guide di Scrum non richiedono l'utilizzo di metodi particolari per l'acquisizione requisiti. Il requisito è che tu mantenga un Product Backlog che sia una lista ordinata prioritaria del lavoro che devi farlo Si raffina questo arretrato, si aggiungono dipendenze tra gli elementi di lavoro e si stima il lavoro. Sprint Backlog è un sottoinsieme di elementi del Product Backlog su cui stai lavorando nell'attuale iterazione. Sebbene sia vero che molte persone usano le storie degli utenti come elementi negli arretrati, non è chiamato come regola di Scrum.

Tutto ciò che hai identificato è che i diagrammi dei casi d'uso sono inadatto qui . Senza conoscere i dettagli del tuo sistema, è piuttosto difficile da consigliare.

Sebbene UML abbia molti diagrammi, raramente vedo un sistema modellato con qualcosa di diverso da questi 3:

• Usa il diagramma del caso
• Diagramma di sequenza
• Diagramma classi

Forse vedi se questi ultimi 2 sono adatti per te.

Questo ovviamente presuppone che tu voglia continuare con UML. Come altri hanno affermato, c'è una miriade di possibili metodi per ottenere lo stesso.

NB. tu menzioni Agile / Scrum ma questo ha davvero poco significato qui.