Grátis: Determinar o tipo de requisito em um sistema pode ser uma tarefa extenuante e, um requisito pode ser classificado inicialmente como um tipo e no de... – Questões Respondidas

Engenharia de Software

Outros

Determinar o tipo de requisito em um sistema pode ser uma tarefa extenuante e, um requisito pode ser classificado inicialmente como um tipo e no decorrer no projeto, ele pode sofrer alterações e receber outra classificação ou ainda, gerar uma série de novos requisitos. Segundo as principais bibliografias especializadas nesse assunto, os requisitos de um sistema podem ser classificados como Requisitos Funcionais, Requisitos Não Funcionais e Requisitos de Domínio.

O sistema deve realizar emissão de nota fiscal eletrônica.

Desafios Para o Conhecimento

ano passado

Desafios Para o Conhecimento

ano passado

Análise e Modelagem de Sistemas

Análise e Modelagem de Sistemas

ITE

Respostas

Ed

ano passado

Pelo que foi descrito, o requisito "O sistema deve realizar emissão de nota fiscal eletrônica" pode ser classificado como um Requisito Funcional, pois descreve uma funcionalidade específica que o sistema deve possuir. É importante garantir que esse requisito seja claro, mensurável e atenda às necessidades dos usuários finais. Durante o projeto, é possível que esse requisito sofra alterações ou que novos requisitos sejam identificados para garantir o sucesso do sistema.

Essa resposta te ajudou?

0

0

left-side-bubbles-background

right-side-bubbles-background

Crie sua conta grátis para liberar essa resposta. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Ainda com dúvidas?

Envie uma pergunta e tenha sua dúvida de estudo respondida!

Essa pergunta também está no material:

Análise e Modelagem de Sistemas

Análise e Modelagem de Sistemas

ITE

Mais perguntas desse material

Em se tratando de modelagem de processos, as notações são conjuntos de símbolos os quais são padronizados, com regras que indicam seus significados. Ao realizar um projeto, a equipe precisa avaliar a organização para escolher a melhor notação. Por vezes, mais de uma notação pode ser importante de ser adotada, cada qual em uma fase do projeto de modelagem. De acordo com o que você conhece das diferentes notações, faça a associação entre as colunas A e B.
[object Object]
[object Object]
[object Object]
[object Object]
a. I-2, II-3, III-1, IV-4
b. I-1, II-2, III-3, IV-4
c. I-3, II-1, III-4, IV-2

Pleeger (2004) aborda no capítulo 4 de seu Engenharia de Software a identificação de requisitos. Para que esta fase do processo de desenvolvimento de um Sistema ou Software seja bem sucedida, um contato próximo com o cliente é de suma importância. Através de perguntas, exemplificações, desenvolvimento de protótipos, o cliente externará o que deseja obter do projeto, e o responsável registrará em documentos os requisitos. Entretanto, o requisito não é um fim em si mesmo. Ele é parte apenas do início de um projeto. Tendo como foco a identificação de requisitos, avalie as afirmativas a seguir:
I. Em uma primeira abordagem, a escrita dos requisitos mostrará ao cliente e ao contratado o que o sistema fará de modo já detalhado, para evitar a necessidade de reescrita futura.
II. A reescrita de requisitos, quando feita, não trará mais ou menos facilidade à equipe de projetistas, pois trata-se simplesmente de alguns acertos dos requisitos.
III. Requisitos que tenham sido escritos e até reescritos, são de tal forma completos, que qualquer validação é ação opcional ao projeto.
IV. Para garantir a satisfação do cliente, todos os requisitos pedidos por ele precisam ser atendidos, mesmo aqueles que são mais desejáveis do que necessários.
V. A lista de requisitos, quando de sua reescrita, especifica como os mesmo serão implementados.
Todas as alternativas estão corretas.
Todas as alternativas estão incorretas.

A Engenharia de Requisitos é um processo que compreende todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. Analise as afirmativas a seguir, com alguns procedimentos básicos de levantamento e análise de requisitos de um sistema, proposto por Sommerville (2011).
I. Negociação dos Requisitos: Neste processo (já com os requisitos listados) é fundamental determinar se há requisitos em conflitos com outros.
II. Validação dos Requisitos: é realizada uma verificação geral dos requisitos, proveniente de um “termo de aceite” onde todas as partes envolvidas (os stakeholders do sistema projetado) concordam e validam os requisitos.
III. Documentação: é o resultado final da Engenharia de Requisitos, e é o principal meio de comunicação entre os Analista de Sistemas ou Engenheiro de Software e o Cliente.
I, apenas.
I, II e III.

Considerando o contexto, avalie as afirmativas a seguir:

I. A partir do resumo apresentado deverá ser elaborado uma lista de Requisitos Não Funcionais do Software a ser desenvolvido.
II. O resumo apresentado já é suficiente para começar as telas do projeto, visto que as principais funcionalidades do Software já foram listadas.
III. O resumo apresentado não expõem de forma clara os Requisitos Funcionais, demonstra somente os Requisitos Não Funcionais.
IV. A partir do resumo apresentado podemos ter uma ideia inicial do projeto, entretanto, será necessário especificar os requisitos e validá-los com o cliente.

Considerando o contexto apresentado, é correto o que se afirma em:

Apenas a afirmação IV está correta.

Uma classe é a representação de um conjunto de objetos, ou em outras palavras, é a representação da abstração do objeto com suas características e comportamentos. Com relação a Programação Orientada a Objetos, no que tange as definições sobre Classes, complete as lacunas da sentença a seguir:
A classe genérica denominamos de e a classe que herda suas características chamamos de . É importante ressaltar que a pode acrescentar novas características e comportamentos e alterar as já existentes, pois ela é considerada uma nova classe. Estas alterações têm efeito somente na nova classe especificada.
Assinale a alternativa que preenche corretamente as lacunas:

Superclasse / subclasse / subclasse;

Quatro Diagramas estão contemplados no Diagrama de Interação: Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Tempo, Diagrama de Visão Geral de Interação. O Diagrama de Sequência é, dentre os Diagramas de Interação UML, o mais comum.

Considerando o Diagrama de Sequência, avalie as afirmativas a seguir:

I. O Diagrama de Sequência foca na troca de mensagens entre um número de “lifelines”.
II. O Diagrama de Sequência descreve uma interação focando na sequência de mensagens que são trocadas.
III. As interações que são descritas por Diagramas de Sequência formam a base para o entendimento de semânticas das metaclasses no pacote de interações.
IV. O Diagrama de Sequência foca na interação entre “lifelines” onde a arquitetura da estrutura interna e o modo como ela corresponde com a passagem de mensagem são centrais.

Considerando o Diagrama de Sequência, assinale a alternativa correta.

Apenas as alternativas I, II e III estão corretas.

No processo de abstração podemos definir classes abrangentes as quais, durante o processo de modelagem, serão refinadas e, a partir de então construir subclasses que poderão herdar as características e comportamentos da classe genérica.

Podemos dizer que uma grande vantagem da Herança em POO é permitir...

A criação de novas classes a partir de classes já existentes, sem duplicar nenhum código.

O Processo Unificado surgiu depois da UML (Unified Modeling Language), a qual originou a partir de três métodos (Booch, OMT e OOSE), todos orientados a objeto. A UML passou a ser utilizada como uma norma pelas empresas de desenvolvimento, mas não era um processo completo, para ser seguido no ciclo de desenvolvimento.

Com relação ao Processo de Software, no que tange os conceitos sobre o Processo Unificado, complete as lacunas da sentença a seguir:

O Processo Unificado (PU) é um modelo , baseado no modelo incremental e que visa iterativa de um software. Podemos dizer que o modelo PU aperfeiçoou o tradicional processo incremental e o iterativo, eliminando algumas desvantagens dos dois processos. Por exemplo, no modelo iterativo, às vezes, o software nunca termina, pois, o cliente está sempre solicitando alterações e se o processo de documentação não for adequado, o software vira uma colcha de retalhos. No caso do incremental, cada parte tem de ser concluída integralmente para se passar à próxima. Já com o PU os processos iterativos e incremental permitindo que o software vá se tornando robusto a cada refinamento, num caminho para a maturidade do processo.

Assinale a alternativa que preenche corretamente as lacunas:

adaptativo / a construção / caminham em paralelos.