Engenharia de Requisitos

1. Modelagem de
Sistema de
Informação
Aula 04 – Levantamento de Requisitos

2. Cenário atual do desenvolvimento de software

3. Causas de falhas em projetos de software

4. Requisitos e análise de sistemas

5. Requisitos - Definição
Segundo o Rational Unified Process (RUP):
É uma condição ou uma capacidade que deve ser atendida pelo sistema.
Definição do IEEE (Institute of Electrical and Electronics Engineers):
É uma condição ou capacidade que deve ser atendida pelo software, necessária a
um usuário para solucionar um problema ou atender a um objetivo.
O conjunto de todos os requisitos formam a base para posterior desenvolvimento
do sistema ou componente do sistema.
SWEBOK (Software Engineer Body Of Knowledge)
Expressa necessidades e restrições ao produto de software que contribui para a
solução de problemas no domínio do negócio.

6. Engenharia de Requisitos
É um 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.
O processo de engenharia de requisitos é composto por quatro
atividades de alto nível :
• identificação;
• análise e negociação;
• especificação e documentação;
• validação.

7. Engenharia de Requisitos

8. Engenharia de Requisitos

9. Engenharia de Requisitos
Este processo deve ser precedido de 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.

10. Engenharia de Requisitos
• Uma forma de avaliar a viabilidade de um projeto é obter, através da
interação com "as partes interessadas" (ou stakeholder em inglês) do
projeto (em reuniões ou entrevistas, por exemplo), a resposta às
seguintes questões:
• Será que o sistema contribui para os objetivos da organização?
• Dadas as restrições tecnológicas, organizacionais 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?

11. Engenharia de Requisitos - identificação
• Algumas das atividades envolvidas nesta fase incluem:
• 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.
• 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.

12. Engenharia de Requisitos - identificação
Algumas dificuldades típicas estão associadas:
• O cliente pode não saber exatamente o que deseja para o sistema, ou
sabê-lo mas não conseguir articulá-lo (o que é bastante comum).
• Os requisitos identificados podem não ser realistas (do ponto de vista
econômico ou tecnológico, por exemplo).
• Cada parte interessada pode expressar os mesmos requisitos de
formas diferentes, sendo necessário - através de um bom
conhecimento do domínio - identificar estas situações.

13. Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Entrevistas e Questionários
• É a técnica mais simples de utilizar. Está condicionada a alguns fatores:
• Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê
margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida.
• Relação pessoal entre os intervenientes na entrevista.
• Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a
ser afetado pela introdução de um sistema na organização, este pode
propositadamente dificultar o acesso à informação.
• Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é
natural que haja tendência para que os intervenientes se dispersem um pouco,
levando a que a entrevista demore mais tempo do que seria suposto. Caso a
entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer
despachar" sendo os últimos pontos da entrevista abordados de forma superficial
(ou podem nem chegar a ser abordados).

14. Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Workshops de requisitos
• Consiste numa técnica usada através de uma reunião estruturada, da qual
devem fazer parte um grupo de analistas e um grupo representando o
cliente , para então obter um conjunto de requisitos bem definidos.
• Ao contrário das reuniões, promove-se a interação entre todos os elementos
presentes no workshop fomentando momentos de descontração como forma
de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel
é conduzir o workshop e promover a discussão entre os vários intervenientes.
• As tomadas de decisão devem seguir processos bem definidos e devem
resultar de um processo de negociação, mediado pelo facilitador. Uma técnica
que é também útil em workshops é o uso de brainstorming como forma de
gerar um elevado número de ideias numa pequena quantidade de tempo.
• Como resultado dos workshops deve ser produzida documentação que reflita
os requisitos e decisões tomadas sobre o sistema a implementar.

15. Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Cenários
• Uma forma de levar as pessoas a imaginarem o comportamento de um
sistema. Através de exemplos práticos descritivos do comportamento de
um sistema, os seus usuários podem comentar acerca do seu
comportamento e da interação que esperam ter com ele. Trata-se de
uma abordagem informal, prática e aplicável a qualquer tipo de sistema.
De um modo geral, os cenários devem incluir os seguintes elementos:
• estado do sistema no início do cenário;
• sequência de eventos esperada (na ausência de erros) no cenário;
• listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de
como estes erros serão tratados;
• outras atividades que podem ser executadas ao mesmo tempo que as deste
cenário;
• estado do sistema depois de o cenário terminar.

16. Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Prototipagem
• Versão inicial do sistema, baseada em requisitos ainda pouco definidos,
mas que pode ajudar a encontrar desde cedo falhas que através da
comunicação verbal não são tão facilmente identificáveis.
• São desenvolvidas apenas algumas funcionalidades sendo normalmente
desenvolvidas primeiro aquelas que são mais fáceis de compreender
por parte do utilizador e que lhe podem trazer maior valor
acrescentado.
• O uso de protótipos deve ser considerado apenas mediante uma análise
custo-benefício, já que os custos de desenvolvimento de um protótipo
podem facilmente crescer, sendo particularmente úteis em situações
em que a interface com os usuários é, para eles, um aspecto crítico.

17. Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Estudo etnográfico
• Análise de componente social das tarefas desempenhadas numa dada
organização.
• Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é
de se esperar que esta sinta dificuldade em articular todos os passos que
segue ou todas as pessoas com as quais interage para as levar a cabo.
• Através de uma observação direta das atividades realizadas durante um
período de trabalho de um funcionário é possível encontrar requisitos que
não seriam observáveis usando técnicas convencionais.
• Esta observação pode ser acompanhada de registros áudio/vídeo, porém não
convém usá-los em demasia visto que o tempo necessário para os processar
pode ser demasiado. Nesta técnica assume-se que o representante do cliente
observado desempenha as suas funções "corretamente", pelo que convém
ter algum cuidado na escolha do mesmo.

18. Engenharia de Requisitos – análise e negociação
Após a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação.
Algumas das atividades envolvidas na análise de requisitos incluem:
• 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;
• priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo
elevada/média/baixa); este pode ser um fator gerador de conflitos;
• confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e
validade.
A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio
do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do
sistema a cada ciclo de trabalho.

19. Engenharia de Requisitos – análise e negociação
Na fase de negociação, tornam-se necessários alguns cuidados para que
esta decorra sem problemas, chegando-se logo a consensos. Algumas
sugestões são:
• 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;
• 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.

20. Engenharia de Requisitos – especificação e
documentação
É nesta fase que se dá a produção propriamente dita do Documento de
Especificação de Requisitos.
Em todos os tipos de especificação há 2 tipos de requisitos a considerar:
• Requisitos funcionais: descrevem as funcionalidades que se espera que o
sistema disponibilize, de uma forma completa e consistente. É aquilo que
o usuário espera que o sistema ofereça, atendendo aos propósitos para
qual o sistema será desenvolvido.
• Requisitos não-funcionais (de qualidade): referem-se a aspectos não-
funcionais do sistema, como restrições e propriedades nas quais o
sistema deve operar ou propriedades emergentes do sistema. São a forma
como os requisitos funcionais devem ser alcançados.

21. Engenharia de Requisitos – especificação e
documentação
Exemplo de requisitos funcionais:

22. Engenharia de Requisitos – especificação e
documentação
EXERCÍCIO:

23. Engenharia de Requisitos – especificação e
documentação
Requisitos Não funcionais
• Demonstram qualidade acerca dos serviços ou funções disponibilizadas
pelo sistema. Ex.: tempo, o processo de desenvolvimento, padrões, etc.
• Surgem conforme a necessidade dos usuários, em razão de orçamento e
outros fatores.
• Podem estar relacionados à confiabilidade, tempo de resposta e espaço
nas mídias de armazenamento disponíveis.
• Caso ocorra falha do não atendimento a um requisito não funcional,
poderá tornar todo o sistema ineficaz. Ex.: requisito confiabilidade em um
sistema de controle de voos.

24. Engenharia de Requisitos – especificação e
documentação
Classificação dos Requisitos Não Funcionais
• Requisitos de produtos : Requisitos que especificam o comportamento do produto.Ex. portabilidade;
tempo na execução; confiabilidade,mobilidade, etc.
• Requisitos da organização: Requisitos decorrentes de políticas e procedimentos corporativos. Ex.
padrões, infra-estrutura,etc.
• Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de
desenvolvimento. Ex. requisitos de interoperabilidade, legislação,localização geográfica etc.
• Requisitos de facilidade de uso. Ex.: usuários deverão operar o sistema após um determinado tempo de
treinamento.
• Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado tempo.
• Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, p.exemplo, 99% do tempo.

25. Engenharia de Requisitos – especificação e
documentação
Classificação dos Requisitos Não Funcionais
• Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma.
• Requisitos de entrega.Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira.
• Requisitos de implementação.: Ex.: o sistema deverá ser desenvolvido na linguagem Java.
• Requisitos de padrões.: Ex. uso de programação orientada a objeto sob a plataforma A.
• Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar com o SQL Server.
• Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo.
• Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc.
• Requisitos de Integração. Ex.: o sistema integra com outra aplicação.

26. Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio
Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e
não de necessidades específicas dos usuários, podendo depois ser classificados como funcionais ou não-
funcionais.
Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas.
Dois exemplos de requisitos do domínio são:
• O calculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3)/5;
• Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas
consideradas pré-requisitos.

27. Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio - Exemplos

28. Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio - Exercício

29. Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio – Respostas