Solitamente i clienti che commissionano un software lasciano a diversi soggetti la possibilità di presentare delle proposte di realizzazione. Per fare ciò, il cliente è costretto a presentare l’idea del software secondo criteri di astrattezza che consentano agli sviluppatori più libertà nel determinare le soluzioni pratiche per realizzarne gli obiettivi.
Anche nel caso in cui il soggetto sviluppatore sia uno solo, però, questa caratteristica resta immutata. Un software è uno strumento teso alla risoluzione di bisogni per mezzo di specifiche funzioni: definire l’idea iniziale è inevitabilmente un lavoro di astrazione.
E’ per questo che i requisiti di un software, nel percorso di analisi, subiscono una trasformazione da un’identità astratta a una concreta.
Un progetto software comincia con la definizione dello scopo che si vuole soddisfare. Quello che succede dopo è trasformare questa definizione in una serie di funzioni che il prodotto deve possedere. Infine, queste si traducono nei requisiti specifici del software.
La forma dei requisiti
In base al modello di sviluppo software di riferimento, cambiano le modalità con cui si scrivono e rappresentano i requisiti. Le tre fondamentali forme che vengono utilizzate sono: la forma classica, le user story e i casi d’uso.
La forma classica
In questo caso i requisiti del software sono descritti in maniera discorsiva e alquanto generale (es: il software dovrà gestire le prenotazioni online del centro estetico).
La user story
Questa particolare forma di rappresentazione dei requisiti è utilizzata prevalentemente nei modelli di sviluppo agili, di cui parleremo successivamente.
In sostanza, si tratta di trasformare lo scopo astratto del software nella descrizione del punto di vista dell’utente. Avremo quindi una user story quando saranno descritte: il ruolo dell’utente, la motivazione che lo muove e l’output che si aspetta di ricevere.
Esempio
In quanto cliente del centro estetico (ruolo)
Voglio esaminare il calendario degli appuntamenti (motivazione)
Per prenotare il prossimo appuntamento (output atteso)
I casi d’uso
I casi d’uso sono la modalità di scrittura dei requisiti che intendono descrivere le possibili interazioni dell’utente e le rispettive funzioni del software. Per fare questo, gli sviluppatori si riferiscono a quelli che vengono chiamati scenari di interazione, ovvero simulazioni di dialogo tra utente e prodotto.
Esempio
Il cliente richiede la visione del calendario degli appuntamenti
Il software fornisce all’utente la visione del calendario
Il cliente seleziona il giorno e l’orario desiderati
Il software riassume i dati della prenotazione e chiede conferma
Il cliente conferma la prenotazione
Il software notifica l’avvenuta prenotazione
Loomen è un’agenzia di sviluppo, comunicazione e marketing che si occupa dello sviluppo di progetti e della loro comunicazione al pubblico. Realizziamo anche progetti di realizzazione software, dal principio alla conclusione. Con questa rubrica vogliamo mostrare cosa significano queste attività, come le realizziamo e come concepiamo la loro natura.