Engenharia de Software I - Exercício 5 (Sommerville)

Prévia do material em texto

1. O que é um requisito?
Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição do
sistema para uma especificação matemática funcional. Isso é inevitável quando os requisitos
podem servir a uma função dupla. Pode ser a base para a proposta de um contrato -
portanto, deve ser aberto à interpretação; pode ser a base para o contrato em si, portanto,
deve ser definido em detalhe; ambas as declarações podem ser chamadas de requisitos.
2. O que são os requisitos do usuário e os requisitos do sistema?
Requisitos de usuário: declarações em linguagem natural com diagramas dos serviços que o
sistema deverá fornecer e suas restrições operacionais. Escrito para os clientes.
Requisitos de sistema: um documento estruturado estabelecendo descrições detalhadas das
funções do sistema, serviços e restrições operacionais. Define o que deve ser implementado
assim, pode ser parte de um contrato entre o cliente e o empreiteiro.
3. Qual é a distinção entre requisitos funcionais e não funcionais?
Requisitos funcionais: o sistema deve fornecer declarações de serviços, como o sistema
deve reagir a entradas específicas e como o sistema deve se comportar em determinadas
situações. Pode explicitar o que o sistema não deve fazer.
Requisitos não-funcionais: restrições aos serviços ou funções oferecidas pelo sistema, tais
como restrições de tempo, restrições no processo de desenvolvimento, padrões. Muitas
vezes se aplica ao sistema como um todo ao invés de características individuais ou serviços.
4. Explique por que os requisitos devem ter precisão, integridade e consistência.
Problemas surgem quando os requisitos não são precisamente definidos, requisitos
ambíguos podem ser interpretados de maneiras diferentes por desenvolvedores e usuários.
Sobre a integridade, em princípio, os requisitos devem ser completos e consistentes. Eles
devem incluir descrições de todos os serviços necessários. Consistentes, assim, não devem
haver conflitos ou contradições nas descrições dos recursos do sistema.
5. Requisitos não funcionais são classificados em três grandes grupos. Caracterize cada
um deles:
a. Requisitos de produto
Requisitos que especificam que o produto entregue deve se comportar de uma maneira
particular, por exemplo velocidade de execução, confiabilidade, etc.
b. Requisitos organizacionais
Requisitos que são consequência de políticas e procedimentos organizacionais, por exemplo
padrões de processo usados, requisitos de implementação, etc.
c. Requisitos externos
Requisitos que surgem de fatores externos ao sistema e seu processo de desenvolvimento,
por exemplo, requisitos de reguladores, requisitos legais, etc.
6. Requisitos não funcionais devem ser mensuráveis. Explique essa afirmação e dê
exemplos de métricas que podem ser utilizadas.
Devido à sua própria definição, requisitos não funcionais são geralmente mensuráveis, assim,
deve-se associar forma de medida/referência a cada requisito não funcional.
Propriedade Métrica
Velocidade Transações processadas/segundo
Tempo de resposta de usuário/evento
Tempo de atualização de tela
Tamanho Megabytes
Número de chips de memória ROM
Facilidade de uso Tempo de treinamento
Número de frames de ajuda
Confiabilidade Tempo médio para falha
Probabilidade de indisponibilidade
Taxa de ocorrência de falhas
Disponibilidade
Robustez Tempo de reinício após falha
Percentual de eventos que causam falhas
Probabilidade de corrupção de dados em
caso de falha
Portabilidade Percentual de declarações dependentes do
sistema-alvo
Número de sistemas-alvo
7. O que é o documento de requisitos de software?
O documento de requisitos de software é a declaração oficial do que é demandado dos
desenvolvedores do sistema. Deve incluir ambas, uma definição de requisitos do usuário e
uma especificação de requisitos do sistema. Não é um documento de projeto, na medida do
possível, deve definir O QUE o sistema deve fazer ao invés de COMO deve fazê-lo.
8. Explique as 4 principais etapas do processo de engenharia de requisitos.
● Elicitação de requisitos: às vezes chamada de elicitação ou descoberta de
requisitos, envolve técnicos trabalhando com os clientes para levantar dados sobre o
domínio da aplicação, os serviços que o sistema deve fornecer e as restrições
operacionais do sistema. Pode envolver usuários finais, gerentes, engenheiros
envolvidos na manutenção, especialistas de domínio, sindicatos, etc. Esses são
chamados stakeholders.
● Análise de requisitos: engenheiros de software trabalham com uma gama de
stakeholders do sistema para descobrir sobre o domínio da aplicação, os serviços
que o sistema deve fornecer, o desempenho do sistema necessários, restrições de
hardware, outros sistemas, etc. Estágios incluem: descoberta de requisitos,
classificação e organização de requisitos, priorização e negociação de requisitos,
especificação de requisitos.
● Validação de requisitos: preocupados em demonstrar se os requisitos definem o
sistema que o cliente realmente quer. Os custos de erros de requisitos são altos,
logo, a validação é muito importante. Corrigir um erro de requisitos após a entrega
pode custar até 100 vezes o custo de corrigir um erro de execução.
● Gerenciamento de requisitos: é o processo de gerenciar os requisitos em constante
mudança durante o processo de engenharia de requisitos e desenvolvimento de
sistemas.
9. Mostre 5 problemas que podem dificultar a análise de requisitos.
1. Os stakeholders não sabem o que realmente querem.
2. Os stakeholders expressam requisitos em seus próprios termos.
3. Diferentes stakeholders podem ter requisitos conflitantes.
4. Fatores políticos e organizacionais podem influenciar os requisitos de sistema.
5. Os requisitos mudam durante o processo de análise. Novos stakeholders podem
surgir e o ambiente de negócios pode mudar.
10. Cite exemplos de fontes de informação e técnicas que podem ser usadas na elicitação
de requisitos.
Podem ser usadas na elicitação de requisitos: entrevistas, questionários, análise de
protocolos, participação ativa dos usuários, cenários, etnografia, reuso de requisitos e etc.
11. Quais verificações devem ser aplicadas durante a validação de requisitos?
● Validade: o sistema fornece as funções que melhor atendem às necessidades do cliente?
● Consistência: existe algum conflito de requisitos?
● Completude: estão incluídas todas as funções e restrições requeridas pelo cliente?
● Realismo: os requisitos podem ser implementados com o orçamento e a tecnologia
disponíveis?
● Verificabilidade: os requisitos podem ser verificados?
12. Liste três técnicas de validação de requisitos.
1. Revisões de requisitos: análise manual sistemática dos requisitos.
2. Prototipação: usando um modelo executável do sistema para verificar os requisitos.
3. Geração de casos de teste: desenvolvimento de testes para verificar os requisitos
implementados.
13. Explique como funciona o gerenciamento de requisitos e por que é tão importante.
Após o sistema começar a ser usado, surgem novos requisitos, é preciso manter o controle
das necessidades individuais e manter ligações entre os requisitos dependentes para que
você possa avaliar o impacto das mudanças nos requisitos. É necessário estabelecer um
processo formal para fazer propostas de mudança e ligar essas aos requisitos de sistema.
14. Quais são os estágios do processo de gerenciamento de mudança de requisitos?
● Decidir se uma mudança de requisitos deve ser aceita.
● Análise de problema e especificação de mudanças: durante essa fase, o problema
ou a proposta de mudança é analisada para verificar se é válida. O feedback dessa
análise é devolvido para o solicitante, que pode responder com uma proposta mais
específica de mudança dos requisitos, ou decidir retirar o pedido.
● Análise de mudanças e custos: o efeito da mudança proposta é avaliado por meio de
informações de rastreabilidade e conhecimento geral dos requisitos do sistema. Uma
vez que essa análise é concluída, toma-se a decisão de prosseguir ou não com a
mudança de requisitos.
● Implementação demudanças: o documento de requisitos e, se necessário, o projeto
e implementação do sistema, são modificados. Idealmente, o documento deve ser
organizado de modo que as mudanças possam ser facilmente implementadas.