Come risolvi le ambiguità nelle specifiche?

Question

Ho bisogno di alcuni consigli su come risolvere le ambiguità all'interno delle specifiche dell'applicazione. Come semplice esempio,

  

Quando un utente non riesce ad autenticarsi dopo un certo numero di volte, invia una notifica all'IT.

Nell'esempio sopra, non è chiaro quante volte "un numero di volte" è. Non è chiaro e non posso semplicemente impostare un limite casuale come 1000 volte.

Come faresti per risolvere porzioni poco chiare in qualsiasi specifica? (non solo quello che ho citato)

E inoltre, che tipo di argomenti dovrei cercare su Google o libri per questo tipo di situazioni? Ingegneria software? Sviluppo agile? Non sono sicuro da dove iniziare.

Eventuali utili conoscenze e suggerimenti sarebbero molto apprezzati.

Answer 1

Se stai monitorando i tuoi requisiti in modo formale, puoi fare i tuoi presupposti e documentarli come requisiti derivati:

Esempio:

Requisiti dell'utente:

Req 1: quando un utente non riesce ad autenticarsi dopo un certo numero di volte, invia una notifica all'IT.

Requisiti derivati:

Req 1.1 Quando un utente non riesce ad autenticarsi dopo tre (3) tentativi, il sistema sospenderà l'account e invierà un'email al desk di supporto IT.

Req 1.1.1 L'email di sospensione dell'account specificherà quanto segue:

• Il nome dell'account dell'utente.
• L'indirizzo IP del computer da cui sono stati effettuati i tentativi di autenticazione.

Avere il cliente o lo stakeholder se il cliente non è disponibile, rivedere e approvare i requisiti derivati.

Per ulteriori informazioni, Google "gestione dei requisiti" o "ingegneria dei requisiti". Il settore dell'industria della difesa è caricato con esempi e modelli, forse troppi;)

Alcuni che ho aggiunto ai segnalibri:

• Guida alla scrittura delle specifiche
• Scrittura delle specifiche dei requisiti software

Answer 2

Rispondi al cliente con le domande esatte che potresti avere. Questa è l'opzione migliore, se disponibile. In caso contrario, renderlo configurabile dall'utente finale (client).

Answer 3

Comunicare con (preferibilmente in questo ordine):

• Analisti aziendali
• Cliente (persona (e) che paga per il prodotto finale)
• Utenti finali

Answer 4

Costruiscilo o prototipalo, quindi mostralo alle persone che hanno scritto le specifiche.

le ambiguità sono molto più facili da chiarire parlando della cosa reale, invece di un pezzo di carta che dice come funzionerà la cosa.

Answer 5

Stai pensando troppo a questo.

1. Il valore "numero di volte" può essere facilmente inserito in web.config
2. Impostalo sul valore appropriato assunto. (non preoccuparti di sbagliare)
3. Invia un'email al tuo manager con il tuo presupposto e come possono cambiarlo se il tuo presupposto non è corretto.

La parte di notifica delle specifiche può essere assunta se ogni altra notifica dell'app è un'e-mail (che non è irrealistica). Altrimenti chiedi prima di fare qualsiasi cosa.

Ovviamente non sono contrario a chiedere chiarimenti. Ma ho scoperto che se si può fare un'ipotesi con svantaggio minimo o nullo , è meglio farlo. Dopo tutto ti hanno assunto per risolvere i problemi e non portarli di più. ;-)

E stranamente; Probabilmente scoprirai che la maggior parte delle tue ipotesi sarà comunque corretta.

Answer 6

Da quell'esempio, vorrei tornare al client e chiedere se vogliono il "numero di volte" essere configurabile. Può anche portare a domande come:

1) Chi manterrà il numero di volte configurato. 2) Avranno bisogno di un'interfaccia utente per visualizzare queste impostazioni e modificarle.

Anche l'adozione di un processo di sviluppo più agile aiuterà. Ad esempio, mostrando loro un esempio che consente tre possibilità di accesso dimostrerà la funzionalità e forse li spingerà a dirti il ??numero.

L'importanza di chiarire i requisiti cambia laddove la risposta alla domanda influenzerà il tempo, la complessità e il costo del progetto.

Answer 7

Ci sono alcuni percorsi diversi che prenderei sulle ambiguità a seconda di chi è disponibile:

1) Project Manager / Business Analyst - > Questi sono probabilmente i più vicini al progetto che potrebbero essere in grado di aiutare a risolvere rapidamente i problemi con le specifiche. Ciò può comportare la richiesta ad altri e la risposta a te più tardi, ma ciò dovrebbe essere accettabile.

2) Specialista Analista / Ufficiale - > Ad esempio, nel caso in cui tu menzioni dove ci sono implicazioni per la sicurezza, se c'è un responsabile della sicurezza che può avere una politica per far valere ciò e dovrebbe essere nella discussione. Un altro esempio potrebbe essere avere un analista di rete per guardare l'architettura da una prospettiva hardware che può essere utile in alcuni casi.

3) Proprietario del prodotto - > Chi è responsabile della definizione della domanda. Nota che questa non è una persona tecnica, quindi essere specifici e avere consigli può essere utile se colpisci un " Sai, non ci ho pensato ... " risposta.

4) Group Manager / Team Lead - > Se tutto il resto fallisce, vai dal capo e chiedi chiarimenti.

" Requisiti Raccolta " oppure " Analisi dei requisiti " sono termini comuni per questa parte del "Ciclo di vita dello sviluppo software" o "ciclo di vita di sviluppo di sistemi" per eliminare qualche altro termine potresti cercare e trovare molti articoli.

Answer 8

Il modo migliore è di scrivere brevi storie utente alternative (casi d'uso) che descrivono come le diverse opzioni influenzerebbero l'utente e chiedere al cliente di scegliere quali devono essere supportate.

Spesso un'ambiguità nelle specifiche riflette l'ambiguità nella mente del cliente: semplicemente non l'hanno ancora capito da soli, quindi questo approccio aiuta entrambi. (Usa note scritte - niente di tecnico - per descrivere le cose nei loro termini.)

Answer 9

Se le specifiche non sono esatte, forse non importa? Non è fondamentale per far funzionare qualcos'altro? Effettua una chiamata, lascia che sia sia 1000. Assicurati che non sia codificato. Una buona idea è quella di metterlo in un file di configurazione (ma non esporlo all'interfaccia dell'utente finale, poiché l'utente di solito ha ancora meno idea di te).

Se è una questione di interoperabilità, allora cosa fanno gli altri ragazzi? è 200 in Windows? Quindi falla 200. Ora abbini sia Windows che le specifiche & nbsp; & # 8212; & nbsp; non male :-)

Nel caso in cui scoprissi che la tua chiamata è stata negativa e avrebbe dovuto essere 1500, almeno puoi dire ai tuoi utenti come risolverlo senza reinstallare il tuo software.

Answer 10

Bene in Corporate Enterprise questo significa che segue le Politiche aziendali generali.

In effetti quando scrivo da solo le specifiche, non mi preoccupo di queste specifiche generali, dico solo che mi riferisco alle politiche e vado direttamente al nucleo dei Requisiti aziendali specifici.

Answer 11

Per questo puoi creare un focus group, oppure puoi comunicare con il cliente / stakeholder appropriato.