-
Não há como dizer se é correto ou não. Isso é alternativo!
-
nao encontrei referencias sobre o uso de diagrama de classses e de interacao.(sommerville e pressman)
No capitulo referente a engenharia de requisitos é citado a utilização de casos de uso, sequência e atividades.
-
Acredito que seja falsa. Já pensou os analistas validando requisitos com o cliente usando diagramas de classes? e de interação?
-
Eu optei por FALSA justamente por esse pensamento.
VALIDAÇÃO -> CLIENTE
Imagina eu conversando com meu cliente com um monte de diagrama na mão.
Mais depois observando melhor "Diagramas UML" engloba todos os diagramas, o CASO de USO pode ser um bom diagrama para validar os requisitos junto ao cliente.
-
Não é apenas porque não se encontra em livros que está errado, quando se trabalha em um projeto de software, é necessário validar o requisito não apenas negocialmente, mas também se este é possível de se desenvolver e para essa validação podemos utilizar estas ferramentas, questão feita para quem possui experiência na prática, não apenas teórica
-
Eu marquei errado tbm, mais analisando melhor a questão a UML e seus diagramas são apenas uma linguagem para se modelar sendo possivel sua utilização em qualquer parte do processo até mesmo na validação dos requisitos. Concordo com o Felipe.
-
Eu marquei errado porquer diz que a validacao de requisitos é parte integrante da especificacao.
Aguem pode explicar o motivo de estar correta esta afimacao.
-
Marquei errado pelo mesmo motivo do colega acima.
No livro do pressman ele separa especificação de validação. Pag 120 6° edição
-
Uma das técnicas de validação é a Análise de Consistência automatizada, descrita por Sommerville. Se os requisitos são descritos utilizando um modelo de sistema baseado em um modelo estruturado, como o orientado a objetos (UML), ferramentas CASE podem ser usadas para avaliar a consistência desses requisitos. Assim, é correto o uso de diagramas UML na validação. Esse uso é indireto, pois quem analisará a consistência na validação são as ferramentas CASE, contudo baseado nos modelos estruturados (diagramas de classe, casos de uso, sequência...)
-
Conforme explicação acima do amigo Wilson
Temos:
Na validação de requisitos - parte integrante da especificação desses requisitos -, é correto o uso de diagramas da UML, tais como diagrama de classes, de casos de uso e de interação.
Utilização de diagrama UML está correto de acordo com técnicas de validação é a Análise de Consistência automatizada
Porém, validação de requisitos não é parte da especificação de requisitos.
São duas fases distintas, portanto está errado.
-
Quando diz parte integrante da especificação de requisitos. A única ideia que me veio é que a validação de requisitos é feita em cima da especificação de requisitos, ou seja, provavelmente com base em documentos formais e informais. Desta forma, a validação é uma reafirmação da especificação , ou seja, parte integrante.
-
Discordo do gabarito. Não por não achar que se deve usar UML para validação. Acho que podemos sim, mas deve-se atentar ao conteúdo dos diagramas. Não daria pra usar os mesmos diagramas do desenvolvimento. Discordo por achar que a validação não é parte da especificação de requisitos. Segundo pressman: Tarefas da eng de requisitos: concepção, levantamento, elaboração, especificação, negociação, validação e gestão.Segundo Sommerville a engenharia de requisitos é composta pelas atividades: Estudo da viabilidade do sistema. Elicitação e análise de requisitos. Especificação de Requisitos. Validação de requisitos. Ou seja sempre se trata a validação como coisa diferente de especificação.
Eu entraria com recurso!
-
A literatura (Pressman e Sommerville) recorrem a esses recursos para auxiliar a elicitação de requisitos. Nada impede que a validação use tais recursos! Porém, não encontrei essa afirmação explícita!
-
Falar em sobreposição até vai. Mas ser parte integrante foi demais.
-
Será que teve recurso ganho para alteração do gabarito dessa questão? Um absurdo, são fases distintas.
-
Problema dessa questão não é o UML, e sim, que o Pressman separa especificação de validação.
E a questão diz que é parte integrante.... Errei o gabarito e a questão errou o conceito.
-
Fiz uma leitura minuciosa no capítulo do Pressman "engenharia de requisitos" e lendo várias vezes a parte de especificação cheguei a conclusão de que a questão está realmente certa. Pressman diz que a especificação pode ser um documento por escrito, um conjunto de modelo gráficos, um modelo formal, um conjunto de cenários de uso, um protótipo ou qualquer combinação de fatores citados. Eu errei a questão por pensar que a especificação era apenas um "detalhamento do documento produzido na fase anterior" com isso acabei errando a questão. Como podem ver especificação não é só documento, isso vai variar em cada projeto. Ele fala em modelo de gráficos deixando em aberto que pode ser tanto aqueles usados para modelar OO (UML) ou para modelar o estruturado (modelo estruturado), por isso que ele diz que vai variar em cada projeto.
Pressman diz também que esses artefatos produzidos na especificação são avaliados na fase de "validação", ou seja, a validação de requisitos examina a especificação (que pode ser em alguns casos um conjunto de cenários e pouco mais do que isso, pode ser um documento contendo cenários, modelos e descrições por escrito) para garantir que todos os requisitos de software tenham sido declarados de forma não ambígua, omissões e erros tenham sido detectados e corrigidos e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto.
Questão muito difícil que obriga uma interpretação muito acima do normal rsrsrssr, é um tipo de questão que tem que ficar armazenada no bloco de notas.
Bons estudos.
-
está complicado estudar, questão fugindo do conceito padrão