Quali metodi di sollecitazione dei requisiti sono adatti quando non ho accesso diretto alla base di utenti?

Quando non si ha una comunicazione bidirezionale frequente con i potenziali utenti, diventa più difficile soddisfare i requisiti. La prima cosa che farei è trovare un qualche tipo di esperto di dominio da usare per aiutare a perfezionare e chiarire i requisiti che hai e per rispondere a domande specifiche del dominio che potrebbero emergere nei requisiti e nelle attività di progettazione. Questa persona potrebbe non essere affatto rappresentativa della tua base di utenti, ma almeno sono a conoscenza che puoi usare per prendere decisioni informate in assenza del contatto con l'utente.

Seguendo questo, ci sono una serie di tecniche di elicitazione dei requisiti che è possibile utilizzare per raccogliere effettivamente i requisiti:

• Documentazione. Se questo sistema sta sostituendo un sistema esistente, puoi scoprire cosa fa quel sistema. Se hai creato quel sistema, usa l'intera specifica dei requisiti, se riesci a trovarlo. Se ci sono sistemi concorrenti là fuori, scopri cosa fanno. Questo è probabilmente il modo migliore per determinare i requisiti funzionali e puoi utilizzare alcuni elementi di dati (come la frequenza di occorrenza su più sistemi) per iniziare a dare priorità alla funzionalità nel tuo sistema.
• Richiesta di difetti o di miglioramento. Se hai accesso a un difetto o ad un tracker di miglioramento di un sistema esistente, scopri cosa chiede la gente. Questo ti permetterà di scoprire quali potrebbero essere i problemi, sviluppare una comprensione di ciò che il tuo sistema potrebbe fare e trovare una nicchia nel mercato per la tua applicazione se puoi fornire funzionalità che i tuoi concorrenti non hanno.
• Leggi e regolamenti. Se il sistema è destinato all'implementazione in un ambiente che deve essere conforme a varie leggi o regolamenti, determinare quali sono tali leggi e regolamenti. Questi devono essere catturati come parte dei tuoi requisiti aziendali.
• Sondaggi e questionari. Contatta il maggior numero possibile di utenti potenziali. Scopri di cosa hanno bisogno e cosa vogliono in questo tipo di sistema. Analizza questo per punti in comune. Siate comunque consapevoli dei requisiti in conflitto.

Qualcosa da tenere a mente è che potrebbero esserci diverse classi di potenziali utenti, ciascuno con aspettative diverse. Potrebbe non essere possibile soddisfare pienamente i requisiti di ciascuno. In effetti, alcuni requisiti generati da persone di classi utente diverse potrebbero persino essere in conflitto, il che significa che non puoi effettivamente soddisfarli tutti in una determinata applicazione.

Hai anche taggato questa domanda con il tag agile . Uno degli inquilini dei metodi agili deve essere in grado di rilasciare rapidamente. Se è possibile creare un sistema e trovare i primi utenti per utilizzarlo, è possibile quindi creare il proprio insieme di requisiti del cliente attraverso il proprio sistema di tracciamento dei difetti e dei miglioramenti.

Le due citate risorse per l'ingegneria dei requisiti sono Requisiti software e Ulteriori informazioni sui requisiti software: problemi spinosi e consigli pratici , entrambi scritti da Karl Wiegers. Sebbene non li abbia mai letti, capisco anche che Requisiti software agili: pratiche di requisiti snelli per team, programmi e l'azienda da parte di Dean Leffingwell e Scrivere Casi di utilizzo efficace di Alistair Cockburn sono altamente raccomandati nella comunità agile.

1. Assumi un esperto dal campo: questo ti offrirà una visione di qualcuno che lavora nel dominio. Anche se si tratta di una sola persona, è molto meglio di quanto tu possa immaginare come funziona la contabilità.
2. Trova potenziali clienti clienti e parla con loro - è qui che vendi il dipartimento entra in azione. Possono provare ad uscire e vendere il prodotto ad alcuni dei primi utenti in cambio di preziose informazioni per te.
3. Rilascia una versione con meno funzioni e ascolta ciò che gli utenti vogliono in seguito (fai versioni iterative in stile agile). - Questo è il numero di progetti agili che funzionano. Rilasciano spesso e con aggiornamenti incrementali. Rilasciano con un set limitato di funzionalità e lasciano il prodotto live nel mondo reale. Il feedback di questi molti e ordinari utenti è il più prezioso.

Modifica successiva:

• l'arretrato non dovrebbe essere preparato per l'intera vita del progetto. Questo è impossibile, a meno che tu non stia creando qualcosa di molto semplice.
• lascia che il backlog sia minimo e aggiungilo nel modo

Se la tua azienda è nel mercato di destinazione per un tale prodotto software, puoi diventare il tuo cliente. Vedi "Mangia il tuo cibo per cani" .