La protezione dei dati della carta di credito è considerata un requisito da parte del cliente

Richiami un punto interessante, poiché non vedo che molti documenti relativi ai requisiti contengano cose come:

• L'applicazione deve essere priva di vulnerabilità SQL Injection o
• L'applicazione deve essere priva di vulnerabilità CSRF,

in quanto tale elenco potrebbe effettivamente essere (più o meno) illimitato e la protezione dei numeri di carta di credito con HTTPS è un dettaglio di implementazione.

Detto questo, il requisito probabilmente esiste da qualche parte, anche se è nella forma:

• L'applicazione deve garantire le carte di credito in modo accettabile per le società delle carte di credito.

È un requisito reale verificabile e deve essere documentato da qualche parte. È non un requisito implicito, non più di "L'applicazione deve utilizzare le migliori pratiche durante la codifica" è un requisito implicito, anche se è una buona idea.

Sì, questo è chiaramente un requisito per qualsiasi sito web moderno per fare affari. È dal cliente? Forse sì forse no. I clienti sicuramente vogliono che tu impedisca il furto dei loro dati della carta di credito, ma ci sono certamente storie utente usate per rappresentare il debito tecnico e altre necessità infrastrutturali come questa.

Inoltre odio vedere come i dati della carta di credito sono protetti come parte della storia dell'utente (è un dettaglio di implementazione lasciato agli esperti tecnici), ma in questo caso è relativamente minore.

Un requisito implicito potrebbe essere

You shall not hit my car when I am driving

Ovviamente questo è ovvio, ma è un requisito? Direi che non lo è. Dal momento che la natura di questa affermazione specifica è una verità universale e il fatto che nello skillset di guida questo è previsto come un requisito di un buon guidatore.

Il linguaggio suona sicuramente come potrebbe essere un requisito, ma non è un requisito secondo me. Qualsiasi programmatore o sviluppatore di software dovrebbe essere consapevole dei problemi di sicurezza nel proprio codice proprio come un conducente dovrebbe naturalmente evitare incidenti.

I programmatori di tanto in tanto scrivono codice non sicuro che mette a rischio gli utenti delle informazioni della carta di credito, così come i conducenti di tanto in tanto incorrono in incidenti. Vedo i difetti di sicurezza come un "incidente" o "incompetenza" o entrambi. I loro standard sono pochi e duri quando si parla di sviluppo del software e la sicurezza delle carte di credito è una di quelle in cui non dovrebbero esserci discussioni su come utilizzare le storie degli utenti e le funzionalità delle carte di credito indipendentemente dalla piattaforma linguistica, dalla struttura e dal design.

In sintesi, lo sviluppo di un'adeguata sicurezza con le carte di credito dovrebbe essere preso in considerazione nelle stime di uno sviluppatore come anticipazione conosciuta e conosciuta del lavoro tecnico richiesto per raggiungere infine la storia o il requisito dell'utente.

Penso che tu abbia ragione.

L'emittente / autore della carta di credito è un attore in questo senario. Hai assolutamente bisogno di proteggere / crittografare i dati dei clienti o sarai tagliato fuori dal sistema di pagamento e bloccato con gli ordini postali e paypal.

In una situazione simile non si detraggono le tasse di vendita perché l'utente e il cliente lo richiedono, ma perché lo Stato richiede assolutamente di farlo. In questo caso, l'agenzia di riscossione delle imposte dello Stato dovrebbe essere esplicitamente definita come attore / soggetto interessato con la propria serie di requisiti e condizioni.