Não é uma diferença entre requisitos (métodos prescritivos) e estórias (métodos ágeis):
Escolha uma: Métodos ágeis não utilizam UML, que é uma linguagem de modelagem usada em métodos tradicionais prescritivos. Estórias representam intenções negociáveis e não requisitos detalhados. São curtas, fáceis de ler e compreensíveis a todos os envolvidos em contraposição a uma especificação de requisitos detalhada. Estórias são detalhadas quando necessário e não no início de um projeto ou fase.
O item que representa o formato de escrita de estórias de usuário é:
Escolha uma: O sistema deve executar <ação>. O sistema deve executar <ação> em <restrição de tempo>. Como um <papel>, eu posso/devo <ação> para que <valor para o negócio>. O sistema deve permitir a <ator> realizar <ação>.
A afirmação que não representa responsabilidades do Product Owner é:
Escolha uma: Product Owner deve se envolver com os colegas de equipe. Product Owner é responsável por fazer com que toda a equipe adote corretamente a metodologia Scrum. Product Owner deve estar envolvido nas atividades de planejamento do release. Product Owner deve ser responsável por escrever e priorizar os itens do Product Backlog.
Sobre elementos de um processo tradicional, é correto afirmar que
Escolha uma: uma fase é definida para fins de controle gerencial. A fase é um elemento de uma iteração. processos podem ter listas de conferência, ou checklists, para apoiar a verificação das atividades realizadas. Em um processo tradicionais, deve haver checklists para todas as atividades e artefatos previstos. o ciclo de vida é o coração de um processo, pois define como as atividades são executadas e relacionadas. A definição de um ciclo de vida ocorre somente em processos prescritivos. a execução das atividades consome e/ou gera artefatos. Artefatos podem ser definidos como documentos, modelos, planos, relatórios ou qualquer item produzido em uma atividade.
Considere que
I. para cada cliente deve ser aplicado um identificador único.
II. o tempo de resposta entre a requisição e a informação não pode exceder a 2m.
III. clientes têm filiais que devem "carregar", na base de dados, o identificador do cliente principal.
IV. o sistema não deve ferir as leis de proteção ambiental.
São requisitos não funcionais os que constam em
Escolha uma: I e II, apenas. II e III, apenas. II e IV, apenas. I, III e IV, apenas.
conforme a imagem escolha uma : especificação de requisitos. documentos de requisitos. elicitação e análise de requisitos. validação de requisitos.
Considere as características abaixo:
I) Há um levantamento dinâmico de ideias. Nenhuma ideia é descartada inicialmente.
II) Possui uma fase de geração de ideias e outra de consolidação dessas ideias.
III) Incentiva a participação de todos os envolvidos.
A que técnica de elicitação de requisitos as características acima correspondem?
Escolha uma: Entrevista. Brainstorming. Questionário. Prototipagem.
Sobre a realização de entrevistas como técnica de elicitação de requisitos, é incorreto afirmar que
Escolha uma: entrevistador não deve assumir postura crítica ou julgar o entrevistado. entrevistador não deve se preocupar em fazer perguntas aparentemente bobas ou sem sentido. deve-se procurar entrevistas todos os tipos de envolvidos. abordagem da entrevista normalmente vai do mais específico para o mais genérico.
Sobre priorização e negociação de requisitos, é incorreto afirmar que
Escolha uma: a priorização consiste no exame dos requisitos coletados e negociação com os stakeholders, caso haja requisitos ou condições conflitantes. pode envolver uma escolha consciente entre funcionalidades, tempo, recursos e riscos. normalmente os desenvolvedores são envolvidos para avaliar a complexidade dos requisitos, pois requisitos muito complexos provavelmente serão excluídos. pode ser realizada por meio de categorização de requisitos.
Sobre requisitos, é incorreto afirmar que
Escolha uma: o custo de remoção de defeitos tende a aumentar de maneira exponencial na medida em que o ciclo de desenvolvimento de software ocorre no tempo. pode-se afirmar que a maioria dos erros de um software tem sua origem durante sua codificação. erros em requisitos podem acarretar diversos problemas tais como atrasos nas entregas, baixa qualidade dos produtos e aumento da carga de trabalho da equipe de desenvolvimento. requisitos incompletos tendem a ser uma das principais causas de problemas relacionados a requisitos.
Sobre o Diagrama de Casos de Uso e a UML, é correto afirmar que
Escolha uma: um ator é algo ou alguém com algum comportamento, tal como uma pessoa (identificada por um papel), um sistema de computador, ou uma organização. o diagrama de casos de uso determina a relação entre os atores e os requisitos funcionais do sistema, substituindo a representação textual dos casos de uso. um diagrama de contexto mostra a relação dos componentes internos do sistema chegando ao nível de pacote e componentes. casos de uso são representações em baixo nível das funções que um ator deseja executar no sistema, incluindo a forma de representação dos atributos e operadores necessários a esta execução.
No que ser refere a Atores, é incorreto afirmar que
Escolha uma: ator é uma entidade que interage com o sistema com o objetivo de completar um evento. ator é sempre uma entidade externa que interage com o sistema. atores não são exibidos normalmente em um diagrama de contexto. pessoas, organizações, outros sistemas e dispositivos podem ser classificados normalmente como Atores.
Sobre pré-condições de um caso de uso, é correto afirmar que
Escolha uma: pré-condições são obrigatórias e devem ser documentadas em todos os casos de uso. pré-condições representam condições que devem ser verdadeiras antes da execução do caso de uso. pré-condições documentam o objetivo de um caso de uso. pré-condições documentam verificações que devem ser realizadas dentro do fluxo principal de um caso de uso.
Sobre o fluxo principal em um caso de uso, é incorreto afirmar que
Escolha uma: existe um e somente um fluxo principal em um caso de uso. a partir do fluxo principal, um ou mais fluxos alternativos podem ser acionados. o fluxo principal é o primeiro fluxo a ser acionado no caso de uso. o fluxo principal, antes de ser concluído, precisa acionar ao menos um fluxo alternativo do caso de uso.
Qual sentença a seguir provavelmente não poderia ser vista em um caso de uso de acordo com as regras de escrita esperadas?
Escolha uma: O caso de uso se inicia com a solicitação do usuário para abertura de uma conta. O sistema calcula o saldo devedor do cliente atual. O usuário clica no botão “Reservar”. O sistema emite o recibo para o operador.
Sobre a documentação de mensagens aos usuários, é incorreto afirmar que
Escolha uma: podem ser documentadas em uma seção específica de um caso de uso ou no documento de Especificação de Requisitos de Software. devem ser definidas pela equipe de desenvolvedores. são referenciadas nos passos dos fluxos dos casos de uso ou em regras de negócio. devem possuir um código único que permite sua referência e identificação.
A classe ContaBancaria (CB) especializa as classes ItemSuportado (IS) e ItemSujeitoAJuros (ISJ) e generaliza as classes ContaCorrente (CC) e Poupança (PP). Nesse sentido, é correto afirmar que ocorre
Escolha uma: herança múltipla de CB em relação a IS e ISJ. herança múltipla de CB em relação a CC e PP. relação de dependência entre CC e PP. relação de dependência entre IS e ISJ.
Considere a figura a seguir:
Na UML, a figura corresponde ao diagrama de
Escolha uma: Casos de uso. Estado. Atividades. Objeto.
Considere o diagrama de classes apresentado abaixo e analise as afirmações abaixo:
I) Um objeto do tipo departamento pode não estar associado a nenhum objeto do tipo PessoaFisica.
II) A multiplicidade do relacionamento entre Departamento e PessoaFisica é de um para muitos.
III) Um Departamento está associado a muitas instâncias da classe PessoaFisica enquanto um objeto do tipo PessoaFisica está associado a um e somente um Departamento.
Das afirmações acima,
Escolha uma: somente a afirmação I é verdadeira. somente a afirmação III é verdadeira. somente as afirmações I e III são verdadeiras. somente as afirmações II e III são verdadeiras.
Seja o Diagrama.
Com base no diagrama é incorreto afirmar que
Escolha uma: o diagrama exibido é um diagrama de atividades. após a atividade “Recebe pedido”, duas atividades são disparadas. o diagrama não apresenta um nodo inicial. a atividade “Envia pedido” pode ser executada logo após a conclusão da atividade “Obtém livros do inventário”.
Não corresponde a uma responsabilidade típica de uma classe de controle:
Escolha uma: Realizar monitorações, a fim de responder a eventos externos ao sistema. Notificar aos atores do resultado de interações entre os objetos internos. Assegurar que as regras do negócio estão sendo seguidas corretamente. Manter valores acumulados, temporários ou derivados durante a realização de um caso de uso.
Não representa estereótipos definidos pela WAE:
Escolha uma: <<server page>> <<redirect>> <<control>> <<submit>>.
Não corresponde a uma responsabilidade típica de uma classe de controle:
Escolha uma: Realizar monitorações, a fim de responder a eventos externos ao sistema. Notificar aos atores do resultado de interações entre os objetos internos. Assegurar que as regras do negócio estão sendo seguidas corretamente. Manter valores acumulados, temporários ou derivados durante a realização de um caso de uso.
Considere as afirmações abaixo:
I - Requisitos funcionais especificam ações que um sistema deve executar sem levar em considerações restrições físicas enquanto requisitos não funcionais descrevem restrições desejáveis ou necessárias, como, por exemplo, relacionados a desempenho ou usabilidade.
II - Requisitos do sistema expressam resultados desejados para superar problemas reais, descrevem o problema enfrentado pelo cliente e as características desejáveis de uma solução, enquanto requisitos do cliente descrevem o comportamento de um sistema apresentado como solução para o problema do cliente e delimitam as interfaces de um sistema que soluciona o problema.
III - Requisitos devem ser especificados antes de se tentar construir o produto ou um módulo seu. Caso isso não aconteça, clientes e usuários finais podem não ficar satisfeitos, além de poder haver atraso e custos além dos previstos.
Das afirmações acima,
Escolha uma: apenas I é verdadeira. apenas III é verdadeira. apenas I e II são verdadeiras. apenas I e III são verdadeiras.
Considere as afirmações:
I) A elicitação de requisitos consiste na busca pró-ativa da obtenção dos requisitos a partir das fontes, considerando as necessidades, expectativas e restrições impostas pelo cliente. A atividade se inicia aplicando técnicas apropriadas para identificar requisitos do cliente, considerando as necessidades, expectativas e restrições impostas pelo cliente.
II) A modelagem dos requisitos consiste na criação da evidência documental da elicitação e análise dos requisitos por meio da aplicação de modelagem dos requisitos e outros tipos de documentação, buscando melhor entendimento e comunicação.
III) Na análise e negociação de requisitos tenta-se convencer o usuário ou cliente de que existem requisitos não necessários e de que esses requisitos devem ser cortados do escopo do projeto.
Das afirmações acima,
Escolha uma: apenas I é verdadeira. apenas III é verdadeira. apenas I e II são verdadeiras. apenas I e III são verdadeiras.
Considere os requisitos:
I. Os valores das faturas devem ser totalizados por cliente e por data de vencimento igual à fornecida pela área de contas a pagar.
II. O software deve ser processável tanto em alta quanto em baixa plataforma.
III. A data de vencimento constante dos boletos de pagamento deve ser igual à data de registro de entrada do documento no cadastro, mais 30 dias corridos.
Exemplo de requisito não funcional consta APENAS em
Escolha uma: I. II. III. I e II.
Qual a vantagem de utilizar questionários para a elicitação de requisitos?
Escolha uma: É possível contar com um alto número de participantes e resultados estatisticamente relevantes podem ser encontrados. Questionários permitem validar o entendimento dos participantes sobre requisitos levantados Questionários levantam muita informação em pouco tempo Todos os itens acima (a, b, c).
De acordo com as dicas e boas práticas de escrita de requisitos, selecione o requisito que não apresenta vícios em sua escrita.
Escolha uma: O sistema deve apresentar arquitetura robusta. O sistema será utilizado normalmente por até 100 usuários. O sistema deve permitir a importação dos dados cadastrais de 2 milhões de usuários em até 4 horas entre 00:00 e 06:00. O sistema executa em qualquer plataforma e é atualizável para qualquer futura versão de qualquer sistema operacional.
São todas características de um subfluxo em um caso de uso, EXCETO:
Escolha uma: Um subfluxo corresponde a um trecho de fluxo que pode ser reutilizado por vários fluxos de um mesmo caso de uso. Necessita que uma pré-condição seja verdadeira para seu acionamento. Pode ser criado para substituir descrições mais extensas que o necessário ou que se repetem em diferentes fluxos de um mesmo caso de uso. Seu acionamento se dá pela escrita de um passo que representa o que o subfluxo faz em sua essência.
A distinção entre os tipos de requisitos não é tão clara quanto podem sugerir as definições de requisitos funcionais e não funcionais. Mesmo assim, podem-se definir requisitos não funcionais como sendo restrições aos serviços ou funções oferecidos pelo sistema. Muitas vezes, aplicam-se ao sistema como um todo.
SOMMERVILLE, I. Engenharia de Software. 9a ed., Pearson, 2011, pp 59 (adaptado).
Com base nesta definição, assinale o item alternativa que representa um exemplo de requisito não funcional: O usuário do sistema deve poder realizar um tour virtual pelos espaços do Cine Theatro Brasil. O usuário deve ser capaz de concluir o registro de uma estória em no máximo 3 cliques do mouse. O sistema deve permitir ao Administrador classificar as estórias cadastradas em ordem da mais recente para a mais antiga. Ao final do dia, o sistema deve gerar um relatório com o resumo de todas as estórias cadastradas no dia e enviá-lo por e-mail ao Administrado.
Casos de uso são documentados por um diagrama de casos de uso de alto nível. O conjunto de casos de uso representa todas as possíveis interações que serão descritas nos requisitos do sistema.
Um diagrama de casos de uso pode conter alguns elementos específicos.
SOMMERVILLE, I. Engenharia de Software. 9a ed., Pearson, 2011, pp 74 (adaptado).
Sejam as descrições de elementos de um diagrama de casos de uso a seguir:
I. Podem ser pessoas ou outros sistemas. São representados como figuras “palito”.
II. Fazem a ligação entre atores e casos de uso.
III. São representados por elipses e identificam interações entre o sistema e seus usuários ou outros sistemas.
Assinale a alternativa que representa a sequência correta das definições dos itens I, II e III (nesta ordem): Atores, generalização, classes. Usuários, associações, casos de uso. Usuários, relacionamento de inclusão, contexto Atores, associações, casos de uso.
As técnicas de elicitação de requisitos surgiram para auxiliar na identificação dos requisitos junto aos usuários. Uma técnica de elicitação deve explorar características específicas do problema sendo tratado no desenvolvimento de um sistema. Como as características dos problemas variam, é necessário um repertório de métodos para cada classe de problemas (Belgamo e Martins, 2000). Belgamo, A.; Martins, L. E. G (2000). “Estudo Comparativo sobre as Técnicas de Elicitação de Requisitos do Software”. In: XX Congresso Brasileiro da Sociedade Brasileira de Computação (SBC), Curitiba – Paraná.
Sejam as características de técnicas de elicitação de requisitos apresentadas a seguir:
I. São reuniões com participação dos desenvolvedores, usuários e outros interessados para
definição de requisitos de um sistema em conjunto. Visa reunir autoridades representativas e gerenciais para promover decisões. Sua aplicação é recomendada quando a necessidade de consenso entre os usuários do sistema se torna fator importante para o desenvolvimento do software. O objetivo dessa técnica é garantir que os usuários se mantenham comprometidos com o levantamento dos requisitos do sistema.
II. Um grupo de pessoas é reunido, um cenário simulado e um assunto discutido para elicitar os requisitos. As pessoas participantes devem se sentir confortáveis o bastante para discutir o assunto sem se sentirem intimidadas. Nenhuma ideia é descartada. Todas as ideias são boas ideias.
III. É muito utilizado quando os analistas identificam a necessidade de coletar informações de muitos usuários ao mesmo tempo.
Assinale a alternativa que representa a sequência correta das definições dos itens I, II e III (nesta ordem): Reunião de equipe, Oficina de Requisitos (JAD), Grupo Nominal. Oficina de Requisitos (JAD), Entrevista, Mapa Mental Oficina de Requisitos (JAD), Brainstorming, Questionário; Reunião de apresentação, Delphi, Engenharia reversa.
Com base no diagrama, é correto afirmar: O tipo de relacionamento entre as classes Pedido e Item_Pedido é chamado de Agregação e representa um relacionamento do tipo “parte-todo”. Esse diagrama apresenta um relacionamento do tipo Composição, do tipo “parte-todo”, no qual a “parte” não pode existir sem o “todo”. Todo cliente possui relacionado a ele necessariamente um pedido. Não está representado, nesse diagrama, nenhum relacionamento do tipo especialização.
Considere as seguintes responsabilidades relacionadas ao desenvolvimento ágil de software:
I. Definir um objetivo e modelar a visão do produto.
II. Redigir requisitos e definir prioridades.
III. Remover obstáculos rapidamente.
IV. Definir e priorizar o backlog do produto (lista de pendências).
V. Garantir que a equipe trabalhe bem em conjunto.
Assinale a alternativa que representa as atividades cuja responsabilidade é tipicamente atribuída
ao Dono do Produto (Product Owner): I, II e III. I, II e IV. II, III e V. II, IV e V.
Cada caso de uso deve incluir detalhes sobre o que deve ser feito para alcançar sua funcionalidade. Deve-se considerar a funcionalidade básica, quaisquer alternativas, condições de erro, qualquer coisa que deve ser verdadeira antes de se começar o caso de uso e qualquer coisa que deve ser verdadeira ao se sair do caso de uso.
SCHNEIDER, G; WINTERS, J. P. Applying use cases – A practical guide. 2a ed., Addison-Wesley, 2001, pp 27 (traduzido).
Sobre os elementos do detalhamento de um caso de uso, pode-se afirmar: A pré-condição determina em qual estado o sistema deve estar antes do início do caso de uso enquanto a pós-condição representa o estado em que o sistema deve estar no término do caso de uso caso nenhum caminho alternativo tenha sido tomado na execução do caso de uso. Um fluxo de eventos é um conjunto de declarações listando os passos de um caso de uso sob a perspectiva de um ator. É uma boa prática que passos que descrevem ações realizadas por um ator humano sejam descritas na voz ativa, enquanto passos representando ações realizadas pelo próprio sistema são descritas na voz passiva. Um fluxo alternativo permite uma sequência diferente de eventos da prevista no fluxo principal. Condições de erro podem ser descritas por meio de fluxos alternativos, mas esse tipo de fluxo não é adequado para representar ações que podem acontecer a qualquer momento, como o cancelamento de uma transação. Um fluxo de um caso de uso pode ser representado por meio de uma lista ordenada de passos. O início do fluxo principal de um caso de uso pode ser descrito por meio de um passo como “O caso de uso se inicia com <determinada ação>” e termina com um passo do tipo “O caso de uso é encerrado”.
Considere a tabela e as afirmações realizadas a seguir:
I. A tabela representa uma matriz de rastreabilidade de requisitos de um sistema. A rastreabilidade pode ser definida como o grau em que um relacionamento pode ser estabelecido entre dois ou mais produtos de desenvolvimento de software. Nesse exemplo, a rastreabilidade se dá entre requisitos de um produto.
II. A rastreabilidade mostrada nessa tabela pode ser classificada como bidirecional, pois a rastreabilidade é estabelecida de um requisito fonte a outro destino, assim como do requisito
destino para o requisito fonte.
III. É adequado que essa matriz seja consultada durante um processo de análise de solicitação de mudanças, uma vez que ela auxilia a definir os requisitos possivelmente impactados por uma solicitação de mudança e, consequentemente, apoia a avaliação do impacto dessa alteração.
Das afirmativas acima, apenas uma está correta. apenas I e II estão corretas. apenas I e III estão corretas. todas estão corretas.
Uma estória de usuário descreve funcionalidade de valor para um usuário ou comprador de um software. Estórias de usuário são compostas de três aspectos:
Uma descrição escrita da estória usada para planejamento e lembrete do que deve ser feito.
Conversações sobre a estória que servem para destacar os detalhes da estória;
Testes que documentam detalhes e podem ser usados para determinar se a estória está completa.
COHN, M. User stories applied for agile software development. 1a ed., Addison-Wesley, 2004, pp 4 (traduzido).
Considerando essas características de uma estória de usuário, é incorreto afirmar: O uso de estórias de usuário traz benefícios ao projeto, pois enfatiza a comunicação escrita e detalhada dos requisitos, pode ser igualmente compreendido por todos os envolvidos (clientes e desenvolvedores) e funciona bem em um processo de desenvolvimento iterativo. Um cartão de estória contém uma descrição curta de uma funcionalidade de valor para o usuário. Existe um formato sugerido de escrita geralmente para as estórias de usuário que contempla a seguinte estrutura: “Como um <papel>, eu posso/devo <ação> para que <valor para o negócio>”. O cartão de estória é a parte visível da estória, mas o importante são as conversações entre o cliente e desenvolvedores sobre a estória. A conversação pode gerar outros tipos de documentação que a equipe considerar necessária, mas não há exigências de qualquer tipo de documento específico nos métodos ágeis. Testes de aceitação validam que uma estória foi desenvolvida com a funcionalidade que o cliente tinha em mente quando escreveu a estória. Normalmente, os critérios de aceitação podem ser escritos no verso dos cartões de estórias de usuário.
Um modelo completo de classes não possui somente classes persistentes ou classes que representam entidades do mundo real. São necessárias classes de diferentes tipos para realizar toda a colaboração necessária e entregar algo de valor para o usuário. Podem ser associados estereótipos predefinidos às classes identificadas: os estereótipos de <<fronteira>>, <<entidade>> e <<controle>> são usados para definir responsabilidades das classes de um modelo.
Considerando esse contexto, analise se as seguintes afirmações são verdadeiras ou falsas:
I. Estereótipos são elementos que permitem a definição de novos tipos de elementos na UML. São considerados um mecanismo de extensão, pois pelo fato de a UML ser uma linguagem padronizada, não é possível criar novos elementos, mas por meio dos estereótipos, é possível definir novos tipos de elementos.
II. Objetos de entidade normalmente participam de vários casos de uso e têm um ciclo de vida longo. Realizar cálculos simples, normalmente com a colaboração de outros objetos de entidade associados através de agregações, pode ser considerado uma responsabilidade desse tipo de objeto.
III. Objetos de controle traduzem os eventos gerados por um ator em eventos relevantes ao sistema. Também são responsáveis por apresentar os resultados de uma interação dos objetos em algo inteligível pelo ator. Esse tipo de objeto existe para que o sistema se comunique com o mundo exterior.
IV. Os objetos de fronteira controlam a lógica de execução correspondente a um caso de uso. Decidem o que o sistema deve fazer quando um evento externo relevante ocorre. Realizam o controle do processamento de um caso de uso ou conjunto de casos de uso.
A ordem correta da classificação das afirmações acima quanto a sua veracidade é: V, V, V, V. V, V, F, F. F, V, V, F. F, V, F, V.
Considere o fluxo de um caso de uso exibido e as afirmações a seguir:
Fluxo
1. O usuário solicita a aprovação da ordem de venda.
2. O usuário confirma a solicitação clicando no botão “Aprovar”.
3. O sistema persiste os dados.
4. A ordem de venda é aprovada.
5. O caso de uso é encerrado.
Afirmações
I – O passo 2 deste fluxo viola uma boa prática da escrita de casos de uso.
PORQUE
II – Não se deve referenciar elementos de interface nos passos dos fluxos de um caso de uso.
Sobre as asserções acima, é correto dizer: As asserções I e II são proposições verdadeiras, e a segunda é uma justificativa correta da primeira. As asserções I e II são proposições verdadeiras, mas a segunda não é uma justificativa correta da primeira. A asserção I é uma proposição verdadeira, e a asserção II é uma proposição falsa. A asserção I é uma proposição falsa, e a asserção II é uma proposição verdadeira.
De acordo com o SWEBOK, o Desenvolvimento de Requisitos inclui as seguintes etapas: Elicitação de requisitos; Análise e negociação de requisitos; Especificação e Modelagem dos requisitos; e Validação de requisitos.
SOFTEX. Guia de Implementação do MPS.Br Nível D.
Relacione as etapas da primeira coluna com suas definições (segunda coluna): I – W; II – Y; III - Z; IV - X. I – Z; II – X; III - W; IV - Y. I – X; II – Y; III - Z; IV - W. I – W; II – X; III - Z; IV - Y.
|
