Engenharia de Software Moderna - Capítulo 3

Request edit access

JavaScript isn't enabled in your browser, so this file can't be opened. Enable and reload.

Engenharia de Software Moderna - Capítulo 3 - Requisitos

Questões disponíveis via uma licença CC-BY-NC. Essa licença permite copiar, distribuir e adaptar as perguntas, sempre para fins não comerciais. Porém, créditos devem ser dados ao livro "Engenharia de Software Moderna".

Sobre o levantamento de requisitos em metodologias ágeis, assinale a alternativa CORRETA. *

1 point

São utilizadas documentações completas.

São utilizados casos de uso.

Diagramas UML são largamente utilizados.

São utilizados pequenos cartões com estórias de usuários.

Estórias de usuários são definidas por 3 Cs: Cartão, Conversa e Caracterização.

A escrita de Estórias de usuários deve ser complementada por comunicação verbal entre desenvolvedores e clientes. Por que há necessidade dessa forma de comunicação? *

1 point

O cliente precisa saber como está a qualidade do código do desenvolvedor.

O desenvolvedor precisa esclarecer detalhes dos requisitos do sistema diretamente com os clientes, em vez de consultar documentos textuais.

É um questão de confiança, pois tanto o programador saberá quem está lhe pagando, como o cliente saberá quem está fazendo seu software.

É um maneira mais iterativa de revisão de código.

Nenhuma das respostas anteriores.

Em um Sistema de Controle de Bibliotecas, podemos definir como requisito não-funcional: *

1 point

O número máximo de livros que um usuário pode pegar emprestado.

O tempo máximo em que a operação de emprestar livro deve ser executada.

O tempo máximo que um usuário pode ficar com um livro emprestado.

O recebimento de e-mail quando o prazo de devolução estiver próximo.

A possibilidade de renovar livros.

Dentre os desafios de Engenharia de Requisitos listados a seguir, qual deles acontece com MAIOR frequência? *

1 point

Falta de acesso às necessidades dos clientes ou a informações do negócio.

Requisitos incompletos ou não-documentados.

Problemas de comunicação entre os membros da equipe.

Stakeholders com dificuldades de separar requisitos de soluções.

Falta de apoio dos clientes.

Sobre Estórias de Usuário, é INCORRETO afirmar que : *

1 point

Uma estória é um conjunto de 3 Cs: cartão, conversas e confirmação.

Uma estória não necessariamente precisa ser uma proposta de agregação de valor para o produto ou negócio, podendo também ser uma estória técnica, como definição de linguagens e bibliotecas.

As estórias devem ser escritas visando satisfazer as demandas de todos os tipos de usuários do sistema.

Deve ser possível estimar o tempo necessário para conclusão da estória.

Estórias devem ser testáveis, isto é, elas devem ter critérios de aceitação objetivos.

Sobre MVPs é INCORRETO afirmar que: *

1 point

O objetivo de um MVP é testar uma hipótese de negócio.

A validação de MVPS é feita em três passos: construir, medir e aprender.

A ideia de MVP é implementar um sistema simples, com um conjunto de requisitos mínimos, mas que sejam suficientes para testar a viabilidade de continuar investindo no seu desenvolvimento.

Um MVP pode ser um software real, implementado em uma linguagem de programação com bancos de dados e integração com outros sistemas.

Quando um MVP falha, deve-se obrigatoriamente realizar um pivô, isto é, abandonar a visão original e tentar um novo MVP, com novos requisitos e para um novo mercado.

Sobre Casos de Uso, é CORRETO afirmar que: *

1 point

São menos detalhados que estórias de usuários.

Um caso de uso não deve fazer referência a outro caso de uso, isto é, eles devem ser auto-contidos..

Casos de uso são documentos textuais e diagramas. Portanto, a modelagem de casos de uso é tanto uma ação de redigir texto quanto de desenhar diagramas.

Casos de uso cumprem o mesmo propósito de pseudo-código, que é definir a implementação em detalhes.

Além das seções nome, ator, fluxo normal e extensões, um caso de uso pode conter seções adicionais, tais como propósito e pré-condições.

Sobre requisitos de software, assinale a opção correta: *

1 point

Requisitos de software devem ser rastreáveis, ou seja, dada uma classe descrita em um documento de especificação de requisitos, verifica-se facilmente sua implementada no código e vice-versa.

INVEST é uma sigla cunhada para recomendar que estórias de usuário sigam padrões acordados com os clientes.

A forma de documentar requisitos mais comum, inclusive na metodologia XP, é a tradicional, por ser consolidada no mercado há muitos anos.

Elicitação de requisitos ocorre ao final do processo de desenvolvimento com o objetivo de validar os requisitos implementados.

Requisitos devem ser documentados de forma subjetiva, pois nem sempre o cliente consegue explicar à equipe de desenvolvimento o que o sistema precisa fazer com clareza.

Clear form

Never submit passwords through Google Forms.

This content is neither created nor endorsed by Google. - Terms of Service - Privacy Policy

Does this form look suspicious? Report

Forms