1. Engenharia de
Requisitos

2. Equipe
• Amilton Luiz
• Hugo Magalhães
• Lucas Fábio
• Márcia Maria
• Rhaissa Santos
• Rodrigo Venâncio
• Tamires Guedes

3. Engenharia de requisitos
• Processo que engloba todas as atividades que contribuem
para a produção de um documento de requisitos e sua
manutenção ao longo do tempo

4. Engenharia de requisitos
• Fases
• identificação;
• análise e negociação;
• especificação e documentação;
• validação.
• Antes dessas fases:
• estudos de viabilidade que, a partir das restrições do
projeto, determinam se este é ou não viável e se deve prosseguir
para a identificação dos requisitos

5. Engenharia de requisitos
Análise de
Viabilidade
Identificação
Análise e
negociação
Especificação e
documentação
ValidaçãoGestão

6. Estudo de viabilidade
• Será que o sistema contribui para os objetivos da organização?
• Dadas as restrições tecnológicas, organizacionais
(econômicas, políticas, ambientais, recursos disponíveis) e
temporais associadas ao projeto, será que o sistema pode ser
implementado?
• Caso haja necessidade de integração entre diferentes
sistemas, será que esta é possível?

7. Estudo de viabilidade
• Se o novo sistema não fosse implementado, quais seriam as
alternativas para a organização?
• Quais são os problemas que os sistemas atuais apresentam e
como é que um sistema novo irá resolver estas falhas?
• De que forma é que o sistema irá contribuir diretamente para
os objetivos da organização?
• É possível a integração com os outros sistemas da organização
(de um ponto de vista tecnológico)? Com que facilidade é que
se consegue partilhar informação entre estes sistemas?

8. Estudo de viabilidade
• O estudo de viabilidade deverá culminar com a produção de
um relatório e deverá determinar a continuação do
desenvolvimento do projeto, tornando mais claras as
restrições (econômicas, temporais e organizacionais) do
projeto e definindo mesmo alguns requisitos de alto nível.

9. Identificação
• Atividades desta fase:
• Compreensão do domínio: é muito importante para o analista
compreender o domínio no qual a organização e o projeto se
inserem; quanto maior for o conhecimento acerca do
domínio, mais eficaz será a comunicação entre o analista e as
partes interessadas.
• Identificação das partes interessadas: estes já deverão ter sido
identificados nos estudos de viabilidade, porém para efeitos de
identificação de requisitos convém concentrar as atenções nos
usuários do sistema.

10. Identificação
• Atividades dessa fase
• Captura: consiste na obtenção com o cliente dos requisitos
(funcionais e não-funcionais) pretendidos para o sistema.
• Identificação e análise de problemas: os problemas devem ser
identificados (e a sua definição deve ser consensual) e devem ser
propostas soluções em conjunto com as partes interessadas.

11. Identificação
• Técnicas
• Entrevistas
• Questionários
• Workshops (reuniões)
• Cenários (série de eventos hipotéticos)
• Prototipagem
• Estudo etnográfico (observação direta)

12. Análise e Negociação de
Requisitos
• Atividades dessa fase:
• classificação: agrupamento de requisitos em "módulos" para
facilitar a visão global do funcionamento pretendido para o
sistema;
• resolução de conflitos: dada a multiplicidade e diversidade de
papéis das partes interessadas envolvidas na captura e análise de
requisitos, é inevitável a existência de conflitos nos requisitos
identificados; é importante resolver estes conflitos o mais breve
possível;

13. Análise e Negociação de
Requisitos
• Atividades dessa fase
• priorização: consiste na atribuição de uma "prioridade" a cada
requisito (por exemplo elevada/média/baixa); obviamente, este
pode ser um fator gerador de conflitos;
• confirmação: é confirmada com as partes interessadas a
completude dos requisitos, sua consistência e validade (de
acordo com o que se pretende do sistema).

14. Análise e Negociação de
Requisitos
• Cuidados necessários às negociações:
• saber lidar com ataques pessoais (evitando-os sempre que
possível, remetendo a sua resolução para mais tarde, fora de
reunião), de preferência nunca tomando partidos;
• fomentar a justificação das posições (negativas) tomadas pelos
intervenientes na negociação;

15. Análise e Negociação de
Requisitos
• Cuidados necessários às negociações:
• salientar (e procurar encontrar) os benefícios que uma solução
apresenta para todos os envolvidos;
• relaxar restrições, quando se torna óbvio que as atuais não
levarão a um consenso.

16. Especificação e Documentação
• Produção propriamente dita do Documento de Especificação
de Requisitos
• Tipos de requisitos:
• Funcionais
• Não-funcionais
• Tipos de especificação:
• Especificação de requisitos do usuário ou utilizador;
• Especificação de requisitos do sistema;
• Especificação do design da aplicação.

17. Especificação e Documentação
• Requisitos Funcionais: descrevem as funcionalidades que se
espera que o sistema disponibilize, de uma forma completa e
consistente. É aquilo que o utilizador espera que o sistema
ofereça, atendendo aos propósitos para qual o sistema será
desenvolvido.

18. Especificação e Documentação
• Requisitos Não-funcionais: referem-se a aspectos não-
funcionais do sistema, como restrições nas quais o sistema
deve operar ou propriedades emergentes do sistema.
Costumam ser divididos em Requisitos não-funcionais de:
Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.

19. Especificação e Documentação
• O Documento de Especificação de Requisitos inclui uma
combinação dos requisitos do utilizador e do sistema e tem
diferentes utilidades para diferentes pessoas:
• Clientes: confirmar a completude dos requisitos e propor
alterações.
• Gestores: orçamentar o sistema e planejar o processo de
desenvolvimento.
• Engenheiros: compreender o sistema a desenvolver.
• Engenheiros (testes): desenvolver testes para validar o
cumprimento dos requisitos.
• Engenheiros (manutenção): compreender o sistema e a ligação
entre as suas partes.

20. Especificação e Documentação
• Modelos:
IEEE
http://standards.ieee.org/findstds/standard/830-1993.html
Aida
https://sites.google.com/site/professoraaidaferreira/engenharia-
de-software-iii/modelos/ESOO_requisitos.doc?attredirects=0&d=1

21. Validação
• Objetivo: demonstrar que o documento de requisitos
produzido corresponde, de fato, ao sistema que o cliente
pretende
• Pretende-se encontrar problemas/conflitos na
especificação, porém ao contrário das fases anteriores esta
fase lida com uma especificação completa dos requisitos.

22. Validação
• Atributos que DEVEM ser observados na validação:
• Validade: a especificação resulta da análise dos requisitos
identificados junto das diversas partes interessadas envolvidas.
Como tal, requisitos identificados individualmente (isto é, junto
de cada parte interessada) podem diferir da especificação final
que se atinge após o cruzamento de informação e é necessário
que cada cliente compreenda e aceite a especificação final
obtida.
• Consistência: não devem existir conflitos entre os requisitos
identificados.

23. Validação
• Atributos que DEVEM ser observados na validação:
• Compreensibilidade / Ambiguidade: os requisitos devem poder
ser compreendidos de forma inequívoca pelas partes
interessadas.
• Completude: todas as funcionalidades pretendidas devem fazer
parte da especificação do sistema.
• Realismo: dadas as restrições do projeto
(tecnológicas, financeiras e temporais) o sistema especificado
tem de ser implementável.

24. Validação
• Atributos que DEVEM ser observados na validação:
• Verificabilidade: de forma a evitar futuras discordâncias quanto à
concretização dos requisitos especificados, estes devem ser
descritos de modo a que seja possível verificar se foram ou não
concretizados, isto é, se o sistema final corresponde à
especificação inicial.
• Rastreabilidade: a origem dos requisitos, em relação ao
cliente, deve estar claramente identificada. Entre outros
motivos, isto é importante para facilitar a gestão futura dos
requisitos.

25. Validação
• Atributos que DEVEM ser observados na validação:
• Conformidade com normas: para além dos aspectos funcionais
dos requisitos, a sua especificação deve obedecer às normas
usadas ao longo de todo o documento.

26. Validação
• Técnicas
• Revisão de Requisitos
• Prototipificação
• Geração de casos de teste
• Análise de consistência automática

27. Gestão de Requisitos
• Devem estar definidas desde o início da gestão de requisitos
políticas para:
• Identificação de requisitos: identificação unívoca em especial
para facilitar a rastreabilidade.
• Processo de gestão de mudanças a utilizar: conjunto de
atividades que permitem avaliar o custo e impacto das
alterações.
• Rastreabilidade: relações entre os requisitos e relações entre
requisitos e design; estas podem precisar de manter associada a
cada requisito informação como a parte interessada que a
propôs, dependências de outros requisitos e associação a
módulos específicos do design do sistema.
• Ferramentas a utilizar: para sistemas grandes, a quantidade de
informação a processar pode ser elevada, sendo o uso
de ferramentas CASE aconselhado.

28. Gestão de Requisitos
• Para manter a consistência entre as várias alterações pedidas
(e para estas serem feitas de um modo controlado), é
importante que o processo de gestão de mudanças esteja
definido de um modo formal

29. Referências
• Soares (2005). Introdução, Identificação e Análise em
Engenharia de Requisitos. António Lucas Soares. 2005.
• Kotonya e Sommerville (1998). Requirements Engineering:
Processes and Techniques. Gerald Kotonya, Ian Sommerville.
Wiley. 1998.
• Thayer e Dorfman (1993). Software Requirements
Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society
Press. 1993.
• Sommerville (2001). Software Engineering. Ian Sommerville.
Addison Wesley. 2001.