quinta-feira, 31 de maio de 2012

Engenharia de Requisitos para Concursos - Parte 1

Bom galera, esse é mais um resumo que eu faço para os meus estudos. Esses também são baseados nas aulas do Pedrosa. Só lembrando que esses são os meus resumos. Usem como quiser, mas não me culpem por informações imprecisas.

Engenharia de Requisitos é a área da Engenharia de Software preocupada com os objetivos do mundo real para sistemas de software. É uma disciplina muito próxima do mundo real ou natural, próxima das necessidades do cliente. Também se preocupa com as funcões de sistemas de softwares (requisitos funcionais) e restrições em sistemas de software (não funcionais)

"Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema."

O objetivo final é gerar especificações precisas do comportamento do software e de sua evolução.

Os requisitos devem gerar uma concordância entre os clientes e a equipe de desenvolvimento, estabelecer o combinado, um entendimento sobre o que vai ser feito. Além disso, esses requisitos devem fornecer aos desenvolvedores uma compreensão melhor das funcionalidades do sistema a ser desenvolvido.

Por servirem como um entendimento sobre o que será feito, eles também informam, por exclusão, o que não será feito, então delimitam o escopo do sistema. Tudo o que está dentro do Modelo de Casos de Uso pode ser considerado como escopo do produto. Casos de Uso é a forma mais comum de especificação de requisitos, mas é pouco usado em metodologias ágeis.

Os requisitos fornencem a base para o planejamento das iterações, para estimar o custo e o tempo de desenvolvimento do sistema.

Definem uma interface para o sistema de acordo com as necessidades dos usuários. Os casos de uso sozinhos podem deixar dúvidas na cabeça dos usuários. Os protótipos de interface ajudam a clarear os requisitos. Isso gera requisitos de melhor qualidade.

Os documentos de requisitos precisam ser completos (todas as funcionalidades), consistentes, sem ambiguidades e corretos, com as reais necessidades do cliente. Normalmente os requisitos não são corretos porque o analista não consegue entender as necessidades do cliente.


A primeira caixa da figura mostra o Estudo de Viabilidade e como já estamos na especificação requisitos, o sistema já teria sido considerado viável.

A segunda estapa é a Elicitação e Análise de Requisitos. É onde se descobre os requisitos. A etapa mais imporante.

A terceira etapa é a Especificação de Requisitos, pega-se o que foi descoberto na Elicitação e é criada uma especificação formal e padronizada.

A quarta etapa é a Validação de Requisitos. É onde se verifica se os requisitos atendem as reais necessidades do cliente. Os clientes assinam a especificação e assim dão o aceite para a versão final do documento.

A figura tem o foco na geração dos requisitos. Depois ainda existe a etapa de Gestão de Requisitos que foca em gerenciar os requisitos depois que eles são gerados. Cuida da evolução desses requisitos.

Na prática, o processo de engenharia de requisitos é iterativo, pode haver sobreposição de atividades e o Sommerville fala isso. Reparem que as setas vão e voltam de uma etapa para outra.

"Requisito é uma condição ou uma capacidade com a qual o sistema deve estar de acordo." ou "Uma condição ou uma funcionalidade necessária a um usuário para resolver um problema."

Pode ser algo abstrato ou uma especificação matemática detalhada. Tudo depende do grau de detalhe dos requisitos, depende do seu público alvo.


Requisitos definem o que o sistema deve fazer e sob quais limitações deve operar.



O Sommerville define requisitos de 3 níveis:
Requisitos de Usuário: em linguagem natural e escrito para clientes leigos.
Requisitos de Sistema: são documentados formalmente, já para a equipe de desenvolvimento
Especificação do Software: Um terceiro nível que é a própria especificação do software, algo bastante detalhado, bem próximo no nível computacional. (isso precisa ser melhor estudado por mim)

Os stakeholders ou partes interessadas são as pessoas que podem ter interesse nos requisitos do sistema por algum motivo. Entre eles podemos citar os engenheiros de software do sistema, os usuários finais que irão usar o sistema, os gerentes da empresa, os especialista no domínio da organização em que o software será implementado e até mesmo fiscais externos para ver se o sistema satisfaz os requisitos legais.

Problemas com Requisitos

Os requisitos apresentam problemas e dificuldades para serem tratados. Eles podem vir de várias fontes diferentes e com interesses diferentes, então, é preciso compatibilizar esses interesses. Um erro comum é o requisito não refletir as necessidades reais dos usuários. É comum a fonte consultada não conhecer a nessecidade real do usuário. Essa fonte pode ser um cliente, mas não é será um usuário do software. Além disso, o analista pode entender as coisas de forma errada.

Outro problema é o requisito inconsistente ou incompleto. As vezes um requisito contraria outro requisito ou alguém esquece de colocar determinado requisito na especificação.

Poder ser muito caro alterar um requisito depois de longo tempo de execução do projeto. Quanto mais tempo um requisito permanece errado, mas caro será o seu reparo quando o erro for detectado e corrigido. Um erro corrigido durante a ênfase na condificação pode custar até 5 vezes mais. Se o produto já estiver em produção pode custar até 20 vezes mais.



Mal entendido entre clientes e analistas podem gerar erros de interpretação dos requisitos. O sucesso das etapas posteriores do seu software vai depender da qualidade dos requisitos gerados.