Questão de Engenharia de Software — Engenharia de Requisitos — FCC 2026
Engenharia de Software›Engenharia de Requisitos
Código
fc077548
Banca
FCC
Órgão
SEFAZ-SP
Ano
2026
Nível
Superior
Cargo
Auditor Fiscal da Receita Estadual - AFRE - Tecnologia da Informação e Comunicação - Conhecimentos Especificos (P3)
Em um projeto desenvolvido com metodologia ágil, ao descrever uma funcionalidade “Envio de Notificação de Vencimento de Tributo”, a equipe cria a seguinte narrativa: “Como contribuinte, quero receber notificação de vencimento para que eu possa pagar antes da data-limite”. Representa uma boa prática de escrita dessa história de usuário e está em conformidade com conceitos de engenharia de requisitos aquela em que a
Auser story está escrita na perspectiva do usuário final, descrevendo claramente quem, o que e o porquê, sem detalhes técnicos da implementação.
Bhistória inclui no texto quais tabelas do banco de dados serão consultadas para gerar a notificação.
Cuser story especifica o método de envio (e-mail, SMS, push) para garantir clareza.
Dhistória detalha a tecnologia (por exemplo, usar SMTP ou serviço externo) no corpo da user story.
Euser story contém todos os requisitos funcionais e não funcionais, inclusive desempenho, tempo de resposta e segurança.
Revelar gabarito e comentário▾
GabaritoA — user story está escrita na perspectiva do usuário final, descrevendo claramente quem, o que e o porquê, sem detalhes técnicos da implementação.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
User Stories em Metodologias Ágeis
Gabarito: letra A. A alternativa A descreve corretamente a boa prática de escrita de user stories: na perspectiva do usuário final, com os elementos quem, o que e o porquê, sem detalhes técnicos. Esse é o formato padrão recomendado pelo Scrum e pela Engenharia de Requisitos, conforme a literatura (ex.: Mike Cohn, "User Stories Applied").
User story (formato padrão): Quem (persona) (Ex.: contribuinte); O quê (funcionalidade) (Ex.: receber notificação); Por quê (benefício) (Ex.: pagar antes do vencimento); Detalhes técnicos (evitar) (Tabelas de banco, Método de envio (e-mail/SMS), Tecnologia (SMTP), Requisitos não funcionais)
Alternativa A — ✅ Correta ⟵ GABARITO
A user story está redigida sob a ótica do contribuinte (quem), expressa o desejo de receber notificação (o que) e o benefício de pagar antes do vencimento (porquê). Não há menção a implementação técnica, banco de dados, tecnologia ou requisitos não funcionais. Isso está alinhado com o conceito de que user stories são lembretes curtos para conversas posteriores, focando no valor para o usuário.
Alternativa B — ❌ Incorreta
Incluir tabelas do banco de dados é um detalhe técnico de implementação. User stories devem descrever o que o sistema deve fazer do ponto de vista do usuário, não como será construído. Esse detalhamento é feito posteriormente, em tarefas técnicas ou critérios de aceitação.
Alternativa C — ❌ Incorreta
Especificar o método de envio (e-mail, SMS, push) também é um detalhe de implementação. A user story deve se ater ao objetivo do usuário; a decisão sobre o canal pode ser definida em conjunto com o Product Owner durante o refinamento, mas não deve constar no corpo da história.
Alternativa D — ❌ Incorreta
Detalhar tecnologia (SMTP, serviço externo) quebra o princípio de que user stories são escritas na linguagem do negócio, não na linguagem técnica. Detalhes tecnológicos são resolvidos durante o desenvolvimento e devem ser evitados na user story para manter o foco no valor.
Alternativa E — ❌ Incorreta
User stories não devem conter todos os requisitos funcionais e não funcionais. Elas são propositalmente breves para incentivar a comunicação contínua. Requisitos não funcionais (desempenho, segurança) são geralmente capturados como critérios de aceitação ou como histórias técnicas separadas ("technical stories").
PEGA ESSA DICA!
Ao escrever user stories, lembre-se do formato "Como [persona], quero [funcionalidade] para que [benefício]". Evite jargões técnicos e mantenha o foco no valor entregue ao usuário. Detalhes de implementação devem ser tratados em reuniões de planejamento ou em tarefas técnicas.