Engenharia de Software · FCC · 2016 | Questão sqc-fc028169

Engenharia de SoftwareEngenharia de Requisitos

Código: fc028169
Banca: FCC
Órgão: AL-MS
Ano: 2016
Nível: Médio

Cargo: Técnico de Informática

Um projeto precisa ter seus requisitos listados de forma clara e precisa para evitar que a implementação incorra em erros que afetem o custo do produto. Como resultado de uma técnica de elicitação, foram definidos os seguintes requisitos: I. A interface do sistema deve ser amigável para o usuário. II. O sistema deve ter o melhor desempenho possível. III. O sistema deve ser confiável. Os requisitos I, II e III

Adevem ser substituídos por outros não funcionais mais claros, como I. O usuário não deve dar mais que 3 clicks para acessar uma ajuda; II. O preenchimento do formulário não pode demorar mais que 30 segundos; III. O sistema deve estar 98% do tempo disponível para o usuário.
Bforam obtidos da técnica de levantamento de requisitos Behavior Driven Requirement, que consiste em workshops nos quais os stakeholders se encontram para discutir as características desejadas do produto.
Cjuntos formam um caso de uso e devem compor um diagrama de caso de uso, que documenta o que o usuário faz do ponto de vista do sistema, aprofundando os detalhes técnicos de como o sistema implementa os requisitos.
Dforam obtidos da técnica de levantamento de requisitos JAD, na qual as questões são dirigidas por escrito aos usuários com o objetivo de obter opiniões diferentes nas mesmas questões. As questões são auto-aplicáveis, pois o próprio informante as responde.
Eforam obtidos da técnica de levantamento de requisitos Entrevista que objetiva identificar riscos, impedimentos e priorizar o trabalho de codificação.

Revelar gabarito e comentário

GabaritoA — devem ser substituídos por outros não funcionais mais claros, como I. O usuário não deve dar mais que 3 clicks para acessar uma ajuda; II. O preenchimento do formulário não pode demorar mais que 30 segundos; III. O sistema deve estar 98% do tempo disponível para o usuário.

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”.

Engenharia de Requisitos - Requisitos Não Funcionais

Gabarito: letra A. Requisitos vagos como "interface amigável", "melhor desempenho possível" e "confiável" não são mensuráveis nem verificáveis, devendo ser refinados em requisitos não funcionais claros e específicos, com métricas objetivas. A alternativa A exemplifica corretamente essa transformação, substituindo cada requisito vago por uma versão mensurável (ex.: 3 cliques, 30 segundos, 98% de disponibilidade).

A banca testa o conhecimento sobre a importância da especificação precisa de requisitos não funcionais. Enquanto requisitos funcionais descrevem o que o sistema deve fazer, os não funcionais impõem restrições de qualidade, desempenho, usabilidade, etc. Para serem úteis, esses requisitos precisam ser escritos de forma verificável – caso contrário, não é possível testar se foram atendidos.

Requisito Original (Vago)	Requisito Refinado (Mensurável)	Métrica Objetiva
I. Interface amigável	I. Acesso à ajuda com no máximo 3 cliques	Número de cliques
II. Melhor desempenho possível	II. Preenchimento de formulário em até 30 segundos	Tempo de resposta (segundos)
III. Sistema confiável	III. Disponibilidade de 98% do tempo	Percentual de disponibilidade

Alternativa A — ✅ Correta ⟵ GABARITO

Propõe substituir os requisitos originais (ambíguos) por requisitos não funcionais mensuráveis, como número de cliques, tempo de resposta e percentual de disponibilidade. É exatamente o que a engenharia de requisitos recomenda: requisitos não funcionais devem ser específicos e testáveis.

Alternativa B — ❌ Incorreta

Menciona "Behavior Driven Requirement" como técnica de levantamento – na verdade, o termo correto é Behavior Driven Development (BDD), que é uma metodologia de desenvolvimento, não uma técnica de elicitação. Além disso, a descrição de "workshops" não corresponde ao BDD, e os requisitos apresentados não foram obtidos por essa técnica.

Alternativa C — ❌ Incorreta

Afirma que os três requisitos formam um caso de uso e devem compor um diagrama de caso de uso. Requisitos vagos como esses não constituem um caso de uso; casos de uso descrevem interações específicas entre ator e sistema. Além disso, diagramas de caso de uso não aprofundam detalhes técnicos de implementação.

Alternativa D — ❌ Incorreta

Descreve a técnica JAD (Joint Application Design) como "questões dirigidas por escrito e auto-aplicáveis", o que é falso. JAD é um workshop colaborativo com stakeholders, conduzido por um facilitador. A descrição dada se aproxima mais de um questionário. Também não há relação com os requisitos fornecidos.

Alternativa E — ❌ Incorreta

Diz que a técnica Entrevista "objetiva identificar riscos, impedimentos e priorizar a codificação". Entrevista é uma técnica de elicitação que busca entender as necessidades dos stakeholders, e não tem esse foco restrito em riscos e priorização de codificação. Além disso, os requisitos do enunciado não foram obtidos por entrevista.

PEGA ESSA DICA!

Na hora da prova, lembre-se: requisitos não funcionais devem ser SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Expressões como "amigável", "rápido" ou "confiável" são subjetivas e devem ser refinadas com métricas concretas. Sempre desconfie de requisitos vagos – a banca adora cobrar que eles precisam ser detalhados.

Gabarito: letra A.

Link permanente: /questoes/fc028169