

Seu próximo nível começa aqui
Com a Assinatura Ilimitada, você tem tudo que precisa para sua aprovação.
Com a Assinatura Ilimitada, você combina prática, teoria e método em uma única assinatura com tudo que você precisa para sua aprovação.
Um analista de requisitos está conduzindo a especificação de requisitos para um novo sistema de informações para atender às necessidades criadas por uma nova prática de negócio que envolve diversos departamentos da organização, com diferentes expectativas e valores.
Considerando-se o contexto descrito, qual das seguintes práticas é recomendada para melhorar a qualidade da especificação de requisitos?
Definir requisitos de maneira genérica para que possam ser reutilizados em outros projetos.
Especificar critérios de aceitação para cada requisito.
Evitar a participação de stakeholders no processo de especificação para reduzir conflitos.
Priorizar os requisitos com base na ordem de chegada das solicitações.
Utilizar linguagem ambígua para permitir flexibilidade na implementação.
Com base nas considerações sobre o nível de detalhamento dos requisitos segundo Wiegers e Beatty (2013), assinale a alternativa que apresenta a situação na qual é possível descrever menos detalhes sobre os requisitos.
Quando desenvolvimento será terceirizado e os membros da equipe estão geograficamente dispersos
Quando o trabalho está sendo realizado para um cliente externo que exige rastreabilidade entre os requisitos
Quando os desenvolvedores possuem uma vasta experiência no domínio e os clientes estão bastante envolvidos no projeto
Quando estimativas precisas são necessárias para o sucesso do projeto e os testes de sistema serão baseados nos requisitos detalhados
Em Engenharia de Software, o uso de normas para especificação de documentos é uma boa prática. Nesse sentido, a norma utilizada para guiar a especificação de requisitos de software é a
IEEE 830.
ISO 25000.
ISO 42010.
IEEE 829.
A engenharia de requisitos abrange as tarefas de levantamento, especificação, concepção, validação, elaboração, negociação e gestão. A tarefa de elaboração concentra-se
no desenvolvimento de regras de legitimação de requisitos, com vistas a garantir que todos os requisitos de software tenham sido declarados de forma não ambígua e que não haja inconsistências com os padrões estabelecidos para o projeto.
em estabelecer uma abordagem iterativa que priorize os requisitos, avaliando-se seus custos e riscos, de modo que cada parte atinja certo nível de satisfação.
no desenvolvimento de um modelo de requisitos refinado que identifique os diversos aspectos da função, do comportamento e das informações do software.
em estabelecer mecanismo de atribuição de prioridades que atenda às metas dos envolvidos e à arquitetura do projeto, por meio do estabelecimento de metas de negócios.
em estabelecer entendimento básico do problema, definindo-se os interessados em sua solução, a natureza da solução desejada e a eficácia da comunicação e da colaboração preliminares entre os demais envolvidos e a equipe de software.
O TRF1 instituiu uma equipe de planejamento para a contratação de uma solução de tecnologia da informação e comunicação. Durante os trabalhos dessa equipe, José elaborou os requisitos de arquitetura da informação, incluindo a definição de padrões e significação dos termos, expressões e sinais a serem utilizados no nivelamento do entendimento da solução a ser contratada.
Ao elaborar tal requisito tecnológico, José estava exercendo a atribuição de integrante:
técnico, tendo realizado a atividade juntamente com o integrante demandante;
técnico, tendo realizado a atividade juntamente com o integrante administrativo;
administrativo, tendo realizado a atividade juntamente com o integrante técnico;
administrativo, tendo realizado a atividade juntamente com o integrante demandante;
demandante, tendo realizado a atividade juntamente com o integrante administrativo.
A respeito do processo de especificação de requisitos, assinale a alternativa correta.
É fundamental que os requisitos sejam rigorosamente documentados no início de um projeto, e não é possível alterá-los após o começo das atividades de desenvolvimento.
Requisitos de usuário são descrições detalhadas da funcionalidade desenvolvida, e requisitos de sistema são a abstração daquilo que é desejado pelo cliente.
O documento de requisitos não é suficiente para limitar o escopo de um projeto.
O cliente deve possuir completo entendimento das suas necessidades e das limitações antes de apresentá-las ao provedor do serviço, a fim de que todo o processo de especificação de requisitos seja concluído em uma única interação entre cliente e provedor.
Além da descrição textual, podem ser utilizados diagramas e gráficos de casos de uso no processo de descoberta de requisitos.
Considere a seguinte lista de requisitos.
I. O sistema deve funcionar nos principais navegadores web e também em ambiente off-line.
II. O sistema deve permitir o cadastro de novos usuários, realizando a validação através de e-mail e código de confirmação.
III. O sistema deve emitir NFe com base no padrão regional.
IV. Deve ser possível ao usuário solicitar a redefinição de sua senha, informando o e-mail cadastrado e um código.
V. O sistema deve funcionar em ambiente desktop (Windows e Linux) e em smartphones (Android e iOS).
Na lista acima,
II e III são requisitos não funcionais.
há requisitos funcionais, apenas.
há requisitos não funcionais, apenas.
I, III e V são requisitos não funcionais.
I, IV e V são requisitos funcionais.
Segundo a norma IEEE 830, uma boa especificação de requisitos deve atender a critérios específicos de qualidade e contar certas características. A respeito do assunto, analise as afirmativas a seguir:
I-A norma IEEE 830 destaca como características, dentre outras, que uma boa especificação de requisitos deve ser correta, completa, modificável e consistente.
II-Quando se especificam requisitos, não é recomendado identificar de maneira única cada requisito, assim a referência a um determinado requisito pode ser aproveitada como referência a outro requisito similar (otimização).
III-Uma especificação é entendida como priorizada quando existem critérios que dão a cada requisito um valor de importância. Isso pode ser muito útil quando se deseja reduzir os riscos de um projeto (priorizando os mais críticos).
IV-O requisito "Definir que 92% das transações devem ser processadas em menos de 2 segundos cada" é um exemplo de requisito cuja especificação atende ao critério da consistência (consistente).
V-A norma ISO/IEC 25010 é uma norma ISO disponibilizada em 2011 para qualidade de produto de software. Tal padrão é muito abrangente e apresenta oito categorias para diferenciar os mais diversos tipos de requisitos funcionais. São elas: Adequação funcional, eficiência no desempenho, compatibilidade, usabilidade, confiabilidade, capacidade de manutenção, segurança e portabilidade.
É correto o que se afirma em:
IV e V, apenas.
I e III, apenas.
I, II, III, IV e V.
II, IV e V, apenas.
I, II e III, apenas.
O estudo de viabilidade constitui-se na fase inicial do desenvolvimento da especificação de requisitos do software e o resultado desse estudo deve, prioritariamente, compreender
uma planilha de custos detalhada de todos as atividades e compras a serem feitas no decorrer do desenvolvimento do software.
a recomendação para prosseguir, ou não, com os demais processos componentes da engenharia de requisitos.
uma classificação detalhada dos requisitos levantados, por ordem de prioridade e de tempo necessários para o desenvolvimento.
a definição de quais deverão ser os módulos de software desenvolvidos internamente e quais deverão ser adquiridos de terceiros.
a definição da equipe de desenvolvimento do software, bem como sua seleção, segundo critérios estabelecidos nesse estudo.
Do ponto de vista de design e de usabilidade, o produto mínimo viável dispensa padrões de qualidade comercial, sendo suficiente que a funcionalidade parcial proposta tenha um nível básico de confiabilidade.
Certo
Errado
Luciano, Analista de Desenvolvimento, está trabalhando em um documento para especificação de requisitos, sendo este um conjunto de sequências de ações que um sistema executa e que produz um resultado observável por um particular ator. Esse documento é chamado
Regras de Negócio.
Matriz de Rastreabilidade.
Casos de Uso.
Protótipos.
Diagrama de Entidade Relacionamento.
Na engenharia de software, é útil registrar os requisitos em diferentes níveis de detalhamento, visando atender públicos distintos. Para esse fim, são utilizados dois tipos de especificação de requisitos e eles estão descritos na alternativa:
Requisitos funcionais e requisitos não funcionais.
Requisitos de produto e requisitos organizacionais.
Requisitos de alto nível e requisitos de baixo nível.
Requisitos essenciais e requisitos desejados.
Requisitos de usuário e requisitos de sistema.
O objetivo principal da especificação é documentar todas as necessidades dos clientes e obter um aceite quanto às entregas de produto propostas.
Certo
Errado
Para a especificação de requisitos, considera-se quatro possíveis notações. Assinale a alternativa que apresenta a especificação em que os requisitos são escritos em um template ou formulário utilizando a linguagem natural.
Especificações matemáticas.
Sentença em linguagem natural.
Notações gráficas.
Histórias.
Linguagem natural estruturada.
A especificação de requisitos é frequentemente composta de vários tipos de documentos e não raro abrange: visão geral; glossário; modelos do sistema; lista de requisitos funcionais e lista de requisitos não funcionais; especificação detalhada de requisitos.
Certo
Errado
Algumas vezes, durante a fase de levantamento de requisitos, é importante identificar como funções e características de um sistema serão usadas por diferentes classes de usuários. Para tanto, pode-se utilizar um conjunto de __________________ que identifique roteiros de uso para o sistema a ser construído.
Assinale a alternativa que preenche corretamente a lacuna do trecho acima.
cenários de uso
protótipos
modelos de domínio
diagramas de comunicação
modelos conceituais
A Especificação de Requisitos de Software, documento de requisitos de software, define o que os desenvolvedores de um sistema necessitam implementar. Essa especificação implica que
requisitos de usuário e de sistema devam ser integrados em uma única descrição de requisitos de software.
metodologias ágeis argumentam que a alteração dos requisitos não tem impacto na implementação do sistema e que, portanto, inexiste desperdício de tempo nesta atividade.
diagramas de sequência e de estado projetados em UML, são pouco úteis quando se deseja mostrar ações que ocorrem em resposta a um determinado evento e/ou mensagem.
documentos de requisitos são extremamente importantes, quando desenvolvedores externos estão implementando o sistema de informação.
A Especificação dos Requisitos do Software deve ser escrita por membros da equipe de desenvolvimento de um projeto, com a participação obrigatória de um ou mais usuários chaves do produto em pauta. Entre outros, deve constar:
Critérios de verificação e validação.
Estruturas internas de dados.
Fluxo de informação entre módulos.
Propriedades emergentes do sistema, como confiabilidade, tempo de resposta e ocupação de área.
Métodos requeridos de desenvolvimento.
A especificação de requisitos constitui-se em uma importante atividade no escopo da engenharia de software. Dessa forma, é correto afirmar que requisitos
não funcionais devem descrever como o sistema deve ser comportar em situações particulares.
não funcionais devem ser explícitos em determinadas ações que o sistema não deva executar.
funcionais devem descrever restrições ou limitações de tempo impostas ao sistema.
funcionais devem atender a restrições impostas por normas e procedimentos.
funcionais devem conter, dentre outros aspectos, como o sistema alvo deve reagir a determinados tipos de entradas.
No que diz respeito ao planejamento, desenvolvimento e manutenção de sistema para web, em uma fase os desenvolvedores fazem um estudo detalhado dos dados levantados e de onde são construídos modelos a fim de representar o sistema a ser desenvolvido. O objetivo é criar uma estratégia de solução, sem se preocupar como ela será realizada, ou seja, utilizar as necessidades dos clientes, depois de compreendido o problema, para resolução do problema solicitado. Assim, é necessário definir o que o sistema deve fazer antes de definir como o sistema irá fazer. Essa fase é conhecida por:
implantação e testes
estudo de viabilidade
projeto e implementação
especificação de requisitos