Requisitos de Segurança

Passo 1Partir da história

A user story e o objetivo de negócio, tal como o produto os escreveu.

PRODUTOComo utilizador, vejo ofertas de parceiros e resgato uma com os meus pontos.

ATALAIABom. Agora, o que nunca deve acontecer nesta história?

Sai da salaHistória: resgatar uma oferta de parceiro

Passo 2Fazer as perguntas não funcionais

Dados, identidade, limites, logging, falhas e abuso.

ATALAIAQuantos resgates por minuto são normais para um utilizador?

PRODUTODois, talvez três. Dez seria um bot.

DEV LEADHoje registamos o código do voucher. Devíamos?

ATALAIARegiste que aconteceu, nunca o código. Um código é dinheiro.

Sai da sala6 perguntas, 6 respostas

Passo 3Escrevê-las como critérios

Critérios de aceitação testáveis, não orientações.

DEV LEADCritério: no máximo 5 resgates por minuto por utilizador, depois um 429.

QATestável. E um caso de abuso: um bot a resgatar a partir de 50 contas.

PROGRAMADORUm evento de auditoria por cada resgate, sem o código do voucher.

Sai da sala6 critérios no ticket

Passo 4Torná-las uma baseline

As mais comuns passam a ser o padrão para cada novo serviço.

ATALAIARate limits, eventos de auditoria e regras de segredos entram na baseline do serviço.

DEV LEADAssim o próximo serviço já começa com elas, e ninguém as volta a discutir.

Sai da salaBaseline: 12 regras para cada serviço