Requisiti di programma ambigui

Se indovini cosa vuole un cliente, fallirai.

I clienti in genere non sanno quello che vogliono. Sanno solo come funziona un processo esistente. Molte volte è il tuo lavoro aiutarli a colmare il divario dal "vecchio modo" al "nuovo e migliorato" modo possibile utilizzando un software per computer (o un nuovo software per computer).

Rispetta ciò che sanno e aiutali a imparare ciò che sai. Allora non fallirai.

Le esercitazioni universitarie / scolastiche sono a volte intenzionalmente vaghe perché mettono alla prova la tua conoscenza dell'argomento e del linguaggio di programmazione. Ad esempio, un esercizio che richiede la connessione a un host remoto potrebbe non specificare che l'applicazione deve supportare sia un nome host sia un indirizzo IP.

Ciò detto, i requisiti nella pratica non sono una cosa monolitica, una tantum. Anche i clienti (ipotetici) che forniscono requisiti dettagliati e privi di ambiguità possono cambiare idea durante lo sviluppo, poiché apprendono di più sulle possibili soluzioni e i requisiti cambiano nel tempo. Punti chiave da considerare:

1. Mantieni una comunicazione aperta tra lo sviluppatore e il cliente. Scrum fa questo attraverso il processo di sprint e il concetto di proprietario del prodotto, per esempio.
2. Rendi disponibili versioni incomplete del prodotto, ad esempio attraverso un programma beta. Ottenere un'applicazione funzionante nelle mani dei clienti ottiene il miglior riscontro possibile.
3. Prendi tempo nella pianificazione per gestire le modifiche ai requisiti. La pianificazione e l'aspettativa sono metà della battaglia.