O documento discute os processos de engenharia de requisitos, incluindo a análise e negociação de requisitos, classificação de requisitos funcionais e não funcionais, e especificação e documentação de requisitos em diferentes níveis de detalhe.

1. Análise de Sistemas
Orientada a Objetos
Aula 02 – Requisitos

2. 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.

3. Engenharia de Requisitos – análise e negociação
As dificuldades encontradas na análise são de diversas naturezas:
• fatores externos (políticos) podem influenciar os requisitos (alguma parte
interessada, com poder de decisão, pode exigir requisitos específicos que
sirvam aos seus interesses e não aos da organização, ou forçar o seu
ponto de vista em detrimento dos demais interessados que irão operar o
sistema);
• o ambiente (econômico e/ou organizacional) em que a análise é feita
possui fatores dinâmicos, e como tal, os requisitos estão sujeitos a
alterações em decorrência destes (por exemplo: novas partes
interessadas são envolvidas no projeto, ou alterações em prazos e
orçamentos disponíveis).

4. 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.

5. 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ãofuncionais 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.

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

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

8. 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.

9. 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.

10. 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.

11. 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ãofuncionais.
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.

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

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

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

15. Engenharia de Requisitos – especificação e
documentação
A documentação produzida poderá ter diferentes destinatários e como tal
diferentes objetivos. Podem-se distinguir três tipos de especificação:
• especificação de requisitos do usuário;
• especificação de requisitos do sistema;
• especificação do design da aplicação
A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se
comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando
"linguagens" que o usuário conheça).
Por exemplo, enquanto que nos requisitos do usuário apenas é feita uma abordagem de alto nível das
funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas (esquemas).
Nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos relativos à
arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas de casos
de uso).

16. Engenharia de Requisitos – especificação e
documentação
Os requisitos do usuário destinam-se portanto aos vários níveis
hierárquicos da organização na qual o sistema será implementado (desde
gestores a usuários), pelo que são descritos usando apenas linguagem
natural, formulários e diagramas muito simples. Obviamente, neste nível de
especificação surgem algumas dificuldades:
• Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem
tornar a sua descrição muito longa ou de difícil compreensão.
• Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a
distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se
difícil.
• Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode
tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos
sejam expressos como sendo apenas um.

17. Engenharia de Requisitos – especificação e
documentação
• Algumas considerações úteis a ter em conta ao escrever uma
especificação de requisitos do utilizador:
• Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a
verificação dos requisitos).
• Distinguir claramente entre comportamentos esperados e desejáveis do sistema
através do uso de expressões como "O sistema permitirá criar (...)" ou "Deverá ser
possível criar (...)" respectivamente. É importante deixar claro o que o sistema
tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de
expressões de forma consistente ao longo de todo o documento.
• Usar formatação de texto para salientar determinados aspectos do documento
(usando negrito, por exemplo).
• Evitar usar termos demasiado técnicos ou fora do âmbito do sistema,
identificando-os e definindo-os de uma forma clara quando for absolutamente
necessário usá-los.

18. Engenharia de Requisitos – especificação e
documentação
Requisitos do sistema
• Os requisitos do sistema têm um carácter mais técnico;
• Descrição detalhada dos requisitos do usuário.
• Uso de linguagens estruturadas e notações gráficas.
• Estes requisitos, destinam-se ainda aos usuários do sistema (e
particularmente aos engenheiros que trabalhem nessa organização) e
destinam-se também às equipes de especificação de arquitetura do
sistema e de desenvolvimento.

19. Engenharia de Requisitos – especificação e
documentação
Design da aplicação
• A especificação do design da aplicação consiste num documento usado
pela equipe de desenvolvimento do sistema no qual estão definidos
pormenores, em um nível mais técnico, acerca da implementação do
sistema e sua arquitetura.
• A partir deste documento, um elemento que entre para a equipe de
desenvolvimento no meio do projeto deverá ser capaz de "se situar"
quando precisar de começar a codificar, compreendendo a forma como a
implementação, em um nível global, está a ser feita, mas sem conhecer
necessariamente os detalhes de implementação aprofundados.